Re: [eigen] Using Eigen in commercial software

[ Thread Index | Date Index | More Archives ]

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?

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.

Thanks again.


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.

        * doc/C09_TutorialSparse.dox:
        Fixed a few typos and cleaned up some language.

  -> that is documentation only.

bjacob:~/eigen$ hg log -u 'williami@xxxxxxxxxxxxxxxxxxxxxxxxxx'
2012-06-04  williami  <williami@xxxxxxxxxxxxxxxxxxxxxxxxxx>

        * Eigen/Core, Eigen/src/Core/PlainObjectBase.h,
        Fixed RVCT 3.1 compiler errors. (transplanted from
        [8d244d9c6668] <3.0>

        * Eigen/Core, Eigen/src/Core/PlainObjectBase.h,
        Fixed RVCT 3.1 compiler errors.

  -> 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 - (transplanted from
        [0b7f92e0e626] <3.0>

        * CMakeLists.txt:
        resolve pkgconfig destination -

   -> 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
        [180613093b9f] <3.0>

        * Eigen/src/Core/Block.h, Eigen/src/Core/util/XprHelper.h:
        Fix MSVC integer overflow warning

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

  -> 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
        unsupported/Eigen/CholmodSupport, unsupported/Eigen/SparseExtra,
        unsupported/Eigen/SuperLUSupport, unsupported/Eigen/UmfPackSupport,
        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

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

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

  -> this code (the whole class) has been removed in Eigen 3.

and so on...


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

Mail converted by MHonArc 2.6.19+