Re: [eigen] Using Eigen in commercial software

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

Konstantin did send his reply to this mailing list on October 10 and
CC'd me and Gael. However, looking at the archives, it does seem that
it didn't come through:
http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2012/10/threads.html
Maybe he wasn't a member and didn't notice the rejection notice.
Though we had temporarily opened the list to non-members around that
date.

We now seem to have replies from all the people we wanted replies
from, sent to this list.

I meant to post an update about this, but was busy.

Benoit

2012/10/18 Bill Greene <w.h.greene@xxxxxxxxx>:
> Did they not reply to the list then? I've been looking for that posting,
> myself.
>
> Thanks.
>
> Bill
>
>
> On Thu, Oct 18, 2012 at 3:12 AM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
> wrote:
>>
>> 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
>> >>>>>> >>> >> >>
>> >>>>>> >>> >> >>
>> >>>>>> >>> >> >
>> >>>>>> >>> >>
>> >>>>>> >>> >>
>> >>>>>> >>> >
>> >>>>>> >>>
>> >>>>>> >>>
>> >>>>>> >>
>> >>>>>> >
>> >>>>>> >
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>
>> >>
>> >
>> >
>>
>>
>