[Pre-RFC] Lang-Level License Management

It occurs to me that LicenseId probably shouldn't be an enum. If we defined it as follows:

pub struct LicenseId {
    pub identifier: &'static str,
    pub copyright_holder: &'static [CopyrightHolder],
}

The common name field is there, and the case where there are no listed copyright holders is handled by an empty copyright holder array.

This struct replaces the pub name: &'static str field in the License struct, not the License struct as a whole.

1 Like

Got it! I like it! :+1:

Don't try to parse the copyright notice years and copyright holders. You need to reproduce the copyright notice verbatim, so just save it as a complete string (including the "Copyright" or "(c)" or "©").

(As an example of complexity, consider the string "Copyright (c) 1999, 2005-2013 Some Person <some.person@example.org>\nCopyright © 2018- Other Person and other contributors of the Foo Revival project".)

1 Like

@josh made me think of an addition to CopyrightHolder:

pub struct CopyrightHolder {
    pub year: &'static [i32],
    pub name: &'static str,
    pub email: &'static str
}

That way we can contact someone in case we need to. Or maybe that should be wrapped in an Option?

That's good to know, thanks.

Anyhow, at this point I think I've got enough information to make a meaningfully better second draft of this RFC. I'll try to make a second thread for that Soon™.

Not bothering to parse the copyright holder seems easier to me.

1 Like

Fair enough. If you capture the complete copyright info in a string, other tooling can be built to parse it out anyways.

Link to it from this thread, I'm very interested to see your progress on this!

1 Like

I understand that this tread is about the proposed feature and not about the licenses themselves. So I'll try and be brief and you're of course free to ignore this if you like. However, I still hope my perspective can be interesting, especially if people starts building infrastructure for dealing with licenses into the language itself.

When I read about licenses and attribution requirements around the web, there seems to be a cargo-cult with people arguing "give credit where credit's due" and "it's the right thing to do". While I love the feel-good ideas behind that, I question if the MIT license actually requires it. Since the MIT license is widely used in the Rust ecosystem, I think this should be considered.

Do people still remember the original 4-clause BSD license which its dreaded advertisement clause? The problematic clause said:

All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the organization.

My understanding is that it was highly problematic because it meant that programs had to display larger and larger amounts of attributions in their manuals.

The BSD license was updated in 1999 to take away this clause and people were happy since they could again ship (proprietary) programs containing BSD licensed code without having to deal with page after page of attributions.

It's been 20 years — have we somehow managed to back ourselves into the same corner again?

For comparison, the 3-clause BSD license says

  1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

  2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

but the MIT license simply says

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

I read this is a more lax version of what the BSD license requires and I always thought that it simply means that I must keep the existing copyright notices intact (in the source code).

To my eyes, the MIT license doesn't say that I must add an "About box" to my program where I show the notice. Simply having the notice in the source files seems to be enough. If the compiler doesn't preserve the notice in the resulting binary, well then that's fine according to the license.

As an example of a license that isn't fine with having the compiler swallow the attributions, see the Apache 2.0 license. It has a section specifically about this, spelling out that you must show attribution notices from a NOTICE file, if one is present. It gives examples of where you can display the notices to satisfy this requirement:

within a display generated by the Derivative Works, if and wherever such third-party notices normally appear

I would encourage people to use that license (exclusively) if that's the effect they really want.


Regardless of the above, having robust infrastructure for this is helpful for licenses that unambiguously require attributions. So thanks for reading and have fun building this :slight_smile:

3 Likes

More prior art: Debian has a specification for machine-readable copyright files for their packaging metadata. Several tools exist to scan a source tree for copyright boilerplate and produce a summary, e.g. licensecheck, scancode-toolkit.

4 Likes

mgeisler, with all due respect, if you're not a licensed lawyer then I'm going to trust the licensed lawyers instead.

2 Likes

Yeah, that makes perfect sense! I mostly wanted to raise the point, since attribution seemed like an implicit assumption until @HeroicKatora chimed in above. So at least two people here believed that attribution isn't required always required in binaries.

The same sentiment is echoed in an old text on the LLVM Developer Policy page, which says at the bottom:

In addition to the UIUC license, the runtime library components of LLVM ( compiler_rt, libc++, and libclc ) are also licensed under the MIT License, which does not contain the binary redistribution clause. As a user of these runtime libraries, it means that you can choose to use the code under either license (and thus don’t need the binary redistribution clause)

This is an example of a major project that interpreted the MIT license to not require attribution in binary redistribution. LLVM is moving to an Apache 2.0 license, with exceptions allowing you to skip attribution.

I don't know if their interpretation of the MIT license changed over time, it might very well have as the rest of the open source community settled on the meaning they MIT does require attribution in binaries.

1 Like

Interesting that you should mention that developer page, because in the thread that I linked to (link again) it was (apparently) the very lawyer who wrote that statement, saying that they messed it up, but it's still there.

It is not accurate, legally, in its description of the MIT license. Effectively, by this statement, we are giving permission to not reproduce the notice, even though the license would actually require it.

Ah, great, I had not read your link again after noticing the LLVM page today. Thanks for pointing me to it again.

I'll be sure to include attribution if I ever find myself distributing binaries with MIT licensed code.

1 Like

ping! Just wanted to see how the RFC is going.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.