eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Recent moves by such companies as Sun Microsystems and Computer Associates to dip their toes into the world of open source have reawakened interest in how open-source software licenses work, and what benefits they bring to software companies—if any.
When companies such as Sun talk about making important products open source, what theyre really interested in, say industry observers, is the open-source business model—the model that has allowed Red Hat, Novell and others to draw on the efforts of thousands of Linux developers around the world. Linuxs GNU GPL (General Public License) has some requirements that wouldnt be acceptable to many businesses, so over the years alternative versions have been created that allow companies more flexibility. Some of these, such as the MPL (Mozilla Public License), have become popular templates for companies wishing to draw on open-source developer resources while retaining the ability to sell their products in a conventional commercial environment.
Two factors limit the options of commercial software makers when they decide to switch to an open-source license, analysts say. One is whether they want the open-sourced code to integrate with software using other types of licenses, something thats difficult or impossible under the GPL. The other is that companies often dont own all of the code in their products, so that the GPL is often out of the question. This is the case with Solaris, for example, which uses code licensed from The SCO Group.
So what exactly can be called “open source”? The Open Source Initiative, which invented the term in the first place, maintains a definition of what constitutes an “open” license, and lists those that fit the definition; the detailed list can be found on the groups Web site. The basic idea is to give developers a stake in the software, not just by allowing them to look at the code, as in Microsofts “shared source” scheme, but by letting them modify and redistribute it as well. Therefore, an open-source license must not, for example, restrict redistribution and must allow modifications and derived works.
Within this definition, however, there are a wide range of possibilities. The main difference between the major types of licenses is whether they allow derived works to be returned to proprietary form, and whether they allow integration with other types of licenses.
Page Two
The GPL, first released in 1989, has become one of the best-known licenses because of its association with the Linux operating system. A distinguishing feature is that it requires derivative works to be distributed under the GPL, thus ensuring that once software is released under the GPL, it will remain open source permanently. In addition, works that contain GPL software must be themselves released under the license; if Microsoft wished to include a GPL-licensed utility in Windows, the entire OS would need to be made open source. “If you want to avoid having your software picked up and used in commercial products, then pick the GPL,” said Bill Claybrook, president of research firm New River Linux & Grid Computing.
These provisions created problems for software libraries, leading to the creation of the LGPL—originally known as the Library GPL, its now generally referred to as the Lesser GPL. Under this license, the libraries themselves and any derived works must be distributed under GPL-type provisions, but software that merely uses the libraries can use another license.
On the other end of the scale is the BSD (Berkeley Software Distribution) license, developed in 1977: It suggests, but does not require, that modifications to source code be returned to the developer community, and allows derived products to use other licenses, including proprietary licenses. BSD-licensed code can also be contained in, or can contain, code that uses other licenses. The flexibility of this license has allowed companies to create proprietary products based on BSD code—Mac OS X, which is based on BSD Unix, is an example. The license is useful for companies wishing to encourage the broad adoption of their software in both the open-source and proprietary worlds. The MIT license is similar to the BSD license in its effects.
Other licenses—and there are many—fall between these two poles. The MPL, developed in 1998 when Netscape made its browser open-source, contains more requirements for derivative works than the BSD license, but fewer than the GPL or LGPL. AOL mixes MPL-covered components with proprietary software in its Netscape browser. Companies open-sourcing existing applications often create customized licenses, as Computer Associates has done with its Ingres database and the CA Trusted Open Source License. This allows third parties to incorporate Ingres into existing products, as long as the Ingres source is included with the product. Another popular scheme, adopted by MySQL, Trolltech, Sleepycat Software and others, is to release software under two licenses—usually the GPL and a commercial license, according to Claybrook.
Next page: Developer interest.
Page Three
Sun has hinted that it might use the GPL for open-sourcing Solaris but, for a variety of reasons, is more likely to use a less restrictive license, or to create its own. Its hands may be tied: SCO last week asserted that Suns licensing rights to SCOs Unix System V intellectual property may be broader than those of any other Unix licensee, but arent broad enough to allow them to release SCOs intellectual property under the GPL.
Sun has said that a licensing deal with SCO last summer has cleared the way for its open-source plans, but it remains in question whether the licensed components of Solaris will be available for the creation of derived products. If not, whatever Sun ends up releasing might be of limited interest to developers, analysts said.
And attracting developers is the whole point: Theoretically, an open-source license will attract a developer community that then pushes the product forward more quickly and at lower cost than would otherwise be possible. This promise has been realized in the most successful open-source projects, such as Linux, argues Claybrook. “The economics of open source are just too overwhelming to not take advantage of,” he said. “Eventually, Microsoft will have to have open-source software in its software stack, or it will not be able to compete.”
However, success isnt guaranteed, and most of the time adopting an open-source license wont have any positive impact for a software company, say some. “For the most part, in my opinion its a fallacy that that will happen,” said IDC analyst Al Gillen. “The concept is that developers will look at the source code and say, Wow, Ive got to go work on that. But an individual will only contribute to a project if it will offer some benefits to them somewhere down the line. People arent going to work on it unless they have some reason to care about it.”
This isnt necessarily the case with Ingres, which CA open-sourced after it failed to make the desired impact on the database market, or even with Solaris. While the company considered its options for four years, Solaris on the x86 architecture ceded much of its market share to Linux, analysts noted. “I dont think that (Sun) will gain the advantages that they would have if they had open-sourced [Solaris] in 2000, when they first started talking about it,” said Claybrook. “You have to have a community of users, and more importantly developers, to make a go of it with an open-source project.”
Check out eWEEK.coms Linux & Open Source Center at http://linux.eweek.com for the latest open-source news, reviews and analysis.
Be sure to add our eWEEK.com Linux news feed to your RSS newsreader or My Yahoo page