Bobulate

A software license lets you do something that you otherwise would not be allowed to do, given the limited permissions granted by Copyright law. That is, it changes the “all rights reserved” into “some permissions granted and all other rights reserved.” Which permissions those are depends on the license; which exceptions to “all rights” exist depends on the jurisdiction under which you’re operating (e.g. while “Fair Use” is something you can do in the United States, that concept doesn’t exist everywhere).

There’s lots of software licenses. There’s even lots of Free Software licenses. The Free Software licenses all grant you permission to do at least four things: use, study, modify and share. Sometimes they allow more. The BSD license allows proprietization. The Apache license allows the use of patents embodied in the software (important in jurisdictions with patents). The GNU General Public License allows you to format shift (e.g. you may publish a GPL licensed program as a T-shirt).

The flip side of permissions is that of conditions: often the permissions are granted provided that you do something else. For instance that you pay for the permission (a proprietary, commercial license would require that). Or that you give the source code of the program to recipients of the binary (as the GPLv2 says). Or that you send your modifications to the original author if you distribute the code in modified form.

The conditions may also include a condition that the same license applies to derivative works. The GPLv2 has such a condition. The EUPL has such a license (plus an escape clause). The CDDL has one. This kind of condition creates an “species” around a single license of like-licensed software. Such a species has software individuals that can be freely combined and modified and shared, since it all falls under the same license.

This kind of condition also creates a division, one between species, because you can’t “breed” between species. The conditions of licenses of two different species cannot be satisfied simultaneously, so you can’t do it. As a consequence, we see that the same functionality is developed multiple times under different licenses. Some might call that wasteful. It’s out in the open, though, and reimplementation only needs to happen once for each species, so the waste of effort is limited. Who knows how much sloth and useless duplication occurs behind closed doors? In any case, we find that a license with conditions creates its own species and that most software combination works within that species.

So-called “permissive” licenses can cross the species divisions, simply because they do not have any conditions that prevent them from being integrated into another species.

If you’re a software developer who is combining pieces of software which are under different licenses, you need to be aware of the species differences. Indeed, sorting out which code can be combined with which can be a considerable effort. The FSF lists dozens of Free Software licenses and whether they’re compatible with the GPLv2 and the GPLv3 — and even the GPLv2 and GPLv3 are different species.

So we have two problems with having lots of species: that of duplication of implementation effort (yes, I too have had to ignore an available Free Software component that did what I needed and had to re-implement it badly because of license incompatibility) and of effort involved in checking for compatibility.

The underlying problem — that of having many license species — is what we call license proliferation: there’s lots of licenses, and more show up all the time. Black Duck software identifies some 1200 of them. The OSI has 60-odd licenses. That’s a lot of extra effort.

So when people ask the FSFE about software licenses, in particular about creating a license with new conditions or that varies an existing one, we say “don’t do it.”

That bears repeating:

Do not write a new (Free) software license. Just don’t. Really. Pick an existing license that does what you need. And if there isn’t one, then what you want is probably not a good idea.

I’m aware that’s an argument from authority. That’s not always a good kind of argument to use. However, you need to be aware that in creating a new species (by creating a new license) you’re committing yourself to the whole rigamarole of re-implementation, and excluding people from outside the species.

Now, as with almost every rule (except rule 34), sometimes the rule is just a guideline. People who know what they’re doing can bend the rules.

There can be really good reasons to bend the rules. For instance, new dangers show up that threaten the Free Software ecosystem. These dangers may be a reason to introduce a new license to counter them — patents, for instance. Who would have though, too, of valuable trademarks in Free Software? They’re explicitly mentioned in the more modern licenses. A simple permissive license that disclaims warranty might not be sufficient if regulatory frameworks change. And in some areas of business, existing regulations might require things of a software license that the existing ones do not provide.

So there can be good reasons to change. And in spite of my position that license proliferation is bad, I’m going to applaud the Mozilla Foundation for choosing to look into updating the MPL (coverage from the Register here).

The MPL is a file-based license, not a work-based license, so it creates species in a different way. Clause 6.2 of the existing MPL allows a transparent upgrade procedure, so I think the proliferation aspect of this license update doesn’t need to be stressed. They’re doing the right thing. The content of the license change isn’t firmly fixed yet: Mozilla is still in the comment phase. Results are expected later in 2010. I’m looking forward to meeting some of the people driving the process in Mozilla next month, for a chat over a glass of wine as to which bits of compatibility are the most important.

So here’s to licenses; let a thousand choices bloom.

PS. Ideally, I think that each license would make a clear statement about what it means in each of the essential areas of licensing. Unfortunately, those “essential areas” have changed over the years, so many do not do so. I hope for a clear new world where we have a small collection of modern licenses (say, Apache v2, GPLv3, MPLv2 and a new permissive license) that define the main species of Free Software.

PPS. Although I think that this applies to every blog post, I think I should add explicitly here: this post does not reflect an official FSFE position on the Mozilla license.

Thanks to all those who commented on my recent proposal to “iconify” licenses. That is, representing the essential terms of various Free Software licenses as icons so you can quickly get a feel for their meaning. This is, in the current state of software licensing, no replacement for actually reading and understanding the licenses, but as a mechanism for quick (as opposed to deep) understanding it seems to work well enough.

ComputerDruid pointed out that we’d need an icon for the network-copyleft effect of the Affero-style licenses (AGPLv2 and AGPLv3). The salient point of the GNU Affero General Public Licenses is that the requirement to distribute source is also triggered by interacting with the program over a network. The license text has an addition (in version 3) to clause 13:

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version …

None of the licenses examined so far has such a clause, so that’s why I hadn’t drawn one up yet.

The “Free Software” icon is the only one that grants permissions. It says “this license grants you the Four Freedoms”. The other icons all describe conditions on the license. Copyleft, network effect. The patent grant is both a permission outside the scope of copyright, as well as a condition related to downstream use of those patents and your own patent rights (if any) in the program (in those jurisdictions where there are software patents). In this sense, fewer icons means fewer conditions, and hence more free to use — but at the cost of not guaranteeing the Four Freedoms downstream, for the most part. Compare, for instance:

• This program is Free Software; you have at least the Four Freedoms, but copyright notices must be preserved and the license text distributed with the program.
• This program is Free Software; you have at least the Four Freedoms, but copyright notices must be preserved and the license text distributed with the program. In addition, you are required to provide source (under some circumstances). The source provision applies to your own code as well that is added to the program (strong copyleft). The source provision applies also if you provide access to the program over a network (Affero). There is an explicit patent grant involved.

Whoo. That’s quite some text, but still a great deal shorter than the GPLv3.

Paul Boddie points out that the “weak copyleft” symbol is probably redundant (I agree). That would make the number of source-related icons three (and the number of the counting shall be three). There would be “provide source” (i.e. weak-copyleft), and then two modifying icons for strong and network copyleft. I like it — something to take into account in the wrap-up to this series.

See, by now we’re almost getting into a grammar of these things, which is something I would like to avoid. Keep it simple, keep an overview that allows selection and understanding at a high level, and then look at the relevant license texts in detail.

So, let’s move on to the license texts in detail for a moment. Yesterday I wrote up that the Apache license, version 2.0 and the Mozilla license, version 1.1 were roughly the same. Both got the same set of icons based on my quick reading of both licenses. So let’s take a closer to see if there are relevant differences in the licenses. If there are, we may need to add a distinguishing badge.

General remarks: Apache has a notion of “contribution” spelled out in the license; I think this is intended to clear up what happens when you send a patch to a mailing list — is that intended for inclusion under the same license or not? In my experience, people do submit patches that they do not want to have included — on public mailing lists, no less — but it is very rare. I don’t think this is a crucial difference. The Apache license explicitly excludes linking as a means of creating a derivative work. The Mozilla license defines “commercial use” in a surprising way that includes many things I would consider non-commercial: namely, if I give my friend a USB stick with the source, that’s commercial use according to the license. Mozilla has a concept of “Initial Developer”, which I think is compatible with the Apache notion of “Licensor” — they’re both licenses that are directed at centralized projects with a clear central copyright holder.

Using the software: Mozilla clause 2.1a allows you to use, sublicense and distribute the code and modifications. Apache clause 2 allows the same, but makes explicit that object code distribution is allowed.

Patent grant: Mozilla clause 2.1b grants a license to those patents embodied in the Original Code. Mozilla excludes patents covered by code deleted from the original code — so you can’t re-implement something covered by a patent, it seems. Apache clause 3 does the patent grant and adds explicit termination conditions to that patent grant. Termination in Mozilla is covered in section 8.2. The termination in Apache applies to the relevant patents, while the Mozilla license terminates on any patent. That’s an important distinction when it comes to litigation; I’m not sure it has a place in this iconic scheme, though.

Trademarks: Neither (software, copyright) license grants a trademark license. Apache makes this explicit.

Distribution: Mozilla clause 3.1 and Apache clause 4.1 both require distributing the license text. Both require a notice of modifications made to the original source, but Mozilla wants that in a separate file while Apache allows you to annotate the files themselves. This is similar to the GPLv2 clause 2a, and is something that I very rarely see people (or Free Software projects) do systematically. I don’t think it’s a crucial difference.

Copyleft: Ha, I’m such a moron. How could I have missed this? See, Mozilla clause 3.1 and 3.2 say that the Mozilla license applies to the source code and that the source must be available, also for modified versions. While you may distribute executables under a different license, they must have corresponding source code available under the Mozilla license. So that’s a copyleft license, and the source for executables is available. But … and this is a pretty darn big but … the Apache license does not require this. Clause 4 says a number of things about distribution as source, and allows distribution in object form, but places no restrictions on the distribution of object forms except that the license needs to be included. In other words, you can use the Apache license and distribute binaries without providing source. With Mozilla, you can’t.

So it’s a good thing that the similarity in the reduced representations of the licenses (i.e. the row of icons) has led to a re-examination of the licenses, because it leads to the understanding that the licenses are not the same, by a long shot. Of course, I could have just looked it up in the FSF license list: Mozilla (copyleft, not GPL compatible) and Apache (no copyleft, GPL compatible). If I were a professor I’d claim I’d made the error intentionally in order to spur closer examination of both licenses.

Mozilla Public License v.1.1

Apache License v.2

Tomorrow I’ll carry on with the next 10 licenses in the top-20 list to see if any interesting new features show up, and then on Saturday I can wrap up with a table showing the 10-mile view of all those licenses.