This chapter is from the book
This chapter is from the book
This chapter is from the book
Simplified License Management
Simplified license management is almost a given with the elimination of software fees. In addition to the termination of complex licensing negotiations and software asset management efforts, there are no nagging concerns about compliance. In reality, however, all licensing issues aren’t eliminated and that has to do with the fact that the GNU General Public License isn’t the only commonly accepted open source license. A summary of other open source licenses in use will be helpful—but first, a little about how they have evolved.
When Richard Stallman started the GNU Project, he also established the Free Software Foundation, a nonprofit organization that promotes and supports the free software movement. As has been mentioned, the word "free" was a source of confusion in that you were free to give software away, but software wasn’t necessarily without cost. When the Debian Project with a version of GNU/Linux began to grow, a set of guidelines was needed to determine what contributed software could appropriately be included with the distribution and still maintain "free software" status. Bruce Perens, the second project leader of Debian, helped create the Debian Social Contract and the Debian Free Software Guidelines. The Debian Social Contract is a set of moral guidelines that engage users and software makers in an agreement regarding free software. The Debian Free Software Guidelines (DFSG) are the rules used to determine whether software actually is free. These rules include free redistribution, inclusion of source code, allowance for modification, and other specifications that protect integrity and redistribution.
Bruce Perens teamed with Eric Raymond to create the Open Source Initiative (OSI) in 1998, which attempted to stem confusion around "free" by coining the term "open source" and writing the Open Source Definition (OSD) that was similar to the DFSG. (See the complete guidelines at http://www.opensource.org/docs/definition.php.)
Open Source License Templates
So what does all of this have to do with simplified licensing? Plenty. Today, many different open source licenses are used and almost all of them certify their openness by comparing compliance to the Open Source Definition. Here are a few of the more common examples:
GNU General Public License (GPL)—As mentioned earlier, this is a legacy of Richard Stallman and the GNU Project. The GPL basically protects the rights of anyone to use, modify, and distribute software licensed under it with freedom to run software for any purpose, freedom to study source code and modify it for any need, and freedom to pass it on with the restriction that any changes made must be contributed back to the community.
GNU Lesser General Public License (LGPL)—With the GPL, anything that is linked to the original work (statically or using a shared library) is technically considered bound by the same freedoms (or restrictions—depending on your point of view). Works that are created and then linked to Linux would then be required to be open and source code provided. The GNU Lesser General Public License or LGPL was created to allow nonfree programs to use shared libraries without the requirement to make them free as well. For example, a database application that uses a library which is licensed using LGPL is not required to provide source code. Applications running on Linux that link using shared libraries such as glibc are not subject to the GPL.
BSD License—The Berkeley Software Distribution, a derivative of Unix distributed by UC Berkeley, included a license agreement that granted provisions to modify code, distribute changes, and charge for the derivative work without any responsibility to return code changes to the open community. Unlike the GPL, BSD licensed code can be made private and then redistributed under a proprietary license. As a result, you can find BSD code in Microsoft networking products and in Mac OS X. The BSD license, or BSD template as it is often referred to, is another popular licensing option used for making software open. It is not as powerful/restrictive as the GNU GPL, but is useful in many situations in which proprietary software is combined with free software to create hybrid, proprietary solutions.
Mozilla Public License (MPL)—The Mozilla Public License was developed by Netscape when Communicator was converted to open source. It closely adheres to the Open Source Definition guidelines and is widely used as an "open" template. The MPL was written after the GPL, BSD, and MIT licenses and has since become the template for the majority of open software licenses.
MIT License—The MIT license is a very basic license that carries no restrictions for use other than to apply ownership. The source may be applied for any purpose without any restrictions other than that the text of the license must be included with the code.
IBM Public License—The IBM Public License is a full open source license similar to the Mozilla Public License, but also includes indemnification provisions. Specifically, contributors making claims about capabilities are solely responsible for those claims; no one else in the chain of original or derived works can be held responsible.
Currently, more than 50 licenses have been approved by the Open Source Initiative as adhering to the guidelines of the Open Source Definition. These are maintained and available for use on the OSI website at http://www.opensource.org/licenses. Using any of these licenses ensures that software covered by the license is "OSI Certified Open Source Software" and is classified as "free" software.
Simplified License Management
Pragmatically, how does this affect enterprise licensing concerns? It reduces workload and worry—reduces, not eliminates. In general, the majority of open source licenses are based on the Mozilla Public License, which means that you don’t have to worry about license count, reuse issues, or distribution. If you’re running Linux as a server operating system, there’s no need to count boxes. Just install it whenever and wherever you need, making as many copies as you like. If you have a fully redundant failover cluster in a remote location, there’s no double cost for software. Want to add extra web servers to accommodate a surge in online sales? No charge.
For many organizations, people changes at the desktop are far more frequent than data center servers. Here licensing can be significantly simplified with open source. If you want no licensing worries at all, you can run Linux OS at the desktop and OpenOffice.org as the office productivity suite. The typical user has everything he needs, including word processing, email, browser, file sharing, and more. This is especially relevant to organizations that can fluctuate in size over short periods of time as a result of special projects, mergers and acquisitions, divestitures, and seasonal changes.
It was mentioned that licensing issues would be reduced, not eliminated. Realistically, you would still need to deal with proprietary software that might be running on or in conjunction with open software. Web application services, databases, desktop applications, and even many of the software services that Novell sells still require license management and compliance.
The net result of all this is that you will have far fewer licensing headaches. There won’t be any renewals, contract negotiations, or renegotiations, and no need to spend valuable resources ensuring that you are in compliance with agreements for what could be a significant portion of your software. At minimum, software covered by any of the preceding licenses allows you the freedom to apply it to any use, copy it, modify it if needed, and redistribute it.
If your organization is developing open source software or modifying it for redistribution, you need to look more closely at the main open source licenses at http://www.opensource.org and see which template would be most appropriate to work from.