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

[Marcus D. Hanwell]

My understanding (and Benoit Jacob consulted the FSF for confirmation) is
that much of the LGPL does not apply to Eigen as it is a pure header,
template class (there is no library to link to). The LGPL3 specifically
covers templates, and there are no static linking issues. The only clause
that applies is that of having to contribute back any changes made to the
Eigen code if you distribute binaries that were compiled using modified
Eigen headers.

http://eigen.tuxfamily.org/index.php?title=Licensing_FAQ#Using_Eigen_in_BSD-licensed_software

I can see that even that restriction might be too much, but wanted to point
out that in the case of header only template libraries some of the drawbacks
of the LGPL are not applicable. I certainly appreciate the need for caution
when depending on any new library for core functionality. As it is, any user
of VTK can use Eigen (and other similar libs) with VTK data structures.

Marcus

On Fri, Jan 29, 2010 at 4:31 PM, Berk Geveci <berk.geveci at kitware.com>wrote:

> 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. There is also the "modification for the customer's
> own use and reverse
> engineering for debugging such modifications" clause that would make
> any commercial
> user of VTK pause and possibly use something else. It is one thing to
> depend on a LGL'ed
> library optionally (like we do with ffmpeg), it is a completely
> different thing to use it in core.
>
> For VTK to use this, they would have to either change the license or
> make an exception
> for VTK (and all projects that may use VTK).
>
> -berk
>
> On Mon, Jan 25, 2010 at 5:49 PM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
> > http://eigen.tuxfamily.org/index.php?title=FAQ#Licensing - this should
> not be
> > an issue. Benoit even asked the FSF about the position - the LGPL3
> license
> > makes provisions for templates etc. The only circumstance they felt it
> would
> > be an issue is the normal one - where we changed the Eigen source code
> those
> > changes must be contributed back/made available.
> >
> > I have worked with Benoit for many years, and am certain he would be open
> to
> > answering any questions you might have. This license was chosen to ensure
> > Eigen could be permissively used in both open and closed source
> applications.
> >
> > On Monday 25 January 2010 17:34:25 Bill Lorensen wrote:
> >> I would be concerned about the lgpl license.
> >>
> >> On Mon, Jan 25, 2010 at 5:30 PM, Andrew Maclean
> >>
> >> <andrew.amaclean at gmail.com> wrote:
> >> > Actually Eigen looks quite good. I wonder how much work would be
> >> > needed to refactor VTK to use this?
> >> >
> >> >
> >> > Andrew
> >> >
> >> > On Tue, Jan 26, 2010 at 1:55 AM, Biddiscombe, John A. <
> biddisco at cscs.ch>
> > wrote:
> >> >> To revisit this question :
> >> >>
> >> >> I'd like to see VTK adopt a decent vector+maths library under the
> hood,
> >> >> a dependency on something like Eigen would not be a problem AFAIAC
> >> >> (Especially if it was inside Utilities and compiled along with VTK).
> VTK
> >> >> shouldn't reimplement these things, but should not introduce too many
> >> >> hard to solve dependencies. Using Utilities/Mathlibrary-1,2,3 etc is
> not
> >> >> a problem for me. There are many algorithms in VTK which mess round
> with
> >> >> points and the code is not very readable. A decent vector/matric
> >> >> template calss would make things much better.
> >> >>
> >> >> In an ideal world all things like boost would work out of the box
> with
> >> >> cmake too and we could replace huge amounts of smartpointer stuff,
> >> >> lists, and the rest with stl/boost objects.
> >> >>
> >> >> JB
> >> >>
> >> >>> -----Original Message-----
> >> >>> From: vtk-developers-bounces at vtk.org
> >> >>> [mailto:vtk-developers-bounces at vtk.org] On Behalf Of David Doria
> >> >>> Sent: 11 January 2010 03:50
> >> >>> To: VTK Developers
> >> >>> Subject: [vtk-developers] Scope of VTK and it's potential as a
> common
> >> >>> research language
> >> >>>
> >> >>> A recent discussion has raised, again, a point which has come up
> >> >>> several times - that is, how much math should VTK include? I agree
> >> >>> that it is very important to address. Here are my thoughts:
> >> >>>
> >> >>> Although VTK is a visualization toolkit, I believe it can and should
> >> >>> act as much more than that. It serves as a common language for
> >> >>> scientists and engineers to share code (clearly within reason -
> >> >>> typically in the computer graphics/computer vision/image processing
> >> >>> fields). This is critically important as technology continues to
> >> >>> advance at an accelerating rate. While yes, we don't strive to
> provide
> >> >>> a full mathematics toolbox, I believe we should not hesitate to
> >> >>> provide things to make it easy for people to share code. If a few
> >> >>> simple matrix multiples force someone to include yet another 3rd
> party
> >> >>> library, it makes it significantly harder to give to a colleague. If
> >> >>> one says "here is my code, you'll need VXL, VTK, ITK, LAPACK, Boost,
> >> >>> etc. etc", that will discourage people from actually use the code,
> as
> >> >>> they will likely have to spend a week getting it to compile and
> link.
> >> >>> If one says "I have implemented all of my research as VTK filters",
> >> >>> the next researcher can simply use it as a building block for the
> next
> >> >>> year's research. I've never seen an actual survey, but I bet the
> >> >>> *majority* of most students (and probably professional's, too) time
> is
> >> >>> spent re-implementing things that have already been written at least
> >> >>> once (probably hundreds of times) and should already be
> >> >>> "plug-and-play". The problem is 100% that the code is not written in
> a
> >> >>> form that is compatible with the next guy's code base. If we strive
> to
> >> >>> setup an environment in which this problem is alleviated, it would
> be
> >> >>> a massive step in the right direction for the success of all future
> >> >>> scientists. The Insight/VTK journal's are already in place to then
> >> >>> make this work in a common environment/language easy to share and
> >> >>> find.
> >> >>>
> >> >>> That said, there is still clearly a line that needs to be drawn. We
> >> >>> should probably not provide everything that is available in a
> >> >>> mathematics package such as Maple. However, again, we shouldn't
> >> >>> hesitate to provide things that are reasonably linked to the
> research
> >> >>> fields that people who use VTK are involved with. If the logic is
> "VTK
> >> >>> is only a visualization toolkit", then all of the readers and
> writers
> >> >>> do not fit the description, which we all know to be critically
> useful.
> >> >>> None of the mathematics functions should be exposed, which would
> make
> >> >>> things much harder. My point is, we have already taken a giant step
> >> >>> over the "only a visualization toolkit" line, so why restrain
> >> >>> continued development in reasonable directions?
> >> >>>
> >> >>> I realize I'm the "new guy" to VTK, but I think this allows me to
> >> >>> bring a nice perspective to the table. Being a current PhD student,
> >> >>> I'm experiencing first hand the "state of the art" of code sharing
> >> >>> and, frankly, it is failing miserably.
> >> >>>
> >> >>> I'd like to hear what some of you veteran VTK-ers and scientists
> think
> >> >>> about this.
> >> >>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100130/14686f49/attachment.html>