| 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
(Mike Milinkovich)
2. Re: Licensing considerations for EE4J implementation projects
(Werner Keil)
------------------------------------------------------------ ----------
Message: 1
Date: Tue, 23 Jan 2018 11:12:52 -0500
From: Mike Milinkovich <mike.milinkovich@eclipse-foundation.org >
To: ee4j-community@xxxxxxxxxxx
Subject: Re: [ee4j-community] Licensing considerations for EE4J
implementation projects
Message-ID:
<2284d68b-67c9-66d1-cef7-4d1fa1407a7d@eclipse- >foundation.org
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 2018-01-23 10:47 AM, Mrinal Kanti wrote:
> On Tue, Jan 23, 2018 at 8:46 PM, Werner Keil <werner.keil@xxxxxxxxx
> <mailto:werner.keil@xxxxxxxxx>> wrote:
>
> Unlike some examples with this dubious "secondary license"
>
> 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.
Yes, exactly. Thank you Mrinal for pointing that out.
There is nothing "dubious" about the Secondary License approach in the
EPL-2.0. FWIW, it was modeled closely after the approach followed by the
MPL-2.0 a few years earlier.
--
Mike Milinkovich
mike.milinkovich@eclipse-foundation.org
(m) +1.613.220.3223
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20180123/bf4fe198/attachment. html
------------------------------
Message: 2
Date: Tue, 23 Jan 2018 17:14:46 +0100
From: Werner Keil <werner.keil@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Licensing considerations for EE4J
implementation projects
Message-ID:
<CAAGawe2+q43gAY8fCbQK5XZvG9mHMedynwoQtX >5TjsdCG+wYFw@xxxxxxxxxxxxxx
Content-Type: text/plain; charset="utf-8"
Please clarify that with Mike/EMO.
Should EPL2 really mandate that any other license can only be seen as
"secondary" rather than equal next to it, then maybe it could be an issue.
The projects I mentioned and the one I lead myself are under EPL1 so I
don't really care with that "hat" on unless we were forced to migrate to
EPL2.
Werner
On Tue, Jan 23, 2018 at 4:47 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
> (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
> **********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j- >community/attachments/ 20180123/2005a97f/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 102
**********************************************