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 JSR-305 anntations
Date Sun, 27 Nov 2016 22:05:40 GMT
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

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