Gilles Gravier's Weblog

Chosing the right license in the open source world

So you are now ready to start creating a product. This product will contain software. Software you will write, or have already written, but possibly also third party software that you will bundle with your own code, and maybe some hardware.

You need to start thinking, very early on, about a crucial element when using software.

Licensing.

You may already have made the decision on whether your software will be commercial or free, closed source, or open source... but you need to look at licensing issues in at least 2 very important places, in particular if you plan to include open source software.

• How do you plan to license your own software within your product 
• What license applies to the third party software you are bundling and how does it interact with, or impact your own software 

Many people tend to associate open source with only the freedom aspect it brings. But it also comes with a serious amount of obligations and responsibilities.

Selecting the right license is the work of licensing experts and lawyers. But I'll try to give some ideas on how to go about making reasonably good choices in this area.

First things first. The Open Source Initiative has a definition of what an open source license is. This definition is available at : http://www.opensource.org/docs/osd/. They also do the complex task of reviewing popular open source licenses and listing the ones that match the definition. This list is at : http://www.opensource.org/licenses/. It provides a basis for selecting licenses from, at least, a limited list.

So what is that makes an open source license. Let me start by quoting the 10 points of the Open Source Definition mentioned above :

---

The Open Source Definition

1. Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

4. Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.

5. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons.

6. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

7. Distribution of License The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

8. License Must Not Be Specific to a Product The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

9. License Must Not Restrict Other Software The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

10. License Must Be Technology-Neutral No provision of the license may be predicated on any individual technology or style of interface.

As you can see, that's a pretty strong definition. Lots of things that must be done, and lots that can't be done, if a license is to merit the qualification of open source.

Not everything can be called open source. Good thing there is a definition.

So. How do you pick the right license for you? What are the implications?

Well, there are 3 main types of licenses available to pick from.

Type A licenses, also refered to as “attribution licenses” are the ones with the fewest requirements. They allow unrestricted development of derived works. You can typically use type A licensed code in any way you like, embedding it into other applications with almost no constraints. Example type A licenses include the popular Apache or, the very simple, yet effective BSD (example from the FreeBSD project) license. One of my favorite ones (which I have yet to see used in common software is the WTFPL “Do What The Fuck You Want To Public License”.

One of the aspects that I've noticed about type A licensed projects is that despite the fact that the license doesn't mandate that derived works should be submitted back to the original project, they tend to generate a strong community feeling in the user / developer community and people still do contribute back to the original source commons. Which goes to show that you don't have to force people to contribute for them to do so.

Type B licenses are the ones that are normally considered as community fostering licenses. The point of these licenses is that when you take code from such a project, you have to contribute back to the project any chance you make to files from the project. You are free to add any new file covered by any license you want (as long as that license of yours doesn't conflict with the normal licensing of the original project files), but any existing file that you change needs to be contributed back to the project if required. Example type B licenses include Sun's own Common Development and Distribution License (CDDL) which covers OpenSolaris.

Many developers use type B licenses when they want to embed some open source project (say, an operating system) into a bundle (could be an appliance) which is licensed differently. Doing so, they have to keep the original open source project with its license, and thus, with source code available, even if they do modifications in the project files. But they can add their own files, drivers, applications, glue and keep those licensed as they want (even, possibly, commercially licensed).

Finally, type C licenses which tend to be project fostering licenses, are such that like type B, any file you modify from the original source commons keeps the original license, but also, any file you add to the project inherits that project's license. These license inherently seek to propagate open source by, in a way, contaminating what they touch. They are often qualified as viral licenses. Should you bundle your own software with a type-B licensed project, your own software automatically gets contaminated and turned into a type-B licensed code for which you also will have to publish source code as defined in the original project's license. This is great when you want the project community to benefit from any derived works built upon that project. But it can also have the side effect that people using code from these projects are forced into publishing their own intellectual property. Examples of type C licenses include the universally known GNU General Public License (GPL) which is used for example for the Linux kernel. Anything tightly bundled with a Linux kernel has to be licensed under the GPL as well.

In order to make this contamination aspect less constraining, there is a derived licensed based on the GPL called the GNU Lesser General Public License (LGPL). It is possible to link through specific means software to an LGPL licensed project without that software being contaminated by the original license. This enables one to bundle an LGPL project with non LGPL code and keep the licenses different for each part of the bundle. OpenOffice.org is licensed under the LGPL, enabling one to plug pieces of code into proper APIs in OpenOffice.org and keeping these plugins licensed the way initially planned.

A typical example of unplanned contamination would be an appliance vendor that makes small consumer devices that sell in hundreds of thousands of units. In order to limit costs, they elect to use a standard chip set that provides the basic functionality directly, then they pick the operating environment to put on it. For costs and simplicity, they pick en embedded Linux platform. Then they develop their own code and glue. They write device drivers for custom hardware, they write a complete GUI that directly plugs into deeply embedded aspects of the operating system, and device configuration, and they sell the whole thing as a consumer appliance. The problem is when somebody figures out that it's Linux inside... and since Linux is covered by GPL, that means that all the software that is deeply linked to the OS is also, necessarily, made GPL. First of all, they have to make the whole source code available (as per GPL, and any other open source license)... but worse, if they embedded other third party code, they can get into legal issues because that third party tool probably also must be made available under the GPL. It can get nasty. Because they didn't consider the implications in advance.

On the other side, sometimes, you WANT to use a viral license like the GPL. Sun has published the OpenSPARC processor under the GPL exactly with that viral aspect in mind. We want other companies to build fancy, successful, commercial products based on the OpenSPARC processor. We want them to not only benefit from the R&D we did to come up with the OpenSPARC processors, but also, we want them to bring their own enhancements, and contribute back to us the good work they throw into the processor. We want the next hot microcontroler based on OpenSPARC to benefit the whole OpenSPARC development efforts.

So as you can see, there are several types of licenses, each with very distinct characteristics. Choosing one isn't something you do lightly.

In order to choose the right license for you, you must first decide what you want to do with your own project. Deciding if you want to make it commercial, or not. Closed, or open source. You need also think about how you expect your users, and possible developers down the line might want to use or reuse your code into their own projects.

Then, if you are going to bundle your code with third party code, you must carefully examine the license you want for your code, and the available third party projects that fit your requirements and their own licenses. Make sure the one you pick has a license that is compatible with your selected license to avoid legal issues down the line.

As you see, choosing proper open source licenses (in products you will use, as well as in products you will develop) is not necessarily an easy task. Following the above guidelines will help you get a general idea. But probably the best single advice to give is to talk to a lawyer specialized in software licensing. They will help you pick the right license that is best for the model you have in mind for your product. Also, people like the FSF organize licensing workshops. For example, the FSF Europe is running a 'Licensing questions and other legal issues' workshop in Zurich, Switzerland on October 17th, 2008. There may be others in your region to chose from.

Posted at 07:03PM Jul 23, 2008 by gravax in Opensource  |  Comments[1]