The whole licensing thing is quite gnarly but important, it also affects other packages. For example, Trixi.jl has dependencies that are GPL (not LGPL, p4est and t8code), but claims MIT for itself – how does that work? 
Is it OK to use that in your own MIT-licensed packages as long as you don’t run it through PackageCompiler, or what?
Both t8code and p4est are licensed under GPLv2:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
For p4est we provide a binary package P4est_jll:
There we package the license in the tarball and provide a link to the source code and any patches we apply, complying with the license.
For Julia packages, we typically provide the Julia source code and not compiled binaries. The Julia source code itself is not a modification of the GPLv2 licensed code and thus not constitute a combined work. The Julia source code can be separated from the GPLv2 work and thus the GPL terms do not apply to the Julia code.
When you install the package, binary code in the form of pkgimages or perhaps even a system image are created, linking the GPL v2 code. Those binaries may now be subject to the GPLv2 terms should you distribute them.
Disclaimer: I am not a lawyer. You should seek professional legal advice in the appropriate legal jurisdiction.
GNU Project’s FAQ says:
However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.
The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can’t treat them as two separate programs. So the GPL has to cover the whole thing.
If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly. The issue is simply one of form: how you describe what you are doing.
which makes it sound somewhat of a subjective decision whether the programs are “at arms length”.
It doesn’t really say anything about it needing to be compiled together though, so it sounds like at least P4est.jl should be GPL licensed (or GPL-compatibly licensed) .
There are three completely separate facets to this that are helpful to detangle:
- There are the terms under which authors decide to license code they write. Everything you write has a copyright, whether you want it or not. Licenses provide the bounds by which folks can use your work without copyright infringement. Novel code that calls into to particular library can and often does have different terms than the library it calls.
- There are the terms under which a wholistic work is distributed. If that piece of work has many constituent parts, its licensing must satisfy all the licensing of all the parts. Generally that means the whole is distributed under the “most restrictive” terms of its parts, but there exist licenses that are incompatible with eachother. Notably, the MIT license happily satisfies the requirements of the GPL, whereas proprietary (non-licensed) code does not.
- Then there’s the question of what makes a “wholistic work” that gets at that “arms-length” question, but this is purely in the context of what the terms of distribution are (see point 2).
This argument of the source of a wrapper/dependent being independent (and thus ok to license differently) , and only the act of installing or packaging puts the whole under the GPL is something I hadn’t considered, so thank you for that!
It doesn’t make reasoning about this easier, though – “sure p4est_jll is MIT as long as you only fork the repo, but as soon as you say ‘using p4est_jll’ it becomes GPL” does not feel that intuitive at first glance 
(makes sense though).
I feel like a license scanner/tracker/enumerator could be quite useful at least for packagecompiler. After all, it’s hard to determine which licenses are contained in the dozens of dependencies in your manifest. For this to be “easily” accomplishable, wrappers like p4est_jll would have to indicate in their package metadata under what license their wrappee(is that a word?) is included. Otherwise, how should Pkg or whatever tool know about that?
Edit: actually, such a took would be useful beyond packagecompiler. It seems like Trixi.jl is effectively GPL as soon as you install it, and it’s quite hard to find out about the most restrictive license as it is now, with transitive dependecies like that. I guess in the sciml or diffeq ecosystems, the situation must be similar (where it does not yet use pure-julia solvers)?
P4est.jl does not depend on GPL code directly though. It depends on P4est_jll.jl which could be configured to be to point at a clean room implementation of p4est licensed under a MIT license should someone make one.
What is undoubtedly covered by the GPL are the the binaries artifacts shipped by a P4est_jll.jl release. This is stated in the P4est_jll.jl LICENSE.
P4est_jll.jl uses a GPL-compatible license, the MIT “Expat” License.
That’s not quite accurate. The original licensing of a given chunk of code doesn’t change, regardless of how it is distributed (or what it’s distributed with). What might happen is that someone may distribute it alongside some other code that has additional, more stringent terms to which the whole thing must satisfy… and it’s under those more stringent terms that the combined work is provided.
In the case of the GPL, MIT-licensed code satisfies the terms of the GPL: it is GPL-compatible. Proprietary (non-open source) code does not satisfy the terms of the GPL: it cannot be distributed together unless its source is released under the terms of the GPL or a GPL-compatible license. That’s the “viral nature” of the GPL: it doesn’t reach in and change licenses, but the entire work must comply with its terms.
That does not sound quite right: One could say that one can combine MIT-licensed code with GPL’ed code, as long as the result is licensed under the GPL. I think that is about it.
I’m not a lawyer. None of this is legal advice.
My point is that it doesn’t really matter to the original permissively licensed code if someone — not necessarily the original author — needs to redistribute it under a more restrictive license. It’s already permissively licensed! And everyone has access to that permissive license if they should so desire.
That permissive license doesn’t change because it’s been redistributed in a different way.
My point was GPL is more restrictive, not less.
Yes, exactly. Conversely, you could say that licenses that are more restrictive than the GPL do not satisfy its terms and thus cannot be distributed together.
Thanks for putting this under more precise terms, I should have been more careful/deliberate.
What I (also) meant to express is that one has to take care with the fact that while a package (in this case the p4est_jll wrapper) displays MIT at the front, which might suggest a permissive license, anything you use/combine—e.g. by installation/(pre)compilation—it with has to comply with the GPL, viral as you say.
This is not a concern if everything stays on your computer, but if you distribute e.g. a compiled version, that’s something to watch out for.
In my case, I previously had the idea in my head to investigate if Julia/Trixi could be an alternative to a Fortran code for a simualtion tool at work. The realisation that it has GPL dependencies certainly put a damper on that, as ensuring license compliance is now much harder.
Julia 1.10 will be GPL free… But a number of packages not…
I am not sure of this. The whole point of the GPL licence is to restrict what you can restrict…
The core idea behind licenses — and the reason that’s the name we use — is that they grant you permissions. In order to get those permissions, you must satisfy their terms (or restrictions).
The MIT license is very short and readable and I encourage everyone to read it at some point. Its first paragraph is granting you permissions that are conditional on two terms: you must include the copyright notice and you PROMISE NOT TO SUE all shouty-like.
The GPL license is not as readable, but it also grants you conditional permissions to use the code. There are many more conditions, and the “scary” one is that you must be able to (re)distribute all the constituent pieces of a thing you made under the terms of the GPL if it includes some GPL’d code. But that’s only scary if the other code isn’t already open source!
Now, yes, if you added proprietary code to the MIT-licensed component that you didn’t upstream and contribute back under the MIT license, then those changes are required to be released under the terms of the GPL. They could also be released in other licenses, too, but at least it needs to be GPL. And, yes, you need to be careful about preserving the license of code you copy and work on — you can’t plagiarize any code without permission. But you can’t unilaterally add restrictions to code that’s already legally available to use without them!
While I agree a lot with what you say here, I find that statement too reassuring.
Sure, copyright holders, who use GPL or MIT licenses share a common interest: they want to grant you the rights to use, modify, inspect or distribute their code. But there certainly is a reason, why someone has chosen a strong copyleft license (e.g., GPL) and not a permissive license (e.g., MIT). Certainly, a lot of copyright holders have not chosen a GPL license, because they really don’t care about your reuse and redistribution with an MIT label on the outside.
Whatever we do licensing-wise, has some repercussions and these, unfortunately, are not certain (e.g., there is uncertainty with regard to the effects of our licensing decisions).
In my world-view, the technical and the legal reality of our code lives in a simplified continuum:
Technical world:
- invalid everywhere
- invalid on some systems
- risky on some systems
- valid everywhere
Legal or licensing world:
- clearly non-compliant everywhere
- non-compliant in some jurisdictions
- legally risky
- clearly legitimate everywhere
While possibly even the technical world is nebulous these days, the legal world most definitely is and one probably seldom is in the safe region 4. While making invalid or risky things in the technical world can cause expensive damage, the risk in the legal world seems higher to me. For example, not many people will say “I am not a computer scientist” before advising you to do something, but everyone writes “I am not a lawyer” for fear of becoming subject to litigation.
While I agree that it may be possible to write MIT-licensed source files that call, import, or extend GPL-covered packages and that there may be cases where a package-level MIT license is defensible, one needs to note that there is a risk in doing so.
Without making Interoperable Europe the sole licensing truth, it is worth looking at the asymmetry in using MIT (outbound) with GPL (inbound) versus the other way around. The MIT (outbound) case carries more warnings and conditions.
The GPLv2, for example, states that when sections of the new work:
are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
As far as I know, how this holds up in courts is a completely different matter, but we may likely agree, that simply putting an MIT license on code that “imports and extends” GPL code is probably naive and potentially risky.
The risk may be unevenly distributed: The consumers of the MIT licensed package may be led to believe that they may distribute their code, which combines with your package’s code under the MIT license as well — after all, that’s why it was invented.
Sure, we may then shift the burden to the consumer of our package because they have not done their fair amount of “due license diligence.” But I believe that that is unfair, because nobody is better placed than a package author to recognize “how closely the different code sources interact.”
I believe that it should be good hygiene to a) at least clearly warn about the GPL dependency or b) to be conservative and err on the less risky side by distributing your package under GPL as well.
I would propose to think about this organization of our source code:
# MyPackage.jl
# SPDX-License-Identifier: MIT
module MyPackage
...
include("GPL_interaction.jl")
...
end # MyPackage
# GPL_interaction.jl
# SPDX-License-Identifier: GPL-3.0-only
import GPL_Backend
GPL_Backend.foo(x::MyType) = ...
And then distribute the package with an outbound GPL-3.0-only license. This way, we are conservative in acknowledging the GPL-dependency and in making it explicit in the package license. At the same time, we are making it easy (in principle) to replace the relevant dependency with a more permissive one.
I would see this as better hygiene.
But packages are independent, separate, and distributed a la carte. Yes, of course it’s not okay for a package to claim outbound MIT licensing if it directly contains/vendors/ships GPL-licensed portions — that’s the context for your interoperable Europe page. But using a separate GPL-licensed library/package/binary is quite well-settled — that’s just fine.
To be concrete, this isn’t unique to the Julia ecosystem and it’s not uncommon — not by a long stretch. Just as one example, take a look at lua. It’s a very straightforward MIT license, both in its source repository and (e.g.) Debian’s package for it. And yet it depends upon libreadline8, a GPL-3+ project. This is just fine! It doesn’t make Lua’s “outbound” license GPL, and it doesn’t mean that Lua (or package managers that distribute it) should flag it as GPL.
What it does mean, though, is that folks that themselves redistribute libreadline, lua, and anything else need to be aware of exactly what they’re redistributing. That’s also a solved problem in other ecosystems — it’s an SBOM! Our SBOMs don’t (yet!) include licensing information, but that’s the way to address this.
None of this is legally shaky, naive, risky, or bad hygiene.
I beg to differ here. It reads as if any Julia package that imports, wraps, extends, or otherwise depends on a GPL package can be shipped as MIT as long as that package does not ship the other source code or its object code directly.
It depends upon the interaction of the code imho. There is no relicensing here of separate code portions – I have not said so. But I can’t see where your Lua example is similar to the multiple-dispatch extension I gave?
The critical part (that’s why I cited the GPLv2 text) is whether code can be considered separate and independent or whether it is more tightly entangled and should be considered a “combined whole.”
I also do not see where SBOM is able to reliably answer the question of license grants? Sure, it is extremely helpful evidence, but it is not a copyright holder. Simply listing a dependency does not answer the degree of separation/independence. It is more complicated than you make it sound in my view.