Re: [eigen] Using Eigen in commercial software |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Using Eigen in commercial software*From*: Bill Greene <w.h.greene@xxxxxxxxx>*Date*: Wed, 19 Sep 2012 12:43:16 -0400*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=126ip6Avuqr2Eu7P+DLKQhU7N06Y00IjLjQrC+elfFA=; b=TS185K6ZE/5zPUiFMH29gk3FGwFE9hVFilZCxHCtCBiEqVxf1/QUb+rFAvHBScuXhX DVYuFHZZXxWrXzq5AIswPJrezgWhrk/Lu2qOsJ9h8H95i2pHbix6CiOGVR3slOkSOYs/ uf1cxTw1kC7gNdUp0Im6WEGM3Y6TFoMESbyMZgKAXds9JQFEiAABhCUzh2vyfahj5PCk YvWR5DXCWGmFju0SAYQqP64pPtWlJOv8iQIImUtYCVJOSBrtsH694BTeZ3jTmx+dlMU3 HJDhkuOaa/XL4+nAGswckvD/QYNGFJ+aQo671ykI7IFpozC3nfNr1CrCfXCoN7PQ5sIt nh8A==

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

>>> >> >>

>>> >> >>

>>> >> >

>>> >>

>>> >>

>>> >

>>>

>>>

>>

>

>

**Follow-Ups**:**Re: [eigen] Using Eigen in commercial software***From:*Clifford Yapp

**References**:**[eigen] Using Eigen in commercial software***From:*Bill Greene

**Re: [eigen] Using Eigen in commercial software***From:*Benoit Jacob

**Re: [eigen] Using Eigen in commercial software***From:*Bill Greene

**Re: [eigen] Using Eigen in commercial software***From:*Benoit Jacob

**Re: [eigen] Using Eigen in commercial software***From:*Bill Greene

**Re: [eigen] Using Eigen in commercial software***From:*Benoit Jacob

**Re: [eigen] Using Eigen in commercial software***From:*Bill Greene

**Re: [eigen] Using Eigen in commercial software***From:*Benoit Jacob

**Re: [eigen] Using Eigen in commercial software***From:*Bastien ROUCARIES

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] 643004966，从技术~走~向管~理** - Next by Date:
**Re: [eigen] Recursion and block matrices** - Previous by thread:
**Re: [eigen] Using Eigen in commercial software** - Next by thread:
**Re: [eigen] Using Eigen in commercial software**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |