Newcomers to the free-software world are often confused by the variety of licensing terms attached to free software. Some free-software devotees twist normal words into jargon and then expect you to understand every nuance they have attached to each piece of jargon.
To write and distribute software that runs on a free platform such as Linux, you must understand licenses and copyright. These matters are regularly confused by intelligent and informed people, free-software devotees among them. Whether you intend to write free or commercial software, you will be working with tools that come with a variety of license terms. A general understanding of the field of copyright and licensing will help you to avoid common errors.
In these litigious times, it is vitally important that we warn you that we are not lawyers. This chapter reflects our understanding of the matters that we discuss, but it does not offer legal advice. Before you make any decisions regarding your own or anyone else’s intellectual property, you should study the subject further and, unless you think it unnecessary, consult an attorney.
We deal with the simpler subject first. A copyright is the simple assertion of ownership of certain types of intellectual property. Under the latest international copyright conventions, you do not even need to claim copyright for material you create. Unless you explicitly disclaim ownership, other people are allowed to use your intellectual property only in strictly defined ways, called fair use, unless you explicitly give them permission, called license, to do otherwise. So if you write a book or a piece of software, you do not need to put “Copyright c year” on it to own it. However, if you do not put this phrase on your writing, you may find it much more difficult to claim ownership in court if someone violates either your copyright (by claiming that, or acting as if, you do not own the copyright) or your license terms. The Berne copyright convention,[1] an international treaty covering international copyright conventions and enforcement, requires participating nations to enforce copyright only
... if from the time of the first publication all the copies of the work published with the authority of the author or other copyright proprietor bear the symbol of a lower case “c” inside of a circle accompanied by the name of the copyright proprietor and the year of first publication placed in such manner and location as to give reasonable notice of claim of copyright.
The sequence (c) has been generally used as a replacement for the lower case “c” inside of a circle, but courts have not upheld that. Always use the word Copyright (in addition to the sequence (c), if you choose), when asserting your copyright. If a c character is available to you, it is best also to make use of that character, but do not neglect the word Copyright.
Copyright is not perpetual. All intellectual property eventually passes into the public domain; that is, the public eventually owns the copyright to the property, and any person can do anything with the property. No license terms are binding once the property is in the public domain. There is one twist: If you create a derived work based on public-domain work, then you own the copyright to your modifications. Therefore, although many old books are now out of copyright, their copyright having passed into the public domain, editors often make small changes here and there, correcting mistakes made in the original. They often then claim copyright ownership of the derived work that includes their changes. This copyright prevents you from legally copying the edited version, although you can freely copy the public-domain, out-of-copyright original.
Note that there are limits on what can be copyrighted. You cannot publish a book containing only the word the and then attempt to extort license fees from everyone using the word the in their books. However, if you create a sufficiently stylized painting of the word the, you would own the copyright to that particular representation, as long as it was sufficiently identifiable for you to show that prior art did not exist with the same representation. Although we are free to use the word the in this sentence, we would not be allowed to sell reproductions of your work without getting a license from you.
These limitations apply to software as well. If you are licensed to alter someone else’s software and you make a trivial, one-word change, it would be absurd for you to claim copyright to that change. You would not be able to defend a copyright claim to that change in court; your contribution would be as much in the public domain as the word the is. However, if you add significantly to the software, you would own the copyright to your modification, unless, for instance, the copyright owners of the original licensed the software for modification with the license restriction that copyright ownership of all modifications revert to them.
Copyright owners have wide latitude in determining license terms. Common areas of restriction (or permission) include use, copying, distribution, and modification. As a concrete example, the GNU General Public License (GPL, commonly called the copyleft) explicitly does not limit use. It limits only “copying, distribution, and modification.”
Here is an example of free-software jargon with which you want to be familiar. In the free-software world, public domain is used almost exclusively in terms of ownership. In other circles, it is often applied to use, as well. Magazine articles that refer to the GPL as a “public-domain copyright” are clearly wrong because the GPL does not give ownership of the copyright to the public domain; articles that refer to it as a “public-domain license” are in one sense correct, because the GPL explicitly places no license restrictions on use. Free-software fanatics, however, often cringe at this use of public domain, and many believe it to be completely incorrect.
Certain license restrictions may not be legal in certain localities. Most governing bodies prevent you from restricting what they consider fair use in a license agreement. For example, many European countries explicitly allow reverse engineering of software and hardware for certain purposes, license terms restricting such activities notwithstanding. For this reason, most license agreements include a separability clause something like the following one, from the GPL:
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
Most license agreements use less comprehensible language to say the same thing.
Many people who attempt to write their own license terms without legal help write licenses with terms that have no legal force, and few of those licenses include a separability clause. If you wish to write your own license terms for your software, and if you care whether people comply with the license terms, have an intellectual-property lawyer vet your license terms.
As described in Chapter 1, the term Open Source was coined in an attempt to resolve the confusion surrounding the word free in “free software.” The Open Source Initiative (OSI) was created in order to administer the term Open Source, and although its attempts to trademark the term (to protect its meaning) were rejected by the US Patent and Trademark Office, the OSI does hold the certification mark OSI Certified Open Source Software. (There are no legal constraints on the use of the term Open Source, but there are on the OSI Certified Open Source Software certification mark.)
The OSI maintains the Open Source Definition (OSD), a description of the rights provided by Open Source licenses; it also maintains a complete list of all licenses that it certifies to have met the requirements of the OSD, among which are: Source code must be available; the product must be freely redistributable; derived works must be allowed; and discrimination against persons, groups, or fields of endeavor must not be allowed. The complete OSD, along with a list of licenses certified as OSI Certified Open Source Software, is available at http://opensource.org/.
The GPL is one of the more restrictive free-software licenses. If you include source code that is licensed under the terms of the GPL in another program, that program must also be licensed under the terms of the GPL.[2] The Free Software Foundation (FSF; author of the GPL) considers linking with a library to be “creating a derivative work”; some others believe it to be a “work of mere aggregation.” Therefore, the FSF holds that you are not allowed to link with a library covered under the terms of the GPL unless the program being linked also is covered by the terms of the GPL. However, some people hold that linking is “mere aggregation,” and the GPL says:
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
If you consider an executable to be a “volume of storage,” you could consider linking mere aggregation.
To the best of our knowledge, this distinction has not yet been tested in court. In the fairly unlikely case that you wish to link a program not licensed under the terms of the GPL with a library that is, ask the authors of the library in question for their interpretation.
The GNU Library General Public License (LGPL) was designed to make libraries more generally useful. The point of the LGPL is to allow users to upgrade or improve their libraries without having to get new versions of programs linked against those libraries. To that end, the LGPL does not attempt to place any licensing restrictions on programs linked against the library, as long as those programs are linked against shared versions of libraries licensed under the LGPL or are provided with the object files for the application, allowing the user to relink the application with new or altered versions of the library.
In practice, this restriction is not significant; it would be unreasonable not to link against shared libraries where they are available.
Few libraries are licensed under the terms of the GPL; most are licensed under the terms of the LGPL. Libraries licensed under the terms of the GPL are usually that way simply because the author did not know about or consider the LGPL. In response to a polite request, many authors will relicense their libraries under the terms of the LGPL.
MIT/X-style licenses are much simpler than the GPL or LGPL; their only restrictions are (stated simply) to keep all existing copyright notices and license terms intact in source and binary distributions, and not to use the name of any author to endorse or promote derived works without prior written permission.
Old BSD-style licenses essentially add to the conditions of the MIT/X-style licenses the restriction that advertising materials that mention features or use of the software include an acknowledgment. The BSD license itself has been changed to removed this restriction, but some software continues to use licenses modeled after the old BSD license.
The Perl language source code is distributed with a license that allows you to follow either the terms of the GPL or of an alternative license, whimsically called the Artistic License. The main goals of the Artistic License are to preserve redistribution rights and to prevent users from selling altered, proprietary modifications that masquerade as the official version. Other software authors have adopted Perl’s convention of allowing users to follow the terms of either the GPL or the Artistic License; a few are licensed only under the terms of the Artistic License.
Different free-software license terms allow various types of commercial use, modification, and distribution. It is often desirable to reuse existing code in your own projects. To some extent, it is inevitable that you do so—almost any program that you write will be linked with the C library, so you need to be aware of the licensing terms of the C library, as well as the terms of other libraries that you link with your program. You may often wish to include fragments of other programs’ source code in your own programs, as well.
Mixing code from software with different licenses can sometimes be a problem. The problem does not occur when linking with shared libraries, but it definitely applies to creating derived works. If you are modifying someone else’s software, you have to understand their licensing terms. If you are trying to combine in one derived work two pieces of software that have different licenses, you have to determine if their licenses conflict. Again, this does not apply when you are writing your own code from scratch.
If you are working with code licensed under the terms of the GPL or LGPL, you cannot include in it code licensed under an old BSD-style license, because the GPL and LGPL forbid “additional restrictions,” and the old BSD license contains additional restrictions (that is, beyond any in the GPL or LGPL) in regard to advertising and endorsement. Because of this conflict, some pieces of software are licensed under alternative terms—both the GPL and an old BSD-style license terms are offered; you can choose with which licensing terms to comply.
If the code licensed under the GPL or LGPL is included in a work derived from a BSD/MIT/X-style license, the entire derived work (for all practical purposes) must be licensed under the terms of the GPL or LGPL, respectively.
There are many other potential incompatibilities. If you are in doubt about what you are allowed to do with particular pieces of free software, do not be shy—ask the copyright owners. Remember that they can give you license to use the software in any way they wish.