Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Licensing considerations for EE4J implementation projects

Mike,

So with Vert.x or JNoSQL, should they ever apply EPL2, does one license have to be "primary" and the other "secondary" or can they also remain side-by side as they are now with those projects?

Except JNoSQL which already uses an EPL 1 based licensing (so does Yasson and no change is proposed there) if either MicroProfile components were to migrate under the EE4J TLP or projects like CDI, Bean Validation, Portlet, etc. all of which are strictly Apache 2, they will face that question.

Thanks,

Werner 



On Tue, Jan 23, 2018 at 5:14 PM, <ee4j-community-request@xxxxxxxxxxx> 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
      (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+q43gAY8fCbQK5XZvG9mHMedynwoQtX5TjsdCG+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:
> >>         <DB5PR03MB1783D0AAE88031837E84F3C591E30@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
**********************************************


Back to the top