CHAPTER 3

Understanding Software Licensing

Software is a type of intellectual property (IP), which is governed by copyright laws and, in some countries, patent laws. As a general rule, this makes it illegal to copy software unless you're the software's author. Open source software, however, relies on licenses, which are documents that alter the terms under which the software is released. As described in this chapter, open source licenses grant additional rights to software's users.

Open source software in general owes a great deal to three organizations: the Free Software Foundation (FSF), the Open Source Initiative (OSI), and the Creative Commons. Each organization has a distinct philosophy and role to play in the open source world. There are also numerous specific open source licenses, which I summarize at the end of this chapter, along with ways that businesses can use them.

• Investigating software licenses
• The Free Software Foundation
• The Open Source Initiative
• The Creative Commons
• Using open source licenses

Investigating Software Licenses

Copyright law has existed for centuries, and as such, it wasn't designed with software in mind. Nonetheless, copyright law does apply to software, and licenses that software authors apply to their software interact with copyright law to create the specific rights that you have—and don't have—to use, modify, and redistribute software. I therefore describe these basic principles, as well as the differences, in broad strokes, between proprietary and open source license terms.

Copyright and Software

A copyright is, as the name implies, a legally recognized right to create a copy of something. In most countries, if you write a book, take a photograph, or create a computer program, you and you alone have a right to make copies of that book, photograph, or computer program. You can give others a right to make such copies, or even relinquish control of the copyright to somebody else.

Copyright laws vary from one country to another, but most countries are signatories to the Berne Convention, an international treaty that requires countries to recognize each other's copyrights. That is, if Fred writes a book (or opera, or computer program) in the United States, that work will be copyrighted not only in the United States, but also in Iceland, Kenya, the United Kingdom, and other countries that have ratified the treaty.

Because most copyright laws were written long before computers came into being, they frequently don't mesh well with the needs of computers. For instance, copyright laws forbid copying of a work, but a computer program is useless without such copies. Examples of copies that must necessarily be made to run a program, or that are advisable for safety, include:

• A copy of the program from an installation medium to a hard disk
• A copy of the program from the hard disk to the computer's random access memory (RAM)
• A copy of the RAM into swap space
• A copy of the RAM into various smaller caches on the motherboard or CPU used to improve performance
• One or more backups of the hard disk, to protect against disk failures

In the past, such copies were generally ignored, on the principle of fair use—that is, exceptions to the otherwise exclusive right to copy a work given to copyright holders. Other examples of fair use include quotes used in reviews or news reports and excerpts used in research or teaching. Today, copyright law explicitly recognizes the need to copy software to use it, at least in the United States.

Using Licenses to Modify Copyright Terms

Although software is subject to copyright law, most software is released with a license, which is a document written in legalese that claims to modify the rights granted by copyright law. In most cases, you don't sign such a license, although in some cases you must click a button to accept the license terms. In the past, licenses were sometimes printed on the boxes in which software was distributed. Such licenses are often called end-user license agreements (EULAs), click-through licenses, shrink-wrap licenses, or click-wrap licenses. Open source software generally comes with a license in a file, often called COPYING.

Software licenses can modify copyright terms by making the terms either more or less restrictive. For example:

• The license to Microsoft Windows 7 Home Basic ties the software to a single computer; once you use the software, you cannot move the software to another computer without violating the license terms. This clause represents a restriction compared to copyright law, which applies to the software without explicit reference to the machine on which it's run.
• The General Public License (GPL), which is the license used by the Linux kernel, grants you the right to redistribute the software, including both the source code and binaries. This represents a loosening of the restrictions provided by copyright law.

As a general rule, licenses for proprietary software provide restrictions on what would otherwise be your rights under copyright law, whereas open source licenses grant you additional rights. There can be exceptions to this rule, though; for instance, a site license is a license for a proprietary program that grants an organization a right to make a certain number of copies of the program—say, 100 copies of a word processor for all the company's computers.

The Free Software Foundation

The Free Software Foundation (FSF) is a critical force in the open source world. Founded in 1985 by Richard Stallman, the FSF is the driving force behind the GNU's Not Unix (GNU) project described in the previous two chapters. The FSF has a certain philosophy, which I describe next. This philosophy manifests itself in the GPL, which is the FSF's favored software license.

Understanding the FSF Philosophy

The FSF advocates what it calls free software, which it defines in terms of freedom to do things you want to do with the software, not the price of the software. A common phrase to make this distinction clear is “free as in speech, not free as in beer.” The FSF defines four specific software freedoms:

• Freedom to use the software for any purpose
• Freedom to examine the source code and modify it as you see fit
• Freedom to redistribute the software
• Freedom to redistribute your modified software

These freedoms are similar to the principles espoused by the OSI, described shortly; however, there are some important differences in interpretation, also as described shortly. The FSF elaborates on the implications of each of its principles, and their interactions, at http://www.gnu.org/philosophy/free-sw.html.

In an ideal world, by the FSF's standards, all software would be free—distributed with source code and all the freedoms just outlined. Some Linux distributions meet this ideal in isolation; however, some distributions include proprietary software. Sometimes this software is freeware, but other times it's a bit of proprietary code that enables the vendor to restrict redistribution and charge money to sell the software. Since free software is not necessarily free of charge, selling it is not a problem from the FSF's point of view, but given the other freedoms, free software's price tends toward zero as it gets passed around.

The point of all this talk of freedom is to empower users—not just developers or companies. If you can modify a program that does almost what you want it to do so that it does exactly what you want it to do, that fact is a big advantage compared to a proprietary program. If you can then redistribute your modified version of the program, you can help others (assuming they want similar functionality). Thus, the FSF philosophy, when applied, can create a benefit to the wider community.

The FSF philosophy and the licenses it inspires are often referred to as copyleft. This is a play on the word copyright, reflecting the fact that copyright provisions are used to ensure freedoms that are, in some respects, the exact opposite of what copyright was created to do—that is, to guarantee a freedom of users to copy software, rather than to restrict that right.

Free Software and the GPL

The legal expression of the FSF's principles comes in the form of the GPL (sometimes called the GNU GPL). Two versions of the GPL are common, version 2 and version 3. (The older version 1 is seldom used anymore.) Both versions of the GPL apply the four freedoms of the FSF philosophy to the licensed software. They also make explicit an implication of those four freedoms, by stating that derivative works must also be released under the GPL. This clause prevents a company from wholly appropriating an open source program. For instance, many companies make Linux distributions, and some use Linux kernels that incorporate bug-fix “patches.” These kernels, like the mainstream Linux kernel, are all available under the GPL. No company could legally release a distribution based on a patched Linux kernel and then refuse to make its kernel patches available.

The GPL version 2 (or GPLv2 for short) was released in 1991, and held sway for many years. In 2007, GPLv3 appeared, with the intention of closing what the FSF viewed as loopholes in the GPLv2, particularly with respect to changes in laws and practices since 1991. Specifically, the GPLv3 contains clauses that are intended to combat use of hardware restrictions that limit the FSF's four freedoms and to address issues related to software patents. Many new programs are now being released under the terms of the GPLv3, and many older programs now use the GPLv3 rather than the GPLv2. Some programs have not changed, though. Notable among these is the Linux kernel itself, which still uses the GPLv2. This is an important choice because it means that the Linux kernel can still be used at the heart of devices that are otherwise fairly closed, such as TiVos and Android-based phones. Many such devices use restrictive boot processes to prevent unauthorized kernels from booting—a process that the GPLv3 would forbid.

A variant of the GPL is the Lesser GPL, or LGPL. Developers often use the LGPL with libraries, which are collections of code that can be used by other programs. For instance, in Linux libraries implement the features that create dialog boxes and menus. Many GUI programs use these features, and placing them in libraries helps programmers and reduces the size of the programs that use them. The wording of the GPL, however, would require that all the programs that use a GPLed library also be released under the terms of the GPL. This strong requirement motivated the creation of the LGPL, which is similar to the GPL but enables programs that use a library to be released under another license—even a commercial license.

Another related license is the GNU Free Documentation License (FDL), which is intended to be used by documentation rather than by programs. The GPL, being written for software, doesn't apply perfectly to static documents, so the FSF created the GNU FDL to fill the gap. A notable user of the FDL is Wikipedia (http://www.wikipedia.org); all of its content is available under the terms of the GNU FDL.

The Open Source Initiative

The OSI was founded in 1998 by Bruce Perens and Eric S. Raymond as an umbrella organization for open source software generally. Its philosophy, described in more detail shortly, is similar to that of the FSF but differs in some important details. As a general rule, more software qualifies as open source than qualifies as free (in the way the FSF means), but precisely what qualifies depends on the open source definition and, in a strict sense, on what the OSI has approved in terms of its licenses.

Understanding the Open Source Philosophy

In the 1980s and 1990s, the free software movement gathered momentum in certain circles, including academia and among hobbyists. Businesses, however, were slow to adopt free software. Many who did adopt it did so reluctantly or even unwittingly—system administrators, pressed to perform their duties with minuscule budgets, would quietly install Linux, Apache, Samba, and other free software as a way to avoid having to buy expensive commercial alternatives.

The FSF's advocacy efforts were (and are) based on a strong moral imperative—software should be free, in the FSF's view, with “free” defined as described earlier. This approach appeals to some people, but others—particularly businesses that want to make money off of software—find this type of advocacy strange at best and threatening at worst.

For these reasons, the OSI's creators designed their organization as a way to advocate free software. By using a new term—open source—and by softening some of the FSF's moral imperatives, the OSI aims to promote open source software in the business world. The difference in tone from the FSF's moral imperative can be seen in the opening statement on the OSI's Web site (http://www.opensource.org):

---

Open source is a development method for software that harnesses the power of distributed peer review and transparency of process. The promise of open source is better quality, higher reliability, more flexibility, lower cost, and an end to predatory vendor lock-in.

---

The biggest philosophical difference between the FSF and the OSI is reflected in a requirement of the GPL: that derived works also be distributed under the GPL. The OSI has certified many licenses as being open source, including the GPL; however, many of these licenses lack similar restrictions. Software released under such licenses has, in the past, found its way into closed-source products. The OSI does not object to such a path, provided the software was licensed in a way that permits it. The FSF, on the other hand, explicitly forbade such appropriation for proprietary uses in its GPL.

As a general rule, free software in the FSF's sense is also open source software, although some licenses the FSF recognizes as being free have not been approved by the OSI. Many open source licenses do not qualify as free by the FSF's definition, though. Figure 3.1 illustrates this relationship.

FIGURE 3.1 Most free software is open source, but a significant amount of open source software is not free.

Today, there is some tension between free software purists in the FSF's sense and the more pragmatic open source community. For the most part, though, the two share goals that are similar enough that their differences are minor. In fact, two terms, free and open source software (FOSS) and free/libre open source software (FLOSS), are sometimes used as umbrella terms to explicitly refer to both types of software and development.

Defining Open Source Software

The open source definition appears at http://www.opensource.org/docs/osd. It consists of ten principles, which are (paraphrased):

Free redistribution The license must permit redistribution, including redistribution as part of a larger work.

Source code availability The author must make source code available and permit redistribution of both source code and (if applicable) binary code.

Permission to derive works The license must permit others to modify the software and to distribute such modifications under the same license as the original.

Respect for source code integrity The license may restrict redistribution of modified source code, but only if patch files may be distributed along with the original source code. The license may require that derived works change the soft-ware's name or version number.

No discrimination against persons or groups The license must not discriminate against any person or group of people.

No discrimination against fields of endeavor The license must not forbid use of the program in any field, such as in business or by genetics researchers.

Automatic license distribution The license must apply to anybody who receives the program without needing a separate agreement.

Lack of product specificity The license must not require that the program be used or distributed as part of a larger program—that is, you may extract a single program from a larger collection and redistribute it alone.

Lack of restrictions on other software The license must not impose restrictions on other software that's distributed along with the licensed software.

Technology neutrality The license must not be restricted based on specific technologies or interfaces.

The first three of these principles are the most important, at least in understanding the point of open source technology. The collection as a whole bears a strong resemblance to the FSF's four principles and the extended description of its implications on the FSF's Web page (http://www.gnu.org/philosophy/free-sw.html). As already described, however, there are some differences, particularly with respect to licensing requirements for derived works.

The Creative Commons

The Creative Commons, headquartered at http://creativecommons.org, was founded by Lawrence Lessig. Its goal is to combat what its creators and supporters view as a creative culture that is increasingly tied to permissions granted (or not granted) by those who hold copyrights on earlier works. Much of our current culture is derived from earlier cultural works—for instance, Star Wars is inspired, in part, by common myths and legends. Star Wars itself is copyrighted, however, which limits the rights of current artists to distribute works that are derivative of it, at least without permission.

The Creative Commons promotes its aims by providing six licenses that are designed for various purposes. You can select a license by answering a few questions on the Creative Commons Web site (at http://creativecommons.org/choose/), such as whether you want to permit commercial use of your work.

The FSF and the OSI are dedicated to promoting software freedoms. The Creative Commons' goals are broader, though; their licenses are aimed at audio recordings, video recordings, textual works, and so on, not just computer programs. Nonetheless, the Creative Commons as an organization helps promote the types of freedoms that also concern the FSF and the OSI.

Using Open Source Licenses

As an individual user, you might not need to delve too deeply into open source license details. The principles behind the OSI guidelines guarantee that you have the right to use open source programs as you see fit, and even to redistribute those programs. If you're building a business, though, and particularly a business that creates or distributes open source software, you may need to better understand these licenses. Thus, I describe a few of them in more detail and I also describe some of the ways that companies have found to use open source licenses as parts of their business models.

Understanding Open Source Licenses

Every open source license has its own unique characteristics. These are mostly of interest to developers who might want to contribute to a software project, but on occasion they may be important to a system administrator. The major open source licenses include the following:

GNU GPL and LGPL As noted earlier, the Linux kernel uses the GPLv2, and many other Linux tools use the GPL (either version 2 or version 3). Many Linux libraries use the LGPL.

BSD The BSD license is used by the open source BSD OSs, and by various software components developed for them. Unlike the GPL, the BSD license allows modifications to be distributed under other licenses. The latest versions of this license are very similar to the MIT license.

MIT The Massachusetts Institute of Technology (MIT) was the original moving force behind the X Window System (X for short), and the MIT license (sometimes called the X11 license) continues to be used for Xorg-X11—the implementation of X included with all major Linux distributions. The MIT license is unusually short.

Apache Like the BSD and MIT licenses, the Apache license is an open source license that permits redistribution under the same or another license. If a text file called NOTICE comes with the original work, it must be included in any derived work. This enables the original developer to provide contact or other information, even to users of heavily modified versions of the program.

Artistic The Artistic license was originally developed for the Perl programming language, but it has been used with other programs. It's filled with requirements and loopholes for those requirements. Most software that uses the Artistic license is shipped with the stipulation that this license is optional; the user may elect to follow the terms of some other license (usually the GPL) instead.

NPL and MPL The Netscape Public License (NPL) and Mozilla Public License (MPL) were developed by Netscape when they brought their Netscape Web browser (the parent of the Firefox Web browser) into the open source field. The NPL reserves some rights for the copyright holder, but the MPL is more open.

Many additional licenses meet the OSI's requirements. You can find a complete list on the Open Source Initiative Web site, http://www.opensource.org/licenses/.

The details of the various open source licenses are probably not important to most system administrators. You may use and redistribute any open source program as you like. If you modify a program, though, you should be aware of redistribution requirements, particularly if you want to merge two or more programs or distribute a program under a modified license. You should also be aware that some Linux distributions may include software that doesn't qualify as open source. Some of this is commercial software, and some of it falls into some variant category.

One final concern when describing software licenses is the license for Linux as a whole. When you download a CD-ROM image file or buy a Linux package, the software you obtain uses many different licenses—the GPL, the BSD license, the MIT license, and so on. Most of these licenses are open source, but some aren't. Many distributions ship with a few shareware or not-quite-open-source packages, such as the shareware XV graphics program. Retail packages sometimes include outright commercial software. For this reason, you shouldn't copy a retail Linux package's disc unless you've researched the issue and found that copying is OK. If the distribution vendor provides free-as-in-beer download links, copying is probably OK.

Linux distributions include installation programs, configuration programs, and the like. These tools are usually all that a distribution packager can lay claim to, in terms of copyright. Most distribution maintainers have made their installation and configuration routines available under the GPL or some other open source license, but this isn't always the case. Such details can turn what might seem like an open source OS into something that's not quite fully open source. Debian maintains a policy of using only open source software in its main package set, although it lets freely redistributable but non-open source programs into its “non-free” package set.

Because a complete Linux distribution is composed of components using many different licenses, it's not very useful to speak of a single copyright or license applying to the entire OS. Instead, you should think of a Linux distribution as being a collection of different products that comes with a unifying installation utility. The vast majority of all the programs use one open source license or another, though.

Understanding Open Source Business Models

Some Linux distributions, such as Debian, are maintained by volunteers or by not-for-profit organizations. Others, such as Red Hat Enterprise Linux, are maintained by a company that expects to make a profit. How, though, can a company make a profit if its core product is available for free on the Internet? Several approaches exist to making money from open source software, including:

Services and support The product itself can be open source, and even given away for free, while the company sells services and support, such as training and a technical support phone line. For instance, a game might be open source but require a subscription to an online service to provide a full set of features.

Dual licensing A company can create two versions of the product: One version is completely open source and another adds features that are not available in the open source version. The open source version is then akin to the free samples that supermarkets often provide—it's a way to draw in paying customers.

Multiple products The open source product may be just one offering from the company, with revenue being generated by other product lines. These other product lines could be other software or some other product, such as manuals.

Open source drivers A special case of the preceding one is that of hardware vendors, who make money by selling hardware. They might opt to release drivers, or perhaps even hardware-specific applications, as open source as a way to promote their hardware.

Bounties Users can drive open source creation by offering to pay for new software or new features in existing software. Sites such as FOSSFactory (http://www.fossfactory.org) can help bring together users, each of whom as an individual might not be able to offer enough money to motivate development, to entice programmers to write the desired code.

Donations Many open source projects accept donations to help fund development. Although this isn't a commercial funding model in the usual sense, it does help fund the operations of organizations such as the FSF.

Beyond these commercial opportunities, of course, a great deal of open source software is developed in academia, by governments, by non-profit organizations, by hobbyists, and so on. Even companies can be motivated to give back changes they make for themselves because hoarding their changes will create more work—if an internal change is not given back to the original author, the change will have to be re-applied with each new release.