Now @bogovicj and I have taken care of the licensing incompatibilities surrounding the
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
$ git grep mpicbg **/*.java
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
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
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.