Re: [eigen] Using Eigen in commercial software

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

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