Re: [jakarta.ee-spec.committee] Recent Edits

[Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx>]

On Tue, May 22, 2018 at 2:47 PM Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:

On 2018-05-22 8:24 AM, Richard Monson-Haefel wrote:

On 2018-05-21 8:22 PM, Bill Shannon wrote:

Mike Milinkovich wrote on 05/21/18 05:00 PM:

---

Participation

Participation in a Specification Project will be limited to parties (the “Participants”) covered under a <<Working Group>> Participation Agreement that will document the intellectual property contributions to the specifications. All Participants with a representative on a Specification Project will grant royalty-free licenses to any Essential Claims (i.e. patent rights) which apply to any Compatible Implementation.

Are Participants always individuals or sometimes companies?  What does "representative" mean in this context?

Participants are generally companies who are Members of the Eclipse Foundation. By may also be individuals who are Committer Members of the Eclipse Foundation and who also sign the Participation Agreement.

Representatives are employees, consultants or officers of Participants.

A Particpant company should be able to, at any time, replace their representative.  This is especially important if the person who is the Representative leaves the Particpant company - espeically if that person is the lead or co-lead or the Particpant has no other Representative on the Specification Project. 

Generally speaking we wanted to follow the Eclipse Development Process and open source rules of engagement for running the Specification Projects. Roughly speaking I was thinking something along these lines (and Wayne in particular has the right to tell me this is bogus):

• When a Specification Project starts, the initial committer list is as normal....the names listed in the proposal at the time of Creation form the initial team. This means that additional names can be added during the review period.
  
• As per usual, each individual's corporate affiliations are listed, and the EF will make sure that all of the requisite paperwork is in place.
• If someone leaves their employer, they can continue to serve on the Specification Project is they want, but their active committer rights are suspended until they have all of their new paperwork in place. If they change employers, that means their new employer would have to become a Participant. If they are individuals, they can follow the individual committer paperwork route.
  
• Once the project gets going, new committers on the Specification Team have to earn their way in via the normal meritocratic processes. This means that if a Participant really wants to change its representative, the incumbent will have to resign and the new representative will have to earn their way in.
• It would be permissible under the EF's rules for the PMC to allow for more relaxed meritocracy requirements for Specification Projects. In particular, demonstrable industry expertise should be recognized.

What you outlined sounds good for implementations such as Glassfish, but not for specification projects.

When a new specification is proposed the vendors that will be expected to implement that specification should be allowed to join the project.  This was usually the case with the JCP which ensured that the vendors had a voice in guiding the specification so that it could actually be implemented and did not favor one vendor over another.  Remember, the specification is not an Implementation but a blueprint for implementations and as such, all parties subject to that blueprint have to agree that the specification can, in fact, be implemented.  

If this you accept this premise than its natural that an organization can be elected to a project as well as an individual.   If an organization (e.g. Red Hat, IBM) is elected to participate in a Specification Project than it makes sense to allow that organization to appoint whomever it feels is appropriate and to be able to replace that person at will.   

Depending on the membership level, an organization should automatically get a seat on any specification project they want but should excercise self-restraint to focus on those specifications germane to their products.  Why, for example, should a company become a strategic member if it cannot have a seat at the table?

• 
  

Also, can a Particpant have multiple representatives on a a Specification Project?

I don't think that there should be an explicit rule that prohibits more than one committer per Participant company. But happy to have someone argue otherwise.

+1

The licenses are granted only to Compatible Implementations of that specification, right?

Correct.

In this case the licenses is the license to use the Specifiation Project’s brand, or the Jakarta EE brand, or both?  What if I create a JMS compliant product that pass the TCK, what license do I agree to and why?

None of the above. You're asking about the use of the specs, and my comment was on the creation of the specs. The license in question here is a royalty free patent license to all patents owned by the Participant which would necessarily be infringed by an implementation of the spec. The questions you should be asking are (a) who are the patent licenses to, and (b) when are those patent licenses effective. In the case of the JCP the patent licenses are to the Spec Lead and they are not granted to downstream implementers until they pass the TCK. In this context, we may want to choose a different approach. Steve Millidge's preference, for example, would be that the patent licenses are granted to any Compatible Implementation. The question then becomes: are those patent rights granted when the implementation passes the TCK, or are they provided to anyone implementing the specification while they're implementing it? Under the JCP, the fact that the patent rights don't vest until the TCK is passed has been used in some discussions to say that open source implementations are suspect since they are exposing their implementations before they have any patent grants. YMMV.

Thanks for the clarification I’m not sure about the later question as to when the patents are granted but I think it should be assumed that if you implement the specification that you are granted the patents.  If vendors are allowed to “self certify” against the TCK binary (or whatever you call it) without paying a fee to pass the TCK then you could require that they also pass the TCK to be given IP rights.

For each Specification Version there will be a single corresponding TCK version which must be used to test each Compatible Implementation

Do you want to distinguish between the source code in the TCK project and the separate and fixed TCK bundle that is used to test for compatibility with a specific version of the spec?  Both of which will be available under an open source license?

We can do this a couple of ways. But ultimately there is a checksummed, unique binary that is the only one that can be used to verify a Version. In fact, that "special" TCK binary could be made available only to Participants, or some other restrictions.

The TCK is going to be open source, so anyone should be able to run their product against the TCK and claim compliance in self certification.  The TCK can not be restricted to only Particpants who pay - that’s how it was done under the JCP and it hurt competition.

Under the JCP they paid license royalties. In the new case we're thinking that they at least need to be Members. Otherwise, how is the system sustainable?
There is a different issue with the above. When you say "claim compliance in self certification", what are they claiming compliance to? If they don't have some sort of trademark license, I don't see how they can claim they're compatible with Jakarta EE. And we want lots of organizations to claim they're Jakarta EE compatible to raise the value of the brand in the marketplace.

I don’t think vendors should be required to pay for the right to claim compliance with the specifications.  If they are members and are compliant, than they should be able to use the Jakarta EE brand without further costs.  If your product passes the TCKs, its compliant, but you can’t use the Jakarta EE brand without also being a member. End of story.  Compliance and the Brand are separate but related in this case.

The EF is sustained by the members. Certain member levels gets an automatic seat at any Specificaiton Project they want, that’s the attraction to the higher membership.  I do not want to see a situation where the price for compliance is a barrier to claiming compliance. Compliance should be a technical issue not a source of income for the EF.  Income for the EF is obtained from Membership, not licensing the IP.   

Specification Documents will be made available under an Eclipse Foundation Specification License (EFSL) that will clearly license all necessary copyright rights to enable independent implementations.

The Brand will be licensed by the Eclipse Foundation for Compatible Implementations of Profiles using an Eclipse Foundation Trademark License Agreement (EFTLA). This EFTLA will contain some TBD commercial terms to ensure the sustainability of working groups which have adopted the specification process. The EFTLA will also be the mechanism by which Compatible Implementations are licensed all patent rights granted by the Participants.

What about specifications defined outside the Eclipse Foundation?  Wasn’t the CDI, MVP, and BeanValidation specifications defined outside the JCP?   It should be possible to define a specifications outside the EF which can be accepted as the standard within Jakarta EE.

Honestly, this use case is driving me crazy trying to figure out how it can be done.

Having the Specification done elsewhere was a workaround for the Spec Lead problem in the JCP. And I don't think it works without a Spec Lead which accumulates the IP rights. Given the open IP flows under this new process, I cannot for the life of me figure out how it is even possible "...to define a specifications outside the EF which can be accepted as the standard within Jakarta EE...". Seriously. Think about it. I don't see how this works without an all powerful Spec Lead. Maybe someone smarter than I has a suggestion?

I don’t have a solution, but the reason - as I understand it - that specifications were defined outside the JCP is that the JCP was not working.  I’m not sure if that will be an issue when it comes to the EF or not.  I would have to see how all the other policies around specification defintion, maintainence, acceptance is handled.

Actually, I think that has to be the case since so many of the technologies used are specified outside the EF.  For example, the HTTP Servlet is dependent on the HTTP specification which is defined by the W3C. Requiring all referenced specifications to be defined by the EFSL won’t work in that case or in others.

This is actually a different use case than the one above. The JCP had processes by which Java bindings to specs created elsewhere could be constructed. We will need to handle this case, but I think the one above is more fundamental.

Understood.

_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee

--

Richard Monson-Haefel
http://twitter.com/rmonson
http://www.tomitribe.com
http://www.tomitribe.io