Licenses and Copyright

If you program for Linux, you do need to understand licensing, no matter if you are writing free software or commercial software. Here's a road map.

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.

Licensing versus Copyrighting

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.

Licensing when Developing under Linux

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:

  • Link dynamically.

  • Provide object files that can be linked to static libraries.

  • Provide source code.

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:

  • Your program uses less system memory when running.

  • Allows your program to be upgraded automatically when bugs are found in the library.

  • Creates smaller binaries.

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.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix