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:
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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Three More Lessons
- Django Models and Migrations
- August 2015 Issue of Linux Journal: Programming
- Hacking a Safe with Bash
- The Controversy Behind Canonical's Intellectual Property Policy
- Secure Server Deployments in Hostile Territory, Part II
- Shashlik - a Tasty New Android Simulator
- Huge Package Overhaul for Debian and Ubuntu
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile