[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
[5731dbe0ec5f] 2011-12-09 Igor Krivenko <Igor Krivenko>
[a1f843f013c9] 2011-12-05 karturov <
karturov@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
[3233ef18be4a] 2011-05-23 David H. Bailey <David H. Bailey>
[efe1a0250288] 2011-05-23 David H. Bailey <David H. Bailey>
[f86a974f6111] 2011-02-03 Jason Newton <nevion@xxxxxxxxx>
[0e182249fb56] 2011-12-10 Andy Somerville <andy.somerville@xxxxxxxxx>
[13f72ac8283d] 2011-11-17 Kibeom Kim <kkimlabs@xxxxxxxxx>
[6e0ee90bd35c] 2011-01-07 Romain Bossart <romain.bossart@xxxxxxx>
If you agree with my assessment, would you consider contacting these
authors to
see if they agree?
I have to apologize again for this annoyance but I really appreciate the
help.
Bill
On Sat, Sep 15, 2012 at 6:30 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>wrote:
> 2012/9/15 Bill Greene <w.h.greene@xxxxxxxxx>:
> > Thanks very much for the quick reply, Benoit.
> >
> > Your analysis of the changesets from authors without an email response is
> > very helpful. Was the part you included in your reply part of a larger
> > analysis that you have done? If so, is that available in a file I could
> > download?
>
> No, I just did it to reply to your email. I included the hg command
> lines in the email, so you can continue iterating over the other
> contributors if you want. The list of contributors to check is the one
> given in the same email that you quoted.
>
> >
> > As far as Eigen support for external sparse solvers, that is something we
> > don't
> > have any immediate plans for but might be nice to use in the future.
> > If Romain Bossart agrees to relicense, that would certainly help.
>
> For context though, even stopping at the contributors who had 3
> changesets in the tree, most of the replies that I got were of the
> form "Oh, do you seriously need my agreement for those few small
> changes I contributed? Sure, I don't care" so I stopped there as this
> started feeling like diminishing returns. I'll contact Romain if there
> is a definite need for it.
>
> >
> > Thanks again.
>
> You're very welcome,
> Benoit
>
> >
> > Bill
> >
> >
> > On Sat, Sep 15, 2012 at 11:43 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx
> >
> > wrote:
> >>
> >> As said in the email that you quote, we tracked contributor agreements
> >> for the relicensing until we had agreement from everyone who had
> >> contributed at least 3 changesets.
> >>
> >> That same email gives the list of contributors who haven't replied
> >> (nobody replied negatively).
> >>
> >> We can use it to check that these changesets are either trivial, or
> >> old enough that the code has been rewritten many times since, or
> >> simple enough to be rewritten, or non-essential enough to be dropped.
> >> Also note that in most cases, these contributors's 2nd changeset is
> >> the same as the first one, transplanted to a different branch. I
> >> comment inline below.
> >>
> >> bjacob:~/eigen$ hg log -u 'Zach Ploskey' --style=changelog
> >> 2011-06-17 Zach Ploskey <zploskey@xxxxxx>
> >>
> >> * doc/C00_QuickStartGuide.dox:
> >> Suggest placing Eigen directory in system include path.
> >> [7035d240ff92]
> >>
> >> * doc/C09_TutorialSparse.dox:
> >> Fixed a few typos and cleaned up some language.
> >> [d03f246ce0d7]
> >>
> >> -> that is documentation only.
> >>
> >>
> >> bjacob:~/eigen$ hg log -u 'williami@xxxxxxxxxxxxxxxxxxxxxxxxxx'
> >> --style=changelog
> >> 2012-06-04 williami <williami@xxxxxxxxxxxxxxxxxxxxxxxxxx>
> >>
> >> * Eigen/Core, Eigen/src/Core/PlainObjectBase.h,
> >> Eigen/src/Core/util/Macros.h:
> >> Fixed RVCT 3.1 compiler errors. (transplanted from
> >> 2d727e1e20b40e1017e6c44cbff8faa3aac1c0c5)
> >> [8d244d9c6668] <3.0>
> >>
> >> * Eigen/Core, Eigen/src/Core/PlainObjectBase.h,
> >> Eigen/src/Core/util/Macros.h:
> >> Fixed RVCT 3.1 compiler errors.
> >> [2d727e1e20b4]
> >>
> >> -> that is trivial compilation fixes
> >>
> >> bjacob:~/eigen$ hg log --style=changelog -u 'Trevor Wennblom'
> >> 2011-08-30 Trevor Wennblom <trevor@xxxxxxxx>
> >>
> >> * CMakeLists.txt:
> >> resolve pkgconfig destination -
> >> http://eigen.tuxfamily.org/bz/show_bug.cgi?id=338 (transplanted
> >> from
> >> be73e9686e0e11caa72778a7dd5dd1a8a1742afc)
> >> [0b7f92e0e626] <3.0>
> >>
> >> * CMakeLists.txt:
> >> resolve pkgconfig destination -
> >> http://eigen.tuxfamily.org/bz/show_bug.cgi?id=338
> >> [be73e9686e0e]
> >>
> >>
> >> -> that is pkgconfig-only (not Eigen code) fixes
> >>
> >> bjacob:~/eigen$ hg log --style=changelog -u 'Sebastian Lipponer'
> >> 2011-12-09 Sebastian Lipponer <lipponer@xxxxxxxxxxxxxxxxxxx>
> >>
> >> * Eigen/src/Core/Block.h, Eigen/src/Core/util/XprHelper.h:
> >> Fix MSVC integer overflow warning (transplanted from
> >> c4d57918acea37c502ac6f7aa4d836910f1ed4a5)
> >> [180613093b9f] <3.0>
> >>
> >> * Eigen/src/Core/Block.h, Eigen/src/Core/util/XprHelper.h:
> >> Fix MSVC integer overflow warning
> >> [c4d57918acea]
> >>
> >> -> this is just a warning fix
> >>
> >> bjacob:~/eigen$ hg log --style=changelog -u 'Romain Bossart'
> >> 2011-01-07 Romain Bossart <romain.bossart@xxxxxxx>
> >>
> >> * unsupported/Eigen/src/SparseExtra/UmfPackSupport.h:
> >> Fix bug 38
> >> * address of temporaries were passed to umfpack_zi_* functions.
> It
> >> is
> >> ok with g++-4.4 or 4.5, but not with the -std=c++0x in both
> >> versions. This patch makes it work for c++98 and c++0x versions
> >> [69d6a720ea83]
> >>
> >>
> >> -> this is a nontrivial code change, but it changes only 10 lines so
> >> would be easy to rewrite if needed.
> >>
> >> 2010-10-04 Romain Bossart <romain.bossart@xxxxxxx>
> >>
> >> *
> >> doc/examples/Tutorial_ReductionsVisitorsBroadcasting_broadcast_1nn.c
> >> pp~,
> >> doc/examples/Tutorial_ReductionsVisitorsBroadcasting_broadcast_
> >> simple.cpp~,
> >> doc/examples/Tutorial_ReductionsVisitorsBroadcasting_re
> >> ductions_norm.cpp~,
> >>
> >> doc/examples/Tutorial_ReductionsVisitorsBroadcasting_visitors.cpp~,
> >> unsupported/Eigen/CholmodSupport, unsupported/Eigen/SparseExtra,
> >> unsupported/Eigen/SuperLUSupport,
> >> unsupported/Eigen/UmfPackSupport,
> >> unsupported/Eigen/src/SparseExtra/CholmodSupport.h,
> >> unsupported/Eigen/src/SparseExtra/SparseLDLT.h,
> >> unsupported/Eigen/src/SparseExtra/SparseLLT.h,
> >> unsupported/Eigen/src/SparseExtra/SparseLU.h,
> >> unsupported/Eigen/src/SparseExtra/UmfPackSupport.h,
> >> unsupported/test/sparse_ldlt.cpp,
> unsupported/test/sparse_llt.cpp:
> >> Updates to the Sparse unsupported solvers module.
> >> * change Sparse* specialization's signatures from <..., int
> >> Backend>
> >> to <..., typename Backend>. Update SparseExtra accordingly to
> use
> >> structs instead of the SparseBackend enum.
> >> * add SparseLDLT Cholmod specialization
> >> * for Cholmod and UmfPack, SparseLU, SparseLLT and SparseLDLT
> now
> >> use
> >> ei_solve_retval and have the new solve() method (to be closer to
> >> the
> >> 3.0 API).
> >>
> >> * fix doc
> >> [6e0ee90bd35c]
> >>
> >> -> This is a nontrivial larger change, but it's in Sparse solvers (a
> >> self-contained part) and it dates back to early 2010 and that code has
> >> been largely rewritten since. Gael could comment. If you are concerned
> >> about this, we could try contacting Romain (we haven't tried so far,
> >> as he has only 2 changesets in the tree).
> >>
> >>
> >> 2007-09-30 Michael Olbrich <michael.olbrich@xxxxxxx>
> >>
> >> * src/internal/Object.h:
> >> Generic loop unrolling with template metaprograms. It seems to
> be
> >> as
> >> fast as manually unrolling. TODO: decide when to stop unrolling
> >> (speed vs. code size). maybe only unroll one loop for larger
> >> matixes.
> >> [9af3c97142d1]
> >>
> >> -> this change dates back to 2007, this code has been rewritten since.
> >>
> >> * src/internal/Minor.h:
> >> for dynamic size matrix (Rows|Cols)AtCompileTime is always
> >> EiDynamic
> >> and not "(Rows|Cols)AtCompileTime - 1" which would be EiDynamic
> -
> >> 1
> >> == -2
> >> [453cda54b0a6]
> >>
> >> -> this code (the whole class) has been removed in Eigen 3.
> >>
> >>
> >>
> >> and so on...
> >>
> >> Benoit
> >>
> >>
> >> 2012/9/15 Bill Greene <w.h.greene@xxxxxxxxx>:
> >> >
> >> > Dear Eigen Developers,
> >> >
> >> > I have been an enthusiastic user of Eigen for the past several years.
> >> > Many thanks for writing such a wonderful matrix class library!
> >> >
> >> > Recently I started work at a commercial software company and would
> >> > like to use Eigen as part of my commercial development work. It seems
> >> > clear to me that this type of usage is permitted. But I have to obtain
> >> > approval from the company's lawyers and they would not give this
> >> > approval.
> >> > First off, they will not consider any software licensed under LGPL3.
> >> > I pointed out that most of the software had recently been re-licensed
> >> > under
> >> > MPL and pointed them to the email threads that, to me, indicated a
> very
> >> > careful, thorough process followed during re-licensing. According to
> >> > them,
> >> > the licensing process was not legally sufficient and their complaints
> >> > appear to focus on this sentence:
> >> >
> >> > "Aside from 3rd-party code, there remain only about 50 changesets
> >> > without re-licensing approval, they all seem to be from contributors
> >> > who contributed at most 2 changesets to Eigen, and 50 changesets is
> >> > about only 1% of the total."
> >> >
> >> > They claim that the potential exists for as many as 50 developers to
> >> > challenge the legality of the re-licensing process.
> >> >
> >> > Can anything more be said about these 50 changesets? Is it possible to
> >> > avoid the code that includes these changes?
> >> >
> >> > Sorry to bother you guys with this issue particularly since it seems
> >> > clear
> >> > to me that the re-licensing process you followed showed due diligence.
> >> > But I'll be very disappointed not to be able to use Eigen in my
> upcoming
> >> > work and I'm looking for any data I can use to convince the lawyers
> this
> >> > should be allowed.
> >> >
> >> > Thanks.
> >> >
> >> > Bill
> >>
> >>
> >
>
>
>
--14dae9341277f43e6404c9d93175
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
OK, thanks, Benoit, I understand.<div><br></div><div>Your samples did help =
me understand how to analyze the changesets.</div><div>From your July 13 em=
ail I found 41 changeset authors with 1-2 changesets</div><div>each that ha=
d not agreed to re-licensing. I found a total of 54 changesets for</div>
<div>these authors. I looked at each of these. As you say, many of them are=
</div><div>trivial, deal with documentation, tests, or Cmake files-- none o=
f which is</div><div>a concern.=A0I did find 8 changesets=A0that definitely=
could be=A0considered non-trivial:</div>
<div><br></div><div>[5731dbe0ec5f] 2011-12-09 =A0Igor Krivenko =A0<Igor =
Krivenko></div><div>[a1f843f013c9] 2011-12-05 =A0karturov =A0<<a href=
=3D"mailto:karturov@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";>karturov@KARTUROV-MOB=
L.ccr.corp.intel.com</a>></div>
<div>[3233ef18be4a] 2011-05-23 =A0David H. Bailey =A0<David H. Bailey>=
;</div><div>[efe1a0250288] 2011-05-23 =A0David H. Bailey =A0<David H. Ba=
iley></div><div>[f86a974f6111] 2011-02-03 =A0Jason Newton =A0<<a href=
=3D"mailto:nevion@xxxxxxxxx";>nevion@xxxxxxxxx</a>></div>
<div>[0e182249fb56] 2011-12-10 =A0Andy Somerville =A0<<a href=3D"mailto:=
andy.somerville@xxxxxxxxx">andy.somerville@xxxxxxxxx</a>></div><div>[13f=
72ac8283d] 2011-11-17 =A0Kibeom Kim =A0<<a href=3D"mailto:kkimlabs@gmail=
..com">kkimlabs@xxxxxxxxx</a>></div>
<div>[6e0ee90bd35c] 2011-01-07 =A0Romain Bossart =A0<<a href=3D"mailto:r=
omain.bossart@xxxxxxx">romain.bossart@xxxxxxx</a>></div><div><br></div><=
div>=A0</div><div>If you agree with my assessment, would you consider conta=
cting these authors to</div>
<div>see if they agree?</div><div><br></div><div>I have to apologize again =
for this annoyance but I really appreciate the help.</div><div><br></div><d=
iv>Bill</div><div><br><br><div class=3D"gmail_quote">On Sat, Sep 15, 2012 a=
t 6:30 PM, Benoit Jacob <span dir=3D"ltr"><<a href=3D"mailto:jacob.benoi=
t.1@xxxxxxxxx" target=3D"_blank">jacob.benoit.1@xxxxxxxxx</a>></span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2012/9/15 Bill Greene <<a href=3D"mailto:=
w.h.greene@xxxxxxxxx">w.h.greene@xxxxxxxxx</a>>:<br>
<div class=3D"im">> Thanks very much for the quick reply, Benoit.<br>
><br>
> Your analysis of the changesets from authors without an email response=
is<br>
> very helpful. Was the part you included in your reply part of a larger=
<br>
> analysis that you have done? If so, is that available in a file I coul=
d<br>
> download?<br>
<br>
</div>No, I just did it to reply to your email. I included the hg command<b=
r>
lines in the email, so you can continue iterating over the other<br>
contributors if you want. The list of contributors to check is the one<br>
given in the same email that you quoted.<br>
<div class=3D"im"><br>
><br>
> As far as Eigen support for external sparse solvers, that is something=
we<br>
> don't<br>
> have any immediate plans for but might be nice to use in the future.<b=
r>
> If =A0Romain Bossart agrees to relicense, that would certainly help.<b=
r>
<br>
</div>For context though, even stopping at the contributors who had 3<br>
changesets in the tree, most of the replies that I got were of the<br>
form "Oh, do you seriously need my agreement for those few small<br>
changes I contributed? Sure, I don't care" so I stopped there as t=
his<br>
started feeling like diminishing returns. I'll contact Romain if there<=
br>
is a definite need for it.<br>
<br>
><br>
> Thanks again.<br>
<br>
You're very welcome,<br>
Benoit<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
><br>
> Bill<br>
><br>
><br>
> On Sat, Sep 15, 2012 at 11:43 AM, Benoit Jacob <<a href=3D"mailto:j=
acob.benoit.1@xxxxxxxxx">jacob.benoit.1@xxxxxxxxx</a>><br>
> wrote:<br>
>><br>
>> As said in the email that you quote, we tracked contributor agreem=
ents<br>
>> for the relicensing until we had agreement from everyone who had<b=
r>
>> contributed at least 3 changesets.<br>
>><br>
>> That same email gives the list of contributors who haven't rep=
lied<br>
>> (nobody replied negatively).<br>
>><br>
>> We can use it to check that these changesets are either trivial, o=
r<br>
>> old enough that the code has been rewritten many times since, or<b=
r>
>> simple enough to be rewritten, or non-essential enough to be dropp=
ed.<br>
>> Also note that in most cases, these contributors's 2nd changes=
et is<br>
>> the same as the first one, transplanted to a different branch. I<b=
r>
>> comment inline below.<br>
>><br>
>> bjacob:~/eigen$ hg log -u 'Zach Ploskey' --style=3Dchangel=
og<br>
>> 2011-06-17 =A0Zach Ploskey =A0<<a href=3D"mailto:zploskey@xxxxx=
u">zploskey@xxxxxx</a>><br>
>><br>
>> =A0 =A0 =A0 =A0 * doc/C00_QuickStartGuide.dox:<br>
>> =A0 =A0 =A0 =A0 Suggest placing Eigen directory in system include =
path.<br>
>> =A0 =A0 =A0 =A0 [7035d240ff92]<br>
>><br>
>> =A0 =A0 =A0 =A0 * doc/C09_TutorialSparse.dox:<br>
>> =A0 =A0 =A0 =A0 Fixed a few typos and cleaned up some language.<br=
>
>> =A0 =A0 =A0 =A0 [d03f246ce0d7]<br>
>><br>
>> =A0 -> that is documentation only.<br>
>><br>
>><br>
>> bjacob:~/eigen$ hg log -u '<a href=3D"mailto:williami@ENG38693=
Win7.ad.garmin.com">williami@xxxxxxxxxxxxxxxxxxxxxxxxxx</a>'<br>
>> --style=3Dchangelog<br>
>> 2012-06-04 =A0williami =A0<<a href=3D"mailto:williami@ENG38693W=
in7.ad.garmin.com">williami@xxxxxxxxxxxxxxxxxxxxxxxxxx</a>><br>
>><br>
>> =A0 =A0 =A0 =A0 * Eigen/Core, Eigen/src/Core/PlainObjectBase.h,<br=
>
>> =A0 =A0 =A0 =A0 Eigen/src/Core/util/Macros.h:<br>
>> =A0 =A0 =A0 =A0 Fixed RVCT 3.1 compiler errors. (transplanted from=
<br>
>> =A0 =A0 =A0 =A0 2d727e1e20b40e1017e6c44cbff8faa3aac1c0c5)<br>
>> =A0 =A0 =A0 =A0 [8d244d9c6668] <3.0><br>
>><br>
>> =A0 =A0 =A0 =A0 * Eigen/Core, Eigen/src/Core/PlainObjectBase.h,<br=
>
>> =A0 =A0 =A0 =A0 Eigen/src/Core/util/Macros.h:<br>
>> =A0 =A0 =A0 =A0 Fixed RVCT 3.1 compiler errors.<br>
>> =A0 =A0 =A0 =A0 [2d727e1e20b4]<br>
>><br>
>> =A0 -> that is trivial compilation fixes<br>
>><br>
>> bjacob:~/eigen$ hg log --style=3Dchangelog -u 'Trevor Wennblom=
'<br>
>> 2011-08-30 =A0Trevor Wennblom =A0<<a href=3D"mailto:trevor@well=
..com">trevor@xxxxxxxx</a>><br>
>><br>
>> =A0 =A0 =A0 =A0 * CMakeLists.txt:<br>
>> =A0 =A0 =A0 =A0 resolve pkgconfig destination -<br>
>> =A0 =A0 =A0 =A0 <a href=3D"http://eigen.tuxfamily.org/bz/show_bug.=
cgi?id=3D338" target=3D"_blank">http://eigen.tuxfamily.org/bz/show_bug.cgi?=
id=3D338</a> (transplanted<br>
>> from<br>
>> =A0 =A0 =A0 =A0 be73e9686e0e11caa72778a7dd5dd1a8a1742afc)<br>
>> =A0 =A0 =A0 =A0 [0b7f92e0e626] <3.0><br>
>><br>
>> =A0 =A0 =A0 =A0 * CMakeLists.txt:<br>
>> =A0 =A0 =A0 =A0 resolve pkgconfig destination -<br>
>> =A0 =A0 =A0 =A0 <a href=3D"http://eigen.tuxfamily.org/bz/show_bug.=
cgi?id=3D338" target=3D"_blank">http://eigen.tuxfamily.org/bz/show_bug.cgi?=
id=3D338</a><br>
>> =A0 =A0 =A0 =A0 [be73e9686e0e]<br>
>><br>
>><br>
>> =A0 =A0-> that is pkgconfig-only (not Eigen code) fixes<br>
>><br>
>> bjacob:~/eigen$ hg log --style=3Dchangelog -u 'Sebastian Lippo=
ner'<br>
>> 2011-12-09 =A0Sebastian Lipponer =A0<<a href=3D"mailto:lipponer=
@gsc.tu-darmstadt.de">lipponer@xxxxxxxxxxxxxxxxxxx</a>><br>
>><br>
>> =A0 =A0 =A0 =A0 * Eigen/src/Core/Block.h, Eigen/src/Core/util/XprH=
elper.h:<br>
>> =A0 =A0 =A0 =A0 Fix MSVC integer overflow warning (transplanted fr=
om<br>
>> =A0 =A0 =A0 =A0 c4d57918acea37c502ac6f7aa4d836910f1ed4a5)<br>
>> =A0 =A0 =A0 =A0 [180613093b9f] <3.0><br>
>><br>
>> =A0 =A0 =A0 =A0 * Eigen/src/Core/Block.h, Eigen/src/Core/util/XprH=
elper.h:<br>
>> =A0 =A0 =A0 =A0 Fix MSVC integer overflow warning<br>
>> =A0 =A0 =A0 =A0 [c4d57918acea]<br>
>><br>
>> =A0 -> this is just a warning fix<br>
>><br>
>> bjacob:~/eigen$ hg log --style=3Dchangelog -u 'Romain Bossart&=
#39;<br>
>> 2011-01-07 =A0Romain Bossart =A0<<a href=3D"mailto:romain.bossa=
rt@xxxxxxx">romain.bossart@xxxxxxx</a>><br>
>><br>
>> =A0 =A0 =A0 =A0 * unsupported/Eigen/src/SparseExtra/UmfPackSupport=
..h:<br>
>> =A0 =A0 =A0 =A0 Fix bug 38<br>
>> =A0 =A0 =A0 =A0 * address of temporaries were passed to umfpack_zi=
_* functions. It<br>
>> is<br>
>> =A0 =A0 =A0 =A0 ok with g++-4.4 or 4.5, but not with the -std=3Dc+=
+0x in both<br>
>> =A0 =A0 =A0 =A0 versions. This patch makes it work for c++98 and c=
++0x versions<br>
>> =A0 =A0 =A0 =A0 [69d6a720ea83]<br>
>><br>
>><br>
>> =A0 -> this is a nontrivial code change, but it changes only 10=
lines so<br>
>> would be easy to rewrite if needed.<br>
>><br>
>> 2010-10-04 =A0Romain Bossart =A0<<a href=3D"mailto:romain.bossa=
rt@xxxxxxx">romain.bossart@xxxxxxx</a>><br>
>><br>
>> =A0 =A0 =A0 =A0 *<br>
>> doc/examples/Tutorial_ReductionsVisitorsBroadcasting_broadcast_1nn=
..c<br>
>> =A0 =A0 =A0 =A0 pp~,<br>
>> doc/examples/Tutorial_ReductionsVisitorsBroadcasting_broadcast_<br=
>
>> =A0 =A0 =A0 =A0 simple.cpp~,<br>
>> doc/examples/Tutorial_ReductionsVisitorsBroadcasting_re<br>
>> =A0 =A0 =A0 =A0 ductions_norm.cpp~,<br>
>><br>
>> doc/examples/Tutorial_ReductionsVisitorsBroadcasting_visitors.cpp~=
,<br>
>> =A0 =A0 =A0 =A0 unsupported/Eigen/CholmodSupport, unsupported/Eige=
n/SparseExtra,<br>
>> =A0 =A0 =A0 =A0 unsupported/Eigen/SuperLUSupport,<br>
>> unsupported/Eigen/UmfPackSupport,<br>
>> =A0 =A0 =A0 =A0 unsupported/Eigen/src/SparseExtra/CholmodSupport.h=
,<br>
>> =A0 =A0 =A0 =A0 unsupported/Eigen/src/SparseExtra/SparseLDLT.h,<br=
>
>> =A0 =A0 =A0 =A0 unsupported/Eigen/src/SparseExtra/SparseLLT.h,<br>
>> =A0 =A0 =A0 =A0 unsupported/Eigen/src/SparseExtra/SparseLU.h,<br>
>> =A0 =A0 =A0 =A0 unsupported/Eigen/src/SparseExtra/UmfPackSupport.h=
,<br>
>> =A0 =A0 =A0 =A0 unsupported/test/sparse_ldlt.cpp, unsupported/test=
/sparse_llt.cpp:<br>
>> =A0 =A0 =A0 =A0 Updates to the Sparse unsupported solvers module.<=
br>
>> =A0 =A0 =A0 =A0 * change Sparse* specialization's signatures f=
rom <..., int<br>
>> Backend><br>
>> =A0 =A0 =A0 =A0 to <..., typename Backend>. Update SparseExt=
ra accordingly to use<br>
>> =A0 =A0 =A0 =A0 structs instead of the SparseBackend enum.<br>
>> =A0 =A0 =A0 =A0 * add SparseLDLT Cholmod specialization<br>
>> =A0 =A0 =A0 =A0 * for Cholmod and UmfPack, SparseLU, SparseLLT and=
SparseLDLT now<br>
>> use<br>
>> =A0 =A0 =A0 =A0 ei_solve_retval and have the new solve() method (t=
o be closer to<br>
>> the<br>
>> =A0 =A0 =A0 =A0 3.0 API).<br>
>><br>
>> =A0 =A0 =A0 =A0 * fix doc<br>
>> =A0 =A0 =A0 =A0 [6e0ee90bd35c]<br>
>><br>
>> =A0-> This is a nontrivial larger change, but it's in Spars=
e solvers (a<br>
>> self-contained part) and it dates back to early 2010 and that code=
has<br>
>> been largely rewritten since. Gael could comment. If you are conce=
rned<br>
>> about this, we could try contacting Romain (we haven't tried s=
o far,<br>
>> as he has only 2 changesets in the tree).<br>
>><br>
>><br>
>> 2007-09-30 =A0Michael Olbrich =A0<<a href=3D"mailto:michael.olb=
rich@xxxxxxx">michael.olbrich@xxxxxxx</a>><br>
>><br>
>> =A0 =A0 =A0 =A0 * src/internal/Object.h:<br>
>> =A0 =A0 =A0 =A0 Generic loop unrolling with template metaprograms.=
It seems to be<br>
>> as<br>
>> =A0 =A0 =A0 =A0 fast as manually unrolling. TODO: decide when to s=
top unrolling<br>
>> =A0 =A0 =A0 =A0 (speed vs. code size). maybe only unroll one loop =
for larger<br>
>> =A0 =A0 =A0 =A0 matixes.<br>
>> =A0 =A0 =A0 =A0 [9af3c97142d1]<br>
>><br>
>> =A0 -> this change dates back to 2007, this code has been rewri=
tten since.<br>
>><br>
>> =A0 =A0 =A0 =A0 * src/internal/Minor.h:<br>
>> =A0 =A0 =A0 =A0 for dynamic size matrix (Rows|Cols)AtCompileTime i=
s always<br>
>> EiDynamic<br>
>> =A0 =A0 =A0 =A0 and not "(Rows|Cols)AtCompileTime - 1" w=
hich would be EiDynamic -<br>
>> 1<br>
>> =A0 =A0 =A0 =A0 =3D=3D -2<br>
>> =A0 =A0 =A0 =A0 [453cda54b0a6]<br>
>><br>
>> =A0 -> this code (the whole class) has been removed in Eigen 3.=
<br>
>><br>
>><br>
>><br>
>> and so on...<br>
>><br>
>> Benoit<br>
>><br>
>><br>
>> 2012/9/15 Bill Greene <<a href=3D"mailto:w.h.greene@xxxxxxxxx";>=
w.h.greene@xxxxxxxxx</a>>:<br>
>> ><br>
>> > Dear Eigen Developers,<br>
>> ><br>
>> > I have been an enthusiastic user of Eigen for the past severa=
l years.<br>
>> > Many thanks for writing such a wonderful matrix class library=
!<br>
>> ><br>
>> > Recently I started work at a commercial software company and =
would<br>
>> > like to use Eigen as part of my commercial development work. =
It seems<br>
>> > clear to me that this type of usage is permitted. But I have =
to obtain<br>
>> > approval from the company's lawyers and they would not gi=
ve this<br>
>> > approval.<br>
>> > First off, they will not consider any software licensed under=
LGPL3.<br>
>> > I pointed out that most of the software had recently been re-=
licensed<br>
>> > under<br>
>> > MPL and pointed them to the email threads that, to me, indica=
ted a very<br>
>> > careful, thorough process followed during re-licensing. Accor=
ding to<br>
>> > them,<br>
>> > the licensing process was not legally sufficient and their co=
mplaints<br>
>> > appear to focus on this sentence:<br>
>> ><br>
>> > "Aside from 3rd-party code, there remain only about 50 c=
hangesets<br>
>> > without re-licensing approval, they all seem to be from contr=
ibutors<br>
>> > who contributed at most 2 changesets to Eigen, and 50 changes=
ets is<br>
>> > about only 1% of the total."<br>
>> ><br>
>> > They claim that the potential exists for as many as 50 develo=
pers to<br>
>> > challenge the legality of the re-licensing process.<br>
>> ><br>
>> > Can anything more be said about these 50 changesets? Is it po=
ssible to<br>
>> > avoid the code that includes these changes?<br>
>> ><br>
>> > Sorry to bother you guys with this issue particularly since i=
t seems<br>
>> > clear<br>
>> > to me that the re-licensing process you followed showed due d=
iligence.<br>
>> > But I'll be very disappointed not to be able to use Eigen=
in my upcoming<br>
>> > work and I'm looking for any data I can use to convince t=
he lawyers this<br>
>> > should be allowed.<br>
>> ><br>
>> > Thanks.<br>
>> ><br>
>> > Bill<br>
>><br>
>><br>
><br>
<br>
<br>
</div></div></blockquote></div><br></div>
--14dae9341277f43e6404c9d93175--