Re: [eigen] Using Eigen in commercial software

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

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