|
If "Force" was the wrong word, then it could be "Require". Do we need to restart the poll for that? Would changing the word here influence anyone's vote?
I wanted to pose two simple positions so we could get a sense of what the overall position is of the group. I felt giving more options and trying to cover every aspect in a simple straw poll would not necessarily help move the discussion forward.
Tom
From: Abraham Marin-Perez <abraham.marin.perez@xxxxxxxxx>
Sent: Friday, July 11, 2025 4:38 PM
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Cc: Thomas Watson <tjwatson@xxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakarta.ee-spec.committee] [Straw poll] namespace policy for existing specifications moving to the Jakarta specification project
Related to Thomas's comment, I think options 1 and 2 are two extremes and, personally, I'd favour an option in the middle (also removing "Force", I agree with Ivar on this): option 1. 5: Existing specification projects to move
Related to Thomas's comment, I think options 1 and 2 are two extremes and, personally, I'd favour an option in the middle (also removing "Force", I agree with Ivar on this):
option 1.5: Existing specification projects to move all of their API package namespaces to jakarta at their next major release after they've moved to the Jakarta specification project
This preserves the Jakarta brand without causing immediate trouble to users, at least until the next major release where compatibility issues aren't unexpected.
Any time existing technologies are moved to an Eclipse project there must be a trademark review by the foundation. At that point the foundation determines what is possible with the existing namespace from the perspective of the foundation's policies. I was
closely involved in exactly this situation when the OSGi Alliance moved all of its specification technologies to the Eclipse OSGi specification project. In that case it was decided OSGi can keep their namespace org.osgi. To do otherwise would have been senseless
to the existing users of the OSGi APIs and would have resulted OSGi deciding to not use the foundation as a home.
The Jakarta specification project cannot control the trademark concerns that would require a change of namespaces when there is a trademark issue. But we can setup a set of policies that make Jakarta more attractive for existing technologies to consider using
Jakarta as a home.
Tom
I think we need to be pragmatic and acknowledge that option 2 can only happen if the Eclipse Foundation either has the trademark for the namespace or is granted full rights to the trademark of the namespace. For example if Spring folks wanted
I think we need to be pragmatic and acknowledge that option 2 can only happen if the Eclipse Foundation either has the trademark for the namespace or is granted full rights to the trademark of the namespace. For example if Spring folks wanted to donate a spec,
the legal on that would be very costly as they'd want to retain control of general use of trademark while needing carve out what use they'd allow from a spec with their name.
We have no issue in that regards with MicroProfile, so we're good there. I'd really be more comfortable with a to-the-point vote on allowing org.eclipse.microprofile vs a generic policy that goes about it in a round-about way that creates additional problems.
Namespaces are trademarks and we really need to think like lawyers when drafting any sort of "bring your own trademark" rule.
Again, MicroProfile's namespace is ok from a trademark perspective, but that's more an exception and not the typical rule.
My vote would be:
- option 4: We prefer jakarta namespaces and evaluate exceptions on a case-by-case basis
David
As discussed at the July 9th meeting, we decided to do a straw poll to determine the specification committee group's opinion on package namespaces used by specifications wanting to move to the Jakarta specification project.
Please respond to this straw poll by July 23, 2025 so we can discuss results at the next specification committee meeting.
For existing specification projects that wish to move to the Jakarta specification project select one of the following options:
option 1: Force the existing specification projects to move all of their API package namespaces to jakarta when they move to the Jakarta specification project
option 2: Allow existing specification projects to retain their own existing package namespaces when they move to the Jakarta specification project
option 3: no preference
Tom Watson
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
