<div dir="ltr">In most cases if the Spec Lead is a large company they need to consult their legal team.<div>Regarding the source code vs. attached "shrinkwrap" license, it gets a lot more complex, especially for Umbrella JSRs like Java EE. There the majority of users won't bother looking at hundreds or thousands of source files including JSR 330, CDI or other components including EJB, JSF, etc. or JMS (<a href="https://jcp.org/en/jsr/detail?id=343">https://jcp.org/en/jsr/detail?id=343</a>) There you'll see, even the RI/TCK license is not Apache or GPL/CPE, but a commercial Oracle License that's far more restrictive. </div>
<div><br></div><div>Martijn is not in this thread any more, and there is no need to add him, but as he mentioned doing a WebSocket project for SE, it would be interesting to hear, if he uses JSR 356 (<a href="https://jcp.org/en/jsr/detail?id=356">https://jcp.org/en/jsr/detail?id=356</a>) That and a few others have 3-4(!) different licenses for RI/TCK alone, depending on usage or the commercial product it's used in. </div>
<div><br></div><div>So from that point of view despite all critical voices (they'll be able to discuss this or try improve points they may find unacceptable) aiming for a single, unified license for ALL RI and TCK seems a good intention and won't put users at risk of surprises if they use an API like WebSockets or JBatch (or even CDI) standalone as opposed to a large platform or umbrella JSR.<br>
</div><div><br></div><div>Werner</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 4, 2014 at 8:11 AM, Jens Schumann <span dir="ltr"><<a href="mailto:jens.schumann@openknowledge.de" target="_blank">jens.schumann@openknowledge.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Von: Werner Keil <<a href="mailto:werner.keil@gmail.com">werner.keil@gmail.com</a>><br>
Datum: Friday 4 July 2014 00:46<br>
An: Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br>
Cc: Reza Rahman <<a href="mailto:reza.rahman@oracle.com">reza.rahman@oracle.com</a>>, Arun Gupta<br>
<<a href="mailto:arungupta@redhat.com">arungupta@redhat.com</a>>, Badr Elhouari <<a href="mailto:badr.elhouari@gmail.com">badr.elhouari@gmail.com</a>>, Adam Bien<br>
<<a href="mailto:abien@adam-bien.com">abien@adam-bien.com</a>>, CDI-Dev <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>>, Eisele Markus<br>
<<a href="mailto:Markus@eisele.net">Markus@eisele.net</a>><br>
Betreff: Re: [cdi-dev] About JSR 330.Next and CDI 2.0<br>
<div class=""><br>
<br>
>In a majority of cases, not just Oracle but also other vendors from a<br>
>legal point still live and practice a "Shrinkwrap mindset", so the only<br>
>license that counts is the one you see when you "open the box". Or<br>
>download artifacts from JCP or a similar place.<br>
<br>
</div>Well, this might be their mindset. However European IP law treats this<br>
quite different and has a strict understanding for doing so (I avoid the<br>
c-word here on purpose). I assume US IP law is quite similar in this<br>
regard - especially in the area of author/copyright owner rights,<br>
exploitation rights, etc.<br>
<br>
I am not familiar with JCP/EC/Oracle/Sun/... internals. Nevertheless I<br>
have been in a legal battle that covered both source code disclaimers and<br>
"intended contractual purpose that lead to the source". Since both did not<br>
match at some point we had to exchange arguments via lawyers. And - at no<br>
surprise - it turned out that European/German IP law is pretty simple and<br>
works just like Mark wrote in his mails before;).<br>
<br>
Of course there are issues if source code is created as an result of an<br>
specification process (say - paper was first). However it won¹t break<br>
source code copyrights and attached licenses, particularly in the case of<br>
JSR-330.<br>
<br>
<br>
Let¹s hope things can be sorted out without lawyers,<br>
Jens<br>
<br>
</blockquote></div><br></div></div>