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

Sun Jan 31 13:58:58 EST 2010

2010/1/31 Bill Lorensen <bill.lorensen at gmail.com>:
> I understand that. Does the FSF person that answered the question
> understand that?
>  What did he mean by "only certain materials"? Are there other
> materials in the header file that might be include that would negate
> his statement?

I am really convinced that I am understanding things correctly here,
because we have discussed this extensively with many people. Section 3
of the LGPL3 was added exactly for the case of libraries that have
code in header files, and we fall exactly into that case. I am not
aware of any kind of material in header files that would negate this
statement, and reading the LGPL text I really don't see how that could
possibly happen. I'm not a lawyer, just a developer who discussed that
extensively with other developers.

Benoit

>
>
> On Sun, Jan 31, 2010 at 1:45 PM, Benoit Jacob <jacob.benoit.1 at gmail.com> wrote:
>> 2010/1/31 Bill Lorensen <bill.lorensen at gmail.com>:
>>> Benoit,
>>>
>>> A bit more due diligence on my part...
>>>
>>> This e-mail:
>>> http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2009/01/msg00083.html
>>> from a FSF Licensing Engineer states:
>>>
>>> "It might help to think of it this way: section 3 describes a specific
>>> scenario where an application *only* uses certain materials from header
>>> files."
>>>
>>> What does he mean by "using certain materials from the header". Does
>>> he realize that there is "code" in the header, not just interface
>>> definitions?
>>
>> Yes, exactly. In a headers-only library like Eigen, 100% of the code
>> is in header files. There is nothing but header files.
>>
>> Benoit
>>
>>
>>>
>>> Bill
>>>
>>> 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
>>>>
>>>>
>>>
>> _______________________________________________
>> 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
>>
>>
>