Licensing Demystified

In our previous part of the series, we examined various licensing policies and strategies of Microsoft. While the programs we discussed in that article are specific to that company, other vendors and software developers also follow similar models. The exact nature of the particular equivalent program (say Volume Licensing) would differ from one vendor to another, but the general principles, benefits and goals remain the same. Therefore, instead of examining the policies of each company individually and running the danger of being repetitive, we shall take a look at the various other policies out there. Some of these policies are company specific, while others are a global initiative.

Note: We use the term 'acquire' instead of 'buy' or 'download' in this article, because the software we are talking about is available both for free and otherwise.

OSM (Open Source Model)



Open source is the opposite of proprietary licensing systems. While proprietary formats tend to black-box and protect information, the OSM seeks to throw the doors open. Allegedly, this is to invite wider participation and foster more secure and robust software. We say 'alleged', because a lot of debates are happening out there, with each camp defending its own model with strong reasons. Hence we cannot make clear pronoucements on a “winning model” between the two-that will have to be decided on a purely case to case basis.

Under the OSM, users are free to copy and distribute the software along with its source code to anyone, for any use. The key here is to make sure that the source code of that software is available for free and on-demand. It is not necessary that software licensed under OSM is free of cost. Vendors may tack on costs based on distribution media or technical support. For example, source code of the RHEL is distributed under the OSM, but RHEL costs money to buy. For example, take a look at

http://www.redhat. com/software/rhel/purchase/.  

The key to the OSM is freely available source code. The definition nowhere states that the final compiled-executable code must be available freely too. To quote, "The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with the source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost-preferably, downloading via the Internet without charge." Under open source, you are automatically granted rights to fire up your favorite text editor, make changes to the code as you received it and call the new one your own (changing its name). Of course, the modified product should remain open sourced as well. The license should also be non-discriminatory, ie, it should not differentiate between different types of users or methods of distribution. If the product is a part of a set of software, then all parts of that software share the same license. That is, if you decide to make changes to (say) the word processor part of OpenOffice.org, the licensing as applied to your modified copy would be the same as you got it originally.

For more information on OSM, consult: http://opensource.org/.

CSL (Community Source Licensing)



This is a variant of both the OSM as well as the SSI (Shared Source Initiative) from Microsoft, that we discussed in our previous issue. CSL seeks to freely share source code and information about a product internally within a select group of participants. Assume that your company along with a few others is engaged in developing a mammoth CRM application. If your group charters a CSL agreement, the intellectual property of the product you are working on is jointly owned by all members of that group. The advantage of such an approach is free flow of information among members that need to know, while keeping that information black-boxed from public. 

For further information on CSL, visit http://www.sun.com/software/communitysource.  

GPL (GNU General Public License and Variants)



This is perhaps one of the most confusing licensing schemas. Generally, when end-users see the text '(GPL)' against a product name, they assume it is free to acquire and use. However, it is not necessarily so and that's what makes this quite confusing. The charter displayed on GNU's website says:

“Think of free software as software which is free of encumbrances, not necessarily free of cost.”

And that



"Free software" is a matter of liberty, not price. To understand the concept, you should think of "free" as in "free speech", not as in "free beer".

The "encumbrances" and "freedom" talked about here are specifically, the right to use, distribute with or without modifications without worrying about acquiring permissions to do the same. Using GPL to distribute your work, merely serves to protect against someone modifying your code and making it proprietary.

GPL has variants such as LGPL (Lesser GPL) and FDL (Free Documentation License). LGPL applies to libraries and modules of larger software. Increasingly, GNU is discouraging the use of LGPL in favor of GPL. FDL grants GPL-like licenses for documentation.

More on GPL is available online at http://www.gnu.org/licenses/. 

Copyleft



The term is actually a GNU invention. Imagine you wrote some program that you want to distribute without any restrictions and you really don't mind if someone copied it and made modifications to it as long as that copy remained free, with the same associated freedoms. Such freedom is granted with 'copyleft', the antonym for copyright.

However, do note that this is not the same as simply moving the software to a public domain, source code and all, with no licensing or copyright whatsoever. There would be nothing to prevent someone from lifting your entire source code, calling it his own and making it proprietary. This would even require you to pay royalties to the copycat! Under copyleft, each person who receives a copy, modifies it and passes it on would pass on the same obligations (of keeping it free and open) to his users as well.

Copyleft and its associated FAQs are available at http://www.gnu.org/copyleft/copyleft.html.

Customer privileges



Acquiring licenses for your software allows you to hold someone accountable for problems. Because, you would be paying your vendor a fee and that fee obliges them to provide you with certain services. 

These services may either be in the form of technical support or upgrades and patches or bug fixing, or a combination of these.

Software sans licensing, even though may be 'free', holds little value to a corporate customer, who wants peace of mind. When you have taken the trouble to deploy all that IT infrastructure, a few extra rupees to ensure it stays up-to-date and reliable is surely, worth it.

A quick analysis



Let's quickly recap everything we've discussed about different types of licensing. If you bought one copy of Win XP, it would be under normal FPP licensing. But if you bought four more, you could ask for Volume Licensing. 

For much larger volumes (250 or more), you could go in for Enterprise Agreements or Open License. RHEL is under open source, but not free. Fedora Core 3 is free and open source. PCQuest took Fedora Core 2 (which is under GPL), customized it and gave it away as PCQLinux 2004. This again, was still under GPL. 



Sun Microsystems makes several products in association with its partners, especially under its Java Enterprise System offering. That is done under its Community
Source Licensing.

With all this you must be ready to tackle software licensing on your own! 

Sujay V. Sarma