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?
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.
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