Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
EPL-2.0 and Leiningen #2358
Recently, the Eclipse Foundation have released the EPL-2.0. There are a few improvements from the EPL-1.0 that Clojure and most Clojure projects use:
Potentially the most interesting to many people is the ability to add a secondary license to allow GPL-2.0+ compatibility.
I've had some discussions on the EPL-discuss mailing list: http://dev.eclipse.org/mhonarc/lists//epl-discuss/msg00158.html, and there is much more detail in the EPL-2.0 FAQ. I would encourage anyone interested in this topic to read the FAQ.
I've put a few abridged questions and answers that I think will answer people's most common questions. You should read the FAQ for the full context on this though.
Q: What is the impact of adding a secondary GPL license?
Q: How can I upgrade a project from EPL-1.0 to EPL-2.0?
Q: How can I upgrade a project to EPL-2.0 with GPL secondary license?
Q: Some organizations do not use GPL-licensed content. What are the impacts of licensing a project with EPL-2.0 + GPL secondary license?
I have a few questions around Leiningen and the EPL-2.0:
I have been disappointed by the way version 2 of the EPL has turned out. At first I was glad to see they were finally addressing the GPL incompatibility problem, but the fact that the GPL "secondary license" is an additional opt-in clause not covered by the "...or later version" section of the EPL v1.0 means that it's essentially useless to large projects with contributor-friendly copyright policies, since it would require tracking down confirmation from hundreds of distinct contributors.
In addition, even if we applied it the secondary license would be of no use to us unless every single one of our EPL-licensed dependencies also explicitly opted in. For this reason I am inclined to ignore it completely. It's really discouraging that they could have done the EPL v2.0 in a way that everyone could have benefited from it, but chose not to.
These problems do not necessarily apply to the license included in the templates, so I would be open to changing those to EPL-2.0+GPL-secondary. Of course, unless Clojure itself also adopts the GPL-secondary that will be a token gesture only, as it will still be impossible to use them legally with GPL code.
I think I agree with everything you've said there, and am also disappointed that EPL-2.0 could have had GPL compatibility.
I'm considering where Clojars/I could build a tool to help make the relicensing approval process much easier for projects, by reducing the MxN problem to an M+N problem.
Yeah, I'm hopeful that Clojure will relicense but agree that this is a token gesture until that happens.
In my mind this is very much a long game. Assuming Clojure ever adopts EPL-2.0 it would still take many years for all of the licensing changes to percolate through the ecosystem, however if we don't start now then it will take longer still for Clojure and GPL to ever be a reality.
I'll open a PR for changing the templates to EPL-2.0+GPL-secondary, I need to do a bit more research first to make sure I get all the details correct.
Thanks. I appreciate your work on this.
It also occurs to me that we could relicense
But changing the templates is a great first step we can take right now.
EPL can't have GPL compatibility, because that would mean someone can take EPL-licensed project and make changes under GPL that can't be taken back. GPL forces itself on linked works, requires documentation of changes, prohibits tivoization (in version 3) and allows the work to be relicensed under AGPL, thus forcing further restrictions (in version 3). Not being able to draw from a derived work is (arguably) against intent of any copyleft license. In other words, GPL is to blame, not EPL.
Allowing GPL as a secondary license is a drastic (unexpected, breaking) change in default licensing terms for Leiningen projects due to the above. I think that the license should be updated to EPL-2.0 and people who want GPL compatibility would add the secondary license notice themselves.
Also, note that GitHub (and I think GitLab, too) still don't recognize EPL-2.0: https://github.com/yegortimoshenko/leiningen-2358
@yegortimoshenko before we discuss this further, have you read https://www.eclipse.org/org/documents/epl-2.0/faq.php? It covers your questions at least partially.
Anyone making changes to leiningen-core (for example) would need to comply with both the EPL and GPL. It's an interesting question, but I don't think people would be able to make their changes under only the GPL. However it probably needs to be investigated further, as this maybe suggests that someone could choose the GPL license and then make further changes under the GPL.
EPL-2.0 with GPL compatibility allows the user of the library to choose the license that works for them. If you want to ignore the GPL secondary license, that is totally fine.
It is a breaking change on Leiningen's part, if
I did read the FAQ, and I have not asked any questions: I thought I'd drop by and warn against (basically) dual-licensing new projects under EPL-2.0 and GPL.
Of course they would be able to, that's the only way to make any license compatible with GPL. And the fact that you are not sure about it underlines that adding a secondary license would be an underhanded change in licensing terms for new projects.
My point is that changes to the project in that case can be made under GPL which would mean they can't be contributed back. It means that the effective license is not reciprocal anymore.
Say I have a project under EPL that I want to use with proprietary code. Someone forks it and makes changes under GPL. I would not be able to take these changes back without relicensing combined work under GPL, including proprietary code.