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

Bill Lorensen bill.lorensen at gmail.com
Sun Jan 31 14:23:20 EST 2010


He might be a lawyer. Why did he say  "only certain materials"?

I'm sorry, but to me the LGPL, no matter what version, is not a simple license.

Let's drop this line of discussion. Neither of us are lawyers.

Bill

On Sun, Jan 31, 2010 at 1:58 PM, Benoit Jacob <jacob.benoit.1 at gmail.com> wrote:
> 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
>>>
>>>
>>
> _______________________________________________
> 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