Re: [jakarta.ee-spec.committee] Interaction Between Code-First and Speci

[Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>]

FWIW, I think that we have strayed quite a distance from stating requirements.

It is a requirement that it be possible that specifications can be co-developed along with multiple implementations. It is also a requirement that we be able to start specs from existing open source projects at Eclipse and other well-managed open source hosts such as the ASF.

To address Bill's original assertion, there are two things happening which I think *do* permit the co-development of implementations and specs. At least in certain communities, using certain licenses.

1. The lawyers seems to be comfortable that you can take an API from an Apache-licensed project and derive a spec document from that under copyright law. The patent grants don't extend, but the idea is that every company involved in the spec project will be granting what patents they have. So clean on the copyright side, and as long as we have some significant patent holders involved, we have some patent aircover. Not bulletproof, but pretty good.
2. The Eclipse Foundation is going to refresh its committer and contribution agreements to say that all contributors agree that their contributions can be used to create specifications. This is a different path to the same result as in #1 above.
   

I appreciate that MicroProfile is a working example of what we aspire to, as it is making great and rapid progress. However, it is not a "real" spec process in that there are no rights granted that enable independent implementations[*]. It works great because everyone gets along. It could totally be gamed by a bad actor.  As part of this process we are going to get a license to the existing Java specification names and namespaces. AIUI that license is at least partially contingent upon Oracle being confident that the new spec process will handle IP flows in a way that they consider appropriate. As in they would be confident in building future products relying upon specs from this process, and that the value of the Java brand will not be harmed. There is zero chance that the current MicroProfile process will meet that test.

[*] Repeat of earlier email

Contributions to open source come with a royalty-free patent license for all of the contributor's patents that read on their contributions or the combination of their contributions and the program as of the day the contribution is made. The patent license applies solely to the implementation the contributions are made to, or derivative works thereof. This is a quite limited royalty-free patent license.

Contributions to open standards (at least the way we're going to do it) come with a royalty-free patent license for all of the contributor's patents that would necessarily be infringed by anyimplementation of the entire standard. So the patent license is not related to their contributions; it is related to the scope of the specification. This is a much broader royalty-free patent license. It also explains the lawyerly interest in the scope statement for a specification.

On 2018-05-31 8:39 AM, Mark Little wrote:

I think so too and importantly so does the community. It's vitally
important we bring a vibrant community to Jakarta EE and whilst I'm
not going to suggest that the MicroProfile way of doing this is the
best it has kind of evolved in precisely the same way we're talking
about here for specs: problem statement, likeminded people hacking
away at options and then we have what we have today and can even
continue to evolve it by community participation. Depending how you
look at it you could see this as "very meta" or recursive ;)

Mark.

On Thu, May 31, 2018 at 1:33 PM, Richard Monson-Haefel
<rmonson@xxxxxxxxxxxxx> wrote:

+1.  I’m pretty sure this is how it’s been done with MicroProfile and that
effort seems to have moved along really well.

On Thu, May 31, 2018 at 5:50 AM Mark Little <mlittle@xxxxxxxxxx> wrote:

Why does that have to be done through a specification though? Why couldn’t
it be done through a discussion between likeminded individuals, groups or
vendors who share the same problem, have different proposed solutions, go
away and try them, then come back at some time (perhaps pre-determined) to
share their experiences and move forward to standardise what works? Now that
problem statement and the range or proposed solutions should be documented
somewhere and I suppose we could call it an “alpha release of the
specification” or maybe just on a wiki or mailing list or google doc or
something else.

Mark.


On 31 May 2018, at 07:46, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:

While there will always be product-specific features, some of which might
make
their way into future versions of the specification, wouldn't it also be
nice if
multiple independent implementations of new functionality could be created
simultaneously to experiment with the new features in different contexts
and
with different customers?  I just don't see how to do that without having
some
sort of specification being developed at the same time as the
implementations.