| Re: [ee4j-community] Licensing considerations for EE4J implementation projects |
Mrinal,
Apologies I seemed to have misunderstood your point.
https://www.cloudfoundry.org/g
overnance/cff_ip_policy/ ) refers to the IP policy for Cloud Foundry projects. Hence my misunderstanding that you wanted to take EE4J project code, perhaps with modifications and move it under the Cloud Foundry organisation.
Can you explain to me, as a non-lawyer, how licensing EE4J under the EPLv2 takes options off the table for an ISV targeting Cloud Foundry?
Thanks
Steve
From: ee4j-community-bounces@eclipse
.org [mailto:ee4j-community-bounces@eclipse.org ] On Behalf Of Mrinal Kanti
Sent: 23 January 2018 15:27
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Licensing considerations for EE4J implementation projects
Steve,
I think you have misunderstood me. I never suggested anything that would hint towards moving EE4J projects to cloud foundry. I have no idea what made you think of that. I am merely exploring a way to enable the downstream community such as Independent Software Vendors (ISVs) to build products and services on the cloud foundry platform using EE4J implementations.
Most open source cloud technology and platforms today encourage the usage of Apache License 2 and I do not assume that this would be a threat to Payara or any of the other cloud base projects that are being developed in the current Eclipse ecosystem. Yet, I find your tone pretty dismissive,
I don't think the compatibility between Apache License 2 and EPL2 warrants a debate, as I believe, we all understand that it is only one-way compatible and therefore would take a lot of options out of the table for ISVs even if the EPL license gets accepted at Cloud Foundry. With respect to whether it would solve the current license compatibility issues under discussion, I would let the PMC decide the best course of action.
-Mrinal
On Tue, Jan 23, 2018 at 8:23 PM, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
IANAL however the referenced Cloud Foundry IP policy does not say you can only run Apache 2.0 licensed software on CloudFoundry. It states that new CloudFoundry projects must be Apache License 2.0 i.e. projects developed under the CloudFoundry organisational umbrella. I don’t envisage any EE4J projects moving to CloudFoundry to continue their development so don’t see how this is a problem.
Let’s leave licensing discussions and the compatibility of various licenses to open-source IP lawyers.
The minutes refer to the PMC requesting confirmation that there is no incompatibility between Apache License 2.0 and EPL 2.0
Steve
From: ee4j-community-bounces@eclipse
.org [mailto:ee4j-community-bounces@eclipse.org ] On Behalf Of Mrinal Kanti
Sent: 23 January 2018 14:38
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Licensing considerations for EE4J implementation projects
Mike,
When some of the Java EE Reference Implementations were being developed through the JCP under Oracle, I doubt if the initial contributors realized the value of those implementations in cloud based deployment environments. I am not blaming them for oversight, as I understand that the cloud ecosystem was also evolving in parallel and probably was not mature enough to be considered as a viable distribution option at that time. The CDDL+GPL2CE or even the recent EPL2+GPLCE does not look favorable for those environments as some of the popular cloud platforms such as Cloud Foundry mandate the usage of ASL (Refer Section II.B of https://www.cloudfoundry.org/governance/cff_ip_policy/ ). With the current licensing of EE4J, I do not see an option where I (or any ISV) can create services or product offerings by leveraging the EE4J implementations on the Cloud Foundry platform. I see that Eclipse Jetty is already targeting Cloud Foundry by virtue of dual-licensing under ASL so this should not be a distant possibility for other EE4J implementations. I am merely suggesting approaches of how we can bridge that gap for EE4J under the current circumstances.
Luckily, we can get Java EE conformant implementations under ASL license elsewhere but that is not what I am trying to suggest here.
When I saw the OCA agreement, I realized that there was an opportunity for having the code re-licensed under a permissive license which would allow us (i.e. everyone in the EE4J ecosystem) to target the cloud ecosystem for distribution. But I also realized, that this opportunity would be lost forever i.e. the OCA would cease to exist, once Oracle completed the transition. This assessment is based upon my observation that the Eclipse Committer or the Contributor agreements do not contain any equivalent clause that would enable the Eclipse Foundation to re-license the code under a different license at a later date without seeking initial contributor consent. So I believed, this is a one-time opportunity and also the best convenient time to explore this possibility.
I also came across couple of scenarios where license incompatibilities between EPL and ASL were being discussed in the EE4J community, albeit, internally. I saw another opportunity if we could resolve those issues while exploring this possibility of re-licensing the implementations under a permissive license such as ASL, provided the PMC or the relevant stakeholders are willing to discuss those issue openly here.
I hope you would have now realized that this is not just some generic debate on the merits of copyleft vs. permissive licensing models.
Also, please feel free to correct any of my earlier assumptions, observations or assessments.
-Mrinal
On Tue, Jan 23, 2018 at 6:13 PM, Mike Milinkovich <mike.milinkovich@eclipse-foun
dation.org > wrote:Mrinal,
All of the code that is moving under EE4J and the EPL-2.0+GPL-CE is currently licensed under the CDDL+GPL-CE. Given that the new licensing regime is practically identical to the status quo which has existed for many years, I don't understand the point you are trying to make. Independent implementations based on Java EE specifications have existed for many years, and we expect that to continue.
FWIW, this is not an appropriate channel to debate the merits of copyleft vs. permissive licensing models. If you want to have those discussions perhaps a list such as license-discuss@xxxxxxxxxxxxxx would be a better choice.
On 2018-01-22 10:12 PM, Mrinal Kanti wrote:
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 [REF4] https://www.eclipse.org/legal/
epl-2.0/faq.php#h.lza2unrion3b
Rules of Engagement for this discussion:
0) MOST IMPORTANT: Lets not lose the forest for the trees.
1) Let's refrain from discussing project specific concerns unless they relate directly to EE4J licensing issue discussed here. However, it should be OK to cite examples from projects where EE4J licensing would have an impact. Refer Rule 0.
2) Most of us here are not qualified lawyers, so unless we claim to be so or have the necessary authority, lets try to restrain our legal viewpoints by suitably qualifying them as personal beliefs, opinions or assumptions.
-Mrinal
_______________________________________________ ee4j-community mailing listee4j-community@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/ee4j-community
--
Mike Milinkovich
mike.milinkovich@eclipse-foundation.org
(m) +1.613.220.3223
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community