[ImageJ-devel] [IMGLIB] moved algorithm and stats packages out of imglib2-core

[Curtis Rueden]

Hi Bill,

The hash of different licenses is starting to sound a bit icky. What's the
> justification? Why not public domain ala IJ1?
>

It is not legal to "release" code to the public domain in the United
States, nor in many other countries. The closest we can get is the BSD
license. It is extremely permissive. The reason ImageJ1 is in the public
domain is because there is one exception: code developed by the U.S.
government (including at NIH) *cannot* be copyrighted, and is automatically
in the public domain. But ImageJ2 does not fall into that category, as it
is being developed as a community effort across several universities
internationally.

Similarly, ImgLib2 is BSD-licensed, to be as permissive as possible.
However, there are some image processing algorithms (in the
imglib2-algorithms package) that depend on GPL-licensed third-party
libraries. In order to use those libraries legally, the imglib2-algorithms
must also be GPL-licensed.

Hopefully that makes sense. If not, ask and we will clarify further.

Regards,
Curtis


On Wed, Feb 29, 2012 at 2:43 PM, Bill Mohler <wmohler at neuron.uchc.edu>wrote:

>  The hash of different licenses is starting to sound a bit icky. What's
> the justification? Why not public domain ala IJ1?
>
>
>
> On 2/29/12 3:30 p.m., Curtis Rueden wrote:
>
> Hi Tobias,
>
> I moved the net.imglib2.algorithm and net.imglib2.stats packages
>> from the imglib2-core into the imglib2-algorithms sub-project (because
>> thats where they should belong.)
>>
>
> The problem with moving things from core to algorithms right now is that
> implicitly, it changes the license from BSD to GPL. ImageJ2 cannot include
> imglib2-algorithms, because of this license difference.
>
> So, there are a couple of potential solutions:
>
> 1) Keep things like net.imglib2.stats in imglib2 core, so that it can
> remain BSD licensed.
>
> 2) Split imglib2-algorithms into multiple components:
> imglib2-algorithms-bsd and imglib2-algorithms-gpl, for example. Then we can
> include imglib2-algorithms-bsd as a dependency for ImageJ2.
>
> The thinking with net.imglib2.stats was that the histogram functionality
> is so common that it belongs in the "core" library. While modularity is
> nice, splitting things up too much runs the risk of confusing new
> developers who do not know why there are so many different JAR files. I
> agree with something Albert said a while back that one primary motivator
> for multiple JARs is to discriminate dependencies. That is, if some code
> depends on e.g. weka, and other code does not, there should be two Maven
> modules: one with a dependency on weka that includes the relevant code, and
> the other without such dependency that includes the rest.
>
> The tricky bit is, the other primary motivator for multiple JARs is, as
> touched on above, licensing. We need to balance and reconcile those two
> needs. The most surefire solution is to have a separate module/JAR for each
> combination of licenses and dependencies—and hopefully that number of
> modules remains manageable.
>
> Maybe it is time to split up imglib2-algorithms into multiple submodules?
> I would be happy to do it, if we all agree.
>
> Regards,
> Curtis
>
>
> On Wed, Feb 29, 2012 at 1:11 PM, Tobias Pietzsch <pietzsch at mpi-cbg.de>wrote:
>
>> Hi all,
>>
>> I moved the net.imglib2.algorithm and net.imglib2.stats packages
>> from the imglib2-core into the imglib2-algorithms sub-project (because
>> thats where they should belong.)
>>
>> With regard to the interfaces and classes from the algorithm package,
>> I think we should reconsider whether we need those at all. In particular
>> for the MultiThreaded interface, I imagine that something similar can
>> be accomplished using the standard java.util.concurrent package.
>> For instance, (potentially) multi-threaded algorithms could be started
>> with an ExecutorService argument.
>>
>> best regards,
>> Tobias
>>
>> _______________________________________________
>> ImageJ-devel mailing list
>> ImageJ-devel at imagej.net
>> http://imagej.net/mailman/listinfo/imagej-devel
>>
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120229/72e4a573/attachment.html>