Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EPL-2.0 and Leiningen #2358

Closed
danielcompton opened this issue Nov 21, 2017 · 10 comments

Comments

Projects
None yet
3 participants
@danielcompton
Copy link
Collaborator

commented Nov 21, 2017

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:

1.4. What are the major changes between EPL-1.0 and EPL-2.0?

  • The term of art is now referred to as "module" rather than "file";
  • The choice of law provisions has been removed;
  • The license is now suitable for scripting languages such as JavaScript; and
  • The license now includes an option to add a secondary license for GPL-2.0+ compatibility.

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?
A: It is almost the same as dual licensing EPL/GPL

Q: How can I upgrade a project from EPL-1.0 to EPL-2.0?
A: The EPL allows new versions of the license to be adopted by projects with little work. A project can use the new version by simply updating the file headers and notices. It would be good practice to discuss this before relicensing though.

Q: How can I upgrade a project to EPL-2.0 with GPL secondary license?
A: You must gain permission from all copyright holders to re-license the content (Ed: Projects with a CLA would allow you to do this, as you have already gotten approval from contributors.)

Q: Some organizations do not use GPL-licensed content. What are the impacts of licensing a project with EPL-2.0 + GPL secondary license?
A: While the EPL-2.0 has a concept called "Secondary Licenses", should an adopter not want to use the Secondary License, then the entire construct can simply be ignored. The code can be consumed purely under the EPL-2.0 without any concerns.

I have a few questions around Leiningen and the EPL-2.0:

  • Should Leiningen itself relicense to EPL-2.0?
  • Should Leiningen relicense to EPL-2.0 + GPL secondary license?
  • Should Leiningen update the templates to use EPL-2.0?
  • Should Leiningen update the templates to use EPL-2.0 license, and including the GPL secondary license?
@technomancy

This comment has been minimized.

Copy link
Owner

commented Nov 21, 2017

Good questions!

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.

@danielcompton

This comment has been minimized.

Copy link
Collaborator Author

commented Nov 21, 2017

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.

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.

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.

@technomancy

This comment has been minimized.

Copy link
Owner

commented Nov 21, 2017

Thanks. I appreciate your work on this.

It also occurs to me that we could relicense leiningen-core as a library more easily than the entire Leiningen application since the list of dependencies and contributors is smaller. And the license compatibility questions are more likely to be relevant for a library than an application.

But changing the templates is a great first step we can take right now.

@yegortimoshenko

This comment has been minimized.

Copy link
Contributor

commented Nov 24, 2017

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.

Related:

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

@technomancy

This comment has been minimized.

Copy link
Owner

commented Nov 24, 2017

@danielcompton

This comment has been minimized.

Copy link
Collaborator Author

commented Nov 24, 2017

@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.

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.

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.

Allowing GPL as a secondary license is a drastic (unexpected, breaking) change in default licensing terms for Leiningen projects due to the above.

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.

@yegortimoshenko

This comment has been minimized.

Copy link
Contributor

commented Nov 24, 2017

That doesn't make any sense; you can't have a change that's breaking for projects that don't exist yet.

It is a breaking change on Leiningen's part, if lein new adds a secondary license clause with GPL, it will result in a very drastic change of effective licensing terms.

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.

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.

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.

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.

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.

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.

@technomancy

This comment has been minimized.

Copy link
Owner

commented Nov 24, 2017

@yegortimoshenko

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2018

This seems to be resolved now.

@technomancy technomancy added this to the 2.8.2 milestone Sep 20, 2018

@technomancy

This comment has been minimized.

Copy link
Owner

commented Sep 21, 2018

You're right; thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.