What's all this GPL stuff, anyhow?
(Apologies to my hero Bob Pease for the title of this paper.)
Warning and disclaimer
The information contained in this document is provided "as-is" for reference purposes only. Neither the author nor Openesque LLC shall be liable for any damages, including incidental or consequential damages as a result of errors or omissions in this document.
This document is not intended for use as a legal interpretation of the GNU GPL. The GNU GPL has many legal ramifications which you should thoroughly understand before deciding to distribute software under its terms. Openesque LLC strongly recommends that you consult an attorney in such cases, especially in the case where you are distributing GPLed software as part of your business.
The GNU General Public License, more often referred to as the "GNU GPL," or just "GPL," is a software license developed by the Free Software Foundation (FSF.) We recommend you visit the GNU website at gnu.org; where you will find the full "official" story of GNU, FSF, the GPL, and the LGPL. This information won't be repeated here in full; the purpose of this document is a (hopefully) gentle introduction to the GPL, along with Openesque's opinions on the GPL and its strengths and weaknesses.
…the GPL is sometimes referred to as "viral" in nature, in the sense that the GPL "infects" all source code it comes in contact with. In my opinion, this is a rather silly argument against the GPL, as all proprietary software licenses I've ever seen do all that and then some.
To jump straight to the gnu.org page on the GPL and its derivatives, click here.
The GPL is widely used in open source software development. The Linux kernel is licensed under the GPL; the user-space tools (what most people think of as "Linux") mostly come from the GNU project and, not surprisingly, use the GPL as well.
The GPL is widely used, and widely misunderstood.
Microsoft appears to be scared to death of the GPL. Anything related to software that scares Microsoft is worth examining in more detail.
The Free Software Foundation (FSF) in general, and Richard Stallman in particular, have taken much abuse about the GPL and their political motivations. In the paragraphs to follow, they'll have to take a little more. However, although Mr. Stallman may be a fanatic, he does make some very important points on freedom in some of his writings which are well worth pondering.
The GPL has been, and undoubtedly will be again, one of the most vigorously debated topics in the world of software. Even Microsoft's hated EULAs fall in a distant second to the GPL in terms of controversy. This document tries to not only convey the essential facts of the GPL, but also a little of the flavor of this debate as well. It is impossible to separate the GPL from the firestorm that surrounds it, and I won't even try to.
Overview of the GPL
Once you acquire GPL-licensed software, you may use it, modify it, and redistribute it without any additional license payments. However, regardless of whether the software is modified or not, the GPL license prohibits you from placing additional restrictions on the use or redistribution of the software. In short, once software is released under the GPL, it and any derivative works must also be released under the GPL. For this reason, the GPL is sometimes referred to as "viral" in nature, in the sense that the GPL "infects" all source code it comes in contact with. In my opinion, this is a rather silly argument against the GPL, as all proprietary software licenses I've ever seen do all that and then some.
An important point to make here (the misunderstanding of which scares many people away from GPLed software): the GPL does not restrict the user to noncommercial use of GPL-licensed software, nor does the GPL apply to the output that the program is designed to produce.
What this means is that it is perfectly acceptable, for example, to use a GPLed spreadsheet program to produce and manipulate proprietary data for profit. It's your data, and (hopefully) your profit, and the GPL has nothing to do with that. This is important to note, as many so-called "freeware" applications do restrict you from using them for commercial use without paying a license fee.
If you decide to take the GPLed spreadsheet source code, modify it, and sell a "new" spreadsheet program, the new spreadsheet application is still bound by the GPL. Note that you can legally sell this software; the GPL has no restrictions whatsoever on how much you can charge for GPLed software. However, the GPL prevents you from changing the licensing terms. This means that if distribute your modified GPL code, you must do it under the terms of the GPL — including providing all of the source code.
The ability to charge for GPL-licensed software is not a hypothetical abstraction. It's one of the ways Openesque makes money. A real-world example: if you want a custom minimal Linux distribution for a web server, Openesque will prepare the custom Linux distribution for you and invoice you for it. The fact that we received the software for free has no impact on our ability to charge you for our modifications to it. This is important, as there are software licenses in use which prohibit charging for the redistribution of said software. However, once you have paid for your custom distribution, it's yours to do with as you see fit. You can resell it if you like, and have no obligation to pay Openesque anything for it.
An important part of the GPL is that it forces source code to be made available. If you distribute GPLed software, you are required to make the complete source code available as well. Source is commonly distributed along with executables. Quite often, only the source is distributed in a GPLed project, and it's up to the end-users to compile executables for their own use. In other cases, the source is not packaged with the executables, but is instead made available for free download via FTP. The GPL allows this as well. Some Linux vendors do this to reduce on the number of CD-ROMs they need to ship, as most people aren't interested in the source. Often times, Openesque isn't interested in the source, although we reserve the right to be at a future date.
Another important point for software developers considering releasing code under the GPL: your code is still your code, even if you include it in GPLed software. You still retain your rights to do with it as you see fit in non-GPLed software. For example, suppose you develop and code a new sorting algorithm. You'd like to incorporate this code into some GPLed software… but you'd also like to incorporate it into your own proprietary software that you release under a restrictive license. That is perfectly acceptable under the GPL. Once you release the GPLed code with your new sort routine in there, you have no say over the GPLed code; it's still covered under the GPL. However, you can still take the code that you developed on your own and use it in any way you see fit.
This used to mean "Library GPL"; FSF has redefined it to mean "Lesser GPL". This is because FSF has decided to discourage use of the LGPL license; FSF has a mission to rid the world of proprietary software and replace it with "free" software — "free" as defined by FSF (more on that later in this document.)
Regardless, the LGPL is a less restrictive version of the GPL which is commonly used for libraries that the authors wanted to make available to developers of proprietary software as well as free software developers. The C libraries used in Linux are the best-known example of LGPLed software. If the C libraries used in Linux were licensed under the GPL, then only GPLed software could be linked to them. This would prevent developing any proprietary applications for Linux. The LGPL is a work-around for this problem.
LGPL-licensed code has the same restrictions on modification and redistribution that GPL-licensed code does. However, it is permitted to link proprietary software to LGPL-licensed software.
What does "free" mean in the GPL?
GPL enthusiasts, as well as the GPL itself, refer to GPL-licensed software as "free software.". This is also the source of much confusion. From the GNU General Public License, Version 2:
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
Openesque uses the term "GPLed software" to refer to software licensed under the GNU GPL. No offense, Mr. Stallman, but "free software" is a misleading term. I refer to FSF's definition of "free software" as GNUspeak (although I didn't invent the term.) To me, it seems to be an Orwellian attempt to redefine "free" to suit FSF's political agenda. It has never been very effective at doing so, although it has stimulated a lot of heated debate across the Internet, which isn't a bad thing.
Some like to turn to Latin to try and explain the GNUspeak as follows: GPLed software is libre (free as in freedom) as opposed to gratis (free as in it doesn't cost anything.) But this isn't true, either. Berkeley license enthusiasts love to hammer on this issue, and they have a valid point. You are not free to use GPLed software in any fashion that you see fit; you do not have the freedom to take it, modify it, and sell it under a more restrictive license… which you can do with BSD-licensed software.
That being said, the GPL is a marvelous software license when used in the correct setting. Choosing to license your software under the GPL can either be an excellent business decision, or a disastrous one.
Why use the GPL?
Perhaps the best reason to use the GPL is the reason Richard Stallman invented it in the first place: to make sure that code you've contributed to the public good isn't improperly co-opted by someone else. That story can be found here — if nothing else, it provides a good horror story about the perils of "public domain" code.
The most common reason for using the GPL, from my experience, is a developer would like to make software available for public use, but is unwilling to donate his or her hard work to another company to take, modify, and sell under a more restrictive license. The GPL prevents this from happening. When it comes right down to it, this appears to be Microsoft's biggest complaint about GPLed software: they can't take it, incorporate it into their products, and bind it by a Microsoft EULA that disallows users from modifying, reverse engineering, or redistributing the software. They also cannot keep GPLed code as a "trade secret".
Some systems such as OpenNMS are released under the GPL; the companies that produce the software look to make money on supporting the product. This can be a great way to make money, but you need to be careful. Many users of open source are quite competent themselves, and will simply maintain a system running your code without any support from you. Don't quit your day job until the orders start flowing in.
Another increasingly common use of the GPL is where a vendor would like to make device drivers or other support software for their products available to the open source community (so they can sell more product and make more money,) but do not wish to give code to their competitors that they can hide in their own EULA. The GPL is a wonderful mechanism for doing so. The competitors can indeed modify this code, but it will make its way back into the community again once it has been released, which benefits all users and developers.
Why not use the GPL?
If you wish to develop software and receive per-seat license fees from users, GPLing your software is a bad idea. As long as you provide the source for your GPLed product, you've fulfilled your obligations under the GPL. You do not have to make it publicly available on an FTP or web server. However, you cannot restrict a user from doing so. You will quickly find your software on different free software sites, and will be hard-pressed to make any money on the sale of your software.
Also, if you are trying to develop a new standard (e.g.: a new Internet protocol,) you may want companies like Microsoft, IBM, and Cisco to support it. The best way to make this happen is to write a reference implementation and release it under a more liberal license that allows your work to be used in any way the end-user sees fit. You should copyright your work; as mentioned before, putting work in the "public domain" is not a great idea. The standard BSD license is perfect for this, modified for yourself or company. If we were doing this, it would look like this:
Copyright (c) 2004, Openesque LLC
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. Neither the name of Openesque LLC nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
In this case, you want the big proprietary players to "steal" your code and include it in their products. DNS, DHCP, and Sendmail are prime examples of this. If you GPL a new standard implementation, you may encourage certain companies to take your idea and release their own, proprietary, incompatible version of it. Of course, there's no guarantee that a company won't "embrace and extend" your work, but with a solid reference implementation readily available to include into their products, others are more likely to do it your way, resulting in at least your core functionality becoming a de facto standard.
This is somewhat off-topic; however, if you enter the Linux world, you will see this issue, so I'm mentioning it here… forwarned is forearmed.
The GNU perspective can be found here. Stallman's argument is basically that Linux only refers to Linus Torvalds's kernel, and "GNU/Linux" should be how a Linux distribution is referred to.
There is a marvelous rant on this topic which may be found here. Also, to hear Linus Torvalds's own perspective on the correct name, click here to see an ABCNews chat session with Linus. Search for "lignux".
Openesque's perspective on this debate: doesn't the FSF have anything better to do — like improving GNOME? Stop trying to grab onto Linus's coattails; the GNU project's body of work has sufficient merit on its own.
We still call Linux "Linux" and will continue to in the future — unless we're under contract to FSF, in which case, the customer is always right.
In Defense of Richard Stallman
After all the FSF, GNU, and Stallman-bashing above, I felt the need to add this section in. Whether you like it or not, and whether you agree with his viewpoints or not, Richard Stallman has been battling for your freedom of speech and the freedom to exchange ideas and information.
These freedoms are a right — and like any any freedom and right, they can be taken from you if not guarded. The Right To Read is a short story by Richard Stallman describing a world where these freedoms no longer exist. Many of the points made in the story were laughed off as hysterics when it was first released. Unfortunately, our world is growing closer to, not further away, from what he described here. See for yourself.
A software patent is a patent on an algorithm, which when you get right down to it, is a patent on logic. Should lawyers be able to patent successful courtroom arguments? Should tax accountants be able to patent optimal tax reduction strategies? Should a blackjack player be able to patent a card-counting strategy? If one can patent a business model, it seems only fair that the answer to these questions is "yes." Not right, and not sensible… but fair.
Unlike physical invention patents, software patents appear to only hurt the individual developer and favor the large corporation. As the number of granted software patents increases, this is likely to become increasingly true. This article on Forbes.com illustrates the point dramatically.
"Your genetic code will be copyrighted and you'll pay a tax on it. If you hum a tune on an elevator, they'll make you pay royalties."
The GNU GPL has helped to bring a large volume of high-quality (and some not-so-high-quality) software into the world. It allows developers to contribute to this pool of software with the knowledge that their hard work will not simply be taken and exploited without returning any contribution to the pool. In this way, the GNU GPL is a wonderful thing.
Openesque LLC's philosophy is "pragmatic, not dogmatic." The GNU GPL is a well thought-out document that so far appears to accomplish its goals well. It's not a universally desirable license to use, and probably never will be. But I'm glad it exists. Thanks to Richard Stallman for dreaming it up, and even greater thanks to all those who have contributed so much time to share their talents with the world using the GPL.
And I love all you BSDers out there too. Rage on.
Notes and references
The Berkeley license, sometimes referred to as the "BSD license," was originally developed by the University of California at Berkeley for its software distributions.
NOTE: Because of the liberal nature of the license, BSD-licensed software can and often is copied and licensed under more restrictive terms. The BSD license permits this type of use. BSDi, for example, was a company that released and maintained a commercial version of BSD/OS. You could not copy or redistribute most BSDi code.