By: Blane Warrene

March 9th, 2005

Reader Rating: 8.5

The decision to choose an open source license can mean different things to different people. Those considering the issue from an end-user perspective may feel that the decision is irrelevant: the equivalent of a commercial click-wrap license that generally also goes unread. For this kind of user, the software simply represents a more economical or more productive path to complete a task or obtain functionality.

Licensing is more critical for developers. The beauty of the open source license is its assignment of copyright (and patents, if held by the author) to the end user and re-distributor without compensation. Thus, for example, the Web professional can leverage an application at no cost, use it in the course of commercial business, and profit by it in interactions with their customers.

Often, in the course of their work, developers discover that the software doesn't quite meet their needs: it lacks a given capability. To resolve the problem, the developers may decide to build new functionality. This is the epitome of the open source license: there are no strings attached! The new, modified solution can be redistributed under the original license (or separate from it, as we will see shortly) depending on the license selection.

The result of this exercise is that hundreds of new open source software packages are available at large. The bad news is that some of these packages may run the risk of infringing upon patents of which the software authors were perhaps not aware.

This possibility, coupled with concern over evolving intellectual property (IP) issues and liability, has become a recipe for developer confusion, especially since a broad list of different open source licenses exists. The process for choosing a license, reviewing code and launching a product without liability concerns becomes more vexing as the open source atmosphere expands.

The Licensing Conundrum

When a developer is considering his or her options for open-source licenses, the first stop should be the Open Source Initiative (OSI) [1]. The group maintains the definition of open source software and certifies licenses that adhere to it. Drop by the site and you will find descriptions of more than 50 licenses.

Recently, questions have arisen as to whether some licenses should be consolidated, though some, such as the Academic Free License, serve niches. Eric Raymond, cofounder and president-emeritus of the OSI, suggests that many of the licenses the OSI lists are essentially individual or corporate vanity projects.

"Only about half a dozen are in any wide use," Raymond told LinuxInsider. "We are mulling ways to push back against further proliferation, but up to now it's been our policy not to reject licenses that fit the OSD even if they are duplicative. That may soon change."

Before we go further, let's step back and see just how a license becomes, well, a license.

How is a License Born?

Raymond's organization vets proposed new open source licenses with a battery of reviews and discussions.

"We look for conformance to the ten points of the Open Source Definition [2]. We have lawyers, and legally savvy non-lawyers, chew over the license on license-discuss. The board considers their recommendations and votes," he said.

Most recently, Sun Microsystems contributed the Common Development and Distribution License (CDDL), through which the company released its Open Solaris. Sun officials have said they chose to opt out of existing licenses so they could build in patent protection for users of the new Solaris platform.

For his part, Raymond does not always believe there is good argument to release new licenses, even if the company is big.

"Most new licenses are exercises in monument-building by corporate legal departments with too much time on their hands," he said. "Occasionally you'll get a license that addresses the underlying legal issues in a genuinely new or interesting way. But that was never common and is now extremely rare."

The Licensing Lowdown

While no formal public tally exists, recent research measuring open source license use has been completed independently and shows that an overwhelming two-thirds majority of open source projects utilize the GNU General Public License (GPL). Following the GPL is the Limited GPL (LGPL), the Berkeley Software Distribution (BSD) and Mozilla licenses.

In distilling the many licenses, a recent book, Open Source Licensing [3], by legal expert Lawrence Rosen broke down a taxonomy of licenses to help categorize them. This also helps developers reduce the time it takes to research different license types for their software.

The current fifty-plus licenses maintained by the OSI fall into four distinct types:

1. Academic Licenses

Representing the most 'free' of open source licenses, Academic licenses place no requirements whatsoever on the license user -- there's not even a requirement for the user to share modifications or redistribute them. Licenses in this category include the BSD, MIT and Apache licenses.

Academic licenses are designed to provide absolute freedom. The only marked restriction is that these licenses prohibit the leveraging of the original licensor's name as an endorsement in marketing efforts. Other than that, these licenses are truly intended for those who seek complete control over the software, its use, modifications, and subsequent re-releases independently or with another software package.

The BSD, granddaddy of open source licensing, originated within the University of California to grant the free use, modification, and distribution of software built within the institution. It has since become a public license available to open source developers.

The MIT was created by the Massachusetts Institute of Technology as a rewrite of the BSD license. The Apache license differs from the BSD and MIT only in its requirement that a notice be included in either documentation or source code of modified works to identify that the new distribution contains software created by the Apache Software Foundation.

2. Reciprocal Licenses

Like other licenses, Reciprocal licenses grant complete rights to the software's use to the developer and end user. The single difference lies in the requirement that any derivatives of the software be released under the same license, and that the source code must be released. The resulting new software must also be free.

The intent of reciprocity is to ensure that a growing universe of free software emerges, and that original works -- as well as modified and new efforts -- remain free to users. Some of the most popular software available today remains free and accessible due to its use of the GPL including Linux, MySQL, the Bash shell, Mailman, gzip and grep.

The centerpiece of this category is the GPL, which was last updated in 1991, though it is expected to be refreshed this year by original authors Richard Stallman and Eben Moglen, with input from the open source community at large. The Mozilla Public License also resides in this category.

3. Standards Licenses

Standards licenses seek to create a base standard of software and documentation. Modified and redistributed sources usually have to be distributed as patches, so as to not modify the core.

For example, imagine a situation in which a Web application is created to allow importing and exporting between the various popular blog applications. A Web developer grabs the source of this new software and builds in an additional function to migrate and convert specific design elements along with data. Under a standards license, the core app would be distributed with a plug-in to enable the latter new capability.

The goal of a standards license is to preserve an existing code base so that the originating author can come back to it and evolve it without difficulty. In some cases, plug-ins will not be affected. In others, the original author will update documentation to allow third-parties to update their plug-ins (often also called patches).

4. Content Licenses

Finally, Content licenses cover elements aside from code, such as art, copy and audio/video. Those familiar with Creative Commons [4] will recognize this license, although a few are listed at OSI, including the Academic Free License.

One caveat with Creative Commons (CC) licenses is that if a Share-Alike attribute is included in a CC license, it makes the license reciprocal, similar to the GPL.

Intellectual Property Concerns

In understanding the licensing process, it's important to distinguish between copyright, trademark and patents. All of these elements play a role in the software we use every day. In some cases, the freedom from patent risk has been included in the license (as in Sun Microsystems' CDDL and, to some extent, others).

However, as Rosen makes clear in his book, many of the licenses protect users from patent requirements of the original software, but cannot necessarily extend that protection once you modify and redistribute the source code or binary.

That said, simplicity remains the core appeal of open source -- find an application that meets a need, download, install, and start using or developing with it.

Organizations like Sourceforge [5] accelerate that process. Sourceforge could be considered the Creative Commons of open source software projects, hosting more than 90,000 open source projects with over one million registered users. It is a popular destination to which multitudes of open source developers and users go to find software. Sourceforge will only host a project using one of the OSI-approved licenses.

This alone is no threat. However, IP and license considerations become critical if source is being modified, packaged into another solution, and distributed.

A cottage industry is brewing just for this purpose, with companies such as Black Duck Software (see this post in Open Sourcery [6]) hoping to capitalize on developer concerns over the creation, use and distribution of open- and mixed-source code by proposing code review solutions. This can be a costly proposition to some and, according to Raymond, may make complete compliance impossible.

"With as much copyrighted and patented code as there is in the world, positive assurance by review is effectively impossible," he said. "The best you can do is make sure your code doesn't have someone else's explicit copyrights in it, and that's not nearly good enough."

Due Diligence

Reviews are carried out regularly, primarily for the purpose of showing due diligence.

Raymond thinks the only strategy that makes sense in the crazed and toxic environment created by modern IP law (especially patents) is to complete just enough of a pro forma review to have on the record that a review was carried out, then basically ignore your risks until and unless you are sued.

"And this is exactly the advice patent lawyers will give you. You don't 'want' to know what patents you may be infringing in advance -- that makes it 'willful' and trebles the damages," he said.

"Yes, this is crazy," he admitted. "It reflects the fundamental insanity of modern IP law."

In recognition of today's evolving IP issues, the GNU General Public License -- one of the most widespread variations -- will be refreshed for the first time in thirteen years. The revision is expected in 2005. However, Raymond suggests developers need not hold off in selecting a license in order to wait for the new GPL as currently, it is essentially vaporware.

Reducing the Risk

Policy makers, attorneys and judges will end up guiding an archaic set of IP laws into the 21st century. The direction this process takes may depend on individuals' and organizations' understanding of open source.

While the OSI carries out a little advocacy for policy makers on open source and the state of intellectual property, according to Raymond, "Our main focus has been on selling the idea to businesses in the belief that they would then sell it to government. There are more politically focused groups we cooperate with, such as OSIA (Open Source Industry Alliance)."

In the meantime, developers are left to pore over licenses and select one on their own. While expensive legal advice can help, others may take a gamble when choosing a license on which to stake their code.

It's important to understand the impact of choosing your license. As you have seen, each license category has its own particular purpose, whether it's to ensure end-user freedom, prevent commercial use, or preserve a standard code base.

Users can switch licensing schemes after they've made their selection and distributed software; however, the issue of existing code and license agreements is murky when it comes to making such a change. These unproven waters mean that developers need very carefully to select a license they can live with for the long term.

For example, if a developer foresees only selling support and customization services over the long term, choosing a reciprocal license that may prevent the sale of the software itself would be sufficient. However, if there's a chance that a future application may become partially proprietary while including original or modified open source, an Academic license may be a better route.

Can developers expect a tool that simplifies license selection from the OSI anytime soon?

Raymond would only say, "Not yet. We're working on that."

[1] http://www.opensource.org/
[2] http://opensource.org/docs/definition.php
[3] http://www.phptr.com/title/0131487876#
[4] http://www.creativecommons.org
[5] http://www.sourceforge.net
[6] http://www.sitepoint.com/blog-post-view.php?id=170388