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