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.
Caution

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.

Licensing and the Linux Kernel

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:

  • The public interface is subject to change at any time and is frequently changed.

  • It violates the spirit of the GPL that has made Linux a success by taking away users' freedom to support themselves, and some users or potential users may become vocal about losing that freedom.

  • Linux developers will not notify you of changes in the interface; you need to be proactive in discovering changes by “joining the kernel-of-the-day club” (downloading, compiling, and running the latest kernel every time a new development kernel is released) or you will get complaints from users that your software suddenly broke.

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.

Licensing Tricks

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.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState