That is also not quite true - here’s an excerpt of section 5, “Obligations of the Licensee”:
Compatibility clause: 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. For the sake of this clause, ‘Compatible Licence’ refers to the licences listed in the appendix attached to this Licence. Should the Licensee’s obligations under the Compatible Licence conflict with his/her obligations under this Licence, the obligations of the Compatible Licence shall prevail.
So under the EUPL, you can relicense with a compatible (i.e., stronger) license. In particular:
‘Compatible Licences’ according to Article 5 EUPL are:
— GNU General Public License (GPL) v. 2, v. 3
— GNU Affero General Public License (AGPL) v. 3
— Open Software License (OSL) v. 2.1, v. 3.0
— Eclipse Public License (EPL) v. 1.0
— CeCILL v. 2.0, v. 2.1
— Mozilla Public Licence (MPL) v. 2
— GNU Lesser General Public Licence (LGPL) v. 2.1, v. 3
— Creative Commons Attribution-ShareAlike v. 3.0 Unported (CC BY-SA 3.0) for works other than software
— European Union Public Licence (EUPL) v. 1.1, v. 1.2
— Québec Free and Open-Source Licence — Reciprocity (LiLiQ-R) or Strong Reciprocity (LiLiQ-R+)
Sure, I can’t weaken the license (e.g. go to MIT) without agreement of other contributors, but since other contributors shared their contributions with me under the EUPL, I can relicence to GPLv2 (not that I would actually do that - I prefer the clear jurisdiction that the EUPL offers and want to stay away from concerns of virality as much as possible)
As a supportive anecdote, I have, at least twice, chosen not to use a Julia package because of a restrictive license, and in one particular case I believe that I would have made some decent contributions to boot. Instead, I saw the license and immediately had to disregard the package entirely, so as to avoid unintentionally authoring code that could be construed as a derivative work.
On that note: I’m confused that we even allow GPL libraries in the General registry. At least in the FSF’s opinion, my understanding is that simply using a GPL package in a non-GPL package is a license violation. Since Julia itself is MIT, that would mean that using any GPL package ever in Julia would automatically violate the license. Do we simply follow a consensus that the FSF’s (legally untested) interpretation that GPL is viral with respect to linking can be ignored?
My understanding is it’s only an immediate license violation if the other license is incompatible with the GPL. If it is compatible, then the combined work must obey the GPL conditions.
Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
[https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic]
There are variants of the GPL license that allow linking, but those are discussed separately.
No, you’re both missing the big thing: this is only a problem if you distribute the derivative work as a whole. That’s the “loophole” that AGPL tries to close.
Simply using is not a re-distribution. It only gets interesting if you’re distributing a bundle that includes both the GPL code and proprietary code. Or if you try to pass off the GPL code as something less restrictive than GPL.
But I’m not a lawyer. I might be wrong, I don’t know.
Simply using a GPL library is indeed not redistribution, but once you start sharing the project (particularly a non-source form) that uses a GPL licensed library the conditions of the GPL around combined works start applying.
The AGPL extends distribution to over-the-network (SaaS) situations, and that specifically is I believe the “loophole” that the AGPL tries to close.
Likewise, I’m not a lawyer, but I do find reading the licenses quite informative.
I think it’s worth mentioning on this that while this does hold in a GPL and MIT case, there’s more nuance to it. For instance, if there’s an MPL licensed package and somebody wants to combine work from it with their own MIT licensed package, they can absolutely do this and their package stays MIT licensed. The MPL component they brought in stays MPL, but there’s no conflict as this behavior is explicitly permitted under the MPL.
I think this is absolutely vital, and in many ways much of the motivation behind my post. I realised that I’d just picked MIT because it was “the obvious choice”, but the topic is important enough that it warrants thinking about how I actually want to release my work.
One other small thing, when you say “license innovation” to me that sounds like creating a homebrew license or breaking new ground. However, all of the licenses mentioned in this discussion so far have been used by large entities with legal teams in major projects. Nobody would be breaking new ground by applying any of these licenses to their projects.
There’s no difference between the two cases. Really. It’s exactly the same with GPL.
Pretty much everything that anyone creates has a copyright. And reproducing copyrighted materials in certain ways (depending upon local laws) is a crime. Licenses grant you the ability to copy/use/distribute those copyrighted materials so long as the original copyright is preserved and some other terms are satisfied.
Combining MIT & GPL code together in a way that creates a singular Derivative Work must be distributed under the terms of the GPL. But that doesn’t change the copyright(s) of the MIT code, nor can it change the original license. MIT satisfies the conditions of the GPL (they’re compatible), and if worked on and distributed separately it’s still MIT. Where it’s different is in the case of proprietary code & GPL or MPL. Because then the GPL insists that the proprietary code be distributed as GPL, which is a fundamental change in license (it’s the whole-cloth granting of one!)
And that’s just it, to change the license in an incompatible way (which is what Keno was suggesting) you need to either have a strong CLA that allows this or you need signed legal agreements from all contributors.
But the thing is, you can also infringe on copyrights when you write your own code. If I read someone else’s copyrighted code that does something I want to do, and then later re-implement it in the same manner, there’s the risk that I could be accused of plagiarizing their work. Maybe I did, maybe I didn’t, but either way, if this is a Derivative Work of their code, then their copyright applies. And thus the only way I can use that code I wrote is by satisfying the terms of their license. If it’s MIT, then that’s trivially satisfiable and something I want to do in any case — give credit!
It’s perhaps worth noting that I don’t fully understand what a Derivative Work is. And I don’t think many people do. In fact, it varies by jurisdiction (and perhaps even judge). The lines are blurry, so I just stay away from them. And stay on well-trod ground. It’s when you go away from that well-trod ground that you’re innovating.
I’m afraid to say Matt that you’re the first person I’ve seen to take this position . Every legal resource on the GPL and MPL I’ve seen describes them as being completely different in this respect.
Right, MIT isn’t alone in this though. Once again to use the MPL as a complementary example, your obligations are in brief:
MIT: Reproduce license, give credit
MPL: Reproduce license, give credit, share modifications
Neither are complicated or onerous. In many ways, this is the essence of my post: while the MIT is widespread, there are very much are other arrangements worth attention and consideration, and more than just a permissive/copyleft dichotomy.
Not defining things is indeed one of the common issues with open-source licenses, particularly the shorter ones. Thankfully, others like the Apache, MPL, and EUPL licenses actually go to some length to avoid exactly this issue.
As an aside: I’d really recommend reading not just legal commentary on licenses but the licenses in full. While there are a few notably impenetrable and confusing ones, many are clearly written and don’t take too long to read.
At the very least, I’ve found quite a bit of value in doing so. There’s only so much a dot-point summary can cover, and in many ways it feels like due diligence for operating in the open-source environment we inhabit.
Most legal resources on GPL and MPL are focused on the case of combining it with commercial and proprietary code. And yes, in that case there is a distinction (did you see my edit there?).
Here’s what the EUPL says on Derivative Works:
This Licence does not define the extent of modification or dependence on the Original Work required in order to classify a work as a Derivative Work; this extent is determined by copyright law applicable in the country mentioned in Article 15.
This makes no obstacle for linking Code A with another software component (Code B) that could be proprietary. There is no kind of “viral effect” resulting from the EUPL licence, in so far linking is done for interoperability. The portions of Code A that are strictly necessary for interoperability may be reproduced in Code B without copyright infringement. The resulting “A-B solution”, which could be commercial, will include the two modules under their relevant licences. This is resulting from interpreting European law and case law[1].
1] Interpretation of Directive 2009/24/EC on the legal protection of computer programs (art 6, 1. a & b) and Court of Justice of the EU – Case C-406/10 of 2 May 2012.
The lawyer who wrote that link is the literal lawyer who wrote the EUPL. Please don’t misrepresent his stance by using something out of context.
I’m not sure what I’m misrepresenting here? My point is simply that each license and jurisdiction’s copyright law has varying definitions on what makes a Derivative Work, so you can’t really talk about it in isolation — not with sharp boundaries, anyhow.
I didn’t see your edit before I posted. That does better clarify, but in the circumstance I described the overall work, in its entirety, becomes GPL. This difference is absolutely key, and relevant without introducing proprietary code. Perhaps I could have done a better job expressing that the scenario I put was mixing MIT and MPL code, not just linking two projects with different licenses.
From the wider reading I’ve done, prescribing what is or isn’t a derivative work is not actually something a license can define, as it is superseded/governed by the IP law of the jurisdiction in question. The EUPL and MPL both set the relevant jurisdiction which makes it possible to actually work out how this is governed, an improvement over licenses that don’t cover this at all.
No, this isn’t a difference. Here, let’s make it concrete.
I’m developing an open source CLI app called “DoCLIWork” with an MIT license. Many others have contributed to it with the MIT license. This is all copyrighted material, but the MIT license grants me the ability to use it. I build and distribute it.
I want to make it a GUI and grab a “WindowingToolkit” package that is GPL licensed. It’s also copyrighted material, but the GPL license allows me to use it. I incorporate it into the newly renamed “DoGUIandCLIWork” app.
No matter the technology I use (packages or static or dynamic linking, or even directly inlined compilation), as long as I don’t jumble them up in a way that’s impossible to trace the original copyrights, I can track those copyrights separately. And thus I can track the licenses separately.
Yes, I need to provide the combined DoGUIandCLIWork bundle under the terms of the GPL. But the MIT License grants me the ability to sublicense to a compatible license, and the GPL is a compatible sublicense. You know what, all those copyrights in DoCLIWork had already been distributed with an MIT License! If I track it carefully and separately, the files underpinning the CLI parts can continue to be developed as MIT licensed work.
This does mean, however, that now I can’t also distribute MKL as the built-in BLAS in DoGUIandCLIWork. Because its license is incompatible with the GPL, and I can’t go to Intel and demand they relicense it under the terms of the GPL. Thus I cannot comply with the terms of the WindowingToolkit and therefore would be violating its copyrights.
Not in the EU you don’t, precisely because of the nature of copyright under EU law & case law that I cited above! That’s the entire point of the discussion, because neither under the EUPL nor the MPL does your interpretation make sense - it goes directly against the license.
The MIT licence grants you permission to sublicense without considering compatibility; it only requires that the copyright notice & permission notice is preserved.
It is the EUPL and MPL that define compatible licenses, and what “compatible” even means, not the MIT license.
The combined work under EU law (as cited above) is not GPL, so you can link to MKL just fine. For the purposes of interoperability (i.e., calling into a framework), no copyright infringement occurs.
Leaving other details aside, I will just mention that this is going in the opposite direction from my hypothetical. I was trying to provide an informative extension to
This is the sort of mixing that I was talking about, and one where incorporation of GPL code makes the overall project GPL, but MPL incorporation does not.
I think there’s value in this discussion of licenses, but it needs to remain grounded in the actual text of licenses and interpretations from legal professionals, and focus more on the nuance in this topic than sweeping generalisations.
It doesn’t really matter what the different license is. Code from neither MPL or GPL can be contributed directly — without consideration — as MIT licensed code to an MIT licensed repository. That’s foundational.
(not that I would actually do that - I prefer the clear jurisdiction that the EUPL offers and want to stay away from concerns of virality as much as possible)
I think this is absolutely vital, and in many ways much of the motivation behind my post. I realised that I’d just picked MIT because it was “the obvious choice”, but the topic is important enough that it warrants thinking about how I actually want to release my work.
. Every legal resource on the GPL and MPL I’ve seen describes them as being completely different in this respect.