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

[Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>]

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.

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

Correct.

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

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.

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.

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