Introduction

So far in this series I’ve explained how the open source community works and some of the principles you should adopt to ensure that your business as able to successfully use open source software, either by starting new projects or by consuming or contributing to existing projects.

In this final article I’ll move on to a topic that’s more theoretical but which you need to have a good understanding of if you are going to use open source software in conjunction with your own proprietary software: Licensing.

You’ve probably never cared about that text where you have to click on " I agree " in the Windows Installer. Well, if you’re getting into open source, you should start caring. At least a little. If you thought that open source is somehow anti-copyright, you’re in for a surprise. Open source actually relies on the copyright system, using licenses with real legalese language. But where traditional software licenses are mostly concerned with forbidding a lot of things, an open source license is more concerned with ensuring that the software can be distributed as freely as possible.

The rest of this article is important for developers who will be contributing to, redistributing, or reusing open source software. If you just want to use open source software out of the box, you can probably continue downloading, installing and clicking on I agree without worrying about the license details.

In order to understand licensing it’s probably worth taking a minute to understand more about the definition of what constitutes open source software. So I’ll deal with that first.

The Open Source Definition

So what does it take to be open source? The Open Source Initiative is an organisation that tries to answer this question. At the OSI website you’ll also find the Open Source Definition. The OSD – which actually is based on the Debian Free Software Guidelines – is a set of principles that all open source licenses must fulfill. If you go and read it, you’ll have a good understanding of what it takes to be open source.

The most important requirements obviously deal with the terms under which you must make your application (or library, etc…) and its source code available, as I discussed in the first article of the series. There are some interesting things that you cannot do. For instance "No discrimination" clauses state that the license cannot forbid specific uses of the software, say to use it for launching nuclear missiles or by some oppressive regime or religious group.

The OSI is a rather self-selecting organisation which was set up in 1998 when the Open Source brand name was launched. (Would you believe that 7 years ago nobody had heard of Open Source and there was only "Free Software"?) Despite its lack of any kind of representative or democratic constituency, its function of determining whether licenses are compatible with the Open Source Definition is reasonably well respected. So a good rule of thumb is that if a license is listed on the Open Source Initiative website it is open source, otherwise it is not. But bear in mind that there are exceptions and that the OSI has no legal right to really define whether your project is Open Source or not. ("Open Source" is also not a trademark, by the way.)

The Open Source Definition itself is very widely agreed upon, and could be regarded as something like an Open Source constitution, including the fact that by now it would be very difficult to make any more fundamental changes to it.

Some Common Open Source Licenses

Licenses are important for a developer, but luckily you can very often get by without ever reading one. (I suggest you do read the licenses you end up using, but the information I will give you next is a good surrogate if you are absolutely against reading legalese.) The trick is to understand the distinctive features of the most common licenses, which will cover most of the projects you encounter. In fact, if you encounter some of the less used licenses, you will usually be able to find some explanation of how the license relates to the well known licenses, e.g: "The Affero license is like the GPL with the addition that Web Services too must publish their source code."

So when the project then says "Licensed under the GPL" you know everything you need to know already. By the way, licensing information is usually very prominent on Open Source projects’ websites and on SourceForge and Freshmeat the license can be used as a filtering criteria.

In this section I’ll introduce you to the licenses that are most commonly used in open source projects. This introduction should take you quite far, but if you are really interested in this topic, I might just as well take this opportunity to advertise a recent doctorate thesis by a friend of mine: The Rise of Open Source Licensing, by Mikko Vlimki (available as free download). It contains in depth analysis not only of the licenses, but also their economical implications and various business models seen in the Open Source world.

The GPL

The GPL , or General Public License is the most popular open source license. This is the license originally written by Richard Stallman and now governed by the Free Software Foundation. Richard Stallman is considered the one to have started what has now become the Open Source movement and he or the GNU project, which is sponsored by the Free Software Foundation, has created many of the command line tools used in Linux today, including many things that are also commonly the application of choice on many proprietary Unix platforms, like the Emacs text editor, the GCC compiler or the Bash shell.

The distinguishing feature of the GPL is that redistribution is allowed and will always be bound by the same GPL requirements, the most important of which is that source code always be made available. So if you release some source code under the GPL license, you’re guaranteed that wherever that code is used, the resulting piece of software will also be released on GPL terms, forever and ever. This has the positive and quite intended effect that the (GPL’d) open source codebase will start growing kind of like an avalanche effect.

Some things to note about the GPL:

The GPL doesn’t require you to give away your source code to everybody on the Internet. It requires that you give it to the recipient (think: customer) of your software.

The GPL in no way means you have to give away anything for free. You could very well sell your app for a million dollars under a GPL license. It does however follow, that you might have difficulties selling the same app to another customer for another million dollars, because your first customer now also has the right to redistribute it, and might offer it to the second customer for less than your price.

If you, or your company, is the only one who has written code for a certain GPL application, you own the full copyright for it. (In fact, even if there are outside contributors, you can require them to hand over their copyrights, or you won’t accept their code.) Therefore you can distribute it under whatever license you wish. Dual licensing is a business model based on this idea and has proved to be one of the most successful business models. As web developers most readers will have heard about the MySQL database, so it will be a good example. MySQL is available under two licenses. From the web you can download the GPL version for free. If you use that to build an application that uses MySQL as its database, you are then bound to also release your own application as GPL. But if you don’t want to do that, you can instead pay MySQL money for a license that gives you the right to distribute your app without being bound by the GPL requirements. So ironically, the GPL has turned out to be a favorite license not only for Free Software zealots, but also for companies doing business with closed source software!

On the other hand, for large collective projects like the Linux kernel, where more than a thousand developers each own the copyright to their pieces of the source code, it would be impossible to have them all agree (or even to contact them) on dual licensing it under some other license. Therefore such large projects really will be GPL forever, just like Mr Stallman had planned it.

The GPL and the LGPL (covered next), and some other licenses that also have this viral feature (you can think of the feature as viral because of the way it causes the license to spread with new software), are often called copyleft licenses. The term was originally coined by Mr Stallman, because he was trying to reverse the negative effects of copyright as he saw them. But nowadays it is a useful word to distinguish viral licenses from more open Open Source licenses (like the BSD or Apache licenses, covered later).

In 2007 the GPL will be updated to a new revision. More on this below.

The LGPL

The Free Software Foundation also has another license, the LGPL. Originally called the Library GPL , it is now short for the Lesser GPL . It is like the GPL in every way, except that it is better suited for – you guessed it – libraries.

With LGPL, the library itself must always be distributed with source code, including any bug fixes or changes you have done to it. But the applications using the library needn’t be, they can even be closed source. This is very convenient for a library that will be used by many different applications and their developers. And rightly so, the LGPL is used for the runtime classes of the Mono project.

Recently the LGPL has been criticised for its language being too specific to the way C/C++ is linked. Therefore some people claim that for modern interpreted object oriented languages the LGPL actually turns into having the same effect as the GPL. This is a technicality for sure and the intent of the LGPL is clear. But since this is lawyer territory we are treading on, people take these things seriously. Accordingly, the Apache Foundation has forbidden using LGPL libraries in its Java projects and also the Mono class libraries are now distributed under a Massachusetts Institute of Technology License ( MIT Licence ).

The BSD style licenses and the Apache license

The Berkeley Software Distribution Licence ( BSD license ) is a very short license that essentially says: "You can do whatever you want and there is no warranty" . While the BSD license was first used in BSD Unix from Berkeley, University of California there are also many other licenses that to all intents and purposes are exactly the same. Some of the most popular are the MIT license and the X license (originally used in the X Window system, the "Windows environment for Unix").

The difference between a BSD style license and GPL license is that a BSD license doesn’t require you to distribute source code. In fact it usually doesn’t require much at all.

Hence, you can even copy BSD licensed source code into any proprietary, closed source, commercial project you might be working on. In fact, a lot of code from the BSD Unix platforms has found it’s way into proprietary Unix platforms. For example there are reports that some small parts of Windows, notably in the TCP/IP stack, have been based originally on BSD code, though it’s hard to say if that’s still the case. See http://www.kuro5hin.org/story/2001/6/19/05641/7357 for a discussion. It is notable in this regard that Windows still has an etc directory under C:WINDOWSsystem32drivers .

Beware that sometimes a BSD license might contain one requirement: the advertising clause . If you use some "BSD with advertising clause" code in your software, you must give appropriate credit to the copyright holders of the copied code. A small detail you’d think, but a major Unix lawsuit was actually decided on this. (USL vs BSDI)

There are other licenses that also are very flexible as of their requirements, but their text is much longer, and they are therefore not said to be "BSD style". It’s kind of like a BSD license with more lawyer work gone into it. For instance, a license might include a detailed discussion about software patents. The Apache license and the Common Public License are popular such licenses.

Web service Licenses

A license that might be of interest to the ASP Today readership is the Affero General Public License. (And despite it being a perfectly good open source license, it doesn’t seem to be on the OSI list. There’s always an exception to the rule.) It is like the GPL, but with the added requirement that publishing the software as a web service also requires you to provide an opportunity for your users to download the source code. Despite the terminology used by Affero, the license is also intended to cover websites that are interactively used by users, not only XML Web Services. This covers a significant loophole in the GPL license: If you base your website on GPL code, it won’t really matter, if all you are going to do is publish it on your own webserver for your users to enjoy. As long as you are not distributing copies of your software to anyone, the GPL imposes no requirements of you in that regard. This also applies to inhouse company software.

GPL v3

The issue of GPL not covering Web services might change. When the Affero GPL was published the FSF said that the upcoming version 3 of the GPL due in 2007 will incorporate a similar Web services clause. On the other hand, recent speculation has it, that they might not go for it after all.

Another interesting issue that will surely be discussed before the new version becomes final is how to deal with software patents. Software patents could pose a serious threat to the whole Open Source process. Details are beyond the scope of this article, but in summary, the strength of the Open Source process is that it allows any teenager, student, hobbyist or small company to participate, while patents on the other hand can require tens of thousands of dollars just to get the patent and even millions if you actually need to defend yourself in litigation. Also the bureaucracy involved is alone quite incompatible with the distributed and low-administration nature of Open Source. Some open source licenses have tried to include a kind of patent termination paragraph as a defense, that you would loose your rights to even use the software if you initiate patent litigation against someone who has contributed to the software.

Since the GPL is by far the most popular open source license (it is the license used in the Linux kernel and most of the basic tools in a Linux distribution) any changes to it will affect a lot of both existing and future software. Therefore many people are now eagerly waiting for a first draft of the new version.

Mixing Code from Different Licenses

So what does this mean? To take a break from the legalese, I’ll now highlight some practical dos and don’ts.

You now know, that if you copy GPL code (or even use a GPL library or other module) into your app, you will have to release your own work as GPL as well. On the other hand, you can copy BSD code and still do whatever you want.

One interesting question is, what happens if you mix code from many open source projects? The answer is: there is a lot of gravitation towards the GPL. Since the BSD license is so flexible, the Linux kernel guys can copy code from FreeBSD, but the BSD guys cannot copy anything from Linux, nor any other GPL codebase for that matter. (Or they could, but then they’d become bound by the GPL and they don’t want that.)

Note that the original copyrights and license terms always stay with the code. You could go and download the Linux kernel sources, find the files that have been copied from BSD, extract those and use them under the BSD terms.

Many licenses are just incompatible, because they both have conflicting requirements. If some other license also requires that redistribution must happen on that licenses terms, it will not be compatible with the GPL that also requires redistribution on its own terms, no more, no less.

Let’s say you find some useful classes in an open source ASP.NET application, that is licensed under the GPL. You do not need the application itself, but the classes you are looking at could be of use in your own proprietary application. So you copy the classes into your own application, that is to be distributed closed source as a proprietary application. You figure that since the application is 1% GPL code and 99% your own code, the GPL doesn’t apply. Well, you figured wrong! As I’ve tried to explain, open source doesn’t mean giving away something for free and it doesn’t mean anyone is abandoning their copyright. The creators of open source software are not trading their code for your money, but they are often trading it for something. The GPL wants to trade it against your source code. The BSD advertising clause trades code against a moment of fame. If you cannot accept the terms the copyright owner is offering you, do not illegally copy someone else’s code!

Choosing a License for Your Projects

Now you have an understanding of the main open source licenses, let’s look at the factors that would determine what license you would choose if you are starting your own open source project.

There are many things to consider, but whatever your needs are, you should really stick to one of the most common licenses – probably out of the ones I have introduced above. Many licenses that have been approved by the OSI are only used by a few projects, which obviously disadvantages those projects from the point of view of user familiarity with the licenses. It makes life easier for everyone, if the license you choose is well known. The fact that some licenses are incompatible with each other, is also a good reason to stick to the popular licenses.

Reasons to use the GPL

There are two quite opposite reasons to choose the GPL. First, it is used by people with a strong ideological motive to promote the Open Source cause (or maybe at this point I should really say "Free Software cause"). The GPL is a very strong Open Source license. Code developed in a GPL project will stay GPL forever, and any work that builds on that code will also become GPL. Also, the GPL is often what you want even if you do not have a big ideological agenda. For instance you might not care about Open Source in general, but you really do not want to see someone ripping of your source code into their own closed source software.

Ironically, another reason to use the GPL is very commercially motivated: dual licensing. That means you provide – in exchange for money – an alternative license for those that do not want to accept the GPL requirements. Typically this model is good for libraries or other low level software, i.e. software that is used by other software. Dual licensing is not very usable for end user applications.

Reasons to use the LGPL

On that subject, unless you do have strong ideological reasons or want to use dual licensing, you typically will not want to use a GPL-like license for libraries and other projects that are not end user applications. As noted, the LGPL is a supplement for the GPL in that area, or a BSD style license will also work.

The logic here is that, for a library, the "users" of the library are really the developers creating other software using that library. Typically you want to allow "normal use" of your Open Source software by everyone. So by this reasoning you do not want to use the GPL for a library, because then it could be only be "used" by those developers that accept the GPL requirements.

Reasons to use a BSD style license

I personally like to use BSD style licenses because they are really simple and short. It takes 10 seconds to read them and they are not incompatible with other licenses. People who use BSD style licenses are typically quite liberal about their source code, for instance they won’t feel bad if it’s incorporated into a proprietary product somewhere. In the old days this apparently used to happen with the BSD Unix code, but now when anyone can find the original Open Source project on the Internet, the likelihood of a proprietary spinoff gaining momentum is actually quite low.

Groups such as a university research team might actually prefer a liberal BSD style license, because they explicitly want their work to be available to all kinds of parties, including proprietary software companies. (In fact the researchers may one day want to start such a company themselves, or they might be hired to work for one.)

The XFree86 X Window System used in Unix (and that includes Linux) operating systems was developed by a consortium who’s members were selling proprietary Unix platforms. They used a simple BSD-style license, and the jointly developed base system was then incorporated into their proprietary offerings. (Nowadays, this codebase is the cornerstone of the Windowing system in Linux, a completely free operating system.)

Reasons to use an Apache-style license

The reasons to use an Apache-style license are quite similar to those for using a BSD-style license. Typically these are used by people who take licensing more seriously, so the short BSD license is not good enough for them. It is quite telling that these licenses are popularly used by larger organizations like the Apache Foundation or IBM – you can see who could afford the lawyers!

Choosing an Existing Project Based on the License

An additional question that might arise is, is there a reason you would want to choose software based on what license it comes with? In general, I would say the answer is, no there is not. As I said right at the start of this article, as a user, you really do not need to care about the license. The different features of the Open Source licenses do not really have many implications on users.

There are however some license-related issues you might want to consider during your evaluation process when choosing between open source applications. For instance, if some software is incompatible with the GPL, which has by far the largest codebase, it could negatively affect the project’s future. On the other hand, the Apache license is is incompatible with the GPL, and obviously that has not been a problem for the popular Apache projects.

Some people have argued, that out of the two main Linux desktops, Gnome would be a better choice because it is friendlier to proprietary software, and thus potentially there would be more Gnome applications in the future. For Gnome it is okay to develop proprietary software, but the Qt toolkit used as a base for the KDE desktop, is only available as GPL, so those wishing to develop proprietary applications for KDE need to buy a commercial license from Trolltech, the firm that owns Qt. (Trolltech uses the dual licensing model.) Even if this reasoning admittedly has some logic to it, there is absolutely no evidence that Gnome would have more applications, proprietary or otherwise.

Conclusion

This article completes the series introducing the open source world. Previous articles have shown you the reasons why it might or might not be beneficial to your business to develop or use open source software. In this article I’ve provided an introduction to a very important topic, open source licenses. There are a number of licenses available, but in most cases you should only consider licenses approved by the Open Source Initiative, and even there for simplicity and compatibility reasons it is best to stick with only the few most popular ones. Open source licenses can be categorised into GPL like licenses, which have the viral copyleft feature, and BSD like short and liberal licenses. Apache style licenses are quite liberal as well, but much more wordy than the BSD license.