Mike Milinkovich wrote on 05/22/2018 08:01 PM:
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?
With the JCP, there were never supposed to be any implementations
that weren't compatible. With this new model, compatibility is
explicitly optional, and thus there will certainly be
implementations that aren't compatible. Whether this will be an
issue for those implementations, I don't know, but I thought it was
worth pointing out.
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.
I'll be interested to see what others think of that.
That would give you a way to enforce additional TCK rules without
putting them in the EFTLA.
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.
(I guess at this point I'm thinking of the Spec Committee as more
like the JCP PMO - defining the rules that we'll operate under.
You're suggesting that it will also operate more like the JCP EC -
approving all the specs. The advantage and the disadvantage of
doing both in one group is that the written rules can be less
precise and complete because you can always impose ad hoc rules as
you run into problems.)
Anyway, would you expect the Spec Committee to define the
TCK consistency requirements, or just to enforce the
requirements defined by some other group?
If the spec process is reusable by other Eclipse projects, should
the TCK requirements be defined in some Jakarta EE specific group,
instead of in the group that defines the spec process for all of
Eclipse?
Basically, the Spec Committee could say "this TCK is not good
enough" and refuse to adopt a new Version of a Spec.
"Not good enough" is different than "not consistent with other
TCKs". And of course you want to set expectations in this area
before the TCK is started, not after it thinks it's complete.
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?
No, that was the job of the EC.
|
