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.
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 :
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 : Unrestrictive licenses
- Type B : File-based licenses
- Type C : Project-based licenses
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.