You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Stephen Connolly <st...@gmail.com> on 2016/11/27 22:05:40 UTC
JSR-305 anntations
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=305
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", “oracle” or similar convention 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=javax.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=javax.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
Re: JSR-305 anntations
Posted by Stephen Connolly <st...@gmail.com>.
On 1 December 2016 at 13:38, Sean Owen <sr...@apache.org> wrote:
> On Thu, Dec 1, 2016 at 2:33 PM Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> Well the question is really this. The Apache Foundation is supposed to
>> provide software for the public good and make that software available, does
>> including the jsr305.jar files constitute a restriction of the goals of the
>> foundation?
>>
>>
> The JAR in question is Apache-licensed, so it's no different than any
> other Apache software. The restriction -- if it exists -- comes from a
> third party, and decision to include particular third-party software, not
> ASF software. There are probably a bunch of such conflicts out there that
> we can't do anything about.
>
> I understand that if it were technically Not Our Problem but happened to
> significantly hamper use of Apache software in practice for a large group
> of people, it would be something to try to do something about. However this
> arises at best when choosing to redistribute the whole Oracle JDK, which
> hardly seems like common usage. IMHO.
>
JRE not JDK... and there are a bootload of docker images out there that are
redistributing the Oracle JRE (perhaps without even knowing)... and let's
not start on the fun of windows installers or VM images
Re: JSR-305 anntations
Posted by Sean Owen <sr...@apache.org>.
On Thu, Dec 1, 2016 at 2:33 PM Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> Well the question is really this. The Apache Foundation is supposed to
> provide software for the public good and make that software available, does
> including the jsr305.jar files constitute a restriction of the goals of the
> foundation?
>
>
The JAR in question is Apache-licensed, so it's no different than any other
Apache software. The restriction -- if it exists -- comes from a third
party, and decision to include particular third-party software, not ASF
software. There are probably a bunch of such conflicts out there that we
can't do anything about.
I understand that if it were technically Not Our Problem but happened to
significantly hamper use of Apache software in practice for a large group
of people, it would be something to try to do something about. However this
arises at best when choosing to redistribute the whole Oracle JDK, which
hardly seems like common usage. IMHO.
Re: JSR-305 anntations
Posted by Stephen Connolly <st...@gmail.com>.
On 1 December 2016 at 13:24, Sean Owen <sr...@apache.org> wrote:
> On Thu, Dec 1, 2016 at 2:13 PM Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> 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:
>>
>>
> snip ...
>
> And of course, IANAL, just a concerned citizen.
>
> First: aren't annotations optional at runtime? these are compile-time
> annotations, and even though they're in the bytecode, if they're not
> present at runtime, that's not an error. So, it may be the case that this
> could be excluded entirely from any project concerned about it without any
> loss. That doesn't address the point about distribution of course.
>
Well since we have no idea what a future JSR may do... for example perhaps
if these were made part of the JRE standard library you could enable fancy
assertions and use the annotations for pre-conditions and post-conditions...
In which case the sun.reflect.annotation.EnumConstantNotPresentExceptionProxy
that you could get - if any of the spec enums have different values from
the draft - might actually affect the JVM behaviour... which is where the
concern arises.
>
> The license you cite concerns redistribution of the JVM, right? its terms
> don't apply outside of that. Do any ASF projects redistribute the JVM? they
> can't do that to begin with, right?
>
ASF projects cannot redistribute the JVM as I understand it... but a
comment on one of the JSON threads raised this issue to prominence for me.
The comment (I think by Jim) was something along the lines of: if a
dependency's license terms put undue restrictions on what consumers of the
Apache project's code can do with that code, then that is a Bad Thing™
> I am not even sure the Oracle license can be read to constrain this
> because even in your instance the javax.* code isn't distributed in the JVM
> package. That is in the realm of things up to third parties who want to
> redistribute the JVM.
>
> I'm all for making things easy and this might be addressable by ASF
> projects but probably isn't something we need to worry about.
>
Well the question is really this. The Apache Foundation is supposed to
provide software for the public good and make that software available, does
including the jsr305.jar files constitute a restriction of the goals of the
foundation?
Re: JSR-305 anntations
Posted by Sean Owen <sr...@apache.org>.
On Thu, Dec 1, 2016 at 2:13 PM Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> 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:
>
>
snip ...
And of course, IANAL, just a concerned citizen.
First: aren't annotations optional at runtime? these are compile-time
annotations, and even though they're in the bytecode, if they're not
present at runtime, that's not an error. So, it may be the case that this
could be excluded entirely from any project concerned about it without any
loss. That doesn't address the point about distribution of course.
The license you cite concerns redistribution of the JVM, right? its terms
don't apply outside of that. Do any ASF projects redistribute the JVM? they
can't do that to begin with, right?
I am not even sure the Oracle license can be read to constrain this because
even in your instance the javax.* code isn't distributed in the JVM
package. That is in the realm of things up to third parties who want to
redistribute the JVM.
I'm all for making things easy and this might be addressable by ASF
projects but probably isn't something we need to worry about.
Re: JSR-305 anntations
Posted by Stephen Connolly <st...@gmail.com>.
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 = 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/jsr305-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 <st...@gmail.com>
Date: 27 November 2016 at 22:05
Subject: JSR-305 anntations
To: "legal-discuss@apache.org" <le...@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=305
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", “oracle” or similar convention 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=javax.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=javax.
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