I do not think that this really can be read as “well settled”:
It’s really not dependent upon interaction of code. It’s all about copyright and your ability to do something that would otherwise be a copyright violation. Which is why the part you quoted contains the word “distribute” 3 times in those two sentences — that’s otherwise a copyright violation. Similarly, the second link you just posted is all about “when it is distributed,” where “it” is a combination of GPL and non-GPL code.
If you’re not personally copying or transmitting or relaying or distributing the GPL code in the first place, you’re not doing anything problematic! Others can gather the GPL’ed packages directly from the original author, who is granting them the ability to download and use it!
Now, once you do start distributing GPL code directly, that’s when you need to be very careful about how you do so. But you’re not bound by license terms of something you’re not copying or distributing. That’s why SBOMs are important: when you’re redistributing something, you want to know exactly what you are shipping and that you have the right to do so.
Specifically, the GPL v2 starts with:
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program).
Let’s start with the agreement: Using open source code is not covered and always possible to my knowledge as well. So that is totally likely uncritical.
# SPDX-License-Identifier: MIT
module MyPackage
using GPL_Backend
GPL_Backend.foo(x)
end
No issues here imo.
Where we currently still disagree is the multiple-dispatch example that extends GPL_Backend in its namespace and I would believe that the question whether something like that is to be considered distribution of a combined derivative work is not settled.
I acknowledge the importance of SBOM tooling. But they cannot make risky legal judgements and they can ultimately not grant permissions. If there are three source files in your package that have MIT, EUPL-1.2, and MPL-2,0 then that is where SBOM tooling has to stop. At most they can do MIT AND EUPL-1.2 AND MPL-2.0.
It is you then as copyright holder of the work that you distribute as a package, who can say: my package has the package-level license MPL-2.0.
OK, I see, there are a few things mixed together here. This very old topic that you resurrected is all about using separate packages/binaries with differing licenses, and that’s the context in which I’ve written all my posts thus far. And it’s there that we seem to have agreement!
If you have a single package with multiple files, each of which is licensed differently, that is a very different case. And it’s indeed harder, but that’s a very separate topic (more in-line with our earlier REUSE discussions). Let’s punt on that discussion in this topic. SBOMs don’t want to look file-by-file, they are collections of packages and — when they include licensing information — they trust the reported licenses from each package.
So then, the question is if this is valid:
# GPL_interaction.jl
# SPDX-License-Identifier: MIT
import GPL_Backend
GPL_Backend.foo(x::MyType) = ...
My answer would be: yes, but with one large caveat: it’s often hard to write this implementation of foo without looking at (and copying/modifying!) the implementation in GPL_Backend. That’ll be plagiarism to redistribute unless you license those modifications as GPL. So, yeah, here I’d agree it’s best practice and best hygiene to just use the same license as your dependency if you’re going to be doing significant reading/copying from GPL_Backend in writing your code. But that’s really not happening in the context of this topic; it’s not relevant at all to non-Julia binaries. In fact, I’d say it shows the value in having JLL wrapper code be MIT-licensed, because then I can easily do exactly this sort of modification (and, e.g., add additional bindings to the binary) under the MIT License, even if the binary itself is GPL.
Finally, I want to be very clear that there’s a two-step process here that I’ve been implicitly keeping in my own mind:
- Am I as a package author bound by the GPL licensing terms? If I don’t copy/modify/redistribute/provide/plagiarize GPL-licensed copyrighted materials myself, then the answer is no! Downstream users can fetch GPL components on their own, and it doesn’t impact me at all. Of course it’s not useful (and a pretty big bug) if my license is incompatible with the GPL, but it’s not a legal issue for me. It’s not unlike arcade simulators, despite the best efforts of Atari, Sony, et al. This part is generally not tricky, and there’s nothing special about the GPL at all — it’s just about knowing what copyrighted materials you’re distributing in the first place. This part doesn’t require complicated legal analyses or a lawyer to parse.
- If I am bound by the GPL due to some portion of my work, how does that impact my otherly licensed components? That’s where the things get tricky and very license-specific… and where I’d throw IANAL and case-law caveats around.
Thanks for the longer clarification now and I see we are getting much closer to a joint understanding.
As far as I understand the wrapper case and the arcade simulator case, I agree that in such cases it’s not your problem as you are not distributing the code. Instead you just call code your users have to provide “at arm’s length” as they say.
In fact, that’s what I currently do in ReuseLicensing.jl, which runs reuse lint via a shell call and users have to install that GPL-licensed Python tool themselves.
SBOM tools treat packages as if they are “encapsulated wholes” with a package-level license for that scope, e.g.,
Package A: MIT
Package B: MPL-2.0
Package C: GPL-3-only
I just find that the package-level license declaration should be an unambiguous and helpful statement made by the copyright holder of the package that’s being distributed. Because unlike a SBOM they can “prune” the license dependency tree where legally possible knowing what it is they are doing with external dependencies, as a strong dependency may indeed just be a normal use/call like GPL_Backend.foo(x).
I am not yet sure whether I would only worry about plagiarism/copying from GPL_Backend. Simply adding a method to a GPL package’s generic function might be seen as an extension/adaptation of that package’s code and not just as an ordinary call.
The key thing to remember that the “teeth” behind any open source license is a copyright infringement. If you’re not violating anyone’s copyright in the first place, then you need not worry about the terms that would give you license to do so legally!
So could adding a method be seen as a copyright infringement? I can’t imagine so. Famously (in the US), complete reimplementations of an API are definitively fair use. Method extension seems just as fair use and even more creative/transformative, but your legal sensitivities may vary. I still find the whole thing rather moot, because I’ve almost never done significant method extensions without “plagiarizing” the original implementations or examples; ensuring a “clean room implementation” is hard and it’s so much easier to just attribute and license appropriately… especially when so many Julia packages are similarly licensed in the first place.