Commercial Developer’s Guide to Open Source Licenses
Many commercial developers are becoming more interested in marrying Open Source with their commercial .NET, Java and legacy assets. But, navigating Open Source licensing can be confusing for enterprise developers, as there are more than 40 licenses approved by the Open Source Initiative (OSI) to chose from. On the eve of the O'Reilly Open Source Conference, IDN talks to some famous Open Source execs to get a rundown on the most popular licensing options.
Many commercial developers are becoming more interested in marrying Open Source with their commercial .NET, Java and legacy assets. But, navigating Open Source licensing can be confusing for enterprise developers. And, why not, with more than 40 licenses approved by the Open Source Initiative (OSI) to chose from?
On the eve of the O'Reilly Open Source Conference, IDN talks to some famous Open Source execs to get a rundown on the most popular licensing options.
Where does a commercial developer begin? Keep in mind that while there are dozens of licenses, it's just a handful of "classic originals" that attract most developers. The history and longevity of these licenses make developers and customers comfortable with their usage.
OSCON Alert: IDN wants to know if you or others in your firm are attending O'Reilly's OSCON 2003 (Open Source Convention) in Portland, Ore. July 7-11. If you'll be there, drop our editors a note to tell us what topic(s) you're interested in, and if we can contact you about future stories looking at how devs are integrating Open Source into their web, Java, .NET and legacy systems. Email us at email@example.com. Thanks.
The GNU General Public License (GPL) is by far the most popular. GPL licenses are designed to ensure developers have the freedom to distribute copies of free software (with an option to charge for the service), make the source code freely available, and allow other developers to change the software or use pieces of it in new programs.
One of the GPLs advantages is its tendency to attract a community that finds bugs, makes contributions and enhances the original program. That's one of the primary reasons why Marten Mickos, chief executive of MySQL AB, chose it.
"We wanted a license that was easy for everyone to understand and wouldn't create any doubt or unnecessary questions from customers," Mickos told IDN. "The GPL was the most acknowledged license at the time and it served our purposes technically, as well."
For Web Den Interactive, the GPL opened more doors while also providing protection. " The biggest benefit of GPL is that it prevents other companies from profiting from our work without our knowledge. They can't integrate it with their product and start to distribute it without talking to us."
The problem with the GPL arises when you modify the code and redistribute the larger set, triggering a forcing clause that mandates releasing those changes back into the community. "The language in the GPL is a little ambiguous and doesn't draw a bright line between which activities trigger this forcing clause and which ones don't," Brian Kelly a partner in the Washington, D.C. office of Fenwick & West LLP told IDN.
The GNU Library or Lesser Greater Public License (LGPL) attempts to address that concern. It was written to enable proprietary software vendors to use some products on a limited basis without triggering the forcing clause.
Marc Fleury, president of JBoss Group, initially released its product under the GPL but switched to the LGPL. "This license protects us, while at the same time allowing for end users to distribute our product under the LGPL without propagation, which is one of the common criticisms of GPL software," says Fleury. "We view it as the best of both worlds."
BSD boosters claim this license is more commercially friendly than the GPL-like licenses because it allows users almost free reign with the code.
"When you revise the source code, you don't have to release it when you distribute the software, " Rick Statile, an attorney with the law firm Kilpatrick Stockton, told IDN. "That sometimes makes BSD more attractive for developers because it eliminates the forcing clause."
But that is also where its critics focus their attention. Fleury says he considered the BSD license, but decided against it because his company is in an extremely competitive field and BSD allows competitors to take without giving back.
Other Options -- Artistic, MIT and Mozilla
The Artistic license and the MIT license are also classics. However, OSI president Eric Raymond told IDN that the Artistic license is beginning to fade from view: "A lot of people have noticed that it's a very vaguely written document and even the Perl people don't really recommend it anymore. "
The Mozilla Public License, which is much like the GPL but with trademark considerations, is gaining momentum. But beyond the classic originals, most of the licenses stem from dissatisfaction with one or more of the distribution terms in the GPL.
Many developers have created their own license terms, but experts don't recommend this approach in most cases because it makes customers a little nervous. Fenwick and West's Kelly recommends keeping an eye on two newer licenses, the Academic Free License and the Open Source License, that address some technical drafting problems found in older licenses.
Various vendors, including Microsoft, IBM and Oracle, are offering a growing number of "shared source" options. Under shared source, the vendor opens up access to underlying source code to the customer/end-user community while protecting the underlying IP (intellectual property) by imposing certain rules on how devs can add code to the code base and share/sell those modifications.
While it might sound like a way to balance the needs of users and developers, experts say that for start-up Open Source projects, shared source poses a risk. "Shared source is a new entity that's corporate-driven and doesn't necessarily jibe that well with the history and tradition of the Open Source movement itself, " says Kelly. "That seems to be the big risk. "
But, at the end of the day, however, OSI's Raymond advises would-be Open Source devs and project creators to "just relax" and not get hung up on keeping your code secret.
"A lot less of your product value is in its secrecy than you think," he says. "For most products, even if the source code is generally available, people other than the original developers are rather poorly positioned to exploit it."