The Eclipse Foundation has released a new version of their license, the Eclipse Public License (or EPLv2 for short). The EPL was changed mainly to make it compatible with GPL and easier to use outside the USA, while keeping compliance with the Open Source Initiative guidelines.
The Eclipse Foundation has released a new version of their default license, the Eclipse Public License (or EPLv2 for short). The EPL has been changed to make it compatible with GPL and easier to use outside the USA, among other features, while keeping compliance with the Open Source Initiative guidelines. EPLv2 replaces EPLv1, which is 13 years old and was largely based in the former Common Public License (or CPL).
InfoQ reached out to Mike Milinkovich, Executive Director of the Eclipse Foundation and former member of the Board of the Open Source Initiative, to know more about the motivations for the new version:
As the Eclipse community is starting numerous runtime projects in the IoT space, the ability to link to and inter-operate with GPL-licensed code has become a necessity
However, Milinkovich added that the EPLv2 being compatible with GPL doesn’t mean that all projects need to abide by GPL: project leads can decide whether a new project will be compatible with GPL or not, and will have the right to change their decision later on provided they have explicit approval of all contributors.
One of the main issues with EPLv1 is that it was explicitly linked to American legislation, specifically to the laws of the State of New York and to the US Copyright Act. On one side, there were concerns that being linked to a particular jurisdiction would make litigation over infringements outside of the USA harder to pursue, which could deter developers outside the USA from using EPLv1. On the other side, there is a subtle problem with the way both licenses apply to other related software.
EPLv1 limits the extent of its applicability to the original licensed code and to «derivative works», interpreting the term «derivative works» as specified in the US Copyright Act, which, in simpler words, defines it as «any form in which a work may be recast, transformed, or adapted». EPLv1 explicitly states that this does not apply to other software modules that might be distributed together with the EPLv1-licensed code but under a different license.
Under GPLv2 and GPLv3 the rights and obligations provided by the license extend to work «based on» or «distributed together with» the GPL-licensed program. This distinction becomes important when considering linking code released under different licenses.
The Free Software Foundation maintains that linking code A to GPL-licensed code B (either statically or dynamically), would mean that code A is based on code B, linking code C to EPLv1-licensed code D wouldn’t make code C a derivative work of code D; this means that the rights and obligations of GPL would extend from code B to code A, while under EPLv1 these wouldn’t extend from code D to code C, making both licenses behave differently and therefore incompatible with each other.
Prior to EPLv2 projects could overcome this limitation by dual-licensing under both EPLv1 and the Eclipse Distribution License (a variant of the New BSD License). The New BSD license is a permissive license compatible with GPL however, as Milinkovich explains:
Licensing under the BSD essentially removes the community-friendly copyleft aspect of the EPL license; EPLv2 allows GPL compatibility while maintaining the EPL copyleft provisions.
It is expected that projects that currently use EPLv1, particularly those under the Eclipse Foundation, will gradually migrate to EPLv2; some projects, like JUnit 5, have already adopted it. However, and as Milinkovich indicated, projects that are part of the Eclipse Foundation but that aren’t currently based on EPLv1, like Eclipse Ceylon or Eclipse MicroProfile, will be free to continue using their current licenses if so they wish.
EPLv2 is very new and as a result developers, projects and organizations are still adapting to its arrival. The Eclipse Foundation has created a FAQ page that, at the time of writing, is still a work-in-progress. Similarly, although EPLv2 has been announced as OSI-compliant, it still doesn’t appear as such on the official OSI website. These issues are expected to be addressed in the relatively near future.
