Guide to FOSS licensing

From JWikiSkene

I recently open-sourced some code that I developed as part of my PhD work. I wanted other developers to be able to use my code legally, for any purpose, and I did not want to charge them. At the outset, I knew that to bring this about, I would have to do something related to copyright, and licensing. I also had a vague notion that I would have to make some decisions over the way in which users of my software could exploit it, commercially or otherwise. However, I didn't know what specifically I needed to do, and what, if any choices I had over how to make the code available.

I initially imagined that my problem was a common one - a naive programmer who having completed a first version of a project wishes to make it available to the public - so I would be able to find some kind of task-oriented documentation for the process online. However, this either doesn't exist, or I haven't worked out the search terms required to reveal it. Instead, I needed to work it out for myself. Here is what I found out.

In the following text, I cite sources using hyperlinks. I may cite multiple pages from the same website. The first time I cite a website, I use its full name and establish an abbreviation for it. On subsequent occasions, I use the abbreviation. However, each link may refer to a different page from the same website. In general the links reference specific pages that provide support for the assertions following them.

But first, a note on spellings. I have used the spelling licence consistently in this document to refer to a contract granting permissions to use a work. According to the top entry from dictionary.com this is a 'chiefly British' variant of license, which you will encounter frequently in other sources. I have however used license and licensing to refer to the act of issuing a licence. This usage is consistent with the usage on UK government websites, e.g. the Intellectual-Property Portal (IPP).

Disclaimer: I am not legally qualified or otherwise expert in this area. The interpretations and opinions on this page are my own, and you should make up your own mind about the issues, using whatever information you can find, either linked from this page or otherwise, before making any decisions or taking any action related to the protection of your intellectual property, or otherwise. You should not, however, use the information provided on this page as the basis of any of your decisions whatsoever. Given this disclaimer, I think that it is unlikely that I could be blamed if you interpret this page as providing advice and disadvantage yourself on that basis. So don't.

I invite comment on this document, particularly if you are knowledgeable on any of the subjects discussed. Although this page should not be construed as guidance, I nevertheless have no wish to provide inaccurate information, and moreover will be personally interested in any clarifications that are provided.

Contents 1 What rights do I have over my source code to start with? 1.1 So exactly what kinds of rights over intellectual property does copyright provide? 1.2 How do we obtain copyright over a work? 1.3 How is copyright enforced? 1.4 What about patents and such? 1.5 Given that I have copyright over a work, how can I let other people use it? 1.6 Summary of copyright 2 Open-source and free-software licences in general 2.1 The Free-Software movement 2.2 The Open-Source movement 2.3 Not 'Free as in beer' then? 2.4 Peculiarities of open-source licences 2.4.1 Disclaimer of liability 2.4.2 Establishing an agreement 2.4.3 Not paying for it 3 Open-source licences in particular 3.1 Public Domain 3.2 Berkley Software Distribution (BSD) 3.3 Mozilla Public Licence v.1.1 (MPL) 3.4 Lesser General Public Licence (LGPL) 3.5 The GNU General Public Licence (GNU GPL) 4 Conclusions

What rights do I have over my source code to start with?

In the UK, several kinds of work are automatically protected by copyright when they are created. According to the website of the UK Patent Office (PO), this includes original literary works, original dramatic works, original musical works, original artistic works, published editions of works, sound recordings, films, and broadcasts. Computer programs are regarded as a type of literary work.

(PO) Copyright confers economic rights over the control of copies of a work to its creators, and moral rights to be identified as the authors of a work. The intent of copyright laws are to encourage the creation of works of the kind protected by copyright, which are deemed to be of a general benefit to society. The economic rights conferred by copyright turn the work into a type of intellectual property. Like more conventional property (houses, cars, computers) ownership of this property can be transferred, by sale, or as a gift. The moral right to be identified as an author to a work cannot be transferred.

It is worth noting here that the Richard Stallman, of whom more below, thinks that the phrase 'intellectual property' is actually propaganda disseminated by people who want strong copyright protections, and that copyrights are not property at all. This opinion is substantiated to some extent by the fact that copyright law and property law are separate branches of the law. However, I will continue to use the term here as a convenient identifier for things covered by copyright, patents and trademarks.

So exactly what kinds of rights over intellectual property does copyright provide?

According to the UK Government (IPP), most uses of copyright material require permission from the copyright holder. However, a reviewer of this article pointed out that this was not strictly true. Actually, particular types of usage are restricted, and everything else is OK. John Casey gives a good summary of these restrictions on the JISC legal site. They include:

• Copying the work
• Issuing copies to the public
• Renting or lending copies to the public
• Performing, showing or playing the work to the public
• Broadcasting the work
• Adapting, or amending the work.

These restrictions include things that I want people to be able to do with my code, including copying the work to other people, and adapting or amending the work. If people are going to be able to use my software in the way I want, I am going to have to grant them permission to do so.

(IPP) There are some exceptional types of use that do not require permission, related to using small pieces of a work for the purposes of non-commercial research, review, critism, etc. However, these exceptions do not seem broad enough to allow someone to use some software that I have written for free, at least not under all the circumstances that I can imagine them wanting to use it.

(IPP) This discussion of what copyright does and does not allow seems a little vague. In fact, precisely what you can and can't do with copyright material does not appear to be defined precisely by any law that is written down (statutes). Instead, some of the exceptions to copyright rely on principles, such as "fair dealing" that may need to be interpreted by a court to decide if a specific use is exempted. Fair dealing or fair use arguments seem to be at the heart of most of the current debates about the sharing of digital media. How many times do you have to listen to a Britney Spears MP3 before you realise that you've wasted your bandwidth?

I presume that most interpretations of copyright law will be delivered as the outcomes of court cases in which someone is being sued for copyright infringement, with associated financial consequences. It is therefore worth being pretty sure that you know your usage is exempted before doing anything with copyright material without the explicit permission of the copyright holder.

How do we obtain copyright over a work?

(PO) Copyright is an automatic protection. As soon as you create a work, the copyright on it is granted either to you, or to your employer, depending on what arrangement you have with them over the ownership of intellectual property. It is quite common for employers to retain ownership of all intellectual property created by their employees (in the course of their duties). This is an issue for me, as University College London, for whom I work as a Research Fellow (RF), do indeed retain the rights to my work. The situation is further complicated in my case by the fact that I only work part-time for the college as an RF. The other part of the time I still work at the college but as a PhD student. It is not clear who owns the rights to the work that I produce as a student. There is also no clear way to distinguish what parts of my output were created as a student and what as an RF as the roles are almost indistinguishable. However, this was resolved simply by obtaining permission to open-source the work from the university, or by obtaining an agreement from them that I am the copyright holder. It is generally worth establishing who has the ownership of the copyright of a work before using it, and attempting to distribute the source code of some software definitely amounts to use.

There is no registry for copyrighted works, you get it just by creating the work, and you don't have to do anything special. This begs the question, what are those little copyright notices that you see all over the place? (PO) Well, in Britain and much of the rest of the world they are not necessary, although in some countries they are. However, their use is regarded as good practice, especially when putting material on the internet, which is by its nature international.

You may also obtain copyright over a work because it was transferred to you. This is unlikely to be the case for code that you are trying to make available as open source. However, there are some situations whereby you may chose to transfer your copyright to a third party in the course of open-sourcing it.

(PO) Copyright does not last forever, but it does last a very long time. Literary works, including computer programs, are subject to copyright until 70 years after the death of the author.

How is copyright enforced?

(PO) Copyright, in the UK at least, seems to be enforced by a mixture of civil actions (suing someone that you think has violated your copyright) and criminal prosecutions, depending on the scale of the violation. This probably means for private individuals that they have to keep an eye out for anybody violating their copyright and pay the cost of attempting to sue them if necessary. This makes it very important to be careful about establishing the ownership and originality of a work. Although copyright is granted automatically when you produce a work, you may need to prove the originality of the work (i.e. that you produced it without copying) in a court. You can apparently do this in the UK by sending a copy of the work to yourself special delivery, to establish that you had possession of the work on a certain date. However, in the U.S., according to their Copyright Office (CO) this practice is know as the 'poor man's copyright' and holds little if any legal power. In the U.S. you can instead register a work with the Copyright Office to establish its ownership at the time of registration.

What about people in other countries using my work? (PO) Copyright is protected by international treaties. Not everybody apparently subscribes to these treaties. However, if you are concerned about your work being used without your permission in non-signatory countries, you may be able to persuade the government of your own country to declare war on them.

What about patents and such?

(IPP) Copyright is only one type of intellectual property. Of particular relevance to the publication of software is the fact that it does not protect the ideas contained in the software, only the work itself. So if you publish some software and only protect your copyright, there is nothing to stop somebody reimplementing your ideas in their own work. Patents are required to protect ideas, and patents are not granted automatically in the same way as copyright. It is currently possible to patent software designs in the U.S. but not in Europe. There is a lot of debate at present about whether software patents are a good thing or not, but I will not discuss the subject here primarily because I do not at the time of writing adequately understand it. However, If you are worried about your ideas being made public, but then abused in some way, you may be concerned about this subject.

Another type of intellectual property called 'trademarks' protects brand identity. This is probably not relevant to this discussion, but it is worth remembering that your copyright on a work may not protect your rights to any branding that you consider to be embedded in the work.

Given that I have copyright over a work, how can I let other people use it?

Since automatic copyright rights prevent anyone but the copyright owner from using a piece of software in several important ways, how can the owner allow these types of usage of the software by others? (IPP) The answer is that they may grant permission to second parties for a work to be used in a particular way. Such a permission is called a copyright licence, and it is an agreement between the copyright owner and the user. As with any other agreement it may come with conditions on the user. For example, the user may have to pay for the licence.

A distinction exists between copyright licences and End-User Licence Agreements (EULAs), which most people will have encountered when using commercial software. EULAs are an agreement between the vendor of some software and the user, and may restrict any type of use of the software, including those already protected by copyright. As discussed below, some issues relating to establishing an agreement apply equally to EULAs and copyright licences.

It is sometimes possible to grant a copyright licence without even knowing it. These implied licences are discussed on this page from bitlaw.com, and arise when the behaviour of the copyright holder is such that a limited licence to use a work is obviously being granted. For example, by placing material in a webpage, you implicitly grant the user the right to download it to their computer for the purposes of viewing it.

It is possible that making some source code publicly available could be sufficient to grant an implicit licence to use, modify and redistribute it. However, it is probably better practice to be explicit about what people may and may not do with software that you have written. In the next section I introduce open-source and free-software licences that assist in making software available for various types of free usage.

Summary of copyright

• Copyright protects a range of works, including software, and it provides a lot of protection. Unless the copyright owner agrees to it, copyright restricts a number of uses of the work, including most forms of copying and redistribution of the work to others.
• Copyright applies automatically on creation of the work, and is usually either owned by the creator of the work or their employee, although it helps to be clear which.
• Copyrights are property and can be bought and sold. They last for a long time, although do eventually expire.
• Copyright only applies to the work, and not the ideas contained in the work, or a few other things like the name of the work. Other types of intellectual property law may be able to protect these things, although they are not generally automatic.
• You can allow someone to use a work in a particular way without relinquishing your copyright. This is called licensing the work. A licence is an agreement between the copyright owner and the user that the user can use the software in some ways usually restricted by copyright, possibly with some restrictions, and in return for some consideration, subject to other laws governing contracts. From the point of view of open-source software we are concerned with open-source licences, which, informally, are a particular kind of licence that grants permission to a second party to redistribute the source code of some software and doesn't require that party to pay for this permission (although they may have to pay to get the source code in the first place). These are discussed in more detail in the next section.
• Copyright licences are different from End-User Licence Agreements (EULAs). However, as discussed below, free and open-source copyright licences may apply restrictions to users that rule out the use of EULAs for redistributions or derivative works.

Open-source and free-software licences in general

It is debatable what constitutes open-source software or an open-source licence. It is not only debatable, but it seems to be pretty fiercely debated, which is why in this document I have been hedging my bets by referring to both 'open-source' and 'free-software' licences. These terms identify the two competing schools of thought on the best way to make software freely available.

The Free-Software movement

The free-software movement has grown up as a result of a concerted effort to produce a free operating system for computers, the GNU project (GNU), a recursive acronym standing for GNU's Not Unix. The project was founded by Richard Stallman, often referred to by his initials RMS, in 1984. RMS remains the leading advocate of free software and is president of the Free Software Foundation (FSF) a charitable organisations that is perhaps best thought of as the political wing of the GNU project. The free software movement has been responsible for some major triumphs in the production of software of comparable quality to commercial software, including the LINUX operating system kernel, the GNU C compiler and the Open Office suite of productivity applications. The movement enjoys some political support, for example from UNESCO.

The free-software movement is based on an ethical notion of free software summarised as follows (FSF):

Free software:

• The freedom to run the program, for any purpose (freedom 0).
• The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help your neighbor (freedom 2).
• The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.

The FSF take pains to explain that the freedoms that it refers to are intellectual rather than commercial. This is frequently summarised by stating that software should be 'free as in speech' rather than 'free as in beer'.

The FSF support its notion of free software with two highly popular licences, the General Public Licence (GPL), and the Lesser General Public Licence (LGPL), which protect programs and libraries respectively, licences that are collectively referred to as copyleft. These licences are discussed at length in the section on licence specifics below. What may not be obvious from the general principles listed above is the extent to which these licences force subsequent users of any software to adopt the same licences, a property referred to as the 'viral property' or in this document at least, virulence.

Why should the FSF make virulence a property of its licences? Is there a practical need for it given the properties that free software is intended to possess, as listed above? It is possible that having the ability to take some free software, and produce non-free versions or modifications of it might restrict the rights described above for the original version, but it is not immediately clear how, particularly given that the GPL and LGPL do not provide any innate protection for the ideas contained in the free software that they protect (this being the role of patent law, rather than copyright law). Instead, it seems that the FSF believes that freedom of software is a right, rather than a privilege for users, and seek to propagate that right using its licences (FSF). Virulence can also be seen as an attempt to obtain some compensation for developers who issue free licences, in that they may eventually obtain benefits from the efforts of other developers who choose to extend and redistribute their work. It is not clear how useful virulence is as a property of copyright licences. However, it is indisputably the case that the free software movement has had considerable economic impact, either due to the zeal of its participants, or to the benefits to development processes that enforcing openness and collaboration imply.

The Open-Source movement

The open-source movement is a slightly less militant offshoot of the free-software movement. The primary difference in philosophy between the movements seem to be that people from the open-source movement will cooperate with people who do not agree with them over the principle that intellectual property should be made freely available, but people from the free software community will not. This theory is supported by the fact that the open-source movement is prepared to call all free-software licences open-source licences, but the reverse does not hold.

The Open Source Initiative (OSI) provides a very thorough definition of what they mean by open-source software. It states that open-source software is any software that bears a licence with the following properties (described in more detail on its website):

• Free redistribution - The licence should impose no restrictions on the distribution of the software. This doesn't mean that any distributor if the software must distribute it for free however.
• The source code of the software must be distributable.
• The licence must allow modifications and derived works.
• The integrity of the author's source code may be protected, for example by insisting that modifications are explicitly documented, but not to the extent that this protection prevents modifications to the software in any practical way.
• No discrimination against persons or groups
• No discrimination against fields of endeavour
• The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional licence by those parties.
• The rights attached to the program must not depend on the program's being part of a particular software distribution.
• The licence must not restrict other software that is distributed along with the licensed software.
• Licence must be technology-neutral. The software doesn't have to be technology neutral, but the licence must be, so it can't depend on mechanisms such as 'click-wrap' discussed below.

The last four conditions in this list are fairly technical and are designed to prevent particular types of bad behaviour in respect of licences. However, the first six sum up nicely what open-source means at a minimum: the source is freely available to all for any purpose.

The OSI review and certify open source licences as conforming to these standards. The licences are published on their website for reuse by developers. At the time of writing the OSI list 58 conforming licences, which is a lot to choose from, particularly if like me you find reading legal-ese difficult. These licences include the GPL and LGPL licences issued by the bastion of the free-software movement, the FSF. In order to reduce the scope of the choice, I have reviewed only a selection of most common choices.

Sourceforge.net is a large and popular site that hosts open-source projects, providing file storage and distributed development tools in support of the open-source community. Sourceforge relies on the OSI's definition of open source, and recommends that projects hosted there use an OSI-certified licence. During their 'Register New Project' process (login required), they state that the most popular open-source licences are the GNU GPL, GNU LGPL, BSD Licence and Mozilla Public Licence (MPL 1.1). They also state that developers have the option of releasing their software into the public domain. In the final major section of this document I review each of these options. However, in the remainder of this section I briefly discuss money, and some peculiarities of open-source licences that may be worth knowing about before choosing one.

Not 'Free as in beer' then?

It is important to understand what you are not paying for when you obtain some free or open-source software. You are not paying for the licence that allows you to use the software freely in the manner discussed above. However, you may have to pay somebody to give you the source code for the software in the first place, a so-called 'distribution' cost.

This might seem strange, because in practice most free and open-source software is also distributed effectively for free, via the internet. Why should this be, if someone could be making money distributing this software?

There are probably a couple of reasons for the prevalence of free distribution, as well as free licensing. The internet makes distribution fairly cheap, and can also offer alternative revenue streams, such as advertising to distributors, meaning they don't have to charge much for distribution. Also, free and open-source licences permit redistribution, but don't force people to charge for it. Therefore, as soon as one party distributes some free software for a charge, there exists a second party with the capability to undercut them on distribution.

How do developers make any money producing free and open-source software then? In some cases, like mine, the software is a by-product, rather than primary result, of work for which the developer is paid. In other cases, developers offer support or consultancy services related to the core product, which is free software. It is also possible to offer and charge for warrantees on free and open-source software, which guarantee compensation to the client if the software does not perform as expected. Warrenty is usually disclaimed in free and open-source licences. There may be other ways to make money out of this kind of software. Also, it seems to be the case that quite a large population of programmers are not interested in making any money at all, and assist with the development of this kind of software due to enthusiasm alone.

Peculiarities of open-source licences

According to (IPP) licences are a type of contract, that is an agreement protected by law. Open-source licences are very unusual sorts of contract for a number of reasons that I will now discuss, and this may impact upon their legitimacy. However, before beginning this discussion, I should point out that many people use open-source licences and believe in the protection that they provide. This may mean that courts will tend to uphold the spirit of these agreements if they are ever challenged, rather than rejecting them on a technical basis. It may also mean that I am entirely wrong about the following matters. I based some of this reasoning on 'Contract Law' by Mary Charman, published by Willan Publishing, which is an A-level law text, and hence about my level. The quality of the following arguments should not be taken as either an endorsement or criticism of the book.

Disclaimer of liability

At least in the UK, there are no special restrictions on the conditions that a licence can apply to its user. However, if licences are a type of contract, then they are hence governed by other laws governing contracts. For example, it would not be legal to write a licence that made any user of your work an indentured slave in perpetuity. This is relevant to open-source software licences, as most contain a disclaimer of liability. These can be considered to be a condition upon the user that they waive their protection under certain laws. However, in the UK at least, it is not possible to disclaim all liability. For example, you cannot disclaim liability for negligence leading to death. The Mozilla Public Licence (MPL) acknowledges this to some extent, but some licences, including the Berkley Standard Distribution (BSD) licence attempt to disclaim even this.

Establishing an agreement

The second peculiarity with open-source licences is the matter of deciding that the user has assented (agreed) to the contract (agreement). In traditional contracts this is made unambiguous by the fact that the parties have to sit down together and sign a document. However, with open-source licences the parties may never even meet, and there is no document to sign. This is also a problem to some extent with EULAs for commercial software. The signing of licences is not a part of the usual business of buying commercial software. However, the developer of the software may prefer to apply constraints to the users in addition to those implied by default by copyright law. The two most common solutions to this problem will be familiar to most regular computer users, and are called 'shrink-wrap' and 'click-wrap' licensing. A user is deemed to have agreed to a shrink-wrap licence if (s)he opens some physical packing containing the software. Click-wrap licences require the user to click an 'I agree' button in response to a window showing the licence terms when the software is first used. As this article from Wiggin and Dana discusses, the strength of these measures is largely untested despite their popularity.

The situation for open-source licences is even more vague, as they generally do not require any explicit assent. The LGPL attempts to define the use of the software as the act of assent as follows:

9. You are not required to accept this License, since you have not signed it.
However, nothing else grants you permission to modify or distribute the Library
or its  derivative works. These actions are prohibited by law if you do not accept
this License. Therefore, by modifying or distributing the Library (or any work
based on the Library), you indicate your acceptance of this License to do so,
and all its terms and conditions for copying, distributing or modifying the
Library or works based on it.

Not paying for it

Finally there is the matter of consideration. A contract cannot be said to hold if the user does not provide anything of value to the provider in return for whatever is being offered. This may not be a big problem in the case of open-source licences. If the licence does not hold, then any user will be in violation of copyright law. It is likely that only the original copyright holder would object, and (s)he was after all the party who attempted to make the software free in the first place, so this is unlikely. However, the situation does raise some doubt in my mind as to the rights of the user should the original copyright holder attempt to withdraw the open source licence at some point in the future.

Having raised these doubts about open-source licences, I should reiterate that I believe that they probably nevertheless provide pretty good protection for software developers and users. Many aspects of copyright law seem to be negotiable, and open-source licences at least have the benefit of making the position of the original copyright holder completely explicit. This would no doubt be helpful in determining a just resolution to any disagreement that might arise at a later time.

Open-source licences in particular

Public Domain

Works originally covered by copyright are said to be in the public domain when their copyright has expired. Works in the public domain can be used by anybody for any purpose. Note that because copyright is granted only when creating a work it is not possible for anybody to somehow steal the copyright on an old work once it has passed into the public domain, although they may obtain copyright on derivative works.

The public domain used to be one of the main ways of releasing free software. The public domain software library contains many examples of this type of work.

(SF) Sourceforge suggests that it is possible for developers to release their projects into the public domain using a small notice disclaiming all copyright rights to the work.

The legitimacy of such declarations is questionable, as discussed in The Public Domain in Copyright Law by Edward Samuels. However, they are arguably no less questionable than free licences as discussed above. In the US, it may be possible to donate software as a gift to the Machine-Readable Collections Reading Room of the Library of Congress. This doesn't eliminate copyright on the work, but transfers it to a body arguable likely to defend the free use of the software (although possibly not if the user is in any way terrifying).

It is worth noting that public domain declarations are different to copyright licences in the sense that the original copyright owner cannot both disclaim ownership of the work, and licence it in some other way. By disclaiming ownership, the original copyright owner also disclaims all rights to restrict the use of the work according to copyright law.

The status of the public domain is itself a contentious issue, and is a battleground for the standard argument between those who argue for more stringent controls on intellectual property, and those who argue for more freedoms. According to copylaw.com, the US currently has a twenty-year embargo on any works entering into the public domain, which it has effected by extending the copyright on all works by twenty years. On the other hand, various activist groups are in favour of preserving and expanding the public domain. The Union for the Public Domain lambasts the UK Intellectual Property portal (used as a source above) for not providing industry with adequate information on the public domain. The Orphan Works movement seeks to expand the public domain allowing free use of works whose copyright owners cannot be identified (known as abandonware in software terms).

Public domain declaration probably provide more protection for the user of public domain software than no declaration at all. However, according to the GNU's take on licences public domain status for source code can be regarded as being equivalent to an all-permissive open-source licence so there are alternatives. However, using a licence would reserve the right of the original copyright owner to issue the work under a different licence in the future.

Berkley Software Distribution (BSD)

The BSD licence is the least restrictive (on the user) actual licence discussed here. It is very short, and can be read at (OSI). The BSD licence was originally applied to a version of UNIX called the Berkeley Standard Distribution.

As far as I can tell, the BSD licence just consists of disclaimers of warranty and liability (i.e. we don't claim this software does anything, and you can't blame us if we've got something wrong that this software that doesn't do anything anyway does), and statements to the effect that users can do anything with the software except remove the BSD licence.

Although you can't remove the licence from the original software, there is apparently no requirement to distinguish the original code from new code in modifications that you make and redistribute, either in source or binary form. You therefore seem to have complete flexibility in the way you use the BSD code, providing you include a copy of the BSD licence with all redistributions, possibly prefixed with a statement such as...

   The following copyright notice and license applies to portions of this software. 

Apparently, an older version of the BSD licence exists that requires all advertising materials related to derived products to also state that portions of the product are due to the original copyright holders. (Berkeley) BSD UNIX was eventually relicensed with this provision removed. However, it may still apply to products licensed by other organisations who reused the original BSD licence.

Mozilla Public Licence v.1.1 (MPL)

The MPL is usually a slightly more viral licence than the BSD, because it ensures that modifications to the open-source software that it protects are also open source. I write 'usually', because the MPL optionally includes a clause allowing relicensing of the code under different licences, and in principle these would not have to be open-source licences. However, they normally would be.

The MPL is quite hard to read. However, the Mozilla foundation provides a version with helpful popup annotations. There follows my own commentary on the most important clauses in the MPL:

1.9

The definition of modifications is central to the effect of the MPL. Fortunately, it is understandable. I reproduce it here in its entirety:

1.9. Modifications means any addition to or deletion from the substance or structure
of either the Original Code or any previous Modifications. When Covered Code is released
as a series of files, a Modification is:

 A. Any addition to or deletion from the contents of a file containing Original
 Code or previous Modifications.

 B. Any new file that contains any part of the Original Code or previous Modifications. 

3.1

All modifications (and hence modification of modifications) will be covered by the licence in the future. This clause really delivers the force of the licence, and determines the degree of its 'virulence', or the extent to which the licence is inherited in derived works. The MPL states that modifications must be covered by the licence. The intent of this is at least partially to ensure that future users of the code contribute their innovations back to the open-source community, in return for having been allowed to use the code for nothing in the first place. However, this constraint is not as strong as you may think, because modifications are defined on a per-file basis (in contrast to the LGPL which is defined in terms of larger functional units called libraries). Hence modified code may depend on code that does not have to bear the MPL licence and may not therefore have to be free, and the total set of modifications that must be contributed back may not add up to a working system in themselves. This might seem completely useless, but it is not inevitable and instead is at the discretion of the user; and, in fact such partial disclosures may still contribute bug-fixes or new innovations to the original corpus, providing somebody can be bothered to read the new code and merge the changes into a more coherent whole.

3.2

The source code for any software covered by the licence must be freely available.

3.3

If you make a modification, you must include a description of the modification in any future distribution of the code (so that the modification isn't confused with the author's original work, thereby potentially harming their reputation).

3.4

If you think there might be any problems with patents interfering with the licensing on this code, you have to put a note in a file called LEGAL that you must distribute with all future versions. You must also make this information public to the best of your abilities.

3.5

For the code to be protected by this licence, it must bear some boilerplate text. This clause is needed because the MPL is such a big document, you would not want to prepend it to the top of all of your code, which you could just about do with the BSD. The BSD doesn't actually require this, just that a single copy of the licence be shipped with the code. However, given that the MPL's definition of modifications depends on the notion of source files, you can see why it helps to be explicit that a file is covered by the MPL.

4

Any problems with compliance to the licence must again go into the LEGAL file. Basically, if you are worried about anything, write something in LEGAL.

6

The Mozilla foundation reserve the right to publish new versions of the licence (actually 1.1 is already the second version of the licence, I haven't considered 1.0 here), but the licence that covers the code doesn't change. If you originally license with 1.1 then you stay licensed with 1.1, as do all derivative works.

7

A disclaimer of warranty, just like the BSD.

8

If I interpret this section correctly, it means that you can't use MPL'd software for any purpose if you are also suing the original copyright holder for a patent violation in that work. So there.

9

A slightly less bombastic limitation of liability than the BSD, which acknowledges that you might still have a bit of liability for the software that you write.

13

Clause 13 allows code licensed under the MPL to be relicensed under one of a choice of licences identified in the boilerplate text by the original copyright holder. For example, the Mozilla Foundation use a 'triple license' that protects code using the MPL with an option to change to the LGPL or GPL. Note that licences can't be changed retrospectively, you can just license a new copy of the code with one of the alternate licences; the original copy remains under the MPL.

The reason for this clause is to allow 'compatibility' with other licences, so that code licensed using the MPL can be combined with code licensed using other licences with more stringent requirements for code freedom, such as the LGPL and GPL. This is a consequence of the desire of the Mozilla development community to cooperate with the free-software community, while also offering more flexible licensing terms for others.

Lesser General Public Licence (LGPL)

The LGPL is similar in force to the MPL, although it ensures that any derivative work is distributed in a form whereby it can usefully be used. This makes it a little more viral than the MPL, as pieces of code that are not necessarily modifications according to the MPL definition may need to come under the LGPL to meet this requirement. Moreover, the LGPL contains a clause that ensures that any work that uses the licenced code should be rebuildable using a modified version of the code. This requirement implies that code linking to the covered library be distributable in a relinkable form, and not all licences permit this. The LGPL may therefore imply restrictions on the code that can be combined with a library licensed under its terms.

The LGPL is a bit easier to read than the MPL although is still quite long. Here are some of the key clauses:

0

The definitions in this clause establish that works covered by this licence are 'libraries', that is reusable collections of software. As mentioned above this is the significant difference between the LGPL and the MPL, as derived works for the MPL don't need to be as easily reusable as LGPL libraries.

1

The source for the library must be distributed.

2a

'The modified work must itself be a software library.'

2b

Modified files must contain prominent notices saying who modified them and when (again to protect the reputation of the original authors).

2c

Any modified work must be licensed using the LGPL or GPL (virulence).

2d

This complicated clause endeavours to protect the functionality of any modified library. It says that anything that the the modified library relies on to provide the stated functionality of the library must be either licensed in the same way as the library, or else totally optional. This applies to things like code-tables. The licence goes to pains to clarify that this doesn't apply to other things that might be distributed with the library, but upon which the library does not depend.

3

Any work licensed with the LGPL may be relicensed with the GPL. The reverse is not true, so this may result in a fork in the project if the modifications are applied to the GPL licensed version.

5

Libraries sometimes publish header information upon which client code depends. This code can contain data definitions and the definitions of simple functions which may be compiled into client code that otherwise doesn't depend on the library. This clause puts limits on how much of this interface code you can use in a product without it starting to look like a modification of the library, and hence being required to bear the LGPL. If you are concerned that there may be some ambiguity regarding the boundary between the code you license using the LGPL and other code, or conversely between your code and an LGPL library, then it is worth reading this clause carefully

6

This clause describes licence conditions on executables using a library licensed using the LGPL. The executable doesn't necessarily have to be licensed using the LGPL or GPL, but if it isn't it has to conform to the conditions listed in this clause. First of all, it has to display a notice clearly indicating that it uses an LGPL library. Secondly, it must do one of the following things, designed to allow the user of the executable to modify the library and recombine it with the non-LGPL bits of the executable (potentially changing the behaviour of that executable, even though it might not have an open-source licence):

• • a) Distribute the executable in a form that can be relinked with a modified version of the library. This might mean providing the whole source code of the project (even those bits not covered by the LGPL), or providing the project in some kind of pre-linked form (such as object code), that can be recombined with a modified version of the library.
  • b) Use a shared-library mechanism to combine the library with the other code, perhaps at runtime, in such a way that the library can be changed.
  • c) Provide an offer, valid for 3 years from the time of distribution, to provide the materials specified in a) (i.e. the source or object files for the rest of the project) at no more than the cost of such a distribution. Clauses d) and e) offer other alternatives for distributing this material, but basically unless you opt for option b), it has to be available.

7

The library may be inextricably linked to other non-LGPL code, provided a version of the project is also provided in which it is not inextricably linked, but instead conforms to the conditions in clause 6.

9

This is the clause quoted above in the discussion on agreeing to open-source licences. It tries to establish the licence by saying that using the library is the same as agreeing to the licence.

The GNU General Public Licence (GNU GPL)

The GNU GPL is the main licence supporting the agenda of the free-software movement. It is the most viral of the licences discussed here.

[GNU] Apparently in the USA, an additional legal instrument exists called a general public licence. This can lead to confusion, so it is sensible to refer to the GNU General Public Licence as the GNU GPL. However, in this document I use GPL and GNU GPL interchangeably to refer to the GNU GPL.

The key clauses are as follows:

0.

The licence applies to the copying, distribution of a work called a 'program' or any work based on that program. It doesn't apply to running the program, or to the output from the program, unless that output is somehow a work based on the program.

1.

The program can be redistributed without modification, possibly with a fee for distribution, providing the licence isn't changed.

2a.

You may redistribute modifications provided modified files contain prominent notices stating that you changed the files and the date of any change. This is to protect the reputation of the original author.

2b.

Any modifications redistributed must be licensed as a whole at no charge to all recipients under the terms of the GPL. This clause establishes the virulence of the GPL, and is its most controversial aspect because the requirement to licence works as a whole has the effect of bringing any new code, or code combined from elsewhere under the terms of the GPL.

3.

The source code of the program must be made freely available in one of the same ways described above for the LGPL.

5.

Attempts to establish an agreement based upon the recipients use of the program.

6.

Even though you may charge a fee to redistribute the program, you must grant all recipients this licence, hence giving them the right to redistribute for free. In practice this clause means that free software is most often distributed for free.

7.

Clause 7 attempts to prevent people from profiting by imposing additional legal constraints on the software, in particular patents. It states that if a patent is taken out on some idea in the software that means that a fee is payable for licensing, hence contradicting a condition of the licence that modifications must be licensable for free, then distribution becomes impossible.

Perhaps unfortunately, this clause does not prevent people from patenting ideas that are realised in free software via the reimplementation of the ideas contained in the free software, so is not at present an alternative to seeking patent protection under any circumstance. However, it does prevent the retrospective acquisition of free software through the use of patents.

9.

Version control. A piece of software may be licensed under GPL version 2, or later with the interpretation that the licensee may choose to abide by a later version of the licence. [FSF] The current GPL version is 2, with work underway to define a version 3.

10.

Acknowledges that the original copyright owner may be prepared to relicense under different terms.

11.

No warranty.

12.

No liability.

It is worth noting that protecting software with the GPL does not automatically imply that the software can become part of the larger GNU project. A case in point is the splitting of the development of the EMACS editor in XEMACS and GNUemacs, a situation arising from a disagreement between RMS and the XEMACS group concerning the ownership of copyright. [FSF]The FSF insist that all copyright to code in FSF projects be assigned to the FSF. According to them, this is necessary because in the US it is hard for anyone but the original copyright holder to act in the event of a violation of licence terms. The FSF wishes to have responsibility for protecting all projects in its compass.

[XEMACS] On the contrary, the developers of XEMACS don't appear to consider the risks of licence violations to be high enough to require such gunboat diplomacy. Moreover, although they have to use the GPL because their product is derived from GNU EMACS, they approach the open-source position of not particularly caring whether future products are free or not.

This disagreement reflects both the philosophical differences between the open and free software camps, and the untested status of free software licences as a means to protect intellectual property, as discussed above.

Conclusions

I had hoped this document would be a little pithier. However, my investigations have led me to the conclusion that licensing and copyright law is a complicated business. Moreover, firm answers to every question may be impossible to find, due to the fact that part of the law is established by negotiation only when necessary, so some things may not yet have been determined.

Open-source licences vary in the extent to which they force users of the software to also adopt open-source licences for derivative products, but are invariant in the fundamental property that they make some source-code available to anybody, for any purpose. In this review I have discussed the main licences recommended by Sourceforge.net, and I think covered the spectrum of virulence, from public domain declarations that attempt to renounce copyright entirely, to the GPL, which seems to be aiming to establish a new, open-source economy of software development.

My opinion of open-source licences is that they are a strange form of contract. They are necessary because of the strong protections that copyright laws provide to software developers. Their legal strength may be dubious in various ways, and the main reason for this seems to be that the law hasn't anticipated the need to provide protection for people with a genuine desire to give intellectual property away for free to people they will never meet, or to protect the recipients of such generosity. However, there does not seem to be any more effective way to protect open-source software than by using open-source licences.

My original objective was to find a satisfactory way to make some of my own software open-source. In the end, I chose the MPL, with possible alternative licensing to the LGPL or GPL. This 'triple-licence' is the same as is used by the Mozilla foundation for its entire code-base. In fact it turned out that my employer, UCL, owned the copyright, so I needed to obtain permission from my head of department first, and acknowledge UCL's rights in the licence boilerplate. I was fortunate that my employer cooperated. If your employer is also a university, RMS has some additional advice concerning free software [FSF].

I chose the MPL licence because both I and the university are somewhat agnostic about the free software movement, and did not want to restrict the use of the code in commercial products. However, I am interested to see developments of the code, and would like to track its usage, so I am keen that people make modifications public, and acknowledge my original authorship. I could have used the LGPL as an alternative, but felt that it may be too difficult to reuse my code if it had to be encapsulated as a single functional unit (this probably indicated some insecurity regarding my own design skills). However, I am happy for people to use the code under the LGPL or GPL licence. I would be slightly less happy if people continued the development of the project under those licences, although if the project enjoys any success whatsoever as open source I will probably be so pleased that nothing will bother me.

My project is now on sourceforge, at http://sourceforge.net/projects/uclmda. It is a set of tools for Model Driven Architecture style development.

Many thanks to all reviewers of previous versions of this document.

Original author: James Skene. Copyright (C) University College London, 2005