Eliminate or reduce the GPL portion of ImgLib2

imglib2
licensing
imglib
Tags: #<Tag:0x00007fd542b73b48> #<Tag:0x00007fd542b73990> #<Tag:0x00007fd542b737d8>

#1

@StephanPreibisch @axtimwalde @tpietzsch I would like to inquire about the rationale for having certain algorithms of ImgLib2 be licensed under the GPL. This came up because @panovr is currently porting Larry Lindsey’s hough transform code from ImgLib1 to ImgLib2, and it makes use of net.imglib2.algorithm.math.PickImagePeaks, which is part of imglib2-algorithm-gpl.

Would it be possible to migrate some or all of the code from imglib2-algorithm-gpl to imglib2-algorithm, relicensing it from GPL to BSD?


#2

This would be great! But of course it is up to the individual authors. From the git history it looks like that would be mainly @StephanPreibisch and @tinevez.
I’m not sure whether there is any problems with licenses of dependencies that would transitively apply?


#3

The only dependency problem is Stephan’s mpicbg library, which is GPL v2 only. Actually, that is a bigger problem for a couple of reasons:

  • Lesser problem: GPL v2 cannot be combined with Apache 2—only GPL v3 can be combined with Apache 2. In practice, obviously, no one is complaining. I believe there are a couple of other “GPL v2 only” components in the SciJava component collection which also suffer from this problem.
  • Greater problem: imglib2-algorithm-gpl requires imglib2-algorithm requires imglib2-realtransform requires jitk-tps requires mpicbg, so actually all of that chain are currently GPL-tainted. @axtimwalde: can we relicense mpicbg as permissive? Otherwise, we have legal problems here.

#4

Dear all.
I am happy to relicense any contribution I had in this repo to a permissive license.
jyt


#5

I filed jitk-tps#7 to follow up on this issue.


#6

Progress is happening!

https://github.com/bogovicj/jitk-tps/issues/7


#7

Now @bogovicj and I have taken care of the licensing incompatibilities surrounding the mpicbg component, imglib2-algorithm, jitk-tps, imglib2-realtransform and bigwarp. Everything is in order there now. The latest pom-scijava on master now has legal component structures there; the next release of pom-scijava will expose those for everything to consume.

So that just leaves my original question:

There is still code in imglib2-algorithm-gpl which uses mpicbg:

$ git grep mpicbg **/*.java
src/main/java/net/imglib2/algorithm/pde/CoherenceEnhancingDiffusionTensor2D.java:import mpicbg.util.Util;
src/main/java/net/imglib2/algorithm/transformation/ImageTransform.java:import mpicbg.models.InvertibleBoundable;
src/main/java/net/imglib2/algorithm/transformation/ImageTransform.java:import mpicbg.models.NoninvertibleModelException;

So I guess those two classes would need to stay GPL. I tried deleting those two classes from the project to see what else uses them, and the answer is nothing. So everything else in the imglib2-algorithm-gpl component, from a technical perspective, does not need the mpicbg library (or any other GPLed library) in order to function.

To clarify this: while IANAL, my understanding is that the decision is up to the copyright holders, which in most cases is the institution that employed you when you contributed code. E.g. for Barry DeZonia, the University of Wisconsin-Madison Board of Regents is the copyright holder, and they empower whatever subgroup of UW is relevant (in this case, LOCI, and therefore me) to make such decisions about code he wrote while working at LOCI.

According to the javadoc, the remaining authors of classes in src/main/java of imglib2-algorithm-gpl who have not yet given consent are: Larry Lindsey (@larrylindsey on GitHub), Jonathan Hale (@Squareys on GitHub), Benjamin Schmid (@bene.schmid), and Stephan Preibisch (@StephanPreibisch). There have also been small bug-fixes from Albert Cardona, Alison Walter, Martin Weigert and Hadrien Mary, although I do not believe these changes are legally sufficient to qualify those people as coauthors. There is also a class in src/test/java written by Johannes Schindelin; ideally that class would also change licenses and therefore permission would be needed.

I got tired out just writing the above, and as usual I have a mountain of things to do, so I guess I’ll let this issue drop for now. It is unfortunate that we cannot use the PickImagePeaks in ImageJ Ops due to this licensing incompatibility. Maybe it would be simpler to just rewrite things in imglib2-algorithm and/or imagej-ops as needed, eschewing this component whenever possible. Certainly I encourage anyone stumbling across this thread to please contribute new code to a permissively-licensed component whenever possible.