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?
1 Like
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.
5 Likes
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).
3 Likes
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)?
2 Likes
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.
2 Likes
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.
1 Like
My point was GPL is more restrictive, not less.
1 Like
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.
1 Like
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.
1 Like
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…
1 Like
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!
2 Likes