Re: [eigen] Using Eigen in commercial software

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

Hi Clifford,

we did get Intel's agreement.

gael.


On Thu, Oct 18, 2012 at 4:35 AM, Clifford Yapp <cliffyapp@xxxxxxxxx> wrote:
> Benoit,
>
> Do I have it right that we down to the Intel contribution for
> relicensing approvals?
>
> Cheers,
> CY
>
> On Fri, Sep 28, 2012 at 4:07 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> 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
>>>>>> >>> >> >>
>>>>>> >>> >> >>
>>>>>> >>> >> >
>>>>>> >>> >>
>>>>>> >>> >>
>>>>>> >>> >
>>>>>> >>>
>>>>>> >>>
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
>
>