Inside the GPL
Date: Jul 23, 2004
The open source software movement is debated a lot these days. As governments, companies, and individuals struggle to find the balance between well-written software and controlling costs, many have turned to "free" or "open source" software solutions such as Linux to obtain functionality and features previously offered only in proprietary software products.
Advocates of the open source movement claim that in an open source world, everyone wins. Consumers get quality software, presumably at reasonable prices, and gain access to the source code of the applications, which gives the consumer a greater degree of control over those applications than with proprietary software that is "closed source."
Opponents of the open source movement argue that open source software creates disincentives for software developers to create new software, because the requirement of sharing the source code makes it more difficult for developers to protect their intellectual property and to profit from the resale of their work product.
In this great debate, who's right? Who's wrong? That's the answer most people are seeking. Is there really a "free lunch" when it comes to software licensing? Or is the old adage of "You get what you pay for" true in software? Frankly, there is no easy answer. But, as in most situations where two groups of extremists blast each other with convoluted rhetoric, the real answer is probably smack dab in the middle.
In this article, we'll examine what's often the centerpiece of this debate: The GNU General Public License (GPL). You can read the full text of this software license on the Free Software Foundation (FSF) web site. (You always read the full text of your software licenses, don't you? If not, you should.)
CAUTION
Disclaimer: The content of this article is provided for informational purposes only. The author of this article is not a lawyer, and nothing here should be construed as legal advice. For all questions regarding legal matters, you should consult an attorney, not the World Wide Web.
Birds Do It, Bees Do It: Software Licensing
You don't own your software. That's right—the operating system on your computer, the word processor you use, the image editing program you use to take the red-eye out of birthday photos—none of it belongs to you.
"But I have a box. And a CD. And manuals. And I paid a lot of money for that software. Of course I own it!"
No, in all likelihood, you don't.
Do you remember when you bought the software package, took it home, and ripped open that envelope containing the CD-ROM for installation? The envelope probably had a lot of writing on it, in small type, and you probably didn't read it. No one ever really reads that stuff. But that writing was a critical piece of finely crafted legalese called an end user license agreement (EULA), which dictates how you're allowed to use the software. Chances are that the EULA was shown to you again during the installation process, and you had to click a button stating that you agreed to the terms.
Surely you read it in its entirety then, right?
TIP
If you're using a computer with Windows installed, your EULA is contained in a text file called eula.txt. Depending on your configuration, try going to c:\windows\system32\eula.txt, or you could just try searching your hard drive for eula.txt.
Eula-gy
The EULA is just what it sounds like: an agreement—between you, the end user, and the company that "sold" you the software you are about to install. It contains a number of restrictions about how you can use the software. For example, the Microsoft EULA on your machine restricts you from using this copy of the operating system on more than one machine. If you have two computers, you can't legally buy one copy of Windows and install it on both machines. The license specifically says that you can't do that. It also contains a number of other provisions. For example:
The license may limit the number of backup copies you're allowed to make.
The license may restrict how many CPUs you can have in the machine on which you're running the software.
The license may allow you to move the software from one machine to another, provided that you completely delete it from the first machine after you install it on the second.
The EULA probably also contains a lot of items that limit the liability of the software company; for example, stating that there is no warranty for the software's performance, or that you're not allowed to export or resell the software.
And then there's usually a termination clause. For example, here's what the Microsoft EULA states: "TERMINATION. Without prejudice to any other rights, Microsoft may cancel this EULA if you do not abide by the terms and conditions of this EULA, in which case you must destroy all copies of the Product and all of its component parts."
Which means that Microsoft has the option of basically taking back their software. If you don't abide by the terms of the EULA, they have the right to make you stop using their software. And if you don't stop using it, Microsoft could take you to court and possibly be awarded damages for your illegal use.
That's why it's not really accurate to say that you "buy" or "own" software. If you buy a lawn sprinkler and only use it to let the neighborhood kids run through the water in the summertime, the lawn care products manufacturer can't come to you and say, "Hey, your license agreement states that only one individual may use the product at a time, so you're in violation of your Sprinkler License and are hereby ordered to either purchase additional licenses or stop using the product immediately."
A software company can do exactly that.
Keep in mind here that we're not trying to pick on Microsoft. Far from it. Microsoft didn't invent the EULA, and they're certainly not the only software company that licenses products this way. Virtually every piece of software you use is governed by one of these license agreements—even the shareware and "free" products you might download online.
Licenses Versus Contracts
What's the difference between a license and a contract? And why does it matter? Without getting too bogged down into legalese, there are some very critical differences between licenses and contracts, especially when we're framing the two concepts as related to software usage.
First, a license is just a grant of rights to do something. You can get a fishing license from the Department of Natural Resources, which gives you the right to go fishing someplace. You can get a marriage license from the state, which gives you the right to marry your fiancé(e). Or you can get a software license, which grants you the right to use the designated software. A license can have restrictions; a fishing license can limit the number of fish you can catch, just as a software license can limit the number of users you can have using that software.
A contract, on the other hand, is a binding agreement between two parties. There are a number of things that a contract must have in order to be legally binding. For example, a contract usually consists of the following items, and in many cases is required to include these items:
Offer
Acceptance of the offer
Promise to perform
Valuable consideration
Terms and conditions for performance
Performance
For example, suppose you're selling a car. You set a price (offer); a potential buyer may accept the price, or may make a counteroffer. When you agree on a price (acceptance), you have the makings of a contract. The agreement is that the two of you will exchange money (consideration) and the car in good working order. As long as the buyer pays, you have to deliver the car (promise to perform). You might also have agreed that the car is in good working order, or even that it is sold "as is," with no guarantee of working at all (a car sold for parts, for example). If you take the buyer's money, but don't give him the car, you have failed to perform, and are in breach of contract. Similarly, if he takes the car and his check bounces, he is in breach of contract.
So why all the hullabaloo over whether the agreement with your software vendor is a license or a contract? Because a license deals specifically with the grant of rights, not the actual transfer of rights. Under a contract, the software company would actually be transferring certain rights to you, and then those rights (such as the right to freely resell, copy, or distribute the software, and so on) would be yours. By simply granting you certain rights to use the software in a prescribed manner, the software manufacturer retains the copyright ownership of their software, and all of the power to control how the software is used that comes with owning the copyrights.
This distinction between a license and a contract is critical trying to determine how the GPL affects your ability to use software. As you'll see shortly, it doesn't really affect end users any more than a typical EULA—in fact, often it's less restrictive than the standard EULA. The real impact of the GPL is the developer's ability to alter GPL licensed software, and to pass on those changes to other users.
A Brief History of the GPL
The GNU General Public License was originated by the Free Software Foundation's Richard Stallman. Stallman conceived the GPL, not surprisingly, after a software dispute involving source code. The first version of the GNU General Public License appeared in 1988, and the GPL has continued to evolve over the years into its current form, which is Version 2, released in 1991. A few other derivative licenses are published by the FSF, such as one geared toward software libraries and another geared toward documentation. However, for the sake of our discussion, the GPL is the license that matters.
The Free Software Foundation still maintains the GPL, and defends it. Columbia University law professor Eben Moglen is the lead counsel for the FSF, and they pursue remedy against people in violation of the license agreement terms. To date, the license has never been challenged in court, largely because there isn't much reason to challenge it. Since it's a license, not a contract, most disputes can be settled by the offender simply stopping distribution of software not in compliance with the license, and perhaps making restitution if the offender has profited from illegal distribution.
No Free Lunch, or Beer
One interesting aspect of the GPL and the notion of free software is that the term free in this context is often confusing. The Free Software Foundation and the open source movement are not necessarily about giving software away. Some opponents of the GPL have made the argument that it flies in the face of a free market, but that's not necessarily accurate. Certainly, some software vendors give away their products (or some version of their products) under the open source/free software banner. However, when we talk about free software and the GPL, the term free doesn't refer to cost.
There are many free distributions of the popular Linux operating system, which can be downloaded online for no charge. However, there are also companies such as Red Hat, which sells a version of the software and is a for-profit entity. For example, at the time of writing this article, you could download Linux for free online. Or you could purchase the SUSE Linux 9.0 Professional Edition for $59.99. Or the Red Hat Professional Workstation edition for $84.99. (These are just two of many possible examples.) Both products are Linux. But both versions have additional software and documentation added to the base Linux that's distributed under the GPL. How is this possible? We'll get to that later. For now, just remember that "free" doesn't mean "no cost." The FSF likes to say that "free" in the context of software should be thought of this way: "Free as in free speech, not as in free beer."
CopyLeft
The spirit of the GPL is rooted in a concept called CopyLeft, which has an unfortunate and confusing moniker. When you create intellectual property—a book, a song, a computer program—as the author, you automatically have certain rights, such as the right to distribute and control who else can distribute your work. For example, the copyright of this article is controlled by InformIT. You can't copy it and put it on your website without their permission. Software development companies use copyright protections as a way of controlling who can use the code that they've written.
So what's the deal with "CopyLeft"? The FSF's goal was to create a way to protect the freedom of people to distribute source code, without encumbrances. So why not just place software in the public domain, giving up your copyrights? That would work—people would then be free to use your code as they saw fit. However, they would also be allowed, by virtue of the process of changing the code in some manner, to place their own copyright restrictions on the new work. Suppose I wrote a simple word processing program and placed it in the public domain; someone else could come along, add a "boldface" feature, and then they would hold the copyright to the new version. There's nothing inherently wrong with that scenario, but it wasn't the goal of the FSF. Their goal was to create more collaboration and freedom.
The answer was CopyLeft. The idea here is that the author of the copyrighted work gives up all rights to the work, but places on it one restriction: If you use it as the basis for your own work, or redistribute it in any way, you have to provide free access to your source code as well. That doesn't stop you from selling the code, but it does mean that you have to show people the work you've done and the changes you've made from the original work. That's the basis of the GPL.
The GPL Nitty-Gritty
The GPL itself consists of a preamble, which explains the philosophy behind the license. There are thirteen terms and conditions of the license, numbered 0–12. Each one of these terms and conditions places a restriction on how you can copy, modify, or distribute an application using the GPL.
It's important to note that, as stated in the GPL, "[...]the act of running the Program is not restricted." That means that if you download and use a GPL application for your own personal or even commercial use, the GPL really has no impact on how you use the program at all. The GPL concerns itself only with distributing and modifying programs.
When it comes to distributing, copying, and modifying software released under the GPL, however, there are a number of important restrictions.
The first restriction, and arguably the most important, is that if you distribute software covered by the GPL, you have to make the source code for the software available. The GPL suggests that you do this simply by including the source code in the package with the binary files for the software. With this method, the source and the program are delivered together, and there's no issue. In some instances, that procedure might not be practical, so the GPL does allow you to distribute the binaries and source code separately, just so long as you do make that source available. And you can't just make it available online. If you're engaged in the distribution of software covered by the GPL, you have to make the source code available via mail order, although the GPL does permit you to charge to cover your expenses in doing so.
The second major restriction of the GPL resides in modifying the software. Everyone is completely free to modify the source code of a GPL-covered piece of software in any way. You can add features or take features out. You can change the look and feel of the application. It doesn't matter what change you want to make—you're free to make it. However, you're not free to do whatever you want with your modified code; there are some restrictions imposed by the GPL.
Let's say that you modify the application simply for your own personal use (or for private use within your company). Then you don't really have to do anything under the GPL. The GPL only kicks in if you decide to distribute your modified version of the software; for example, if you want to give your program to a client or sell it to customers. Then you're distributing software covered by the GPL, and under the terms of the GPL, your modifications are bound by GPL restrictions as well; anyone who gets a copy of your modified software must also be provided with the source code for the modifications.
This restriction doesn't mean that you can't charge money for the changed application; you're completely free to do so. However, keep in mind that once someone has a copy of the modified source code, the GPL gives that person or company the right to distribute that software—without paying you a license fee or charging one to pass on the software. They can give it away freely.
This point is one of the most often cited and most misunderstood by critics of open source software. After all, if you invest the time and energy into modifying the software, shouldn't you be compensated for your efforts? And how can you ensure that you will be compensated, if the first person you sell your product to starts giving away your new version?
The short answer is that you can't ensure your compensation. Indeed, someone can come along, buy the software, and then turn around and start giving it away, complete with the source code you wrote to make your changes. However, as the rise of Linux and Linux vendors has shown, you still may be able to profit from your changes in several ways:
You can charge for supporting your software. While someone might be able to get the software for free, they might need your help in installing and using it correctly. The GPL doesn't prohibit you from charging for these services.
The GPL also doesn't prohibit you from charging for the version of the software you're distributing, and many people (and certainly many companies and organizations) would rather pay for your modified software, to ensure that they're getting the version you created and not some other version that has been modified even further.
Finally, the GPL doesn't stop you from making warranties on versions of the software you create and distribute, which adds value to potential customers. If you purchase Linux from Red Hat, you get the support, documentation, and peace of mind that comes from having purchased a CD from a known entity. If you download it free from the Net, you don't necessarily get that same level of assurance. To many consumers, that's a very important distinction.
So the GPL doesn't in any way stop you from charging for software. You can charge a fee to download GPL-covered software (so long as that fee includes both source and binaries) or to receive a published version on CD or some other media. You can charge for support, and even charge for custom application development. The "freedom" that the GPL grants includes the freedom to make money and sell a product. However, keep in mind that your changes will become available to anyone who purchases the modified product, and that they could, in turn, choose to distribute the product for free. That's the double-edged sword of the GPL, although clearly that hasn't stopped companies from making their way in the market economy with GPL software.
The Impact of the GPL
So what effect has the GPL had on software development and the open source movement as a whole? It's actually had a tremendous impact.
First, many very common UNIX applications, such as GNU Emacs, have been released under the GPL, and are used by countless numbers of users every day.
Second, the open source software movement has taken several ideas promoted by the GPL and modified them slightly. The most important is the idea that software licensing should include access to source code. As we move into a more complex era of computing, this issue becomes important for multiple reasons:
Stability and longevity. If your company invests in a proprietary software package for a mission-critical task, and the company that sold you the software subsequently goes out of business, what do you do? It might mean scrapping a large-scale deployment, which can be very costly. However, with source code, you could have internal company developers charged with maintaining the application, fixing bugs, and even developing new features.
Security. By being able to review the source code, you can be certain that a mission-critical application is secure and doesn't contain any backdoors or other potentially devastating security flaws.
These are just a couple of reasons that have caused many people to advocate the inclusion of source code in software distribution.
However, some developers want to distribute source code, but don't want to forgo all distribution rights, as would be required under the GPL. As a result, there have been a host of competing open source licenses: the Apache License, the BSD License, the IBM Public License, the Sun Public License, and the QtPublic License, to name just a few. The Open Source Initiative (OSI) reviews licenses for compliance with the goals of open source, and publishes approved licenses on the OSI web site.
There is even an effort to create open source or copyleft-style licenses for creative content, such as writing, video, Flash animations, etc. This effort is spearheaded by the Creative Commons, which has a number of different licensing options available to the creative community.
The bottom line is that the GPL and licensing agreements from the open source community aren't a panacea for protecting individual liberties, and they're not an affront to the free market and the protection of intellectual property. They're simply another tool that developers have in their arsenal to control how they would like the software they create to be used.
Inside the GPL: Tip Sheet
The GPL doesn't contain restrictions on how software is to be used—just how it can be distributed, copied, or modified. Specifically, the GPL requires the following:
Any software distributed under the GPL has to be accompanied by the text of the GPL, unmodified in any way.
Software distributed under the GPL can and should contain copyright notices of the original author.
If you distribute software under the GPL, you have to provide a way (electronically and mail order) for people to obtain the source code.
If you modify a program covered by the GPL, you have to release your modifications under the GPL.
On the other hand, the GPL offers some freedoms:
If you're just an end user of a GPL-licensed product, you aren't required to distribute it.
You can still charge money for your product, even if it's released under the GPL.
Your product doesn't have to become a "GNU" product, and you don't give up your copyrights under the GPL.
Here are some more resources for learning more about the GPL and other non-restrictive public licenses: