I would like to trigger a discussion on the choice of EPLv2 as
the license for EE4J "implementation" projects. The intent
here is to analyze the impact of EPL licensing on the projects
under the EE4J umbrella and the larger Java EE ecosystem in
light of current challenges and propose solution options.
ASSUMPTIONS:
1) There are/would be separate repositories for projects
involving Java EE specifications such as JAX-RS API (hereby
referred as "specification projects") and their
implementations such as Eclipse Jersey (hereby referred as
"implementation projects")
2) Like most standardization best practices, there would be
separate and independent governance framework (policies,
processes, methods) for specifications and implementations.
3) I assume that it would be possible to re-license code under
Apache License from the existing GPLv2+CE through the OCA
[REF2] which may not be possible otherwise [REF3].
4) Re-licensing to a less restrictive license (such as ASL)
would not have any negative impact on existing projects and
their downstream derivatives.
5) Projects (such as Eclipse Jetty) that do not need to modify
the EE4J implementation project source code are not addressed
here as they can be or are already addressed through
dual-licensing.
I understand that as of now, this assumed distinction between
specification and implementation projects may not be
universally applicable (looking at you JSON-P). Nevertheless,
I shall take that assumed distinction forward as I believe
that it would be necessary for the standardization of the
future enterprise Java platform (at least till the Eclipse
Foundation publishes their official governance framework
around EE4J and the new Java EE).
PROLOGUE:
I find it perfectly acceptable for the specification projects
to use the EPL license as I believe, it has all the necessary
clauses that would protect the brand, the interest of the
Eclipse Foundation and its members/associates. But I would
like to ask if EPL is the right license for the EE4J
implementation projects? Do we really need all the copyleft
clauses of EPL license in the implementation projects as well?
At first look, it seems very convenient that everything under
the EE4J umbrella should be consistently licensed under EPL
just like almost all other projects in the larger Eclipse
ecosystem. But some of the recent discussions here have forced
me to challenge this convenience.
PROBLEM:
The copyleft clauses of EPL can have downstream impact on
projects that uses a less restrictive license such as Apache
License (ASL) and are not currently using EPL. In my opinion,
this should be OK as long the downstream projects are using
the EE4J project binaries as-is. This is fine as far as the
API specifications go. But if the downstream projects need to
"tweak" the implementation projects (without changing the API)
to meet their specific requirements, there is currently no
provision to do so other than to re-license their own projects
under EPL. Dual-licensing does not seem a viable option in
case of EPL as I DO NOT think that dual-licensing grants one
the right to modify and re-license "initial contributions"
under a different license without the explicit consent of
"initial contributors". The option of forking implementation
projects is also ruled out, as I believe, the copyleft clauses
of EPL would be transitively applicable to the fork as well
(i.e. they need to be released under EPL). The choice of ASL
as Secondary license to EPL is also ruled out as EPLv2 does
not allow any other license other than GPLv2 (or later) in its
Secondary license clause. The only other other option is to
take a greenfield approach for implementing the entire
specification if someone wants even a slight variation to any
of the existing EE4J implementation projects.
One workaround to this problem could be to have the desired
modifications pushed to the respective upstream EE4J
implementation projects and then incorporate their binary
releases in the downstream ASL projects. For obvious reasons,
this does not seem practical as the upstream EE4J
implementation projects reserve the right to veto the changes
(say, on grounds that they are specific to a particular
scenario and do not have universal relevance).
PROPOSED SOLUTION:
I see this licensing issue as a potential recurring pattern
with wider impact rather than a one-off case and propose
couple of solution options that can address it:
SOLUTION OPTION A:
Re-license the EE4J implementation projects under ASL (The
specification projects can remain as-is under EPLv2). This
option would address the problem at the source(i.e. upstream
EE4J implementation projects) itself rather than mitigating it
at the individual points of impact(downstream ASL projects).
We may lose the copyleft clauses of EPL in the implementation
projects. But, are those copyleft clauses worth the challenges
we are facing and the convenience that we have to trade?
SOLUTION OPTION B:
Allow ASL as the Secondary license for EPLv2. I believe, this
is currently not possible under the terms of EPLv2 [REF4].
But, if allowed, then EITHER the EE4J implementation projects
OR the downstream project itself can be re-licensed with EPLv2
with ASL as secondary license (replacing the current GPLv2 as
there can be only one secondary license) without any further
downstream licensing impact. Any one of these either-or
scenario should suffice.
I believe, either options suggested above should be viable
subject to assumption (3) and OCA availability. Doing so would
facilitate and encourage the adoption of EE4J implementation
projects not only within the Eclipse ecosystem but outside as
well. It would be easier to work on acceptance and
interoperability of the implementation projects (and their
downstream derivatives) in communities which are otherwise
very strict on the usage of less restrictive licenses such as
ASL.
From a marketing perspective, I think it would be a very
effective way to evangelize the new Java EE even in
environments(such as cloud) which it does not natively
support.
ILLUSTRATION:
To further illustrate, if an ASL licensed Project X within the
EE4J umbrella or larger Eclipse ecosystem wants to use Eclipse
Jersey by modifying its code in order to make it suitable for
use in a cloud/micro-service runtime then they need not have
to re-implement the entire JAX-RS specification just to
incorporate their minor enhancements in order to remain
compliant with the entire JAX-RS specifications and still
release under ASL. Dual-licensing or forks are not an option
due to reasons stated earlier. However, If either Option A or
Option B is implemented then it should be trivial for the
downstream Project X to incorporate their specific needs as a
simple fork while still maintaining JAX-RS compliance and
without causing any downstream licensing impact.
EPILOGUE:
If the EE4J committee has already reflected upon the prospect
of using either of the proposed solution options for
implementation projects I would like to know why those options
were ruled out and if it would be possible to reconsider the
decision in the current scenario.
Quick References:
[REF1]
https://www.eclipse.org/legal/epl-2.0/faq.php
[REF2] Oracle's consolidated ownership of code as per
http://www.oracle.com/technetwork/oca-faq-405384.pdf
[REF3]
https://www.apache.org/licenses/GPL-compatibility.html
