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