Re: [eigen] Using Eigen in commercial software

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

2012/9/28 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> Here's the current status:
>
> [5731dbe0ec5f] 2011-12-09  Igor Krivenko  <Igor Krivenko>
>
> I am just contacting him now thanks to Bastien's information.
>
> [a1f843f013c9] 2011-12-05  karturov  <karturov@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>
> He replied saying he's waiting for a confirmation from his legal department.
>
> [3233ef18be4a] 2011-05-23  David H. Bailey  <David H. Bailey>
> [efe1a0250288] 2011-05-23  David H. Bailey  <David H. Bailey>
>
> I am just contacting him now thanks to Bill's and Bastien's information.

That was erroneous metadata. The author of this patch was another
David, but the person pushing this patch got confused by information
on that bug (http://eigen.tuxfamily.org/bz/show_bug.cgi?id=276). I've
now contacted this David.

Benoit

>
> [f86a974f6111] 2011-02-03  Jason Newton  <nevion@xxxxxxxxx>
>
> Has already sent his agreement on this list.
>
> [0e182249fb56] 2011-12-10  Andy Somerville  <andy.somerville@xxxxxxxxx>
>
> Has already sent his agreement on this list.
>
> [13f72ac8283d] 2011-11-17  Kibeom Kim  <kkimlabs@xxxxxxxxx>
>
> Has already sent his agreement on this list.
>
> [6e0ee90bd35c] 2011-01-07  Romain Bossart  <romain.bossart@xxxxxxx>
>
> Has sent his agreement privately to me and Gael. We are asking him to
> please re-send it to this list.
>
> Benoit
>
> 2012/9/26 Clifford Yapp <cliffyapp@xxxxxxxxx>:
>> Benoit -
>>
>> How do we stand on the relicensing responses?  Is there anyone we need
>> to try to locate more current contact information for?
>>
>> Cheers,
>> CY
>>
>> On Wed, Sep 19, 2012 at 12:43 PM, Bill Greene <w.h.greene@xxxxxxxxx> wrote:
>>> Based on Bastien's comment, I'm guessing this is the David H. Bailey who
>>> contributed the Eigen change.
>>>
>>> http://crd-legacy.lbl.gov/~dhbailey/
>>>
>>> Bill
>>>
>>>
>>> On Wed, Sep 19, 2012 at 7:44 AM, Bastien ROUCARIES
>>> <roucaries.bastien@xxxxxxxxx> wrote:
>>>>
>>>> Igor is active in other field: Igor Krivenko (igor@xxxxxx)  and david
>>>> is well known on SIAM
>>>>
>>>> On Wed, Sep 19, 2012 at 7:48 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
>>>> wrote:
>>>> > 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
>>>> >>> >> >>
>>>> >>> >> >>
>>>> >>> >> >
>>>> >>> >>
>>>> >>> >>
>>>> >>> >
>>>> >>>
>>>> >>>
>>>> >>
>>>> >
>>>> >
>>>>
>>>>
>>>
>>
>>