Open source software licences: GPL

Part of the article Open source software licences explained.

What is the GPL?

The GNU General Public License or GPL is sometimes termed a copyleft licence, in that it relies on the legal mechanisms of copyright to ensure that the software it covers remains available for everyone to copy and modify.

The main requirement it imposes can be roughly described as: software covered by it, or anything that can legally be described as a derived work of that software, may be redistributed only with its source code made available and under the GPL.

There are in fact two widely-used versions of the GPL, the GPLv2 and GPLv3. Although they provide similar provisions, they are not compatible—code published under one of them can't be combined with that published under the other. This awkward situation is usually resolved by including a “v2 or later” or “v3 or later” clause with the licence, allowing people who receive the code to silently “upgrade” it from GPLv2 to v3, or v3 to a later version, if it suits their needs.

The GPL is used by a great many applications including the Linux kernel, gcc compilers, GNU operating system utilities, and numerous applications published by proprietary companies, such as the MySQL database.

Why would I want to release my code under the GPL?

The GPL reflects quite well the way that a lot of developers instinctively feel about publishing their own code: that it's fine for you to make use of it, but you should do the same in return. Quid pro quo.

Companies and institutions are often keen on the GPL because they perceive it as protecting them from competitors and preserving a possibility of future licensing income for them. A competitor can't simply build something on top of their code and sell it as a proprietary product without paying for it as they could with a BSD licence, because the modified program must also be placed under the GPL. To take advantage of this, it's quite common to publish code under the GPL with an alternative commercial licence option for customers who want to use the code in their product.

What are the disadvantages of using the GPL?

For such a popular licence, the GPL attracts a fair bit of aggressive criticism. You can find an example in this article by Matt Gemmell, in the section titled “Use a permissive license”. The gist of the argument is that publishing under the GPL is both counter-productive because it will inhibit people from doing useful things with your work, and unfriendly because it gives the impression that the work is freely available while preventing it from being reused in many contexts (notably a lot of commercial ones).

Factually, this is broadly true and the confusion described certainly happens. But this is also very close to the one of the main arguments for the GPL—that it helps avoid software getting sucked into a proprietary hole, preserving work as a public good. If you are a publicly-funded researcher you might think of this as an ethical judgement about whether you should encourage your work to remain public by preventing it being subsumed by proprietary interests, or try to protect potential intellectual property revenue for your institution, or else try to enhance the wider economy by making your work available to everybody in it, commercial interests included.

The calculus may depend on whether your work is a component like a library, or a complete end-user application in itself. Arguments like the above usually assume that you are publishing code so that other developers can build on it; for complete applications this is not usually the case.

There are some less nuanced disadvantages to the GPL. The introduction of the GPLv3 in 2007 made it a much more complex licence to understand the implications of, in any practical context. (I used to recommend that people interested in the GPL should simply read the licence, since the GPLv2 is not that long and is quite clearly written, but v3 is much longer and trickier and I can't honestly claim to fully understand it myself. This guide explains most of the changes, but there are some subtle bits.)

Also, the GPL might not prevent the sort of exploitation you care about. For example, nothing in it prevents someone from taking your code, integrating it into a proprietary web application, and running it on their public servers without ever “publishing” the application itself. A variation, the Affero GPL, seeks to address this, at the cost of more complexity and licence compatibility confusion.

And it might prevent things that you actually want to permit. For example, GPL code cannot be distributed through Apple's iOS App Store^[1]. This may be a sign of a technological shift undermining the goals of the GPL—the increased control over distribution channels for software on locked devices making it less relevant whether a user can get source code or not, since they can't make use of it anyway.

There may also be practical difficulties enforcing the licence—for an interesting take on this see Matthew Garrett's article The economic incentive to violate the GPL. Of course this is also true of proprietary licences, but since GPL software is readily visible and does not usually cost anything, other people may be more relaxed about violating the licence terms.

How would I apply the GPL to my own code?

Given the complexity caused by the two incompatible versions of the licence, I would recommend using a “GPLv2 or later” scheme unless you have read the GPLv3 and are confident that it is more appropriate.

Copy the following text into a header comment at the top of each of your source files:

  Copyright (c) <year> <copyright holders>

  This program is free software; you can redistribute it and/or
  modify it under the terms of the GNU General Public License as
  published by the Free Software Foundation; either version 2 of the
  License, or (at your option) any later version.  See the file
  COPYING included with this distribution for more information.

Make sure the copyright note has the right year and identifies the correct copyright holders.

Then copy the text of the licence itself into a file named COPYING or COPYING.txt in your source code root directory, and add a reference to it in your README file.

As always, ensure you retain any copyright and licence notes in anyone else's code you have used, and make sure that the licences of such code are compatible with the GPL.

See Sonic Visualiser for an example of a project with GPL licensing.

Can I incorporate someone else's GPL code into my own software?

Only if your software will also be published under the GPL, source code and all. Bear in mind that that can only be the case if every part of your software is capable of being relicensed under the GPL—so any other libraries you use must be either GPL or BSD-licensed themselves, unless they are part of the operating system you are writing for. You can't mix commercial or academic-use-only licences with the GPL.

Also, you can't incorporate GPLv2 code into GPLv3 or vice versa unless the GPLv2 code has an “or later” provision, in which case the incorporated code effectively becomes GPLv3.

Return to the article Open source software licences explained, go on to read about the LGPL, or go back to read about BSD-style licences.

^[1] The GPL requires that someone redistributing a program should impose no further legal restrictions than those in the GPL itself, but the Mac and iOS App Stores impose additional restrictions such as a limit on the number of devices the downloaded app can be used on. (Developers can provide their own licence agreement for apps on the Mac App Store, but there are still some quite strict restrictions about what that agreement may say and the GPL is certainly not covered.) The iOS App Store developer agreement also prohibits making the same software available by any other means than the App Store.

In practice this is probably a classic situation where most people will turn a blind eye as long as nobody complains and there seems not to be ill-intent. It's known that Apple have pulled at least two GPL applications from the iOS store following complaints from copyright holders (GNU Go, VLC) while leaving others intact (Wesnoth).

The Android Market / Google Play terms, in contrast, do not conflict with the GPL.

Microsoft's Windows Phone Marketplace terms ban GPLv3 software explicitly and are probably also incompatible with GPLv2.