Hi Bill,<br><br><blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">The hash of different licenses is starting to sound a bit icky.
What's the justification? Why not public domain ala IJ1?<br></blockquote><br>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.<br>
<br>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.<br>
<br>Hopefully that makes sense. If not, ask and we will clarify further.<br><br>Regards,<br>Curtis<br><br><br><div class="gmail_quote">On Wed, Feb 29, 2012 at 2:43 PM, Bill Mohler <span dir="ltr"><<a href="mailto:wmohler@neuron.uchc.edu">wmohler@neuron.uchc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
The hash of different licenses is starting to sound a bit icky.
What's the justification? Why not public domain ala IJ1?<div><div class="h5"><br>
<div>
<div><br>
</div>
</div>
<br>
On 2/29/12 3:30 p.m., Curtis Rueden wrote:
<blockquote type="cite">Hi Tobias,<br>
<br>
<blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">I moved
the net.imglib2.algorithm and net.imglib2.stats packages<br>
from the imglib2-core into the imglib2-algorithms sub-project
(because<br>
thats where they should belong.)<br>
</blockquote>
<br>
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.<br>
<br>
So, there are a couple of potential solutions:<br>
<br>
1) Keep things like net.imglib2.stats in imglib2 core, so that it
can remain BSD licensed.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Maybe it is time to split up imglib2-algorithms into multiple
submodules? I would be happy to do it, if we all agree.<br>
<br>
Regards,<br>
Curtis<br>
<br>
<br>
<div class="gmail_quote">On Wed, Feb 29, 2012 at 1:11 PM, Tobias
Pietzsch <span dir="ltr"><<a href="mailto:pietzsch@mpi-cbg.de" target="_blank">pietzsch@mpi-cbg.de</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I moved the net.imglib2.algorithm and net.imglib2.stats
packages<br>
from the imglib2-core into the imglib2-algorithms sub-project
(because<br>
thats where they should belong.)<br>
<br>
With regard to the interfaces and classes from the algorithm
package,<br>
I think we should reconsider whether we need those at all. In
particular<br>
for the MultiThreaded interface, I imagine that something
similar can<br>
be accomplished using the standard java.util.concurrent
package.<br>
For instance, (potentially) multi-threaded algorithms could be
started<br>
with an ExecutorService argument.<br>
<br>
best regards,<br>
Tobias<br>
<br>
_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagej.net" target="_blank">ImageJ-devel@imagej.net</a><br>
<a href="http://imagej.net/mailman/listinfo/imagej-devel" target="_blank">http://imagej.net/mailman/listinfo/imagej-devel</a><br>
</blockquote>
</div>
<br>
</blockquote>
</div></div></div>
<br>_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagej.net">ImageJ-devel@imagej.net</a><br>
<a href="http://imagej.net/mailman/listinfo/imagej-devel" target="_blank">http://imagej.net/mailman/listinfo/imagej-devel</a><br>
<br></blockquote></div><br>