Software licensed under the GNU General Public License is free software, and all software that builds on GPL-licensed components is also free and must also be licensed under the GPL. It is therefore often thought that GPL-licensed software is unsuitable for proprietary projects. The two most frequently found myths are:
- You cannot ask for license fees.
- The source code of the project must be published.
If these claims were true, GPL-licensed software would indeed be unsuitable for proprietary projects. But they aren’t. So, let’s have a closer look and see what the situation is really like.
The Family of GNU Licenses
The Free Software Foundation has published a family of software licenses. The most important one is the GNU General Public License, but there is also the GNU Lesser General Public License and the GNU Affero General Public License. In this blog entry we will only consider version 3, the current version of these licenses.
The GNU General Public License
The GNU GPL grants the licensee a couple of rights. The simplest on is the right to use the software. The licensee may also study the software. For this purpose the licensor must provide the source code of the software. This can be done in several different ways. For example, software and source code can be conveyed on a CD or DVD. Or the source code can be published on a publicly accessible web server.
The licensee may redistribute the software without any changes under the GNU GPL. And the licensee may modify the software or use it in his own projects. If he conveys software that contains modified or unmodified components that are licensed in under the GPL, his own product is also subject to the GPL. Therefore each of his licensees has all the rights granted under the GPL such as access to the source code and the freedom to modify and distribute the software.
The GPL does not contain any passage stating that license fees can not be asked for. The GPL faq list states explicitly that one can ask for license fees for software under the GPL (see, e.g., here).
Neither does the GPL state that the source code has to be made public. It is the licensees and only the licensees who must be granted assess to the source code. And the licensor decides who his licensees are. The fact that a GPL-licensed component is publicly available, e.g., over the internet, does in no ways mean that a project building on this component must also be publicly available.
The GNU Lesser General Public License
The LGPL is intended to be a license for libraries. The main idea here is that the library remains free software. But it may be used in proprietary applications without these applications becoming free software. An application that links to or uses a library licensed under the LGPL can be conveyed under any license as long as this license does not restrict the licensee in the way he may use the LGPL-licensed library. The source of the LGPL-licensed library has to be provided to licensees.
The situation is a little bit different in case you modify the library. The library and its modifications are still subject to the LGPL. It is therefore necessary to provide any licensee with a copy of the modified source code and grant him the same rights that were connected to the original library. There is yet no need to also release the whole application under the terms of the LGPL.
The GNU Affero General Public License
The AGPL can be regarded as an extension to the GPL. It is intended for licensing software that is not conveyed to users but rather accessed through a network. These users are granted the same rights as licensees who receive the software. In particular the users are granted access to the source code of the software.
Compatibility of the Licenses
In its current version, the version 3, the three different licenses are compatible with each other. It is possible to use components or libraries under any of the licenses in a combined project with the statements of the licenses remaining valid. For example, if a project uses a library released under the LGPL and a library released under the GPL the project is subject to both licenses. In effect it is the stronger GPL that prescribes which rights the licensees of the project have. An application that uses components licensed under the GPL and components under the AGPL has to grant all the rights of both the GPL and the AGPL. That means that all users, not just the licensees who receive the application, are granted access to the source code of the application.
Libraries or components released under the LGPL can easily be used in proprietary projects. The libraries and components are still subject to the LGPL. Their use or free distribution by customers can in no ways be restricted. But applications that use libraries or components released under the LGPL may still be released under an arbitrary license.
One should note that subclassing a Java (or other OO) class licensed under the LGPL is regarded as a use of an interface of a library comparable to a function call of a library. It is not regarded as a modification of the original class. Therefore the subclass does not fall under the requirements of the LGPL.
As long as you do not distribute GPL- or AGPL-licensed components or your own software building on them and only use it internally you are not obliged to granting any rights. Thus all internal usages are unrestricted and harmless. A typical case is the set-up of a Linux server. The Linux kernel is licensed under the GPL. Still using the Linux operating system is not connected to any obligations for the user. The same holds obviously true for all internal usages of GPL-licensed software.
Even more, installing a Linux server on a customer’s site is absolutely unproblematic. It is so even if one demands a fee for installation and/or maintenance. Asking for fees for services around GPL-lisensed software is unproblematic under all circumstances. Asking for fees for the license is also legally allowed. But no customer would be in need to buy such a license if he could get access to the software and its source code for free from other sources.
Providing services for Linux servers, actually demanding license fees for Linux distributions has been a successful business model for companies like Debian, Red Hat, and SuSE for almost two decades now. They show that successful business models can be constructed around freely available software.
Quite some applications today are no longer licensed and conveyed as bundled software as, e.g., Microsoft Office. Rather the application only runs on a network of servers and is accessed by users through the internet. Examples are web mail systems or photo sharing services. These applications are commonly known as software as a service.
The GPL is a license which is designed for cases where the software is conveyed to users. If this does not take place the GPL does not make any statements at all. As a consequence you may use components released under the GPL in your SaaS-projects without the need to make the source code available to anyone outside your company. This is a known loophole of the GPL and the reason for the existence of the AGPL.
“Ordinary” Client Projects
An “ordinary” client project is a project where a software company develops an application for one particular client or a particular small set of clients, usually on demand of the client. Even in these projects, the use of GPL-licensed components can be feasible. Actually, the requirement to hand over the source code of the project to the client is not really a big restriction because contracts regularly contain clauses by which the source code is handed over anyway. Since the client pays for the development of the software he has the right to receive all artefacts of the development including the source.
The issue that is more relevant here is that the client also receives the right to re-distribute the software including the option to ask for fees. So an important question here is whether or not the client may have an interest in re-distributing the software. Let’s consider two examples. Suppose your company developed an application which is not only useful for the client but also for many companies in the industrial sector of client. An example may be an application managing end customer data like addresses and payment management. Such a system is not particular specific to your client. He may thus have an interest in re-selling the application to his competitors. The GPL provides him the freedom to do so.
Suppose the application you create for your client is a software model of the core process of the client’s business model. The application models the key properties that sets the client ahead of his competitors. In the automotive industry, to give an example, this may be car configurator that directly interacts with order systems and production lines. The application is essential to the economic success of your client and constitutes one of his core values. In such a situation, the client has almost no reason at all to re-distribute the application. Thus, though the client is granted certain rights under the GPL, you can be quite sure the client has no interest in actually putting these rights to use. It is therefore a valid option to use GPL-licensed components in such projects.
Although the use of GPL-licensed components in proprietary projects has quite a bad reputation, the situation may be not quite as bad as one may expect. The following cases can be regarded as unproblematic.
- The use of LGPL-licensed libraries or components.
- The internal use of GPL-licensed components.
- The external use of GPL-licensed applications, if it is providing service around the application that constitutes the business model.
- The use of GPL-licensed components in SaaS-projects.
In ordinary proprietary projects one has to consider whether the client may have an interest to use the right of conveying the application to his competitors as granted by the GPL. If this is not the case, GPL-licensed components may also fruitfully be used in such a project.
This text does not constitute a legal advice. It only presents the author’s opinion.