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