Difference between revisions of "Licensing FAQ"

From Eigen
Jump to: navigation, search
 
Line 1: Line 1:
This page should address any licensing concern that anyone may have about using Eigen. We are convinced that Eigen's licence allows virtually anyone to use it.
+
This page used to have a long FAQ that we thought was useful when Eigen was LGPL-licensed.
  
If you still have a concern, don't hesitate to contact us.
+
Now that Eigen is MPL2-licensed, there is no need anymore for that. Common questions about the MPL2 are answered on the [http://www.mozilla.org/MPL/2.0/FAQ.html MPL2 FAQ]. Do not hesitate to write to the Eigen mailing list if you have further questions, although we aren't lawyers and you will be better served by asking directly the MPL2 specialists (see above MPL2 FAQ link).
  
The answers below are mutually redundant for the sake of being easier to find.
+
The MPL2 is a simple, file-level-copyleft license (meaning that the copyleft does not propagate across source file boundaries) which should allow use by all projects.
 
+
=General licensing questions=
+
 
+
==How is Eigen licensed?==
+
 
+
Eigen is dual-licensed: at your choice,
+
 
+
* either under the [http://www.gnu.org/licenses/lgpl.html LGPL], version 3 or later,
+
* or under the [http://www.gnu.org/licenses/gpl.html GPL], version 2 or later.
+
 
+
Note that this is an OR, not an AND. You do not need to conform to both licenses, you just pick the one that you prefer.
+
 
+
Typically, almost everybody will regard Eigen as just LGPL-licensed. Exceptions, where one may want to regard Eigen as GPL-licensed, are [[#Why_add_the_GPL_as_another_license_choice.2C_since_anyway_the_LGPL_is_more_liberal.3F|described below]].
+
 
+
==What is the LGPL?==
+
 
+
The [http://www.gnu.org/licenses/lgpl.html LGPL] is one of the most popular open source licenses.
+
 
+
It is quite permissive, at least much more permissive than the GPL license. It allows any software to use Eigen. For example, proprietary software may use Eigen without disclosing any of its own source code.
+
 
+
==So what does the LGPL require me to do?==
+
 
+
In the following answer, we're assuming that you're using Eigen ''unmodified''.
+
If you are using a  ''modified Eigen'', then there's an additional clause, see [[#Forking Eigen|our section on forking]].
+
 
+
When you distribute software that ''uses'' Eigen, the LGPL requires you to:
+
* Say somewhere that that software uses Eigen, and that Eigen is LGPL-licensed.
+
* Give a link to the text of the [http://www.gnu.org/copyleft/lesser.html LGPL] license.
+
See Section 3 of the [http://www.gnu.org/copyleft/lesser.html LGPL].
+
 
+
That's pretty much the same as the 2-clause BSD license.
+
 
+
For the interested reader, let us explain where this analysis comes from. Since Eigen is only header files, you only need to honor Section 3 of the LGPL when distributing Eigen. We got this [http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2009/01/msg00083.html confirmed] by the [http://fsf.org FSF]. Fortunately, Section 3 is very short and readable. Let us just elaborate on our above interpretation of it. Section 3 says that you should mention "prominently" that your application uses Eigen. However, we do not seek to enforce a strong meaning of the word "prominently". For example, the bottom of a README file or of a website would be "prominent" enough for us. Feel free to contact us if you want to further clarify this. Also, the LGPL says that you should be distributing the LGPL and GPL texts itself, but common sense suggests clearly that it should be enough to distribute [http://www.gnu.org/copyleft/lesser.html links to them]. Since the LGPL page links prominently to the GPL page, just linking to the LGPL should be enough. And of course, all that does not imply at all that the LGPL license applies to your own software. The 2-clause BSD license has very similar requirements, by the way.
+
 
+
==But the LGPL is a very complex license!==
+
 
+
Hold on! In the case of Eigen, it's much simpler than in the generic case. So the usual concern about the complexity of the LGPL doesn't apply to us.
+
 
+
The LGPL3 license provides three ways in which LGPL-licensed software may be used: these are sections 3, 4 and 5 of the license.
+
 
+
Since Eigen is a headers-only library, it can be used entirely under Section 3. This is good news for Eigen users, as this section is the simplest one. We just [[#So what does the LGPL require me to do?|explained what it requires]]. That is pretty much equivalent to the requirements of the 2-clause BSD license.
+
 
+
By contrast, most other libraries (not Eigen) are binary libraries that one links to, and in that case Sections 4-5 apply, and these are indeed rather complex. This is where the LGPL's reputation for complexity comes from. Again, Sections 4-5 don't apply to Eigen, where all the code is in header files. We got this [http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2009/01/msg00083.html confirmed] by the [http://fsf.org FSF].
+
 
+
==In the case of Eigen, how does the LGPL differ from the 2-clause BSD license?==
+
 
+
In the case of Eigen, the LGPL only differs from the 2-clause BSD license on one important point, which we explain in [[#Forking Eigen|our section on forking]].
+
 
+
==Forking Eigen==
+
 
+
''Forking'' Eigen means ''modifying'' Eigen ''itself'' and distributing software based on your modified Eigen. In that case, there is the following additional requirement:
+
 
+
If you are distributing software based on your modified Eigen, then you must make your ''modified Eigen'' available under the LGPL license.
+
 
+
The ''only'' thing that you have to make available under the LGPL, is your ''modified Eigen''. You still don't have to make any other software available under the LGPL, not even software that uses Eigen or software that uses your modified Eigen.
+
 
+
Just ''using'' Eigen in your software does ''not'' constitute forking. Forking Eigen involves modifying Eigen's own files in some way. The LGPL is also explicitly saying (in Section 0) that subclassing a Eigen class (a.k.a. inheriting from a Eigen class) does ''not'' constitute forking.
+
 
+
If you are using your modified Eigen only internally, i.e. you are not distributing software based on it, then you don't have to make it available under the LGPL.
+
 
+
As long as you're not modifying Eigen's own files, you can safely ignore this. Thus, for almost all of our users, the LGPL is for all practical purposes essentially equivalent to the 2-clause BSD license.
+
 
+
==But doesn't the LGPL have issues with code that is in header files, and template libraries?==
+
 
+
Not anymore. That was the case in the old LGPL 2.1. That problem has been solved in version 3 of the LGPL. The relevant part of the LGPL3 is Section 3.
+
 
+
We asked the [http://fsf.org FSF] to confirm this, and [http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2008/02/msg00008.html here was their reply].
+
 
+
This is the reason why we require the LGPL version to be at least 3.
+
 
+
==But doesn't the LGPL have issues with static linking?==
+
 
+
Linking, static or not, just doesn't apply to Eigen, which is just header files! In Eigen, there is nothing to link to.
+
 
+
The "issues of LGPL with static linking" refer to Section 4 (specifically 4.d.1.) in the LGPL3. As we already discussed, the whole Section 4 does not apply to Eigen at all. Instead, Section 3 applies.
+
 
+
==But what if an application A links statically to a library B that uses Eigen?==
+
 
+
Even in that case, Section 4 still doesn't apply, one is still entirely in the domain of Section 3, so there still is no issue with static linking. The LGPL does not extend to an application linking statically to a library that uses Eigen.
+
 
+
Let us explain that. Section 3 talks about "incorporating material from header files". It doesn't matter how this material is incorporated. It's not restricted to directly #include'ing the headers. Nothing prevents it from applying also to the case where one is linking to code that comes ultimately from #include'ing headers. All what matters is that the material ultimately comes from header files. And in the case of Eigen, all source files are header files (and their contents only make sense anyway as headers).
+
 
+
Thus there is absolutely no reason why Section 3 wouldn't apply here too.
+
 
+
==Why add the GPL as another license choice, since anyway the LGPL is more liberal?==
+
 
+
A library licensed under the LGPL3 cannot be used by a program licensed under the GPL2 ([http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility see here for details]). Therefore, we offer the GPL2 as an alternative license choice for Eigen, in order to allow GPL2 programs to use it.
+
 
+
There is another circumstance in which the GPL license may be useful. Some optional advanced functionality can be enabled by letting Eigen use external libraries, which we call back-ends. Some such libraries are GPL-licensed. For example, in our FFT module (currently unsupported) there is an option to use the FFTW library as a back-end for higher performance. Since FFTW is GPL-licensed, this is only possible if Eigen is used under GPL license. Meanwhile, commercial users of Eigen will instead use the Intel MKL back-end, using MKL under a commercial license and Eigen under LGPL license.
+
 
+
=Using Eigen in proprietary software=
+
 
+
==Can Eigen be used in proprietary, closed-source software?==
+
 
+
Yes! Eigen is already in wide use in proprietary, closed-source software. This is entirely welcome. Of course, you do not have to disclose any of your own source code. Using Eigen does not affect the licensing of your own software in any way. The LGPL license of Eigen does not extend in any way to your own software.
+
 
+
Here are some examples of companies using Eigen in proprietary closed-source projects:
+
* The [http://yujinrobot.com/ Yujin Robot] company uses Eigen for the navigation and arm control of their robots.
+
* [http://www.redsword.com Red Sword Studios], maker of the iPhone games [http://linktoapp.com/Gradient Gradient], [http://linktoapp.com/Fortress+Luna Fortress Luna], [http://linktoapp.com/Stimulus Stimulus], and Lustre, uses Eigen extensively.
+
* At least two very important (top-10) software companies are using Eigen internally but we haven't yet asked them for permission to say this publicly. Contact us if you would like to know more.
+
 
+
==So is the LGPL a perfectly business-friendly license?==
+
 
+
Yes, absolutely! Note that the LGPL is very different from the GPL in this respect. There are countless examples of LGPL-licensed libraries in very wide use by businesses, including in closed-source applications:
+
* [http://qt.nokia.com/ Qt], the C++ application framework.
+
* [http://www.gtk.org/ GTK+], the GUI toolkit.
+
* [http://webkit.org/ WebKit] components such as WebCore and JavaScriptCore, see [http://webkit.org/coding/lgpl-license.html this page].
+
* [http://www.gnu.org/software/libc/ The C standard library] that comes with GCC.
+
* [http://ffmpeg.org/legal.html FFmpeg], [http://www.libsdl.org/license-lgpl.php SDL], [http://connect.creativelabs.com/openal/default.aspx OpenAL].
+
 
+
Eigen itself does have several big commercial closed-source users, see the partial list of [[Main_Page#Projects_using_Eigen|projects using Eigen]], and several large companies are not mentioned there.
+
 
+
==But the LGPL is too complex! My legal department will take forever to analyze it!==
+
 
+
In the case of Eigen, the LGPL is actually very simple, [[#But the LGPL is a very complex license!|as we explain above!]] The key here is that Eigen is a headers-only library, so the only section of the LGPL that governs the usage of Eigen is Section 3, and it is very simple!
+
 
+
The LGPL's reputation for complexity comes from Sections 4-5, which just don't apply to Eigen.
+
 
+
==How about static linking?==
+
 
+
This has been [[#But_doesn.27t_the_LGPL_have_issues_with_static_linking.3F|discussed above]].
+
 
+
==I'm distributing a proprietary, closed-source application that uses Eigen. What am I required to do?==
+
 
+
See our [[#So what does the LGPL require me to do?|answer above]]. The fact that your application is proprietary does not make any difference here.
+
 
+
==Are there circumstances in which the LGPL puts significant other requirements on me?==
+
 
+
There is one such circumstance, this is when you are [[#Forking Eigen|forking Eigen]]. See our [[#Forking Eigen|section on this topic]].
+
 
+
As long as you're not modifying Eigen ''itself'', you can safely ignore this. Hence almost all of our users can safely ignore this.
+
 
+
=Using Eigen in BSD-licensed software=
+
 
+
In this section we discuss usage of Eigen in BSD-licensed software. Of course, the same applies to MIT-licensed software and other similar licenses.
+
 
+
==Examples of BSD-licensed projects using Eigen==
+
 
+
There are many examples of BSD-licensed projects that use Eigen under LGPL license. Here are a few inspiring ones.
+
* The [http://www.ros.org Robotic Operating System (ROS)] developed by [http://www.willowgarage.com Willow Garage]. It [http://www.ros.org/wiki/eigen uses Eigen] in 39 of its packages.
+
* [http://code.google.com/p/libmv Libmv], a structure-from-motion library.
+
 
+
==The LGPL license is too complex to even read!==
+
 
+
In the case of Eigen, the LGPL is actually very simple, [[#But the LGPL is a very complex license!|as we explain above!]] The key here is that Eigen is a headers-only library, so the only section of the LGPL that governs the usage of Eigen is Section 3, and it is very simple!
+
 
+
The LGPL's reputation for complexity comes from Sections 4-5, which just don't apply to Eigen.
+
 
+
Of course, even in the case of Eigen's case, the LGPL is still not quite as simple as the BSD license, but very few licenses are.
+
 
+
==So what does the LGPL require when distributing software that uses Eigen?==
+
 
+
See our [[#So what does the LGPL require me to do?|answer above]]. It's pretty much the same as if Eigen were BSD-licensed.
+
 
+
==So, in the case of Eigen, how is the LGPL different from the BSD license?==
+
 
+
As we explained above, the LGPL puts an important requirements on [[#Forking Eigen|forks of Eigen]]. See [[#Forking Eigen|our section on that topic]]. Namely, if one forks Eigen and distributes software based on the forked Eigen, then one must distribute the forked Eigen under the LGPL.
+
 
+
Note that this does not at all propagate to your own project. If you develop a library that uses Eigen, and you distribute your library under the BSD license, people will be able to create proprietary forks of your library, as allowed by the BSD license. The only thing that will not be allowed is a proprietary fork of Eigen itself. If people fork both your library and Eigen, the LGPL will still apply only to their fork of Eigen, not to their fork of your library.
+
 
+
==I'm developing a BSD-licensed library and I don't want to pass on LGPL requirements to my users!==
+
 
+
Don't worry! The only LGPL requirements that you might be passing to users are the 2 clauses [[#So what does the LGPL require when distributing software that uses Eigen?|described above]], which are very similar to the 2 clauses of the BSD license itself.
+
 
+
Concerning the interdiction of proprietary forks, as we [[#So, in the case of Eigen, how is the LGPL different from the BSD license?|just explained]],  it will only apply to Eigen, not to your own code.
+
 
+
==How about static linking?==
+
 
+
This has been [[#But_doesn.27t_the_LGPL_have_issues_with_static_linking.3F|discussed above]].
+
 
+
Also, as we [[#But_what_if_an_application_A_links_statically_to_a_library_B_that_uses_Eigen.3F|explained there]], if you develop a BSD-licensed library using Eigen, then your users can statically link to your library without the LGPL applying at all.
+
 
+
==But I really want to allow my users to do proprietary forks not only of my library, but of all its dependencies!==
+
 
+
Isn't Eigen worth making a little exception? Are you really sure that your users care about that, in the case of Eigen?
+
* Firstly, your library, not Eigen, is what matters to your users. Eigen is just generic math code, and is far less likely to be where users want to develop their own proprietary extensions. Eigen is just ''generic-purpose mathematical code''. It's not what most businesses seek to have a competitive advantage in.
+
* Secondly, the LGPL does allow proprietary extensions from the outside. The only thing that the LGPL doesn't allow is proprietary forks. Eigen is really easily extensible from the outside, by design. That means that if your users need to develop proprietary extensions of Eigen, they will in most cases be able to do it by building around Eigen, rather than forking it.
+
* Thirdly, forking Eigen itself typically requires very good C++ coding skills AND mathematics skills. For that reason, only a small minority of your users would have even the technical ability to fork Eigen in a meaningful way.
+
 
+
==But I'd like to keep depending only on BSD-licensed software!==
+
 
+
We all would like to have all of our software stack aligned on one license! But let us explain why that should not be a reason to stay away from Eigen.
+
* Are you concerned about making your licensing terms more complicated for your users? [[#So what does the LGPL require when distributing software that uses Eigen?|As explained above]], the only requirements that using Eigen might pass on to your users, are completely similar to the requirements of the BSD license that you are already passing to your users. So at least you are in known territory and Eigen only adds more stuff of the same nature. So if, for example, the MIT or X11 licenses are OK for you, then so should the LGPL in the case of Eigen. And it's not like you're opening the door to a proliferation of similar licences: the LGPL is one of the three most widespead open source licenses, alongside the BSD and GPL licenses.
+
* Do you think that accepting multiple licenses is unusual? It's not. Almost all large open source software projects do so. For example, Mozilla, OpenOffice, KDE, GNOME, Qt, all have variously-licensed dependencies, and in many cases (at least KDE, WebKit...) various licenses on their own code. Being able to pick the right library based on technical merit is widely considered to be far more important than keeping a "pure" licensing environment.
+
* Finally, even if the idea of a pure licensing environment had merit, it has the very bad effect of '''dividing the open source community''' into sub-communities that don't work with each other. The GPL-only community, the BSD-only community... Is that what we really want?! Isn't it a better idea to just accept some licence impurity? Let's stick together ;)
+
 
+
=Special topics=
+
 
+
==What about Eigen plugins?==
+
 
+
As you may know, Eigen has a plugins mechanism that can be used to extend it from the outside, see e.g. [http://eigen.tuxfamily.org/dox/CustomizingEigen.html#ExtendingMatrixBase this documentation page].
+
 
+
What you have to keep in mind when using the plugins system is that, when you compile your application, typically:
+
* Eigen is using your plugin
+
* The code in your plugin is using code from Eigen
+
* Your application is using the combination (Eigen + your plugin).
+
It is ''your'' responsibility to pick the right license for your own code so that all of this is possible. If you don't know how to license your plugin, natural choices to consider are to license it like Eigen, or like your own application (check that the specifics of your case allow it), or under a very permissive license such as MIT or BSD licenses.
+
 
+
Using the plugin system does ''not'' by itself consitute forking Eigen. Let us explain this. When you compile software using Eigen with your plugin, Eigen is just #including your plugin. From the point of view of Eigen, your plugin is just another header file to #include. Eigen also includes several standard header files, for instance <cmath>. Now if you modified your <cmath> header, even in a way that directly affects Eigen, that certainly wouldn't be forking Eigen. This shows that if A #includes B and you modify B, that can't be considered a modification of A. One might argue that Eigen plugins are special because of the very special locations within Eigen's source where they get included. But nothing in the text of the LGPL suggests that that should make any difference. Conclusion: using a plugin with Eigen does not by itself constitute forking Eigen.
+
 
+
What if you don't agree with that analysis and are still concerned that that might be considered a way of forking Eigen? Then it's very simple: just let the added methods in your plugin be just inline wrappers around functions that you define completely outside of Eigen. Nothing prevents you from doing so. Plugins are only here for the little extra convenience of being able to add member methods rather than just global functions.
+

Latest revision as of 14:46, 15 July 2012

This page used to have a long FAQ that we thought was useful when Eigen was LGPL-licensed.

Now that Eigen is MPL2-licensed, there is no need anymore for that. Common questions about the MPL2 are answered on the MPL2 FAQ. Do not hesitate to write to the Eigen mailing list if you have further questions, although we aren't lawyers and you will be better served by asking directly the MPL2 specialists (see above MPL2 FAQ link).

The MPL2 is a simple, file-level-copyleft license (meaning that the copyleft does not propagate across source file boundaries) which should allow use by all projects.