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

[Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>]

On 2018-05-22 4:41 PM, Bill Shannon wrote:

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

Correct.

So you'll update the text to make that explicit?

Done.

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.

And so someone who chooses not to be Compatible won't know what Essential Claims, if any, they don't have the rights to.

Well, strictly speaking even if they are Compatible, they won't know what Essential Claims they do have rights to. But that is no different that the situation than if they had implemented some piece of software without reference to the Specification. As far as I know, the JCP has never asked its participants to list the patents that they are licensing via the JCP. So to me this is just the status quo. Do you think this is an issue?

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.

Right, what I meant was do we want to make that distinction in the document you're writing?

Done.

Would the choice of open source license for the TCK limit what could be done to produce or restrict access to the TCK binary?

I made sure that the license choices included in the list would all allow the re-licensing of binaries. Note that I did not explicitly include EPL-2.0 with Secondary License set to GPLv2+CE. Not because I don't think it was allowed but because it would be superfluous as the the TCK binary would have to be based on selecting the EPL-2.0. If anyone feels strongly that we should like it along with that explanation, that would be fine.

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.

If you want to be able to do that, you'll probably have to restrict the choice of licenses for the TCK, right?  Do you think it's necessary to put the binary under a proprietary license?  Desirable?

I think that the TCK binary needs to be under a non-open source license because there will be terms in there that tie it to branding. Definitely worth more conversation.

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.

The EFTLA could simply require that you "pass" the TCK, where each TCK could define what it means to "pass".  The TCK rules would only apply when using the EFTLA, not when using the TCK under its open source license.  Would that give too much freedom to TCK authors and too little consistency across TCKs?  Or would consistency be enforced by the PMC?

I think that if there are TCK consistency requirements they enforced by the Spec Committee, not the PMC. Basically, the Spec Committee could say "this TCK is not good enough" and refuse to adopt a new Version of a Spec.

But out of curiousity, what is the status quo? Did someone from Oracle or the JCP staff review the TCKs done by Red Hat for its specs to decide whether they met some quality objectives?

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