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

Mon Feb 1 10:39:02 EST 2010

Benoit,

ITK is also in discussion about adding a math library. There are many
cross over developers between VTK and ITK and I'm certain the same
arguments we are using here will pertain to the ITK discussion.

Bill

On Mon, Feb 1, 2010 at 10:02 AM, Benoit Jacob <jacob.benoit.1 at gmail.com> wrote:
> Thanks for sharing your experiences, that was interesting to read.
>
> Eigen different from VTK in many respects. It is very small; being a
> matrix library, it has a huge number of potential users; so it always
> had as many users as we could handle, including industrial users, in
> spite of the LGPL; finally, Eigen, being very small and spearheading
> the current push to displace Fortran in favor of C++ as the preferred
> language for matrix computations, would be a good candidate for
> proprietary forks.
>
> Benoit
>
> 2010/2/1 Will Schroeder <will.schroeder at kitware.com>:
>> 17 years doing this stuff and I have not seen a fork in our community (which
>> includes VTK, ITK, CMake, CDash, ParaView, GCCXML. Slicer, VXL, and many
>> other very valuable pieces of software). My experience tells me that it is a
>> rare event. By way of explanation, putting my business hat on for a minute,
>> the only place I can hire developers/support personnel for a project is from
>> the community, and if I've tried to "own" the project I've likely pissed
>> them off and will have few takers, if any. Not only that but the community
>> would forge ahead and develop independently, and if vital enough would leave
>> the proprietary fork in the dust.
>>
>> I just argued this in my recent blog
>> http://www.kitware.com/blog/home/post/3, by using GPL or LGPL, the license
>> is so confusing (as evidenced by this eigen thread) it leads to FUD and
>> hence commercial (and some government) entities won't touch it, not to
>> mention even friendly open-source communities like VTK (i.e., it is unlikely
>> that we will ever incorporate LGPL/GPL into our core). Further, this means
>> that these entities are less likely to contribute to it. This is a pity
>> because we've seen millions of $ go into our OS products from these
>> so-called commercial and gov't bad guys, which has benefited us tremendously
>> both technically and financially. GPL and LGPL are an impediement to the
>> growth of the FOSS world, IMHO. I believe that these so-called bad guys are
>> the unrecognized champions of OS software....a topic for another blog :-)
>>
>> Finally, as a software person I like to see my stuff used. I don't really
>> care if someone takes my stuff and embeds it into a commercial application.
>> In the end I know that more often or not if it is valuable work, and due to
>> the inherent complexity of software, the commercial entity will come back to
>> Kitware and say "can you please help me?" and we will make money, expand our
>> influence and reputation, and set the stage for the next business
>> relationship. And in many cases some of that funding will go towards
>> improving the OS tools, sometimes just bug fixes but often pretty fancy
>> implementations. For this reason we actually encourage people and
>> organization to take products like ParaView and create derivative works, in
>> the end it increases our exposure, customer base, and technology base.
>>
>> Will
>>
>> 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
>>>
>>
>>
>>
>> --
>> William J. Schroeder, PhD
>> Kitware, Inc.
>> 28 Corporate Drive
>> Clifton Park, NY 12065
>> will.schroeder at kitware.com
>> http://www.kitware.com
>> (518) 881-4902
>>
> _______________________________________________
> 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
>
>