Automatic MIT licensing

[p-zubieta]

It seems that currently BB automatically assigns a MIT licenses to jll packages.

It may be wise to avoid this or to give the user the option to at least opt-in if it is known that the jll package will be MIT compatible.

[staticfloat]

So the MIT license bundled with the JLL packages is supposed to apply to the actual JLL code itself, since it comes from an MIT-licensed program (BinaryBuilder.jl).

After discussing this with our resident licensing expert, I think we're going to take the following steps:

• Relicense the auto-generated wrapper code under CC0 (essentially putting it out there as public domain).

• Alter the autogenerated LICENSE.md to make it explicit that the CC0 applies only to the Julia source code within src/, and that the JLL package will download artifacts that may contain their own licenses. Each JLL should be shipping with a license within it located in share/licenses/${src_name}.

• Extract metadata about the build and store it in plain format within the JLL package itself. For the purposes of this issue, I'm thinking just the licenses and source locations are important, but I'm opening another issue to track other things we might want to store: Store more metadata in JLL packages/tarballs #639

[p-zubieta]

OK. I like the idea. That way it would be much clearer what is going on. And sourcing licenses and URLs seems enough to avoid issues with GPL licenses (which was my main concern).

[stevengj]

Relicense the auto-generated wrapper code under CC0 (essentially putting it out there as public domain).

Have you read CC0? It's way more complicated than the MIT license: https://creativecommons.org/publicdomain/zero/1.0/legalcode

Much easier to just use the MIT license, which has essentially the same effect as being in the public domain and is compatible with all other licenses.

[p-zubieta]

That is a good point. I still think the other two points proposed by Elliot are worth implementing.

[StefanKarpinski]

May I suggest the ISC license? It’s similar to MIT but without and advertising or attribution clauses, which is very minimal.

[stevengj]

(The MIT license has no advertising clause—you're thinking of 4-clause BSD.) ISC seems fine, but I would stick with the functionally equivalent MIT license simply because that's so widely used in the Julia package ecosystem, and license proliferation is confusing.

[StefanKarpinski]

I was thinking of the original BSD license / the MIT X11 license. Sticking with MIT seems fine. Could also dual license under MIT or CC0—that way it's MIT if that's convenient or public domain if that's more convenient.

[stevengj]

CC0 is hugely complicated because there is no uniform way to put things in "public domain". It's not clear what problem that solves here compared to the MIT license (aka "expat license").

[StefanKarpinski]

Dual licensing means that either one can be used, so any complexity of CC0 can be ignored if one prefers. I think the idea behind CC0 is to try to minimize the potential conflict that there could be with any usage of the code. For example, MIT technically requires keeping the copyright notice with the copyright holder's name, whereas CC0 means you can just take the code and use it anywhere and not bother with any license file at all.

[stevengj]

I know what dual licensing means, but I doubt the utility of including a complicated CC0 statement and then telling people to ignore it — the mere fact of including it is still a complication. Nor do I think it's a good idea to encourage people to re-use code without propagating a clear statement of the code's origins and copyright status.