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

[Mark Little <mlittle@xxxxxxxxxx>]

IP flow is very important. However, if we come up with a process that
is driven solely by that aim and the end result is something that
prevents code-first development and rapid iteration then I think we
need to go back to the drawing board. Or put another way, let's make
it clear that IP flow is only as important as code-first development.

Mark.

On Fri, Jun 1, 2018 at 4:29 AM, Mike Milinkovich
<mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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.
>
> 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.
> 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.
>
>
>
>
> _______________________________________________
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
>