Open source licensing gives you the freedom to deploy software for whatever purpose you want, even to tinker with its internals or to build complex systems with components from different developers. That's great for pilot projects and research, but when it comes to enterprisewide deployment, those same licenses can become a hindrance.
Although open source is most famously associated with the GNU General Public License, the GPL is hardly the only choice available. As of this writing, the Open Source Initiative (OSI) has approved 58 licenses as having met its definition of open source.
This proliferation of licenses can be a significant problem for corporate legal departments, according to Stuart Cohen, CEO of Open Source Development Labs (OSDL), the nonprofit advocacy organization that employs Linux creator Linus Torvalds.
"If you're the user, you have no choice," Cohen explained in a recent phone conversation. "You pick a set of solutions you want, and you're forced to go through the due diligence of all the licenses. Your other choice is to eliminate pieces that have unique licenses, but now you're getting away from your solution."
And customers aren't the only ones affected. According to Cohen, services organizations such as Capgemini, EDS, Hewlett-Packard Global Services, IBM, and Oracle have to deal with managing this abundance of licenses when providing solutions for their clients. "It's a cost for everyone," he told me.
Eric Raymond, author of The Cathedral and the Bazaar and co-founder of OSI, also chimed in, pointing out how too many licenses can lead to integration headaches. "Having lots of licenses means there are lots of ways licenses can rub up against each other when code is mixed and recombined. This creates edge cases in which people don't clearly know what their rights and liabilities are," he said.
The open source community, including OSDL, OSI, the FSF (Free Software Foundation), and a number of software vendors and customers, has been discussing the need for license consolidation for nearly a year. Cohen feels that in an ideal world there should be no more than six or 10 licenses that cover 80 percent of the projects out there. And yet no clear solution is in sight.
According to Raymond, OSI is considering assigning certain licenses "Preferred" or "Best Practice" status and steering projects toward them. But that policy doesn't seem likely to dissuade companies that have evaluated available licenses and have chosen to create new ones anyway. For example, Computer Associates announced its own license last year, and Sun Microsystems revealed still another in January.
Raymond refers to such company-specific licenses as "corporate vanity licenses," but Cohen disagrees. Given the cost of drafting and maintaining a new license, he says, there's more to it than that. As proof, Cohen offers the fact that CA and others have indicated their willingness to work with the community to create standardized, corporate-friendly licenses.
"The most important news is that the big vendors are interested in getting together to talk about how we can work together on this, as well as members of the development community and the users," Cohen said.
That last part is key. As users and customers of open source, it's up to us to explain how license proliferation affects our ability to bring solutions to market quickly. That's a message that major sponsors of open source projects will understand. Voice your concerns to your vendors; let the industry know we want a simplified playing field for open source licensing.