A significant facet of our jobs as IT (formerly known as DP) professionals involves dealing with software licenses. Personally, I consider it to be the most distasteful aspect of my job. Why? Because the administrative expenses associated with software licenses are sunken costs. Like leeches, these expenses suck the life out of your IT budget, without contributing in any way to the success of your IT operation. Think I'm exaggerating the extent of the problem? If so, then how do you account for the genre of software that has been created to do little more than count instances of licensed software and ensure license compliance? (Software titles in this genre no doubt have their own licenses.)

If you are strictly a consumer of software products—and by that I mean that either 1) you use only canned software or 2) you use software that you have written in-house for use strictly in-house—then you may have little interest in the morass that now engulfs our industry. Your administrative costs all revolve around counting the number of licenses you have and comparing that to the number of users or computers using the software, ensuring that the former count matches or exceeds the latter count. Meet that requirement (and don't do any of the other prohibited things like reverse-engineering file formats or using the software in creative-but-unanticipated ways) and you'll avoid the severe punishments meted out to the miscreants—like monetary penalties, dismemberment, death, or worst of all, a software audit by the Business Software Alliance. (For some reason I can't help but think of Monty Python's "Nobody expects the Spanish Inquisition" skit when I think of a BSA audit, but I digress.) Of course, if you use open-source software in this manner, you won't have to count the licenses or instances.

If you write software for others to use (as an individual or as part of a corporation), you can have a much more difficult path to travel. Not only do you need to ensure that you meet the licensing terms of whatever software you use in the production of your software while you're using it, but you'll need to ensure that you meet the terms while distributing your software, too. For example, you may have used a proprietary tool to produce your program but be unable to distribute everything from the original tool needed to run your program. The end-user needs to purchase a copy of the proprietary tool to use your program. While some simple programs are distributed with these limitations, more familiar examples include packages that use the proprietary extensions found in any of the commercial databases. Buy a product tied to one of those databases and you've committed to purchasing a license of the target database as well.

Basing your product on open-source tools instead of proprietary ones isn't going to relieve you of any licensing burden, to be sure. In some ways, the burden might be greater. The licenses available in the open-source world run the gamut from the ultra-liberal BSD style (where the software truly is a gift that you are welcome to use, modify, and redistribute without any strings attached whatsoever) to the forced-largess brought about by the GPL-style license (where you need to distribute any changes that you make to GPLed software and make available your product's source code if you have directly tied your software to GPLed software). Determining when you have crossed over into GPL land can easily be a major problem, subject to interpretation.

In many ways, the success of the open-source movement is at the root of the problems surrounding open-source licensing. Many companies have wanted to proclaim their new-found appreciation of the movement (if for no other reason than that it makes for wonderful press releases), yet when rubber meets the road many find themselves unwilling or unable (because of their own licensing of other software) to make the leap fully into the GPL or BSD world. What course do they take? They pull a page from the open-source playbook and write their own license, of course! And of course, they all have their own stipulations.

One of the first to do this was Mozilla.org, the organization given the stewardship of the Netscape browser code when it was open-sourced. The precedent of the Mozilla Public License Version 1.0 has validated all of the other companies that have created their own licenses. The list includes such luminaries as IBM (IBM Public License), Sun Microsystems (Sun Public License), Intel (Intel Open Source License), MIT (MIT license) and even NASA (NASA Open Source Agreement). The de facto organization that reviews these licenses for conformance to the spirit of open source and then gives them a "seal of approval" if they are found worthy is the non-profit Open Source Initiative (OSI). On the OSI site, you can find a list of approved licenses and the text of those licenses. If you want some entertainment, pick a couple of them and read them over. While each license is a fairly easy read (one of the requirements of an OSI-approved license is that it doesn't require a lawyer for interpretation), a software package that you write using multiple open-source packages based on multiple licenses can cause you some indigestion; you need ensure that you meet the requirements of all of the licenses involved.

Notably missing from the list of OSI-approved licenses is Microsoft's "Shared Source Licenses." It's not that these don't meet the requirements as much as it is that the OSI and MS have had a shaky relationship and MS has not submitted its licenses for approval. Having read over the MS licenses, I can say that they are no better or worse than those on the OSI list, depending upon your needs. Not surprising to me was that some MS variations provide for licenses to be valid only on the Windows platform. I'm not sure how that fits in with the true spirit of open-source software, but if everyone else is customizing their view of open-source, why not MS, too?

I can't help but feel that the proliferation of all of these licenses can only lead to a slow-down in open source. Movements are afoot to clean up the mess, and if you read much of the material coming from the community, you'll see that the call to apply the KISS (keep it simple, stupid) principle to licensing is getting louder. And just as you think things will start improving, you'll note the hype surrounding GPL Version 3 that seems to pervade much of the headlines of late. In a nutshell, the big issue surrounds DRM (the acronym for Digital Rights Management, or Digital Restrictions Management if you're a card-carrying member of the Free Software Foundation as I am). On the one hand, you have the FSF, which believes DRM to be Satan's spawn, and on the other hand, you have the pragmatists (including Linus Torvalds) who realize that some allowances must be made for things such as Apple's iPod and high-end graphics cards if Linux and other open-source products are to gain acceptance from a wider audience.

Where will all of this end? I don't know. I strongly believe in the open-source model, and apparently many corporate entities do, too. It's just that all of our views of what it should look like differ. Many packages are available that are too compelling to ignore, yet the burden of employing them can be nasty. Until the open-source market gets the license morass drained, all I can offer is the suggestion to put on your muck boots and slog through. And please, don't write your own license!

Barry L. Kline is a consultant and has been developing software on various DEC and IBM midrange platforms for over 23 years. Barry discovered Linux back in the days when it was necessary to download diskette images and source code from the Internet. Since then, he has installed Linux on hundreds of machines, where it functions as servers and workstations in iSeries and Windows networks. He co-authored the book Understanding Linux Web Hosting with Don Denoncourt. Barry can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..