The Open Source initiative has, to date, approved 73 licenses. How many do you really need? If you're a company or individual producing Open Source software, no more than 4. And you can get along with just 2 of them.
But the fact that there are 73 licenses is a problem. Many of those licenses are incompatible with each other. To understand the legal implications of mixing software under two of those licenses together in the same program, you'd have to learn 5256 different combinations!
And the worst thing about this is, it's my fault! Well, partially. When I wrote the rules for Open Source licensing in 1997, as a policy document of the Debian project, not many people took what we then called Free Software seriously, and it was unthinkable that 73 different licenses that complied with my Open Source Definition would ever be written.
Fortunately, you don't have to deal with many of those 73 licenses. When you need to distribute or modify software that is under one of them, you'll need to understand that one. And folks who are just users get off easy: you don't really need to read an Open Source license just to use the software, because the rules I wrote require that the license give you the right to use Open Source software for any purpose.
Understanding licenses isn't really an Open Source issue. Most software is copyrighted and under some sort of license, and the licenses on proprietary software are much more pernicious than those on Open Source.
But most companies, even large ones, aren't yet completely able to cope with the implications of software licensing. At your next departmental meeting, ask how many people have clicked Yes on a license of a web site or software application while at work. Then, ask how many of those folks are authorized to enter into a contract on behalf of the company.
See the problem?
To understand how many Open Source licenses you really need, it's important to set some goals. First, the licenses must all be compatible with each other. There's no point in licensing your own company's Open Source so that its not compatible with other Open Source from your company. And second, the licenses should fulfill the various different business purposes for Open Source.
Open Source has business purposes? If you're a business. The two main ones are:
For example, if you're creating a standard that you'd like everyone to use regardless of whether their own software is Open Source or proprietary. Some years ago, a manufacturer of circuit design software created a standard file format for circuit designs, and distributed Open Source software that circuit chip foundries could use to read that format under the BSD license, which has no significant restrictions.
Because the company's competitors could also use the same format with their software, the foundries had an incentive to implement the format and simplify their operations. Thus, the circuit design software manufacturer was assured that their software's output would be usable with essentially all chip foundries.
About 14 years ago, I created the Busybox embedded systems toolkit for Linux. I put in a month's worth of evenings on the project, which was to build a command-line environment that would fit on a single floppy disk, for the Debian GNU/Linux distribution's installer. I released the product under the GPL license.
Subsequently, embedded systems companies adopted Busybox because doing so gave them some time-to-market advantage in putting their product offerings together: they wouldn't have to re-do my work. Because I'd used the GPL, their extensions to my software had to be under a GPL-compatible license too, and had to be made available in source-code form.
The various embedded Linux companies shared that work with each other and the entire Open Source community. At least 5 person-years of work have been added to that program, and all of that work is available for anyone to use. Had I used a license without the share-and-share-alike provisions of the GPL, those embedded companies would have kept their additions to themselves as proprietary software. And that wouldn't have done them much good, because Busybox wasn't business-differentiating for those companies.
One of the ways around the issues of security and control that make some businesses wary of cloud computing is to build a private cloud -- one that remains within the corporate firewall and is wholly controlled internally. Private clouds also increase the agility of IT an organization's IT infrastructure and make it easier to roll out new technology projects. Download this eBook to get the facts behind the private cloud and learn how your organization can get started.