Re: [eigen] Using Eigen in commercial software

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

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
>>
>>
>