Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] An open proposal for the direction of future Java EE Naming

Ondro,

Thanks for the explanation and confirmation.

I saw rumors and mentions of e.g. domains that suggested these are protected in some way.
Yet before throwing extra characters into that alphabet soup, is it possible to share which names are still valid candidates? Otherwise this will take longer than today's Germany finding a new coalition.

Should the extra "E" be accepted by those who need to give their blessing, then I would highly appreciate having just ONE acronym like "E4JEE" rather than "EE4J -> E4JEE", that would just confuse everybody even more. Imagine "IoT" was brand protected and instead of just having "iot.eclipse.org" we had to deal with something like "eot.eclipse.org/eiot" ?;-O

Werner



On Tue, Jan 23, 2018 at 4: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: An open proposal for the direction of future Java EE
      Naming (Ondrej Mih?lyi)


----------------------------------------------------------------------

Message: 1
Date: Tue, 23 Jan 2018 16:14:18 +0100
From: Ondrej Mih?lyi <ondrej.mihalyi@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] An open proposal for the direction of
        future Java EE Naming
Message-ID:
        <CACZTZYUZSC88gW8hO1QNiTgf7otK-7xsLrW1f=nKZuHMy+3y=Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi, Werner,

You are correct, this is my own suggestion, but I wouldn't publish it here
if I didn't feel the unanimous support from others in the community. I
can't talk for Payara in this matter but I think I can say that Payara
investigates other alternative names to raise in the EE4J PMC since almost
none of those suggested by the community passed the evaluation of the PMC.

As explained elsewhere, names like OpenEE or OpenJEE couldn't pass legal
verification, either because they are already used as trademarks on other
projects or because they use the Java trademark incorrectly. The naming
pattern with "for Java EE" at the end which I suggested could pass those
legal verifications in the same way as the current EE4J name with "for
Java" at the end. It may be necessary to shorten Java EE to JEE in the
short version (e.g. E4JEE) to be able to trademark the short form by the
Eclipse foundation. But, as I argued, that would still be better than EE4J.

Ondro

2018-01-23 15:55 GMT+01:00 Guillermo Gonz?lez de Ag?ero <
z06.guillermo@xxxxxxxxx>:

> A message from Wayne Beaton to the PMC list minutes ago talks about just 3
> possible names. I doubt OpenEE or OpenJEE are contained in that list.
>
> In this scenario, I totally support Ondrej's idea with a name that clearly
> states the relationship to Java EE. Sure it would be a long name but I
> prefer that over a new name that doesn't say anything of its origins and
> spirit.
>
>
> Regards,
>
> Guillermo Gonz?lez de Ag?ero
>
> El mar., 23 ene. 2018 a las 15:44, Werner Keil (<werner.keil@xxxxxxxxx>)
> escribi?:
>
>> Ondro,
>>
>> Thanks for your message. Interesting twist, I assume it is mostly your
>> own suggestion rather than an official one by Payara (you are not the PMC
>> rep there, are you?)
>>
>> I don't know which exact options were condensed into a short-list, but I
>> remember e.g. OpenEE or OpenJEE (should the acronym be allowed) were among
>> more often suggested names.
>>
>> I really don't see much difference between E4JEE and EE4J, if "JEE" was
>> still acceptable then OpenJEE (similar to OpenJ9) or even OpenEE sound
>> better as a brand for the "platform" as opposed to the EE4J TLP which most
>> likely is going to stay.
>>
>> None of the suggestions are without "JEE" or "JavaEE" so it s up to
>> others to decide, if this is worth our time to discuss them. If "JEE" was
>> OK then see above, it just spells more easily than any of the
>> tongue-breakers and artificial contructions that nearly seem like the
>> German party that once doomed the whole world...
>>
>> Whether EE4J or any other EE includes "Eclipse" and "Enterprise" or
>> "Enterprise" and something else (e.g. "Extension") that has not been
>> finally confirmed either. It was put on some project pages, but it may not
>> be written in stone, that one "E" could also stand for "Extension" or
>> similar.
>>
>> Werner
>>
>>
>> On Tue, Jan 23, 2018 at 1:43 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. An open proposal for the direction of future Java EE Naming
>>>       (Ondrej Mih?lyi)
>>>    2. Re: Licensing considerations for EE4J implementation projects
>>>       (Mike Milinkovich)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Tue, 23 Jan 2018 11:31:04 +0100
>>> From: Ondrej Mih?lyi <ondrej.mihalyi@xxxxxxxxx>
>>> To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
>>> Subject: [ee4j-community] An open proposal for the direction of future
>>>         Java    EE Naming
>>> Message-ID:
>>>         <CACZTZYWU7EfT1p36JygOwL+_F7kCOUTtkFmWo=3+FbW3u1r1Hg@
>>> mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>
>>
>>>
>>> Dear EE4J PMC, Eclipse and Oracle representatives.
>>>
>>> We've seen an already lengthy discussion about a new Java EE brand name.
>>> I
>>> acknowledge that most of the suggested names couldn't pass legal
>>> restrictions by various involved parties.
>>>
>>> However, I feel that the only name currently accepted by the EE4J PMC is
>>> EE4J itself. I have multiple reasons to be afraid that this is very
>>> impractical and inconvenient brand for a continuation of the Java EE
>>> platform. But before explaining them, I would like to propose another
>>> direction to choose the final brand.
>>>
>>> I propose to consider using a naming pattern of *"<something> for Java
>>> EE"*.
>>> An example would be "Extensions *for Java EE*" or "Components *for Java
>>> EE*"
>>> or "Specifications *for Java EE*".
>>
>>
>>>
>>> The short form could be Ext4JavaEE, E4JavaEE, C4JavaEE, E4JEE, I don't
>>> want
>>> to propose concrete names or short forms. I only think it's important to
>>> keep Java EE in the full name to keep the link with the original
>>> platform.
>>>
>>> The idea is based on the fact that Java as a word is allowed to be used
>>> in
>>> the form of "..for Java". Similarly, it should be legally OK to use the
>>> pattern "...for Java EE".
>>>
>>> I've already discussed this proposal with other influential people in the
>>> community before coming here. I've got only positive reactions, I was
>>> really surprised I didn't receive any hesitant or negative feedback. You
>>> may have a look at the discussions on Twitter
>>>
>> <https://twitter.com/reza_rahman/status/955031112086183941> or on the
>>> Java
>>> EE Guardians group
>>> <https://groups.google.com/d/msg/javaee-guardians/
>>> L3SmXeVwi-g/D04hFH-fAQAJ>.
>>
>>
>>>
>>> In the end, I'll summarize my objections against using EE4J as the brand
>>> name and for using a brand that relates to Java EE better:
>>>
>>> - EE4J is already a top level Eclipse project and while its main focus is
>>> on Java EE, we've also discussed that MicroProfile could be transferred
>>> under the same top level project. So EE4J isn't only about Java EE
>>>
>>> - the name EE4J doesn't reflect its relationship with Java EE well
>>> enough,
>>> it only refers to Java (with 4 Java at the end) and with the double E as
>>> a
>>> hint to Java EE
>>>
>>> - the name EE4J already includes the word Eclipse, which isn't
>>> appropriate
>>> for a brand name since it's already in the name if it's prefixed with
>>> Eclipse (Eclipse EE4J). Also, many people could correlate the new name to
>>> the Eclipse IDE and could think that it's a collection of IDE plugins
>>> aimed
>>> at enterprises. For that reason it would be better to use the name
>>> Eclipse
>>> E4J instead, loosing the double E as the last link to the old Java EE
>>> name
>>>
>>> - last but not least, the community seems to extremely dislike EE4J as a
>>> new brand for Java EE, because it goes against the values of Java EE and
>>> the community. Among those values are continuity, clarity, and integrity.
>>> And by integrity, I mean that for years we've kept telling people that
>>> the
>>>
>> correct name is Java EE <https://javaee.github.io/javaee-spec/JEE>. And
>>
>>
>>> with a name like EE4J we would have to educate people again and do a lot
>>> of
>>> explaining.
>>>
>>> Dear EE4J PMC and others,
>>>
>>> I hope that under these arguments you'll reconsider the current direction
>>> of the decision-making of the new brand name and you'll evaluate the
>>> suggested approach, trying to address the points above.
>>>
>>> Kind regards,
>>>
>> Ondro Mih?lyi
>>
>>
>>>
>>>
>>>
>>> 2018-01-16 20:39 GMT+01:00 John Hogan <jhogan515@xxxxxxxxx>:
>>>
>>> > Well put Ryan.  I totally agree.
>>> >
>>> > On Tue, Jan 16, 2018 at 11:33 AM, Ryan Cuprak <rcuprak@xxxxxxxxx>
>>> wrote:
>>> >
>>> >> Hello,
>>> >>  I just wanted to express my disappointment specifically with the
>>> Java EE
>>> >> branding. While I applaud the efforts Oracle has been making in
>>> donating
>>> >> Java EE to the Eclipse Foundation, the lack of brand continuity going
>>> >> forward I believe is going to hurt the platform. I disagree that Java
>>> EE is
>>> >> perceived as being an Oracle technology. From my experience, it
>>> perceived
>>> >> as a standard with implementations from Oracle, IBM, Apache, etc.
>>> >> Ultimately, the confusion over Java EE branding I think will hurt the
>>> >> commercial containers (like WebLogic) as Java EE may no longer be
>>> viewed as
>>> >> a long-term stable platform with a future.
>>> >>  Transitioning Java EE to new stewards and establishing new processes
>>> for
>>> >> the platform is a major undertaking. Rebranding is very risky under
>>> the
>>> >> best of circumstances. I hope that this position will be rethought or
>>> >> modified. Maintaining name continuity for at least a couple of years
>>> until
>>> >> the new process is up and running would go a long way to ensuring the
>>> >> success of this platform.
>>> >>
>>> >> -Ryan
>>> >> Connecticut Java Users Group
>>> >>
>>> >> On Jan 16, 2018, at 10:04 AM, will.lyons@xxxxxxxxxx wrote:
>>> >>
>>> >> Hello -
>>> >>
>>> >> Reza Rahman has recently posted a Joint Community Open Letter on Java
>>> EE
>>> >> Naming and Packaging
>>>
>> >> <https://javaee-guardians.io/2018/01/02/joint-community-
>>> open-letter-on-java-ee-naming-and-packaging/>.
>>
>>
>>> >> Our feedback is given below - most of it is context explaining our
>>> >> direction.   We hope it is helpful.
>>> >>
>>> >> Oracle has previously communicated that it intends to work with the
>>> EE4J
>>> >> community to:
>>> >> 1) Define a branding strategy for the platform, including a new name
>>> for
>>> >> Java EE to be determined.
>>> >> 2) Enable use of existing javax package names, and enable extension of
>>> >> existing javax namespaces (e.g. javax.servlet.*) to enable
>>> compatibility
>>> >> and evolution of existing APIs.
>>> >> 3) Use a different namespace naming convention, i.e. different from
>>>
>> >> ?javax.*?, for net new APIs/technologies.
>>
>>
>>> >>
>>> >> Note that doing the above remains work in process, but it remains our
>>> >> intent.
>>> >>
>>> >> The open letter requests that Oracle and other EE4J stakeholders work
>>> >> together:
>>> >> 1) To allow the new platform to retain the Java EE name
>>>
>> >> 2) To allow use of existing ?javax? packages for existing technologies
>>> >> 3) To allow use of the ?javax.enterprise? package for new technologies
>>
>>
>>> >>
>>> >> Oracle has already expressed its intent to do what is requested in
>>> point
>>> >> #2 above.   This would allow for compatibility between EE4J releases
>>> and
>>> >> existing Java EE releases at the package level.   We will focus on
>>> points
>>> >> #1 and #3 below.   Why not allow use of the Java EE name, and why not
>>> allow
>>> >> use of the javax.enterprise namespace for all new EE4J technologies?
>>> >>
>>> >> The industry has changed since the Java EE development process was
>>> >> originally created. The process was not seen as being nimble,
>>> flexible or
>>> >> open enough.  Our shared goal is to create a more nimble process,
>>> with more
>>> >> flexible licensing, and more open governance that is not dependent on
>>> a
>>> >> single vendor.  We believe this will encourage more participation and
>>> >> innovation.  We see general support for this new direction from
>>> across the
>>> >> community.
>>> >>
>>> >> This new direction implies many changes, starting with a change in the
>>> >> technology development process.   The Java EE process, or to be more
>>> >> specific, the JCP process that was used for Java EE development, is a
>>> >> highly structured process that grants specification leads significant
>>> >> influence over how technologies are specified and implemented.  The
>>> EE4J
>>> >> process will be different.  It will be more open.  Single vendors
>>> including
>>> >> Oracle will continue to contribute, but will no longer have the same
>>> level
>>> >> of influence over how new EE4J technologies evolve.  We believe there
>>> is
>>> >> consensus that this is a positive step for the community.
>>> >>
>>> >> This new development process drives choices around use of the Java EE
>>> >> name, and use of the javax.* package names for new technologies.  The
>>> Java
>>> >> EE and javax.* names leverage the Java trademark, and indicate that
>>> the
>>> >> source of these technologies is Oracle and community processes
>>> managed by
>>> >> Oracle. As a critical identifier of the source of products to our
>>> users, we
>>> >> must continue to reserve use of such names using the Java trademark to
>>> >> serving that fundamental source identifying function.  This will help
>>> us to
>>>
>> >> maintain the Java trademark, which is in Oracle?s interest and in the
>>> >> community?s interest.  We recognize there are likely to be
>>> requirements to
>>
>>
>>> >> create new versions of existing Java EE specifications that were
>>> already
>>> >> created using the existing JCP process.  We believe we can work out an
>>> >> approach to allow use of javax.* names for extensions to these
>>> existing
>>> >> specifications in order to accommodate these requirements.   However,
>>> if we
>>> >> adopt a new process for new EE4J technologies, as is desired by the
>>> >> community, we believe we must require that a new namespace be used
>>> for the
>>> >> new EE4J technologies that are developed using that process, and a new
>>> >> brand (other than Java EE) that includes these new technologies.
>>> There is
>>> >> a tradeoff here, and we believe that the net benefit of the new
>>> process
>>> >> warrants the adoption of a new namespace for new EE4J technologies,
>>> and a
>>> >> new brand.
>>> >>
>>> >> We will work with the EE4J community to mitigate continuity concerns
>>> that
>>> >> accompany this change.   We are making it very clear that EE4J will
>>> be an
>>> >> evolution of existing Java EE 8 technologies:
>>>
>> >> ?    We are contributing our existing GlassFish Java EE 8 Reference
>>> >> Implementation sources to EE4J.
>>> >> ?    We will contribute our existing TCKs.
>>> >> ?    We are intending to allow certain uses of existing javax
>>> packages as
>>
>>
>>> >> those packages evolve for compatibility.
>>>
>> >> ?    We are intending to allow use of existing specification names for
>>> >> component specifications.
>>> >> ?    We are building an initial EE4J implementation that is intended
>>> to
>>> >> be both Java EE 8 and ?EE4J? compatible.
>>> >> ?    We will work with the EE4J community to promote the new brand.
>>
>>
>>> >>
>>> >> These are positive steps we can take.
>>> >>
>>> >> We support the efforts of the EE4J Project Management Committee to
>>> make
>>> >> branding recommendations to the Eclipse Foundation.  We encourage the
>>> >> community to support the effort as well, and extend thanks to all for
>>> the
>>> >> continued interest in Java EE and EE4J technologies.   And we hope to
>>> >> deliver soon more new projects with GlassFish sources contributed to
>>> EE4J!
>>> >>
>>> >> Thanks
>>> >>
>>> >> Will
>>> >>
>>> >> _______________________________________________
>>> >> 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
>>> >
>>> >
>>>
>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: <https://dev.eclipse.org/mailman/private/ee4j-
>>> community/attachments/20180123/e6b4772f/attachment.html>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Tue, 23 Jan 2018 07:43:25 -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:
>>>         <a8a9bf7f-617a-f71d-76ad-c46f29977e89@eclipse-foundation.org>
>>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>>
>>> 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 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
>>>
>>>
>>> --
>>> 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/f71422a2/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 90
>>> *********************************************
>>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20180123/b346d338/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 96
*********************************************


Back to the top