Stephans Blog

Is your Open Source project correctly licensed? When I was thinking about my open source projects I remember I was shocked. They probably haven’t been correctly licensed (they were in the end) What license you can use depends on the third party open source projects you use. But not only that, it depends on what links to what.

(Sorry for all the license typos :-)

Suppose I have two servers, one licensed under the Apache 2.0 license and one licensed under the GPL. And the GPL version uses the Alfresco GPL CIFS server, no problem. I can mix those licenses in my project and use the GPLed Alfresco server, although parts of my project are Apache 2.0 (the first server). But when my Apache 2.0 server directly uses the GPL Alfresco server, I’m no longer allowed to distribute my project with the GPL Alfresco code because I violate their license.

To prevent problems some people do license audits by looking at the Java code in the repository, the imports and then looking at the dependent libraries and their licenses. Reposita will have this feature soon. Maven is working on it by analysing dependencies. But in the end it depends on what code is calling what code, not what code is packaged with what library, or what code imports what code (some people claim a Java import equals linking though) or what license files might be packaged with the project.

So we need a way to annotate code with the license it has, so we can at runtime - for example with aspects - check if Apache 2.0 code directly calls GPL code. Then we’re in trouble.

Java 5 to the rescue. With Java 5 Sun introduced annotations. We now can write a @License annotation and annotate our code with the @License() annotation.

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE})
public @interface License {
  String name();
  String version();
}

Annotating our code like this:

@License(name = "Apache",version = "2.0")
public class Example {
    public void doWhatever() { ... }
}

helps us in the end to determine the license of the code programmatically. Either by wrapping method calls in aspects and checking the license of the caller and the callee or for example by checking all classes in a jar. The first example could be used during a QA test or during code audits. The aspects then would be removed for deployment. The second variant works great for license audits, merger and acquisitions, new projects, open source projects etc. This would enable us to more directly audit classes, code and their license and not depend on the JavaDoc license header (where sometimes the JavaDoc or license header gives the wrong information, because the license has changed several times).

For this to work most open source projects need to annotate their code though ;-) I guess we need a JSR and some standard annotations and conventions to make this work for all.

Thanks for listening.

Update: Some Feedback: analysing import does not help. With more and more dependency injection (Spring XML, Guice annotations) there is no longer an import relationship between your code and the third party code. License violations can then only be determined at runtime.