| Re: [ee4j-community] Licensing considerations for EE4J implementation projects |
Werner
Send ee4j-community mailing list submissions to
ee4j-community@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community
or, via email, send a message with subject or body 'help' to
ee4j-community-request@eclipse.org
You can reach the person managing the list at
ee4j-community-owner@eclipse.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ee4j-community digest..."
Today's Topics:
1. Re: Licensing considerations for EE4J implementation projects
(Mrinal Kanti)
------------------------------------------------------------ ----------
Message: 1
Date: Tue, 23 Jan 2018 21:17:33 +0530
From: Mrinal Kanti <mrinal.kanti@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Licensing considerations for EE4J
implementation projects
Message-ID:
<CAAenm-_zAekyJCVfZZchB5eML+pP8ZaiF3=wogT9f0UCr4RJmg@mail. gmail.com >
Content-Type: text/plain; charset="utf-8"
On Tue, Jan 23, 2018 at 8:46 PM, Werner Keil <werner.keil@xxxxxxxxx> wrote:
> Unlike some examples with this dubious "secondary license"
> <https://projects.eclipse.org/projects/rt.vertx >
>
What dubious "secondary license" are you referring to? Read the EPL2 FAQ at
https://www.eclipse.org/legal/epl-2.0/faq.php#h.w1np1lrpht6k . The
motivation for Secondary license clause in EPL is clearly stated there.
-Mrinal
>
> Werner
>
> On Tue, Jan 23, 2018 at 3:53 PM, <ee4j-community-request@eclipse.org >
> wrote:
>
>> Send ee4j-community mailing list submissions to
>> ee4j-community@xxxxxxxxxxx
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://dev.eclipse.org/mailman/listinfo/ee4j- community
>> or, via email, send a message with subject or body 'help' to
>> ee4j-community-request@eclipse.org
>>
>> You can reach the person managing the list at
>> ee4j-community-owner@eclipse.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of ee4j-community digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: Licensing considerations for EE4J implementation projects
>> (Steve Millidge (Payara))
>>
>>
>> ------------------------------------------------------------ ----------
>>
>> Message: 1
>> Date: Tue, 23 Jan 2018 14:53:05 +0000
>> From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
>> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
>> Subject: Re: [ee4j-community] Licensing considerations for EE4J
>> implementation projects
>> Message-ID:
>> <DB5PR03MB1783D0AAE88031837E84F 3C591E30@DB5PR03MB1783.eurprd
>> 03.prod.outlook.com>
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> 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-foundation.org <mailto:mike.milinko
>> vich@xxxxxxxxxxxxxxxxxxxxxx>> 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<mailto:
>> 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 release
>> d 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 list
>>
>> ee4j-community@xxxxxxxxxxx<mailto:ee4j-community@eclipse. org >
>>
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>>
>> https://dev.eclipse.org/mailman/listinfo/ee4j- community
>>
>>
>> --
>> Mike Milinkovich
>> mike.milinkovich@eclipse-foundation.org <mailto:mike.milinkov
>> ich@xxxxxxxxxxxxxxxxxxxxxx>
>> (m) +1.613.220.3223
>>
>> _______________________________________________
>> ee4j-community mailing list
>> ee4j-community@xxxxxxxxxxx<mailto:ee4j-community@eclipse. org >
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/ee4j- community
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <https://dev.eclipse.org/mailman/private/ee4j- community/
>> attachments/20180123/fad77bfb/attachment.html>
>>
>> ------------------------------
>>
>> _______________________________________________
>> 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
>>
>>
>> End of ee4j-community Digest, Vol 5, Issue 94
>> *********************************************
>>
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20180123/8988b92c/attachment. html
------------------------------
_______________________________________________
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
End of ee4j-community Digest, Vol 5, Issue 101
**********************************************