www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: JSR-305 anntations
Date Thu, 01 Dec 2016 13:13:15 GMT
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:


This has a compile scoped dependency on the annotation jar:


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:


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

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)


---------- 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:

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:


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
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 {
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.

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!


View raw message