This informative article covers the scope of various free and open source licences along with the subtle differences between them. It concludes with a few guidelines on choosing a software licence, and a brief description of the top 10 free and open source licences.
According to Wikipedia, A software licence is a legal instrument governing the use or redistribution of software. Why is it so essential to license software? To answer this question we first need to understand the different categories into which software can be grouped. Software can be closed source or proprietary, which means that only you, who have bought it, can execute it and you do not have the right to inspect, modify or distribute the code. Then there is open source or free software, which offers you various levels of freedom over the code. The third category of software does not have a licence but is still bound by copyright laws. Finally, there is software in the public domain. This is like the literary works of Kalidasa, Shakespeare or Dante, which are out in the open wilderness of the public domain for use or misuse by the general public.
So, in general, if your piece of code adopts a software licence, it becomes either proprietary software or free/open source software. If you do not add a licence to your piece of code, there is still no need to panic because it is bound by implicit copyright laws, just like any other creative work. But there is a catch to this. Once the copyright term expires, the software goes into the public domain. Then you no longer have any right over your software, which becomes open for exploitation and can be used by anyone without even mentioning your name or efforts. Besides, the copyright period differs from one country to the next. In India, the copyright term expires after 60 years. But there could be a banana republic somewhere in Latin America or the Caribbean with a copyright term of say one year, after which your software is doomed. If the software falls into the public domain, then any dealings with it become a matter for the legal sharks to feast upon. So it is absolutely essential to add a licence even if the software is irrelevant and primitive.
Different categories of software licences
Software licences can be broadly classified into two categories. These are: proprietary licences and the free/open source licences. The former are adopted by software companies or individual developers to include one or more restrictions on how the software is used by a customer. Proprietary licences can restrict modification, sharing, inspection, redistribution and reverse engineering. Some of the popular proprietary licences are supported by organisations and companies like The Open Group (Yes! UNIX is closed source!), Microsoft, Adobe Systems, etc. Microsoft Windows EULA is an example of a proprietary software licence. To those in the software freedom movement, proprietary licences are anathema. So I am going to discuss what interests us more — the open source software licences. But dont forget that having some licence is far better than no licence at all.
Open source software is widely supported by many enthusiastic developers. One of the reasons for such untiring support is the idea that with each line of code contributed, we are working towards the development of mankind by spreading knowledge. But are we fighting on the right side for the right reasons? To answer this question, we need to understand the different free/open source licences. It is often confusing when people talk about free software, open source software, free and open source software, etc. Are they different or synonymous with one another? The answer is that they are all different. But the differences are very subtle and often do not seem to make much sense.
There are many organisations in the open source arena dealing with software licences. Two of the major players are the Free Software Foundation (FSF) and the Open Source Initiative (OSI). They both review free/open source software licences for their legal validity and usefulness. If a particular software adopts a licence approved by the FSF, then it is called free software. Similarly, if a software adopts a licence approved by the OSI, it is called open source software. Most often, licences are approved by both the FSF and the OSI, and such software can be called free and open source software (FOSS). For example, open source licences like the GNU General Public License (GPL), the MIT License and the PHP License are accepted by both the FSF and the OSI. So software that has one of these licences can be called FOSS. Artistic License version 1.0 is accepted by the OSI but not by the FSF. So software adopting this licence is open source software but not free software. Similarly, the original BSD License is accepted by the FSF but not by the OSI. So software adopting this licence can be called free software but not open source software.
So we have now learned to identify free software and open source software. But why should there be two rival organisations working towards achieving more or less the same goals? In my opinion, this is the curse associated with the free/open source initiatives. You can go to the respective websites of these two organisations and find articles mildly critical of the other initiative. The OSI argues that the FSF approach is more philosophical in nature rather than being a practical one. The OSI feels that the term free is misleading and ambiguous. Well, many people care more about free beer than free speech so OSI scores a point there. But the FSF has its own list of accusations against the OSI. The FSF feels that the OSI licences are slightly weaker than the FSF licences. FSF also accuses the OSI of supporting companies providing software residing on the fringes of freedom and openness. This infighting can also be generalised as the main theme of open source software development.
The story goes like this. Two friends, who are developing a free/open source project, have a breakup. The next day, one of them forks the project and after a few years there are two software with differences so minute that you need advanced degrees to identify them. One such instance is the birth of LibreOffice from OpenOffice. The latter now has an Apache License whereas LibreOffice has a Mozilla Public License v2.0. The reason for the split was mostly related to the intricacies of the licence used by Oracle, which owned OpenOffice at that point in time. The bottom line is that both FSF and OSI validate software licences for their potential usefulness, and the criteria for evaluation have only minor differences but the rivalry is intense. So, finally, which initiative is the better one? Well, I dont want to answer that question as it might trigger something similar to the editor war.
Different types of free and open source licences
Free and open source software licences can be further classified into copyleft licences and permissive licences. Both provide the same set of freedoms as far as usage, inspection and modification are concerned. But the freedom for redistribution is different for copyleft licences and permissive licences. A copyleft licence explicitly makes sure that a derived or modified work of free/open source software also adopts a licence similar to what accompanied the original software. The GNU GPL is an example of a copyleft licence. Thus, if you adopt GPL for your software, every derivative work will also come under GPL or a similar licence. But remember, copyleft licences are also based on copyright laws. Figure 1 shows the copyleft symbol. The symbol alone has no legal validity and the great Richard Stallman himself criticised its use in many legal documents. Copyleft licences are very strict about retaining the freedoms associated with software, whereas permissive licenses are not so strict about retaining the rights for derivative works.
Permissive licences allow a user to adopt a different licence for the modified source code of an existing free/open source project. Software using this licence can be modified and the derived work can be made closed source software. This provision can lead to the exploitation of free/open source software by people with vested interests. The BSD License and the MIT License are permissive licences, and are sometimes misleadingly called copycenter licences because they lie somewhere between copyright software and copyleft software. There is also a slightly stricter variant of permissive licences called copyfree licences, which have an additional restriction while redistributing a derived work. They ensure that all the direct modifications of an existing work retain the same licence. The simple BSD License is an example of a copyfree licence. So, every copyfree licence is permissive but not all permissive licences are copyfree. The Apache License is an example of a permissive licence that is not copyfree.
The relative openness of different types of software
Now let us consider some obscure types of software for their perceived openness or closedness. First, let us consider freeware. This is software freely available to end users (free as in free beer). But the source code is not open for inspection or modification. So it cant be termed free or open source software. This shows us another of the paradoxes associated with free software. Software which is freely available may not be free software, whereas software for which you have to pay money might actually be free software. Another uncommon type of software is abandon waresoftware that has been abandoned by its owner or developer. The owner may no longer be tracking or enforcing copyright violations; even so, this software does not qualify as free or open source software. You must be very careful if your project development involves this sort of software because you could be charged for copyright violation at a later stage.
Some strange licences
There are also some weird software licences whose usage is very limited. These are created for the sake of fun or in protest. For example, there is one called the Beer-ware License! It is a very relaxed licence and its full text, obtained from Wikipedia, is given below.
/* * ---------------------------------------------------------------------------- * THE BEER-WARE LICENSE (Revision 42): * <phk@FreeBSD.ORG> wrote this file. As long as you retain this notice you * can do whatever you want with this stuff. If we meet some day, and you think * this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp * ---------------------------------------------------------------------------- */
The Beer-ware License was created to mock the large number of restrictions made by the GNU General Public License, a supposedly liberating licence. It essentially gives every one every freedom. But no self-respecting programmer will squander away their programs in such a manner. No real software project has adopted this licence. Another quirky and interesting licence is called the WTFPL. Modesty does not allow me to expand the abbreviation of the licence but interested readers can search the Web for an answer. This is a permissive free software licence approved by the FSF. Both the aforementioned licences dedicate the software to the public domain.
Some guidelines for choosing a free/open source licence
Let me attempt to give a few guidelines for choosing the right software licence for your project. The first suggestion is that if your software is worth even a dime, please consult a decent lawyer. Software licensing is a slippery slope; one wrong move and you are in deep trouble. So if you have the slightest of doubts while choosing a software licence, take the decision only after consulting an expert. But if you are developing software with no monetary benefits in mind, then you can adopt one of the free/open source licences, after some deliberation. If you want your work and all the subsequent derivative works to be placed in the free software domain, it is better to choose a copyleft licence like the GNU General Public License. One problem with this choice is that your software or library might be overlooked by some of the companies in the free/open source sector that are developing commercial software. Even though it is a free software licence, the GPL is a very strict one — adopting it guarantees the freedom of your software forever but might make it less popular in the long run. On the other hand, if you are more interested in your work proliferating, rather than being in strict allegiance with the free software philosophy, then you can select one of the permissive licences like the MIT License. This, essentially, guarantees almost every freedom including the freedom for proprietary software to link your libraries. This may not be preferable for many developers.
Another situation in which you need to opt for a licence is when you are producing a manual or document for uploading onto the Web. Then it is a very good idea to license the work with the Creative Commons (CC) License. This can be used to make sure that your work is attributed to you, shared alike, is used for non-commercial purposes and anyone trying to create work that is derivative of yours can be stopped.
The top 10 free/open source licences
The following section lists and then briefly explains the top 10 free/open source licences. The selection of a particular licence is not based on popularity alone but also on how strongly it represents its licence category, as well as its general usefulness to developers.
- GNU General Public License
- GNU Lesser General Public License
- Apache License
- BSD Licenses
- MIT License
- Creative Commons License
- Artistic License
- Mozilla Public License
- Common Public License
- Microsoft Public License
GNU General Public License
This is one of the most popular free and open source licences. In fact, it has become so popular that all the other licences are divided into two categorieslicences which are compatible with GPL and those that are not. Two licences are considered compatible with each other if they can be used in a single project without violating the terms of one another. GPL is accepted by both the FSF and the OSI. It is a copyleft licence and often considered one of the strictest licences as far as freedom and openness of a project is considered. It does not allow proprietary projects to even dynamically link to free and open source modules. The only downside is that this licence is often overlooked by developers due to its alleged strictness with regard to software freedom. The latest version is GPL version 3. The Linux kernel and the GCC are examples of software using this licence.
GNU Lesser General Public License
The GNU LGPL is another very popular free and open source software licence. It is a weaker form of GPL. The main difference is with respect to the dynamic linking of shared libraries. LGPL allows proprietary software to dynamically link to shared libraries. Both FSF and OSI have approved the LGPL, making it a free and open source licence. LGPL is a copyleft licence. Both GPL and LGPL were created by the FSF itself. These two GPL family licences are used in almost half the software projects that were analysed by a company called Black Duck Software. This clearly shows the dominance of the GPL family of licences. LGPL is compatible with GPL and is mostly used to license libraries.
Apache License
This licence has been written by the Apache Software Foundation (ASF). Many studies show that Apache Licenses are used by nearly a quarter of all the free/open source projects. The Apache License is approved by both the FSF and the OSI, and it is widely considered a permissive licence. The FSF recommends the Apache License for projects with code less than 300 lines. The Apache License version 2 is compatible with GPL version 3. The Android operating system has adopted the Apache License.
BSD Licenses
BSD Licenses are a family of permissive licences proposed by the University of California, Berkeley. The original BSD License was used with the Berkeley Software Distribution (BSD), a UNIX-like operating system. The modified BSD License has the approval of both the FSF and the OSI, making it a free and open source software licence. The modified BSD License is also compatible with GPL version 3.
MIT License
The MIT License is a permissive licence proposed by the Massachusetts Institute of Technology (MIT). It is GPL compatible and is used by Ruby on Rails, jQuery, X Window System, etc. The MIT License is also approved by both the FSF and the OSI, making it a free and open source licence.
Creative Commons License
The Creative Commons (CC) License has been proposed by an organisation called Creative Commons. This licence allows the free distribution of a copyrighted document. A CC License involves the selection of any one or more of the following four conditions: attribution (BY), share alike (SA), non-commercial (NC), and no derivative works (ND). BY implies that any use of your work or a derivative work should acknowledge the original creator. SA means that all derived work should carry a licence similar to the original work. NC means that the work can only be used for non-commercial purposes. ND means that the work should not be modified in any manner leading to a derivative work. Out of the 16 possible combinations of these four conditions, only six are used as valid CC Licenses. They are: BY, BY+SA, BY+NC, BY+ND, BY+NC+ND and BY+NC+SA. The FSF approves only two CC Licenses as free software licences BY and BY+SA, and none of the others. The OSI does not approve any of the CC Licenses. CC Licenses are more often used to license works like books, journals, games, etc, rather than software.
Artistic License
Artistic License was originally created by Larry Wall, the creator of the Perl programming language, which uses this licence. The original version was intended to enforce FOSS-like licences by using contract law rather than copyright law. But the initiative was widely criticised by the FSF for not conforming to the free standards expected of such a licence. It was, however, approved by the OSI. Subsequently, Artistic License version 2 made some changes to its original draft and now enjoys the approval of the FSF too. Artistic License version 2 is GPL-compatible.
Mozilla Public License (MPL)
The MPL is a detailed licence developed by the Mozilla Foundation. It is approved by both the FSF and the OSI. But MPL version 1.1 is not compatible with GPL. MPL version 2 is also not compatible with GPL under certain circumstances. Thus, developing a project involving both GPL licensed components and MPL licensed components is a difficult task. MPL is somewhat relaxed when compared with many other copyleft and permissive licences. Thus, software licensed under MPL can be widely used by proprietary developers. Examples of projects using MPL include Mozilla Firefox and Mozilla Thunderbird.
Common Public License
The Common Public License (CPL) has been proposed by IBM. Both FSF and OSI have approved it, making it a free and open source licence. The Korn shell was originally released under CPL. The CPL is not compatible with GPL. To reduce the number of free/open source licences, IBM agreed to collaborate with the Eclipse Foundation. Now, both IBM and the Eclipse Foundation are using a licence called the Eclipse Public License (EPL), which is based on CPL.
Microsoft Public License
It might be shocking to read about a free and open source licence supported by none other than Microsoft. In fact, Microsoft has two open source licences — Microsoft Public License (Ms-PL) and Microsoft Restrictive License (Ms-RL). The former is the least restrictive licence proposed by Microsoft. It is approved by both the FSF and OSI, thus making Ms-PL a free and open source software licence. But Ms-PL is not GPL compatible, according to FSF.
There are literally hundreds of free/open source licences for developers to choose from and I have just covered the tip of the iceberg. But interested readers can find the full texts of each and every licence on the Web. Devour them carefully and, who knows, you might even uncover a hitherto unknown loophole in one of the licences. This has happened in the past, leading to revisions in the texts of many licences.
