Licensing FAQ

From Eigen
Revision as of 13:04, 28 January 2010 by Bjacob (Talk | contribs)

Jump to: navigation, search

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.

If you still have a concern, don't hesitate to contact us.

The answers below are mutually redundant for the sake of being easier to find.

General licensing questions

How is Eigen licensed?

Eigen is dual-licensed: it can be redistributed and/or modified, at your choice,

  • either under the LGPL, version 3 or later,
  • or under the 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 described below.

What is the LGPL?

The 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.

In the case of Eigen, the LGPL only differs from the BSD license on one important point, which we explain below. As long as you're not modifying Eigen itself, you can safely ignore this. Thus, for 99.9% of our users, the LGPL is for all practical purposes essentially equivalent to the BSD license.

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 C++ library, it can be used entirely under Section 3. This is good news for Eigen users, as this section is the simplest one. It basically just means that when they distribute their software, they just have to say somewhere that it uses Eigen, that it is LGPL-licensed, and give links for Eigen and the LGPL. That is pretty much equivalent to the requirements of the 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, which is a pure template library with nothing to link to. We got this confirmed by the FSF.

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 FSF to confirm this, and 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.

You might wonder what happens if a BSD-licensed Library X uses Eigen and then a proprietary Application Y links statically to X. Does the LGPL apply to Y? No, it doesn't. Because if it did, then it would already apply to X itself as the object files from X's source files are statically linked together to form Library X. Such an interpretation would imply that Section 3 of the LGPL is completely useless. This is obviously not the spirit of the text. Conclusion: if Library X includes Eigen and Y statically links to X, then the LGPL license of Eigen does not impact this static linking.

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 (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.

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:

Eigen itself does have several big commercial closed-source users, see the partial list of 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, 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?

Linking, static or not, just doesn't apply to Eigen, which is just header files! In Eigen, there is nothing to link to. This is the key to understanding why the LGPL licence is so simple, in Eigen's case.

I'm distributing a proprietary, closed-source application that uses Eigen. What am I required to do?

When you distribute your Eigen-based software, the LGPL license requires you to:

  • say somewhere that you're using Eigen and that it's LGPL-licensed;
  • distribute the text of the LGPL license, or a link to it.

So this is very similar to the requirements of the 2-clause BSD license.

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 confirmed by the FSF. Fortunately, Section 3 is very short and readable. Let us just elaborate on our above interpretation of it. The LGPL says that you should mention "prominently" that your application uses Eigen. However, we do not seek to enforce a strong meaning of this term. 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 text itself, but common sense suggests clearly that it should be enough to distribute a link to it. And of course, distributing the text of the LGPL license does not imply at all that the LGPL license applies to your own software. The BSD license has very similar requirements.

Are there circumstances in which the LGPL puts significant other requirements on me?

There is one such circumstance. It is the case where you have made changes in Eigen itself and want to distribute software based on this modified Eigen. You must then make your modified Eigen available at least under the LGPL license. But of course, even in that case, you still don't have to make the rest of your own source code available to us or to anybody else.

Also note that this requirement only applies when you are distributing this software. If you are using your modified Eigen only internally, then there is no such requirement.

As long as you don't modify Eigen itself, you can safely ignore this.

Is there any risk that the LGPL license could "contaminate" my own software as a result of using Eigen?

No, there is no such risk at all, in the case of Eigen.

For example, some people are concerned about statically linking to LGPL software, but as we said above, static linking is not applicable to Eigen which is only header files anyway.

If some your code is a fork of Eigen, in other words, if that code is a modified version of Eigen's own code, then the LGPL does indeed apply to it, as we explained above. But that's not something that can happen naturally just as a result of using Eigen. It involves actively copying Eigen's own source code into your own source code and then modifying it. By contrast, using Eigen only involves adding #include<Eigen/...> directives to your source code. Thus, this won't happen accidentally. So far, it never happened with any of our users. Also note that even in this unlikely scenario, it would only concern the part of your code that is a modified version of Eigen's own code. It still wouldn't propagate beyond that to the rest of your code.

Just using Eigen does not incur any risk of implicitly letting the LGPL license apply to any part of your own software.

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.

The LGPL license is too complex to even read!

In the case of Eigen, the LGPL is actually very simple, 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.

So what does the LGPL require when distributing software that uses Eigen?

As we explain above, in the case of a project that uses Eigen, you only need to honor Section 3 of the LGPL, which is really similar to the 2-clause BSD license. It says that when you redistribute software that uses Eigen, you must:

  • say somewhere that you're using Eigen and that it's LGPL-licensed;
  • distribute the text of the LGPL license, or a link to it.

So, in the case of Eigen, how is the LGPL different from the BSD license?

Essentially in only one way that we described above: if one distributes software based on a modified Eigen, then one must also distribute the modified Eigen under the LGPL license. This forbids the distribution of proprietary forks of Eigen. By contrast, the BSD license would allow this.

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 described above, which are very similar to the 2 clauses of the BSD license itself.

Concerning the interdiction of proprietary forks, as we just explained, it will only apply to Eigen, not to your own code.

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? 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 splitting 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 ;)