Exploring Copyright Protection 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 the right to make copies of that book, photograph, or computer program. However, you can give others the 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 signed the Berne Convention, an international agreement that requires countries to recognize one another’s copyrights. That is, if Carol 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 the 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 the following:

• A copy of the program from an installation medium to a disk drive
• A copy of the program from the disk drive 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 disk drive backups to protect against disk failures

In the past, such copies were generally ignored on the principle of fair use—that is, exceptions that allow portions of copyrighted material to be copied. 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 legal document 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 named COPYING.

Software licenses can modify copyright terms by making the terms either more or less restrictive. For example, 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 restrict 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 the right to make a certain number of copies of the program—say, 100 copies of a word processor for all of the company’s computers.

Understanding the FSF Philosophy

 The FSF advocates what it calls free software, which it defines as freedom to do things you want to do with the software, not the price of the software. A common phrase used 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, as you’ll soon see. The FSF elaborates on the implications of each of its principles, and their interactions, at 
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 of the freedoms just outlined. Some Linux distributions meet this ideal in isolation, whereas other distributions include proprietary software. Sometimes, this software is freeware. At 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. However, 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 term came from 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 the freedom of users to copy software, rather than to restrict that right. Copyleft licenses require that any modified programs derived can be distributed only under the same license terms of the original program. Thus, copyleft licensing is sometimes called reciprocal licensing.

Examining 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 current versions of the GPL are common: version 2 and version 3. Both versions of the GPL apply the four freedoms of the FSF philosophy to the licensed software. They also state explicitly that derivative works must be released under the GPL, thus making it a copyleft license. 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 it held sway for many years. In 2007, GPLv3 appeared, with the intention of closing certain loopholes in the GPLv2, particularly with respect to changes in laws and practices since 1991. Specifically, the GPLv3 contains clauses 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 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 (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 not only helps programmers, but also reduces the size of the programs that use them. The wording of the GPL, however, would require that all programs that use a library with a GPL also be released under the terms of the GPL. This strong requirement motivated the creation of the LGPL, which enables programs that use a library with a GPL to be released under another license—even a commercial license.

Another related license is the GNU Free Documentation License (FDL), for use in 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 (wikipedia.org). All of its content is available under the terms of the GNU FDL.

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 selling 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 for 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 a mission statement on the OSI’s website (opensource.org): “Open source enables a development method for software that harnesses the power of distributed peer review and transparency of process. The promise of open source is higher quality, better reliability, greater 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 GPL requirement 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.

 Today, some tension exists between free software purists in the FSF’s sense and the more pragmatic open source community. For the most part, however, 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 refer explicitly to both types of software and development.

Defining Open Source Software

 The open source definition appears at opensource.org/definition. It consists of 10 principles, which are paraphrased here:

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 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 software’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 terms of 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 (gnu.org/philosophy/free-sw.html). As already described, however, some differences exist, particularly with respect to licensing requirements for derived works.

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 Berkeley Source Definition (BSD) licenses are used by the open source BSD OSs and by various software components developed for them. Unlike the GPL, the BSD licenses allow modifications to be distributed under other licenses. The latest versions of this license are similar to the MIT license in brevity.

MIT  The Massachusetts Institute of Technology (MIT) was the original moving force behind the X Window System (X for short), and the MIT license continues to be used for Xorg-X11—the implementation of X that is still included with several Linux distributions. However, some Linux distributions have moved from X to Wayland, which also uses the MIT license. The MIT license is unusually short—only around 160 words.

 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.

The original version of the Apache license (version 1.0) was created in 1995. The current version is 2.0, and thus sometimes the Apache license is referred to as Apache 2.

Many additional licenses meet the OSI’s requirements. You can find a complete list on the Open Source Initiative website at 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 wish. 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 a variant category.

One final concern when describing software licenses is the license for Linux as a whole. When you download an image file or buy a Linux package, the software you obtain uses many 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, if you’ve purchased a Linux package disc, you should not copy it unless you’ve researched the issue and found out that copying is okay. If the distribution vendor provides free-as-in-beer download links, copying is probably allowed.

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 licenses, it’s not useful to speak of a single copyright or license applying to the entire OS. Instead, you should think of a Linux distribution as a collection of 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 then 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 the following:

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. They might opt to release drivers, or perhaps even hardware-specific applications, as open source as a way to promote their hardware.

Bounties  Bounties are a crowdfunding method. Users can drive open source creation by offering to pay for new software or new features in existing software. Sites such as FOSS Factory (fossfactory.org) and Bountysource (bountysource.com) can help bring together users, each of whom individually might not be able to offer enough money to motivate development, to entice programmers to write the desired code. With bounties, the programmer who completes the project first is allowed to collect the project’s accumulated funds.

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, nonprofit organizations, hobbyists, and so on. Even companies can be motivated to give back changes they make for themselves, because hoarding their changes will create more internal work for the company—if an internal change is not given back to the original software author, the company will have to reapply the change with each new release of the software.