Licenses and Copyright

How often do you see on Usenet a sentence like “DISCLAIMER: I am not a lawyer, and I am not qualified to give legal advice ?” Perhaps one day tort reform will be passed and non-lawyers won't have to make a disclaimer like this in order to avoid being sued. Until then, I need to make the same disclaimer: I am not a lawyer. I don't even play one on T.V. What you read here is my interpretation of these licenses, and while I have done my best not to err, to err is human. Before betting your life, your fortune, or your sacred honor on my interpretation you should read them yourselves, come to your own understanding of them, and if you are not comfortable ask a lawyer.

The first thing you need to understand is the difference between copyright and license. A copyright safeguards the ownership of an intellectual property. If you hold copyright to some intellectual property, you have several rights regarding that property, and you can assign (sell or give) some or all of those rights to others. A License, on the other hand, is a document lets someone use your intellectual property.

For example, the GNU General Public License (GPL), which is often incorrectly called a “copyright,” is a license. Applying the GPL to code to which you own the copyright does not assign the copyright to the Free Software Foundation (FSF, the authors of the GPL). You still own the copyright—applying the GPL to your code merely lets other people modify and redistribute your code in accordance with the GPL's terms. The GPL is too long to include in this article; you can use FTP to retrieve a copy from the canonical site, prep.ai.mit.edu, in the /pub/gnu directory.

The GPL is one of the most popular licenses in the Linux world; the MIT X and BSD licenses are also popular. The MIT license is very permissive: it says (like all software licenses of which I am aware) that no warranty is provided, that the copyright notices must be maintained, and that MIT's name (or with similar licenses, the name of the copyright holder) cannot be used in advertising or publicity without written permission. The BSD license, by contrast, requires that all advertising materials display an acknowledgment of “the University of California, Berkeley and its contributors,” while prohibiting using either name as an endorsement. In other respects, it is much like the MIT license. If you can't figure out how to acknowledge MIT and BSD without using them, talk to a lawyer. The MIT and BSD licenses are short enough to reprint in this article—see the sidebars.

Let's say you wish to develop free software derived from software that is licensed under the terms of any one of these agreements. All you have to do is maintain the current copyrights and insert your copyright notice for the code you add, thereby licensing your additions under the same license as the rest of the code.

However, if you wish to develop commercial software derived from free software, there are thornier issues. The MIT and BSD licenses do not require you to release your source code. You must simply follow the terms of the license, which mostly have to do with maintaining copyright notices and following limitations about advertising and promotion. If the original software is licensed under the GPL, however, you must release your source code in compliance with the GPL in order for you to distribute the derived work.

The biggest single concern shared by software developers new to Linux is that because Linux is subject to the GPL, any software written or compiled under Linux is also subject to the GPL. Fortunately, this concern is groundless. Plenty of commercial software is available for Linux, and it does not violate the GPL in any way. Developing and compiling your software on a Linux system does not cause your software to be derived from the GPL-licensed Linux source code.

Some people assume that because they use #include to include system header files in their application, their application is suddenly considered to be “derived from” those header files. This is not the case; the declarations in header files are legally considered “public interfaces” and cannot be copyrighted. This is the same as any other development platform: the header files on every commercial platform sport copyright notices that assert ownership over the header files, but that doesn't mean your application was derived from those header files.

Some people also assume that if they compile their program with the GNU C compiler (gcc), their program must be licensed under the terms of the GPL. This is not true. The GPL states that “the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program).” Many commercial software vendors compile their products exclusively with GCC; some Unix systems are shipped from the vendor with GCC as the standard system compiler. They are not in violation of the GPL.

You do need to be careful, however, when linking with libraries that are licensed under a slightly relaxed version of the GPL called the GNU Library General Public License, or LGPL. Linux's standard C library, and most of its other libraries, are licensed under these terms, which require you (read the license for further details) to do one of the following:

The second option isn't very easy to implement, and the third option, while great for freely redistributable software, is less than ideal for more restricted commercial software vendors. The right answer for everyone, whether the software is free or not, is to link dynamically. This provides several advantages:

Since dynamic linking is the default on all normal Unix platforms, using it on Linux platforms is not likely to be a hardship.

Note that this restriction applies only to libraries licensed under the LGPL. Commercial libraries such as the Motif libraries are not affected by this condition, nor are libraries that are licensed under the BSD or MIT terms. Since there is rarely any reason to link statically, you can almost always ignore this issue. You need only worry about it if you want to distribute a program that is staticly linked against an LGPL-licensed library and you do not wish to distribute the source code.

There are a few things that you can do that are incompatible with using the GPL. First of all, you can't derive a work from code licensed both under the GPL and the BSD license. This is because the GPL forbids imposing any restrictions beyond those imposed by the GPL, and the BSD license imposes the additional restriction that UCB and its contributors be acknowledged in advertisement.

Also, non-disclosure agreements (NDA) that prohibit you from releasing source code developed under the terms of the agreement are blatantly incompatible with using the GPL. If you sign an NDA that doesn't allow you to distribute source code, and then write code for a GPL application under the terms of the NDA, you can use your modified version of the GPL application (remember that the GPL doesn't restrict use in any way), but you cannot redistribute it.

Similarly, if your code uses a software patent, the patent must be licensed for everyone's free use, or you cannot redistribute your modified version of the application.

The Linux kernel is licensed under the GPL. This means that if you write code linked into the Linux kernel, and want to distribute it, the code must be licensed under the GPL. For example, you are not allowed to distribute the driver for a new hardware device as an object file that needs to be linked into the kernel at compile time. To do so would beg a lawsuit brought by everyone who holds copyright to some part of the Linux kernel.

It is possible, however, to distribute a driver in binary form only, under any licensing terms you wish, as a kernel loadable module. The kernel provides a public interface to which object modules can be bound at run time. The key words here are public interface. A public interface cannot be copyrighted. The declarations in a C header file and the system call interface are also examples of public interfaces, that are also not copyright-able. You can safely think of the kernel-loadable module interface as “system calls for code running with kernel privileges in kernel space”.

However, it is usually not advisable to distribute binary-only kernel loadable modules, for a variety of reasons:

Maintaining a binary-only product based on a kernel-loadable module is definitely possible but doing this does take extra work, and if you don't account for the work beforehand, you may be unhappy when you need to take the time. To say this another way: most commercial software development on Linux raises no more issues than are raised on any other platform, but binary-only kernel modules do raise other issues that you would need to consider.

Sometimes people want their code to be licensed under terms that are compatible with both the GPL and the BSD licenses. There are three ways to do this.

The first involves the copyright instead of the license. You can donate the copyright to the public domain which gives intellectual ownership to everyone in the world, individually and collectively. Anyone can do anything at all with the code, with no restrictions whatsoever. Since they own the code, they don't need a license to use it.

The second involves writing a very permissive license that allows anyone to use the code for almost any purpose. As long as you don't add any restrictions that aren't in the GPL, and as long as you don't prevent other people from adding restrictions, code protected by this form of licensing can be used for projects that use the GPL or the BSD license, without legal problems. If you choose to write your own license, be sure to get legal help in doing so. There are many licenses written by laymen that are legal nonsense, and if you want to have any chance of being able to enforce your license, get a legal opinion. Also, get a legal opinion if you do want other people to be able to use your code, since without a license, it is illegal to use code you don't own. anyone concerned about lawsuits won't be able to use your code if it is licensed under non-enforceable terms, even if you have personally decided you would never sue anyone over use of the code.

Perhaps the best option, however, is this: as the copyright owner, you can license your code to anyone you like under any license you like. You don't have to offer only one set of license terms. You can offer users the choice between, say, the GPL license terms and the BSD license terms. For example, a set of libraries called PAM is being developed which will need to be linked both with GPL applications and BSD applications. Its license first gives the BSD license terms (modified not to mention UCB, since UCB isn't involved in its development), and then says, “ALTERNATIVELY, this product may be distributed under the terms of the GNU General Public License, in which case the provisions of the GPL are required INSTEAD OF the above restrictions.” Some code in the Linux kernel has been licensed in this way.

Shareware hasn't really caught on in the Linux world. Perhaps because so much quality software is available without any sort of payment, and perhaps because Linux grows out of the movement to write free software for Unix and predates the shareware movement, there are only a few popular shareware packages in the Linux world. Most of these provide for optional payment for personal use, and required payment only for business or commercial use. There are no legal restrictions that keep you from releasing shareware for Linux, but be aware that you are entering relatively uncharted waters if you choose to license a Linux application as shareware.

The most important thing to remember is that licensing isn't a particularly complicated issue in most cases. This entire article has been concerned mostly with exceptional cases. Most normal application vendors and most free software authors will have no licensing issues to resolve. Just be aware of the differences between licensing techniques, so that you will be aware of the issues involved. if you ever do have a problem to resolve.