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

Berk Geveci berk.geveci at kitware.com
Sun Jan 31 09:29:56 EST 2010


Hi Benoit,

That's great! The only clause that still gives me pause is the
following from section 4:

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



More information about the vtk-developers mailing list