Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec.committee] Recent Edits

On Mon, May 21, 2018 at 7:46 PM Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Bill,

Thanks. Excellent questions.


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.  

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





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?



Will there be any tracking of Essential Claims that apply to a given specification?

No. I don't think anyone wants to maintain lists of patents. The idea is simply that if you participate and own a patent that applies, you can never sue the author of a Compatible Implementation.


Branding and Certification

There may be multiple Specification Implementations. Compatible Implementations may make use of Specification Implementations.

TCKs must be made available under an open source license.

Any open source license?

We can decide on a list if we want. At a minimum I think we're already using EPL-2.0, EPL-1.0 (maybe?), BSD-3-Clause, APACHE-2.0, and GPL-2.0 with Classpath Exception. If we wanted to we could state a list and then say any exceptions would have to be unanimously approved by the Steering Committee. (This mimics the approach to alternate licensing at the Eclipse Foundation itself.)

+1



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. 


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


If the TCK is open source, which license will be used to enforce rules around the use of the TCK to prove that an implementation is compatible?  The EFTLA? 

My strawman proposal is the EFTLA. Happy to consider alternate approaches.
FWIW, the EPL-2.0 does allow for binaries to be put under a different license, including proprietary ones.

Will those rules thus be decided by EF and consistent across all TCKs from all projects?

Well that's actually a tough question. The JCP allowed Spec Leads to license TCKs as they saw fit. Red Hat uses the ALv2 for its TCKs for example. So this definitely has to be discussed. But I am searching for solutions which are consistent. The JCP Spec Lead approach is *not* going to work at the Eclipse Foundation because there is no Spec Lead which acquires special IP rights. So what worked before will not necessarily work here.

--
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
(m) +1.613.220.3223

_______________________________________________
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

Back to the top