<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body 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?<br>
<div class="moz-signature">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="ProgId" content="Word.Document">
<meta name="Generator" content="Microsoft Word 2008">
<meta name="Originator" content="Microsoft Word 2008">
<link rel="File-List" href="Signature_files/filelist.xml">
<!--[if gte mso 9]><xml>
<o:DocumentProperties>
<o:Author>Bill Mohler</o:Author>
<o:Template>Normal.dotm</o:Template>
<o:LastAuthor>Bill Mohler</o:LastAuthor>
<o:Revision>5</o:Revision>
<o:TotalTime>4</o:TotalTime>
<o:Created>2010-07-23T20:48:00Z</o:Created>
<o:LastSaved>2010-07-23T20:57:00Z</o:LastSaved>
<o:Pages>1</o:Pages>
<o:Words>94</o:Words>
<o:Characters>536</o:Characters>
<o:Company>UConn Health Center</o:Company>
<o:Lines>4</o:Lines>
<o:Paragraphs>1</o:Paragraphs>
<o:CharactersWithSpaces>658</o:CharactersWithSpaces>
<o:Version>12.256</o:Version>
</o:DocumentProperties>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:Zoom>200</w:Zoom>
<w:SpellingState>Clean</w:SpellingState>
<w:GrammarState>Clean</w:GrammarState>
<w:TrackMoves>false</w:TrackMoves>
<w:TrackFormatting/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:Compatibility>
<w:SplitPgBreakAndParaMark/>
<w:UseFELayout/>
</w:Compatibility>
</w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" LatentStyleCount="276">
</w:LatentStyles>
</xml><![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Times;
panose-1:2 0 5 0 0 0 0 0 0 0;
mso-font-charset:0;
mso-generic-font-family:auto;
mso-font-pitch:variable;
mso-font-signature:3 0 0 0 1 0;}
@font-face
{font-family:Webdings;
panose-1:5 3 1 2 1 5 9 6 7 3;
mso-font-charset:2;
mso-generic-font-family:auto;
mso-font-pitch:variable;
mso-font-signature:0 0 65536 0 -2147483648 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:"";
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-ascii-font-family:Times;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Times;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;
color:black;}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;
text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;
text-underline:single;}
tt
{font-family:Courier;
mso-ascii-font-family:Courier;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Courier;
mso-bidi-font-family:Courier;}
span.SpellE
{mso-style-name:"";
mso-spl-e:yes;}
span.GramE
{mso-style-name:"";
mso-gram-e:yes;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.Section1
{page:Section1;}
-->
</style><!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Times New Roman";
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;}
</style>
<![endif]--><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1027"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1"/>
</o:shapelayout></xml><![endif]-->
<div class="Section1"><br>
</div>
</div>
<br>
On 2/29/12 3:30 p.m., Curtis Rueden wrote:
<blockquote
cite="mid:CADN69yme_NePuOE+2faNQ30bWYtEFgJGOPGse7+wb0pcni9-NQ@mail.gmail.com"
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 moz-do-not-send="true"
href="mailto:pietzsch@mpi-cbg.de">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 moz-do-not-send="true"
href="mailto:ImageJ-devel@imagej.net" target="_blank">ImageJ-devel@imagej.net</a><br>
<a moz-do-not-send="true"
href="http://imagej.net/mailman/listinfo/imagej-devel"
target="_blank">http://imagej.net/mailman/listinfo/imagej-devel</a><br>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>