Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] How to name implementation of javax.* and jakarta.* APIs? 
Hi all,

If we allow it, i will tell you a little history.

Today, I have searched using JAXB artefact on jakarta.
I have gone on maven central. What my surprise because i don't found it.
knowing that it exists, I continue. And finally, i found it. This name is jakarta.xml.bind-api:jakarta.xml.bind-api 

I can understand the name change javax to jakarta.

Why we must change acronyms ?
I am thinking in particular of JPA, JAXRS, CDI.
Personally, at my level, I campaigned for the use of JPA instead of specific implementations. 

For JAXRS, on maven central, we have more 688 pages of artefacts.
Not to mention the lack of documentation on the web because the new acronym will be unknown. 

---
Regards,
Lilian BENOIT


Le 22/05/2019 22:47, Bill Shannon a écrit :

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.

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 [1]".

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



Links:
------
[1] https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ 
_______________________________________________
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

Back to the top