|
On 2019-05-24 4:43 p.m., Lilian BENOIT
wrote:
Thanks Mike
for this clarification.
We will be interest to knowing if we could use acronyms for
future.
Unfortunately, that is a more complicated question. It is clear
that Oracle would prefer that we do not.
For
example, JPA or JMS. Jakarta could replace Java . It was spirit of
blog post
https://blogs.eclipse.org/post/wayne-beaton/renaming-java-ee-specifications-jakarta-ee
CDI haven't the word Java in its acronym. Why should we change it
?
A other example is JAX-RS, using a new acronyms will be harmful
more that renaming package.
For developers, he should looking for Jakarta REST (one
proposition in mailing-list) on Internet. He will found no
information or little. All information (Documentation, tutorial,
answer) of JAX-RS will be lost.
Regards,
Lilian.
Le 24/05/2019 17:12, Kevin Sutter a écrit :
Thanks for the insights, Mike! I hope we
can now put this package
naming issue to bed... I'd still like to discuss the use of
acronyms
in documentation -- both Specifications and vendor
documentation.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter [1]
From: Mike Milinkovich
<mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
To: jakartaee-platform-dev@xxxxxxxxxxx
Date: 05/24/2019 09:32 AM
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] How to
name
implementation of javax.* and jakarta.* APIs?
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
-------------------------
On 2019-05-22 4:47 p.m., Bill Shannon wrote:
I don't think we want to encourage the continued use of acronyms
that
refer to the Oracle technology.
The Eclipse folks know how much fun it has been dealing with
Oracle
legal, and they're the ones in the crosshairs if this is done
wrong,
so maybe they should be the ones to decide just how far this
renaming
needs to go.
The clear advice that I heard from the Oracle lawyers (and our
own)
was that a namespace such as jakarta.ejb is perfectly fine.
Scott Stark wrote on 5/22/19 1:19 PM:
When I asked our legal team for their opinion on this, they
thought
the idea of trademarks in package or class names as something
that
should cause confusion and possibly require a trademark license
was to
put it kindly, far fetched.
This is introducing unnecessary technical problems due to name
churn,
so unless Oracle is going to present a legal request that states
all
of the allowed disallowed sub packages under jakarta.*, we are
only
going to accept that the heretofore understood translation of
javax to
jakarta is the only translation that needs to happen at the code
level.
On May 22, 2019, at 12:48 PM, Bill Shannon
<bill.shannon@xxxxxxxxxx>
wrote:
IANAL
Nothing in trademark law has changed relative to the use of
these
names or acronyms in implementation packages.
My understanding is that if you're using (e.g.) "EJB" in a way
that
references Oracle's Enterprise JavaBeans technology, and you're
using
it in a way that trademark law would consider "fair use", then
you're
ok.
If you're using "EJB" to refer to something this is not Oracle's
Enterprise JavaBeans technology, and using it in a way that
might
cause confusion in the marketplace, that would be an issue.
We can keep trying to interpret trademark law, and keep looking
for
loopholes, but my advice is to just avoid the issue as much as
possible and concentrate on more important technical problems.
Scott Stark wrote on 5/22/19 10:36 AM:
That does not help with nuances that have come up within the
specification committee with respect to usage like:
1. In the Big Bang approach, there is an assumption that
javax.ejb
would translate to jakarta.ejb, javax.jms to jakarta.jms, etc.
Some
have indicated that this is not allowed as even the ejb and jms
sub
packages are not allowed to be used. If true, this complicates
any
tooling and compatibility mapping layers.
2. A further variation on this is an implementation package such
as
org.jboss.ejb.
Does the Eclipse Foundation have.a view on these uses?
On May 22, 2019, at 4:53 AM, Mike Milinkovich
<mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Strictly speaking the Eclipse Foundation does *not* have a
trademark
agreement with Oracle. We have a copyright license, but have no
special rights whatsoever to any of Oracle's trademarks.
However, the salient point from my perspective is what I wrote
in my
blog post "Update on Jakarta EE Rights to Java Trademarks [2]".
In addition to the above, any specifications which use the javax
namespace will continue to carry the certification and container
requirements which Java EE has had in the past. I.e.,
implementations
which claim compliance with any version of the Jakarta EE
specifications using the javax namespace must test on and
distribute
containers which embed certified Java SE implementations
licensed by
Oracle. These restrictions do not apply to Jakarta EE
specifications
which do not utilize javax, including future revisions of the
platform
specifications which eliminate javax.
This means that any Jakarta EE *specifications* that contains
even a
single javax namespace has Oracle-imposed runtime restrictions
that
may or may not be good for the community.
From the point of view of an implementer, I don't think that
there
would be any restrictions on claiming that a single version of
Eclipse
Jetty supports both Jakarta EE 8 (using javax) and Jakarta EE 9
(perhaps 100% using jakarta).
Does that help?
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
[3]
Links:
------
[1] https://www.linkedin.com/in/kevinwsutter
[2]
https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/
[3]
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|
