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

Mon Feb 1 10:02:31 EST 2010

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
>