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

Mon Feb 1 09:33:38 EST 2010

2010/2/1 Berk Geveci <berk.geveci at kitware.com>:
>>> It would be great then if a BSD like license can be adopted with
>>> explicit clauses such as these.. but that's entirely upto the eigen
>>> folks.
>>
>> Yes, that would be nice. In our case, as I explained, such a "BSD +
>> preventing proprietary forks" would be equivalent to the LGPL, but
>> that would allow us to do without our long FAQ. I could attempt to
>> write such a license, but that's not reasonable as I'm not a lawyer.
>
> I believe that there are several licenses that already do this. Take a look
> at this page: http://developer.kde.org/documentation/licensing/licenses_summary.html
>
> One that sticks out is the Apple Public License:
> http://www.opensource.org/licenses/apsl-2.0.php

Unfortunately, it is already too long to bring the advantage of being
"nearly as simple as the BSD license".

What I am wondering is if it is possible to take the BSD, add 5 lines
to it to prevent proprietary forks, and be done.

Benoit

>
> -berk
>
> On Mon, Feb 1, 2010 at 8:38 AM, Benoit Jacob <jacob.benoit.1 at gmail.com> wrote:
>> 2010/1/31 Karthik Krishnan <karthik.krishnan at kitware.com>:
>>> I believe Benoit's already put forth one (and the only ?) concern : to
>>> prevent forks of eigen.
>>
>> Indeed, that's the main reason: we don't want to allow _proprietary_
>> forks of eigen. Different open source projects are in different
>> situations, allowing them different licenses. Eigen is a
>> volunteer-only project, so developer motivation is subtle and is our
>> only asset, and Eigen developers have stated that their motivation
>> would be affected if our license allowed proprietary forks.
>>
>>> It would be great then if a BSD like license can be adopted with
>>> explicit clauses such as these.. but that's entirely upto the eigen
>>> folks.
>>
>> Yes, that would be nice. In our case, as I explained, such a "BSD +
>> preventing proprietary forks" would be equivalent to the LGPL, but
>> that would allow us to do without our long FAQ. I could attempt to
>> write such a license, but that's not reasonable as I'm not a lawyer.
>>
>> Benoit
>>
>>>
>>> On Mon, Feb 1, 2010 at 8:24 AM, Andrew Maclean
>>> <andrew.amaclean at gmail.com> wrote:
>>>> Jacob,
>>>>   In an attempt to move along a very interesting discussion, I would
>>>> like to get to the point:
>>>>
>>>>   Would you be happy to use a BSD like license the same as VTK? It
>>>> seems to me that this will nicely remove all the complexities raised
>>>> in the previous discussion.
>>>>
>>>> Is there a specific reason for preferring LGPL?
>>>>
>>>> Regards
>>>>   Andrew
>>>>
>>>>
>>>>
>>>> On Mon, Feb 1, 2010 at 6:55 AM, Benoit Jacob <jacob.benoit.1 at gmail.com> wrote:
>>>>> 2010/1/31 Benoit Jacob <jacob.benoit.1 at gmail.com>:
>>>>>> 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.
>>>>>
>>>>> ...and perhaps most conclusively, these files are inherently header
>>>>> files at the level of their contents, for example, they have include
>>>>> guards, and they define templates without instantiating them which
>>>>> would be a NOP if they weren't headers.
>>>>>
>>>>> Benoit
>>>>>
>>>>>>
>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ___________________________________________
>>>> Andrew J. P. Maclean
>>>> Centre for Autonomous Systems
>>>> The Rose Street Building J04
>>>> The University of Sydney  2006  NSW
>>>> AUSTRALIA
>>>> Ph: +61 2 9351 3283
>>>> Fax: +61 2 9351 7474
>>>> URL: http://www.acfr.usyd.edu.au/
>>>> ___________________________________________
>>>> _______________________________________________
>>>> 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
>>
>>
>