Theoretically, but it requires you to contort the codebase to maintain the licensing split (I expect spaghetti code is near-unavoidable) and makes it hard to fiddle much with central parts of the codebase.
It’s worth being precise here. You can’t relicense an EUPL-licensed project without being a rightsholder. What you can do is use the EUPL-licensed project in a larger work that is distributed under a compatible license. “License laundering” the EUPL project itself is not what the compatibility clause allows for.
If the Licensee Distributes or Communicates Derivative Works or copies thereof based upon both the Work and another work licensed under a Compatible Licence, this Distribution or Communication can be done
under the terms of this Compatible Licence.
So the terms allow the licensee (not the copyright holder) to license an entire combined “derivative work” under the different terms of one of the “Compatible Licenses” (which is a list including the MPL and the GPL and others).
This is also the understanding of the Free Software Foundation’s legal counsel (in their commentary on various licenses)
[…] it gives recipients ways to relicense the work under the terms of other selected licenses, and some of those—the Eclipse Public License and the Common Public License in particular—only provide a weaker copyleft. Thus, developers can’t rely on this license to provide a strong copyleft.
Sentence 3: “However, it gives recipients ways to relicense the work under the terms of other selected licenses,“ is misleading. “Relicensing” the original work is not permitted. What is permitted is to reuse the covered source code (= copy it and merge it) in another project licensed under a compatible license, and to continue the distribution of this other project under the compatible license. But this is not a global relicensing (= changing the license) of the original work “as is”.
My takeaway is that if you pluck the EUPL part out of a combined work, it’s still EUPL. Taking the MIT as an illustrative example of a minimal license, it specifically grants:
the rights to use, copy, modify, merge, publish, distribute, sublicense
Article 5 of the EUPL (the “compatibility clause”) says:
If the Licensee Distributes or Communicates Derivative Works or copies thereof based upon both the Work and another work licensed under a Compatible Licence, this Distribution or Communication can be done under the terms of this Compatible Licence.
The “compatible license” clause specifically covers distribution. To me this seems distinct from permitting anyone to relicense the original work via a larger combined work with a different license.
No, you cannot just relicense an existing work. This requires the consent of the original copyright holder, otherwise CLAs would not be a thing.
Think about it - if this were true, it would mean that all previous distributions of the old (identical) code were now also licensed under the new license. This is obviously nonsense, if the old code is & was available under the old license (as the license stipulates it must be!) then you can always go back to that old version and just get it from there.
The consent of the original copyright holder was already given in the EUPL itself, which says that you can redistribute the work (or something derived therefrom) under a different license (from a given list) as long as you combine it with something else.
That’s not what I’m saying.
Of course, you can still download the original files under the EUPL as long as they are being distributed somewhere. But this is no different from pretending that the MIT license is a copyleft because the original files are still available somewhere under the original terms, even if a new, modified version is distributed under different terms.
The new terms apply to the new version. Whether you want to call this “relicensing” or “changing the terms for the new version”, I don’t care.
Note that the FSF is not a disinterested party in this discussion; they have their own agenda, and when they provide “counsel” on other licenses that should be understood not to be impartial.
Which of the licenses in the appendix of EUPL do you think provides a “loophole” to relicense as proprietary?
Yes, that’s the case for the EUPL because it has this consent mechanism built in, but things like MIT do not - and hence the consent of the original author is required to change the license of a contribution from MIT to something else. I thought you were speaking generally here, not specifically
What I’m trying to say is that there is a material difference between these terms. You can’t “unpublish” open source the same way you can in principle deprive someone of access to a proprietary product. You can definitely renegotiate/renew a standard licensing agreement and colloquially refer to that as “relicensing”, even if the licensing terms are exactly the same (proprietary software licenses with expiration dates are common after all). In open source this is just not necessary to do, because there is no limit placed on the validity of the license, it’s usually given in perpetuity.
(barring technical means to scrub the code from the internet of course, but let’s assume we don’t have the means to do so)
While that’s technically true, it’s not really meaningful. You only need consent of the original author if the new licensing arrangement breaks MIT’s terms. And basically no other OSS license breaks the MIT’s terms.
So yes, if I wanted to strip your copyright notice from some code you wrote and licensed as MIT, I’d need your permission. But if I wanted to continue working on it (and accept contributions from others) under a different license that’s just fine as long as I can continue satisfying the terms of the MIT. It won’t take long for your contributions (which, yes, are still MIT licensed and still require your copyright notice!) to become inexorably intertwined with others’ copyrights that were contributed under the new terms.
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
This is not worded very precisely (what even constitutes a “substantial portion”?), so if you want to merge non-MIT code & MIT code in the same file (or even function), it suddenly becomes fiendishly difficult to make it clear which parts of the code are falling under the MIT license vs. whichever other license you’re trying to use. That’s where the “MIT public API that internally calls the proprietary API” comes from, because then this separation becomes easier to do, by having distinct files or modules or other such mechanisms.
The notice needs to stick around as long as the original code is still there And removing it in lieu of a different license (i.e. relicensing) requires consent of the original author. As a maintainer, this is a huge hassle, and trying to mix things and hoping it works out is not a safe strategy.
No one is talking about “unpublishing” anything, we’re talking about new versions.
Suppose you release a package Foo, and now I come along and release a fork Foo++ which, while derived from / incorporating the Foo sources, contains substantial new features and changes.
If Foo was under the MIT license, I don’t need to release the source code of Foo++ at all in any form. I can just distribute it as commercial binary-only proprietary software. Or I can release the source code of Foo++ under license terms such that all of the changes have additional restrictions, from MPL or GPL to something much more restrictive like non-commercial-use only. I still need to include your MIT copyright headers, but those headers don’t prevent me from appending additional conditions of my own in my modified files..
If Foo was under the MPL license, I can put as many of the new features and changes of Foo++ as I can into separate files, under any license terms I want, while the original Foo source files are released under the MPL but with modifications that make them call my new files.
If Foo was under the EUPL, I can add one file under the MPL and then distribute the combination under the MPL, which brings me back to scenario (2).
If Foo was under the GPL, it likely that the entire Foo++ source code, including all enhancements, needs to be released under the GPL. (There are still some potential loopholes and gray areas, but they are much narrower. The price of this is the complexity of the GPL and the difficulty of combining it with code under other licenses. And, of course, you may decide that you want to allow non-open-source forks/enhancements.)
Maybe, but they also have legal counsel and lots of experience with software licenses and enforcement thereof. So you may not agree with their recommendations on which licenses they like or dislike, but it seems foolish to dismiss out of hand their understanding of what the licenses do.
The MPL, for example, allows you to combine with proprietary code as long as it is in separate source-code files. See above.
That’s all only the case if you’re trying to preserve the MIT licensing of a project (or portion thereof). If you don’t care about that, you can plop the MIT license and copyright notice anywhere and use your own — more restrictive — terms for the overarching project. See, for example, all the proprietary software that includes some credits screen full of open source copyright notices and licenses.
Yes, I know What I’m saying is that in Open Source you practically can’t remove the old version that is still under the old license, even if it contains exactly the same code, because people make backups, do a source clone etc. etc.
Yes, all of this is correct. Your own modifications can be licensed under whichever terms you choose, including MIT.
Yep!
Sure, and you don’t even need to go to the MPL to do that, since the EUPL is not a viral license in the first place. You can keep the “old” code under EUPL and ship that as part of your proprietary software as much as you want.
This depends on your jurisdiction, and at least under EU law, it’s not necessarily the case that your entire thing has to be GPL’d. That is the perspective the FSF & a lot of american law takes, but it’s not necessarily true in the EU. See also:
I mean, yes, if you don’t preserve the MIT licensing notice you are in violation of the license.
No, the reason that proprietary software has credits screens is precisely because they need to preserve that notice, since they’re shipping (vendoring) something licensed with that license and the license of that thing requires them to display it. If they didn’t care about that, they wouldn’t ship the license, and then would get sued for it, just like the company in the German court case got sued.
No, #include of (declaration only) headers does not imply static linking. It is how you tell the compiler what is present in other compilation units. The headers are API definitions.
The consensus position among computer people is that APIs ought to not be subject to copyright (and therefore GPL).
Among lawyers, there is no consensus whether APIs are in fact copyrightable. Cf eg Google LLC v. Oracle America, Inc. - Wikipedia.
That being said, I think static linking unambiguously makes the combined work derivative of all its parts.
Dynamic linking is a can of worms. I think the consensus position is “it ought to and legally does depend on a lot of hard-to-verbalize contingent factors”, and there is no consensus on the exact boundaries and details.
To give an example: I create a proprietary program. Some functionality is dynamically linked (like e.g. malloc). There are multiple implementations of this functionality, some of which are GPL, some might be MIT and others might be proprietary. It is the users decision, right before runtime, via mechanisms such as LD_PRELOAD to decide which implementation of this functionality to run against. Obviously not a derived work (otherwise I could retroactively make anything a derived work of anything by re-implementing a dynamic library they use!).
But if no competing implementations of the GPLed library exist, and it is essential to my proprietary program, and I happen to bundle a copy of the GPLed library with my product… then I probably have created a derivative work. And it might stop being derivative if some third party happens to create a competing implementation of the same API, unknown to me or the authors of the GPLed library.
You make a valid point, yet I think that in practice the scenario of keeping the original files intact, yet continuing development in another set of files under another (proprietary) license is a huge enough nuisance and a potential legal minefield (eg ensuring that the new code is not “derived” from the existing one in any sense, etc) to deter these kind of solutions.
MPL and EUPL walk the thin line between protecting FOSS values and being acceptable for at least some non-FOSS stakeholders. Many Julia packages implicitly face this question.
Windows is proprietary, not (A)GPL. Why would copyright law apply on copyleft licenses on the “what is bundling” question?
It’s not a technical detail when your software can run without the GPL parts.
If you’re not serving it externally, AGPL is fine here.
Still not clear though. What if you use a bundled GPL library to compute a numerical result. You can also provide a return 0 shim that is not bound by the GPL. Technically it’s not a derivative work. Sure, it returns the wrong result, but there’s no law or license that says your math has to be correct! Decades of precedent point in the opposite direction: NO WARRANTIES OR GUARANTEES, EXPRESS OR IMPLIED
A small literature update and a related tooling note that may be useful here.
Rosen’s Open Source Licensing — a classic — is from 2004. For a more current treatment I would also point to Amanda Brock, ed., Open Source Law, Policy and Practice, 2nd ed., OUP 2022. It covers not only license interpretation, but also open-source governance, business models, compliance, and policy. That seems relevant because many of the questions in this thread are not just “which license text?”, but also “what legal and organisational machinery follows from that choice?”
There is also a tooling angle. A single root LICENSE file is often too coarse once a package contains source files, generated files, documentation, examples, assets, notebooks, CI files, or vendored material under different terms. The REUSE specification, mentioned earlier, addresses this by making copyright and licensing information file-level, machine-readable, and auditable, using SPDX identifiers/expressions, a LICENSES/ directory, and optionally REUSE.toml.
I have opened a PR adding REUSE support for PkgTemplates.jl and would be grateful for review/testing by people who care about package licensing.
Implementation outline
The plugin generates REUSE.toml, populates LICENSES/ with the relevant license texts made available by a snapshot from SPDX License List Data, adds SPDX copyright/license headers, optionally adds a README ## Licensing section, and can wire reuse lint into CI. In particular, it supports SPDX license expressions rather than only single license identifiers, because practical package licensing may involve expressions such as MIT OR Apache-2.0, GPL-3.0-only WITH GPL-3.0-linking-exception or custom LicenseRef-* licenses.
These discussions remind me of the time when I had to take some courses in law as an economics major. We had a really good, experienced senior lecturer, and while we were not supposed to interrupt with questions, we could write them on a piece of paper and pass them forward.
90% of them were like this, “what if” speculations from people trained predominantly in mathematical methods, interpreting legal questions literally, as a math problem.
We were (repeatedly) told that law does not work like that. This, of course, did not stop the flow papers passing forward. I still remember one of them, a student wanted to know if trading 100 euros for x euros was an unconscionable contract for various values of x, and tried to find a threshold by sending multiple questions forward with various x’s, effectively applying bisection. I think the lecturer kindly asked him to stop way before his preferred rtol.
For the purpose of licensing Julia packages, I don’t think we should focus on corner cases, as they have very little case law to go by and in any case we are not trained in law. Instead, the potential copyright owners should just think about what they want, and how to find a license that matches that. No, it won’t cover everything, no contract or license ever does. The idea is to make a best effort, then carry on writing code, which most of us know much better than copyright law.
Personally, when I write FOSS, what I want is contributors, who will find bugs, implement missing functionality, and occasionally take the software in great directions I was not originally planning on. Originally I thought that the MIT license was best for that. Then I have seen scenarios (outside the Julia ecosystem) where companies just pulled the plug on formerly open projects, thank you for your contributions, updates will be sold for customers from now on. So now I am a bit wary about licensing like that and I imagine that some others are too.
And removing it in lieu of a different license (i.e. relicensing) requires consent of the original author. As a maintainer, this is a huge hassle, and trying to mix things and hoping it works out is not a safe strategy.