Difference between revisions of "Licensing FAQ"

From Eigen
Jump to: navigation, search
(So what does the LGPL require me to do?)
(In the case of Eigen, how does the LGPL differ from the 2-clause BSD license?)
Line 49: Line 49:
 
==In the case of Eigen, how does the LGPL differ from the 2-clause BSD license?==
 
==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]]
+
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==

Revision as of 19:51, 31 March 2010

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.

Contents

General licensing questions

How is Eigen licensed?

Eigen is dual-licensed: 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.

So what does the LGPL require me to do?

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 LGPL license.

See Section 3 of the 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 confirmed by the 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 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.

If you are forking Eigen itself, then it's different, see our section on forking.

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 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, which is a pure template library with nothing to link to. We got this confirmed by the 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 our section on forking.

Forking Eigen

Forking Eigen means modifying Eigen and distributing software based on your modified Eigen.

This is where the LGPL places a significant additional requirement on you, compared to, say, the 2-clause BSD license: 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. As long as Eigen's own files are used unmodified, you're not forking it. 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 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.

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 (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 Yujin Robot company uses Eigen for the navigation and arm control of their robots.
  • 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:

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?

This has been discussed above.

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

See our 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. See our 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.

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.

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.

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

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 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 forks of Eigen. See 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 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.

How about static linking?

This has been discussed above.

Also, as we 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? 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 ;)