| Re: [ee4j-community] An open proposal for the direction of future Java EE Naming |
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. 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/ > or on the Java955031112086183941
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
*********************************************