Mailing-List: contact legal-discuss-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: legal-discuss@apache.org
MIME-Version: 1.0
In-Reply-To: <CA+nPnMwhqMDAqdhA6UNdtGt7YD027i936=e0G=PDeE69SY2nVg@mail.gmail.com>
References: <CA+nPnMwhqMDAqdhA6UNdtGt7YD027i936=e0G=PDeE69SY2nVg@mail.gmail.com>
From: Stephen Connolly <stephen.alan.connolly@gmail.com>
Date: Thu, 1 Dec 2016 13:13:15 +0000
Message-ID: <CA+nPnMya95F7-bLKQPq+g-HxK-_YXAqqTw1w09U9vSDaSYd6pg@mail.gmail.com>
Subject: Re: JSR-305 anntations
To: "legal-discuss@apache.org" <legal-discuss@apache.org>
Content-Type: multipart/alternative; boundary=047d7b86caf8a6e47a05429895e0
archived-at: Thu, 01 Dec 2016 13:13:30 -0000

--047d7b86caf8a6e47a05429895e0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Is this something we need to worry about?

To make this more concrete - and I am not picking on hadoop, just the first
example I could find - Consider Hadoop Common 2.7.1:

https://repo.maven.apache.org/maven2/org/apache/hadoop/hadoop-common/2.7.1/=
hadoop-common-2.7.1.pom

This has a compile scoped dependency on the annotation jar:

<dependency>
  <groupId>com.google.code.findbugs</groupId>
  <artifactId>jsr305</artifactId>
  <scope>compile</scope>
</dependency>

Now in and of itself, that is not a problem for the Hadoop project...

Now somebody else turns around and reuses Hadoop to create a Docker image..=
.

Not picking on anyone in particular, just the first image I found:

https://github.com/sequenceiq/hadoop-docker

If we look at what is included in that image:

$ docker run -t -i  sequenceiq/hadoop-docker:2.7.1 bash
bash-4.1# java -XshowSettings:properties -version
Property settings:
...
    java.vendor =3D Oracle Corporation
...
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
bash-4.1# find . -name jsr305\*.jar
./usr/local/hadoop-2.7.1/share/hadoop/yarn/lib/jsr305-3.0.0.jar
./usr/local/hadoop-2.7.1/share/hadoop/tools/lib/jsr305-3.0.0.jar
./usr/local/hadoop-2.7.1/share/hadoop/common/lib/jsr305-3.0.0.jar
./usr/local/hadoop-2.7.1/share/hadoop/kms/tomcat/webapps/kms/WEB-INF/lib/js=
r305-3.0.0.jar
./usr/local/hadoop-2.7.1/share/hadoop/hdfs/lib/jsr305-3.0.0.jar
./usr/local/hadoop-2.7.1/share/hadoop/httpfs/tomcat/webapps/webhdfs/WEB-INF=
/lib/jsr305-3.0.0.jar

Oh dear... that docker image is redistributing the Oracle JRE *and* it is
also redistributing 6 copies of a jsr305.jar which would appear to be in
direct conflict with the redistribution terms of the Oracle JRE

It would seem by including that jar file we are not making it easy for
third parties to consume our projects.

Now yes, most likely the person who created that docker image was ignorant
of the fact that they were redistributing a JRE and may not have therefore
read the redistribution terms...

But even if they had, have we made it easy for consumers of our projects to
be aware that the jar may be banned under the terms of the Oracle JRE
redistribution license?

Can somebody redistributing Hadoop know that it is safe to remove all those
jsr305.jar files?

So hopefully a more concrete question will prod somebody to at least
consider the questions.

(BTW the fix for the docker image is probably to switch to OpenJDK which is
a tested JRE for Hadoop... but that assumes that the trademark licensing
terms for Java do not bring back in a similar issue)

-Stephen

---------- Forwarded message ----------
From: Stephen Connolly <stephen.alan.connolly@gmail.com>
Date: 27 November 2016 at 22:05
Subject: JSR-305 anntations
To: "legal-discuss@apache.org" <legal-discuss@apache.org>


The recent hubub over the license terms has prompted me to raise a
question. The driver was a statement that a principle of the ASF is that we
should minimise restrictions on how software released by the ASF can be
used by others.

My question concerns the "JSR-305" annotations JAR files:
https://search.maven.org/#artifactdetails%7Ccom.
google.code.findbugs%7Cjsr305%7C3.0.1%7Cjar

I need to establish some context first.

JSR 305: https://jcp.org/en/jsr/detail?id=3D305

This JSR was set up to develop a standard set of annotations that can
assist defect detection tools.

The JSR appears effectively dead. It has not produced anything officially
in the 10 years since it was initiated.

There are some JAR files floating around that "claim" to represent the
JSR... they are produced by the findbugs project (which is run by the spec
lead for the JSR)... so they may indeed represent the vision that Bill has
for the JSR... but until they are published via the JSR page, my
understanding is that such JAR files are just rumour... the fact that these
JARs include a @Nonnull annotation which is distinct from the stated intent
on the JSR page to have a @NonNull annotation further highlights how the
JAR is at odds with the official JSR process.

Now I am not criticising Bill here, I am just point out that - IANAL but it
would seem to me - perhaps legally and certainly technically there has not
been any releases from JSR 305

Now what does this matter to the ASF. Findbugs is not an ASF project...
being mostly GPL licensed... with the exception of the annotations. So the
jsr305 JAR is Apache License, Version 2 which should be completely
compatible with our license ;-)

The problem is here:

http://www.oracle.com/technetwork/java/javase/terms/license/index.html

Specifically (although there are other relevant sections, this is the
primary concern):

F. JAVA TECHNOLOGY RESTRICTIONS. You may not create, modify, or change the
behavior of, or authorize your licensees to create, modify, or change the
behavior of, classes, interfaces, or subpackages that are in any way
identified as "java", "javax", "sun", =E2=80=9Coracle=E2=80=9D or similar c=
onvention as
specified by Oracle in any naming convention designation.

As I understand it, what the JRE binary redistribution terms mean that if
you are redistributing at least an Oracle JRE, you are not allowed to
include classes in the "java" or "javax" package space *unless* those
classes have been released through the JSR process...

And the "JSR-305" JAR file contains just that.

So the questions:

Q1. Should ASF projects be bundling the "jsr305.jar" in any of their
'convenience' binaries? (if we do, then that restricts the ability of
others to use those binaries)... I think the answer is no... but I am a
pedant!
Q2. Should ASF projects be exposing the "jsr305.jar" as a transitive
dependency? (if we do, then that restricts the ability of others to use
those projects)... I think the answer is no... but I am a pedant!

To be clear, as I understand it, if you create a Docker image that includes
a JRE and happens to also have the "jsr305.jar" then my reading of the JRE
binary redistribution license terms would seem to say "you do not have a
license to redistribute that Docker image"

Q3. "change the behaviour of" seems somewhat broad, is it broad enough that
the dynamic references to the "jsr305.jar" annotations that are left when
you compile a Java class would fall into scope.

So how does Q3 come into effect.

If I annotate a method with say @Nonnull

public class Widget {
...
@javax.annotation.Nonnull(when=3Djavax.annotation.meta.When.ALWAYS)
public static Widget getInstance() {
...
}
}

That will encode the bytecode for the annotation into Widget.class

If we load that up in a JRE and the annotation classes are not available
(because we stripped them from the redistributable so we could ship the JRE
binaries) then the JRE is supposed to ignore the annotations...

But what happens if JSR-305 ever reboots... or if some other JSR project
gets fed up waiting and produces a @Nonnull(when=3Djavax.
annotation.When.PERMANENTLY)

The inclusion in our bytecode of the annotation will change that annotation
behaviour such that any JRE code that uses the annotation will now see
something like sun.reflect.annotation.EnumConstantNotPresentExceptionProxy
rather than the enum value.

So, Q3 basically boils down to... since we don't know what a future JSR-305
or even some other future JSR may do... including the annotation bytecode
in our own bytecode could have the effect of changing the behaviour of code
in the java or javax package namespace... so can we even use the
"jsr305.jar" at compile time and then remove the jar but still cause issues
for anyone consuming our software?

I think Q3 may need a legal opinion from legal person who also understands
how Java bytecode works...

Oh fun eh!

-Stephen

--047d7b86caf8a6e47a05429895e0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Is this something we need to worry about?<div><br></div><d=
iv>To make this more concrete - and I am not picking on hadoop, just the fi=
rst example I could find - Consider Hadoop Common 2.7.1:</div><div><br></di=
v><div><a href=3D"https://repo.maven.apache.org/maven2/org/apache/hadoop/ha=
doop-common/2.7.1/hadoop-common-2.7.1.pom">https://repo.maven.apache.org/ma=
ven2/org/apache/hadoop/hadoop-common/2.7.1/hadoop-common-2.7.1.pom</a><br><=
/div><div><br></div><div>This has a compile scoped dependency on the annota=
tion jar:</div><div><br></div><div><div>&lt;dependency&gt;</div><div>=C2=A0=
 &lt;groupId&gt;com.google.code.findbugs&lt;/groupId&gt;</div><div>=C2=A0 &=
lt;artifactId&gt;jsr305&lt;/artifactId&gt;</div><div>=C2=A0 &lt;scope&gt;co=
mpile&lt;/scope&gt;</div><div>&lt;/dependency&gt;</div></div><div><br></div=
><div>Now in and of itself, that is not a problem for the Hadoop project...=
</div><div><br></div><div>Now somebody else turns around and reuses Hadoop =
to create a Docker image...</div><div><br></div><div>Not picking on anyone =
in particular, just the first image I found:</div><div><br></div><div><a hr=
ef=3D"https://github.com/sequenceiq/hadoop-docker">https://github.com/seque=
nceiq/hadoop-docker</a><br></div><div><br></div><div>If we look at what is =
included in that image:</div><div><br></div><div>$ docker run -t -i =C2=A0s=
equenceiq/hadoop-docker:2.7.1 bash<br></div><div>bash-4.1# java -XshowSetti=
ngs:properties -version<br></div><div><div>Property settings:</div><div>...=
</div><div>=C2=A0=C2=A0 =C2=A0java.vendor =3D Oracle Corporation<br></div><=
div>...</div><div>java version &quot;1.7.0_71&quot;</div><div>Java(TM) SE R=
untime Environment (build 1.7.0_71-b14)</div><div>Java HotSpot(TM) 64-Bit S=
erver VM (build 24.71-b01, mixed mode)</div></div><div><div>bash-4.1# find =
. -name jsr305\*.jar</div><div>./usr/local/hadoop-2.7.1/share/hadoop/yarn/l=
ib/jsr305-3.0.0.jar</div><div>./usr/local/hadoop-2.7.1/share/hadoop/tools/l=
ib/jsr305-3.0.0.jar</div><div>./usr/local/hadoop-2.7.1/share/hadoop/common/=
lib/jsr305-3.0.0.jar</div><div>./usr/local/hadoop-2.7.1/share/hadoop/kms/to=
mcat/webapps/kms/WEB-INF/lib/jsr305-3.0.0.jar</div><div>./usr/local/hadoop-=
2.7.1/share/hadoop/hdfs/lib/jsr305-3.0.0.jar</div><div>./usr/local/hadoop-2=
.7.1/share/hadoop/httpfs/tomcat/webapps/webhdfs/WEB-INF/lib/jsr305-3.0.0.ja=
r</div></div><div><br></div><div>Oh dear... that docker image is redistribu=
ting the Oracle JRE *and* it is also redistributing 6 copies of a jsr305.ja=
r which would appear to be in direct conflict with the redistribution terms=
 of the Oracle JRE</div><div><br></div><div>It would seem by including that=
 jar file we are not making it easy for third parties to consume our projec=
ts.</div><div><br></div><div>Now yes, most likely the person who created th=
at docker image was ignorant of the fact that they were redistributing a JR=
E and may not have therefore read the redistribution terms...</div><div><br=
></div><div>But even if they had, have we made it easy for consumers of our=
 projects to be aware that the jar may be banned under the terms of the Ora=
cle JRE redistribution license?</div><div><br></div><div>Can somebody redis=
tributing Hadoop know that it is safe to remove all those jsr305.jar files?=
</div><div><br></div><div>So hopefully a more concrete question will prod s=
omebody to at least consider the questions.</div><div><br></div><div>(BTW t=
he fix for the docker image is probably to switch to OpenJDK which is a tes=
ted JRE for Hadoop... but that assumes that the trademark licensing terms f=
or Java do not bring back in a similar issue)</div><div><br></div><div>-Ste=
phen</div><div><br></div><div><div class=3D"gmail_quote">---------- Forward=
ed message ----------<br>From: <b class=3D"gmail_sendername">Stephen Connol=
ly</b> <span dir=3D"ltr">&lt;<a href=3D"mailto:stephen.alan.connolly@gmail.=
com">stephen.alan.connolly@gmail.com</a>&gt;</span><br>Date: 27 November 20=
16 at 22:05<br>Subject: JSR-305 anntations<br>To: &quot;<a href=3D"mailto:l=
egal-discuss@apache.org">legal-discuss@apache.org</a>&quot; &lt;<a href=3D"=
mailto:legal-discuss@apache.org">legal-discuss@apache.org</a>&gt;<br><br><b=
r><div dir=3D"ltr">The recent hubub over the license terms has prompted me =
to raise a question. The driver was a statement that a principle of the ASF=
 is that we should minimise restrictions on how software released by the AS=
F can be used by others.=C2=A0<div><br></div><div>My question concerns the =
&quot;JSR-305&quot; annotations JAR files:=C2=A0<a href=3D"https://search.m=
aven.org/#artifactdetails%7Ccom.google.code.findbugs%7Cjsr305%7C3.0.1%7Cjar=
" target=3D"_blank">https://search.maven.<wbr>org/#artifactdetails%7Ccom.<w=
br>google.code.findbugs%7Cjsr305%<wbr>7C3.0.1%7Cjar</a></div><div><br></div=
><div>I need to establish some context first.</div><div><br></div><div>JSR =
305:=C2=A0<a href=3D"https://jcp.org/en/jsr/detail?id=3D305" target=3D"_bla=
nk">https://jcp.org/en/jsr/<wbr>detail?id=3D305</a></div><div><br></div><di=
v>This JSR was set up to=C2=A0develop a standard set of annotations that ca=
n assist defect detection tools.</div><div><br></div><div>The JSR appears e=
ffectively dead. It has not produced anything officially in the 10 years si=
nce it was initiated.</div><div><br></div><div>There are some JAR files flo=
ating around that &quot;claim&quot; to represent the JSR... they are produc=
ed by the findbugs project (which is run by the spec lead for the JSR)... s=
o they may indeed represent the vision that Bill has for the JSR... but unt=
il they are published via the JSR page, my understanding is that such JAR f=
iles are just rumour... the fact that these JARs include a @Nonnull annotat=
ion which is distinct from the stated intent on the JSR page to have a @Non=
Null annotation further highlights how the JAR is at odds with the official=
 JSR process.</div><div><br></div><div>Now I am not criticising Bill here, =
I am just point out that - IANAL but it would seem to me - perhaps legally =
and certainly technically there has not been any releases from JSR 305</div=
><div><br></div><div>Now what does this matter to the ASF. Findbugs is not =
an ASF project... being mostly GPL licensed... with the exception of the an=
notations. So the jsr305 JAR is Apache License, Version 2 which should be c=
ompletely compatible with our license ;-)</div><div><br></div><div>The prob=
lem is here:</div><div><br></div><div><a href=3D"http://www.oracle.com/tech=
network/java/javase/terms/license/index.html" target=3D"_blank">http://www.=
oracle.com/<wbr>technetwork/java/javase/terms/<wbr>license/index.html</a><b=
r></div><div><br></div><div>Specifically (although there are other relevant=
 sections, this is the primary concern):</div><div><br></div><div>F. JAVA T=
ECHNOLOGY RESTRICTIONS. You may not create, modify, or change the behavior =
of, or authorize your licensees to create, modify, or change the behavior o=
f, classes, interfaces, or subpackages that are in any way identified as &q=
uot;java&quot;, &quot;javax&quot;, &quot;sun&quot;, =E2=80=9Coracle=E2=80=
=9D or similar convention as specified by Oracle in any naming convention d=
esignation.<br></div><div><br></div><div>As I understand it, what the JRE b=
inary redistribution terms mean that if you are redistributing at least an =
Oracle JRE, you are not allowed to include classes in the &quot;java&quot; =
or &quot;javax&quot; package space *unless* those classes have been release=
d through the JSR process...</div><div><br></div><div>And the &quot;JSR-305=
&quot; JAR file contains just that.</div><div><br></div><div>So the questio=
ns:</div><div><br></div><div>Q1. Should ASF projects be bundling the &quot;=
jsr305.jar&quot; in any of their &#39;convenience&#39; binaries? (if we do,=
 then that restricts the ability of others to use those binaries)... I thin=
k the answer is no... but I am a pedant!</div><div>Q2. Should ASF projects =
be exposing the &quot;jsr305.jar&quot; as a transitive dependency? (if we d=
o, then that restricts the ability of others to use those projects)... I th=
ink the answer is no... but I am a pedant!</div><div><br></div><div>To be c=
lear, as I understand it, if you create a Docker image that includes a JRE =
and happens to also have the &quot;jsr305.jar&quot; then my reading of the =
JRE binary redistribution license terms would seem to say &quot;you do not =
have a license to redistribute that Docker image&quot;=C2=A0</div><div><br>=
</div><div>Q3. &quot;change the behaviour of&quot; seems somewhat broad, is=
 it broad enough that the dynamic references to the &quot;jsr305.jar&quot; =
annotations that are left when you compile a Java class would fall into sco=
pe.</div><div><br></div><div>So how does Q3 come into effect.</div><div><br=
></div><div>If I annotate a method with say @Nonnull</div><div><br></div><d=
iv>public class Widget {</div><div>...</div><div>@javax.annotation.Nonnull(=
<wbr>when=3Djavax.annotation.meta.<wbr>When.ALWAYS)</div><div>public static=
 Widget getInstance() {</div><div>...</div><div>}</div><div>}</div><div><br=
></div><div>That will encode the bytecode for the annotation into Widget.cl=
ass</div><div><br></div><div>If we load that up in a JRE and the annotation=
 classes are not available (because we stripped them from the redistributab=
le so we could ship the JRE binaries) then the JRE is supposed to ignore th=
e annotations...</div><div><br></div><div>But what happens if JSR-305 ever =
reboots... or if some other JSR project gets fed up waiting and produces a =
@Nonnull(when=3Djavax.<wbr>annotation.When.PERMANENTLY)</div><div><br></div=
><div>The inclusion in our bytecode of the annotation will change that anno=
tation behaviour such that any JRE code that uses the annotation will now s=
ee something like sun.reflect.annotation.<wbr>EnumConstantNotPresentExcepti=
o<wbr>nProxy rather than the enum value.</div><div><br></div><div>So, Q3 ba=
sically boils down to... since we don&#39;t know what a future JSR-305 or e=
ven some other future JSR may do... including the annotation bytecode in ou=
r own bytecode could have the effect of changing the behaviour of code in t=
he java or javax package namespace... so can we even use the &quot;jsr305.j=
ar&quot; at compile time and then remove the jar but still cause issues for=
 anyone consuming our software?</div><div><br></div><div>I think Q3 may nee=
d a legal opinion from legal person who also understands how Java bytecode =
works...</div><div><br></div><div>Oh fun eh!</div><span class=3D"gmail-HOEn=
Zb"><font color=3D"#888888"><div><br></div><div>-Stephen</div>


</font></span></div></div><br></div></div>

--047d7b86caf8a6e47a05429895e0--