[vtk-developers] Scope of VTK and it's potential as a common research language

Benoit Jacob jacob.benoit.1 at gmail.com
Sun Jan 31 14:50:39 EST 2010


2010/1/31 Berk Geveci <berk.geveci at kitware.com>:
> I don't agree. Here are two sections:
>
> 0. Additional Definitions.
>
> ...
>
> A “Combined Work” is a work produced by combining or linking an
> Application with the Library. The particular version of the Library
> with which the Combined Work was made is also called the “Linked
> Version”.
>
> ...
>
> 4. Combined Works.
>
> You may convey a Combined Work under terms of your choice that, taken
> together, effectively do not restrict modification of the portions of
> the Library contained in the Combined Work and reverse engineering for
> debugging such modifications, if you also do each of the following:
>
> ...
>
>
> I read these together to conclude that a binary that is compiled from
> any code that includes Eigen is "Combined Work" (a work produced by
> combining through the inclusion of templates). If that is the case, 4
> would apply and hence the reverse engineering clause. It would be
> against the spirit of LGPL to grant templated libraries less
> protection than compiled libraries so why would they leave such a
> loophole?

Section 3 only talks about using material from header files. It never
says that this material is assumed to be used by #include'ing it.

If VTK uses Eigen headers code, and then application X uses VTK, then
the only Eigen code that application X uses is code from Eigen's
header files. Actually, all Eigen code is located in header files. So
Section 3 still fully applies.

One might wonder the extent to which that might be used to abuse the
LGPL by claiming that arbitrary files are header files. In the case of
Eigen, it's very simple: all our internal source file have the ".h"
extension and all our documentation tells to use Eigen by #including
files, not linking to anything.

As to why this "loophole", I believe that's simply because there's no
way around it if the FSF wanted the LGPL to be applicable at all to
libraries that have nontrivial code in header files, which includes
most C++ libraries including Qt (think QVector). The reason why
there's no way around it is that #including is in essence similar to
static linking, and doesn't have a runtime analogue.

Benoit



>
> Of course, the copyright holders of Eigen are free to write an
> addendum to the license that explicitly states (4) does not apply.
>
> My vote is to keep Eigen out of core VTK. I wouldn't have any problem
> with releasing an application that brings together VTK and Eigen (and
> Qt for that matter) because I don't see any issues with LGPL's
> requirements but I don't think many of VTK's users that develop
> proprietary apps would share my opinion. We have worked very hard to
> keep VTK's license free of complications and the value Eigen adds is
> not worth wasting all of that effort.
>
> -berk
>
>
> On Sun, Jan 31, 2010 at 11:14 AM, Benoit Jacob <jacob.benoit.1 at gmail.com> wrote:
>> 2010/1/31 Berk Geveci <berk.geveci at kitware.com>:
>>> Hi Benoit,
>>>
>>> That's great! The only clause that still gives me pause is the
>>> following from section 4:
>>
>> Section 4 doesn't apply at all to Eigen ;) see my previous e-mail.
>>
>> So if this is your only concern then I am very optimistic :)
>>
>> Benoit
>>
>>>
>>> "You may convey a Combined Work under terms of your choice that, taken
>>> together, effectively do not restrict modification of the portions of
>>> the Library contained in the Combined Work and reverse engineering for
>>> debugging such modifications ..."
>>>
>>> I am guessing that this applies to Eigen and it allows anyone the
>>> right to reverse engineer a proprietary application for the purpose of
>>> debugging Eigen. Am I right? If that is the case, this would be a
>>> concern because this section does not impose a clear limitation on
>>> what reverse engineering means. To track a particular bug in Eigen,
>>> which is intertwined with the original code, you may need access to
>>> some top-secret-data-structure that the developers do not intend to
>>> release. I would expect that this would be unacceptable to some of the
>>> users of VTK.
>>>
>>> Sorry for making this complicated but such is life when mixing
>>> open-source with proprietary app development.
>>>
>>> -berk
>>>
>>> On Sun, Jan 31, 2010 at 12:36 AM, Benoit Jacob <jacob.benoit.1 at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> [Re-sending now that I am subscribed to the list which is subscribers-only]
>>>>
>>>> I'm one of the developers of Eigen. Reading your e-mails and your
>>>> concerns, I updated a bit the FAQ, see especially:
>>>> http://eigen.tuxfamily.org/index.php?title=Licensing_FAQ#How_about_static_linking.3F_2
>>>>
>>>> Let me summarize things a little (just elaborating on what Marcus said).
>>>>
>>>> Executive Summary:
>>>>
>>>> The LGPL version 3 is fully applicable to template libraries and there
>>>> simply is no issue at all with static linking, not even if VTK uses
>>>> Eigen and then some application links statically to VTK.
>>>>
>>>> Explanation:
>>>>
>>>> First of all, the old LGPL version 2.1 did indeed have lots of issues
>>>> with template libraries. That's why we don't use it for Eigen.
>>>>
>>>> The LGPL version 3 provides 3 different ways in why LGPL-licensed
>>>> libraries may be used: these are Sections 3, 4, and 5.
>>>>
>>>> In the case of Eigen, the only of these sections that you have to read
>>>> is Section 3. It covers the case of template libraries. Eigen is to be
>>>> used entirely under Section 3.
>>>>
>>>> Section 3 is very simple, it's essentially the same thing as a
>>>> 2-clause BSD license. That doesn't mean that LGPL=BSD, because there
>>>> still is the fact that the LGPL prevents proprietary forks of Eigen
>>>> itself.
>>>>
>>>> I would now like to address this concern:
>>>>
>>>>>> I disagree with this not being an issue. Adopting something licensed
>>>>>> under LGPL as a
>>>>>> core library in VTK is a bad idea since it would preclude anyone
>>>>>> building a statically
>>>>>> linked application using VTK - unless they were distributing all of
>>>>>> the components
>>>>>> required to relink.
>>>>
>>>> The "issues with statically linking to LGPL libraries" refer to
>>>> Section 4, specifically 4.d.1. As I said, Section 4 simply doesn't
>>>> apply to Eigen. The confusion comes from the fact that most LGPL
>>>> libraries are used under Section 4 (e.g. Qt is) but Eigen is just a
>>>> special case as it is a pure headers-only library with nothing to link
>>>> to. Thus Eigen is used entirely under Section 3, thus bypassing
>>>> Section 4 entirely, thus bypassing the issues with static linking in
>>>> particular. Subsequently, it just doesn't matter that VTK is a binary
>>>> library and not a headers-only library, because Section 4 just never
>>>> was used in the first place.
>>>>
>>>> More details and explanations in the FAQ that Marcus already linked to:
>>>> http://eigen.tuxfamily.org/index.php?title=Licensing_FAQ
>>>>
>>>> I hope that this addresses your concerns and am available if you need
>>>> more explanations, or disagree with mine!
>>>>
>>>> Thanks,
>>>> Benoit
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>
>>>>
>>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>>
>



More information about the vtk-developers mailing list