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