Re: [eigen] Using Eigen in commercial software

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

I have sent emails to Konstantin, Jason, Andy, Kibeom and Romain. I
have also opened this list temporarily to non-members to avoid
rejecting their replies. The downside is we'll temporarily be
vulnerable to spamming.

Unfortunately, Igor and David didn't provide email addresses. It's
very important when pushing patches from contributors to ensure that
their author field has an email address.

Benoit

2012/9/18 Bill Greene <w.h.greene@xxxxxxxxx>:
> OK, great! Thanks, Benoit.
>
> Bill
>
>
> On Tue, Sep 18, 2012 at 2:07 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> Thanks for this work. I will contact them asap, hopefully this week
>> but I am at an industrial meeting until Thursday.
>>
>> Benoit
>>
>> 2012/9/16 Bill Greene <w.h.greene@xxxxxxxxx>:
>> > OK, thanks, Benoit, I understand.
>> >
>> > Your samples did help me understand how to analyze the changesets.
>> > From your July 13 email I found 41 changeset authors with 1-2 changesets
>> > each that had not agreed to re-licensing. I found a total of 54
>> > changesets
>> > for
>> > these authors. I looked at each of these. As you say, many of them are
>> > trivial, deal with documentation, tests, or Cmake files-- none of which
>> > is
>> > a concern. I did find 8 changesets that definitely could be considered
>> > non-trivial:
>> >
>> > [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
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>