Software licensing

Open software licensing

First, you should understand what we mean by Software Freedom and open source software, and free content.

Software licensing is a complex topic. It is easy to say to yourself: "oh, I'll worry about this later". The problem with this attitude is that if your software is successful, the policies you set initially may be almost impossible to change, as you have to have permission of all copyright holders to make a change to an aggregate work. For example, it took the Mozilla project several years, and huge amounts of work, to get permission to relicense their code base from all of the authors. In some other examples, entire libraries' functionality have had to be duplicated, due to lack of forethought about whether binary commercial plugins might be absolutely essential under some circumstances.

Requiring copyright assignment so that you have control can also become a nightmare: it reduces the number of possible contributors significantly, as many people have employers who won't allow copyright assignment or make it very difficult, and it reduces the number of people with standing in court in case the copyright is violated. Some projects, notably the GNU project for some software, require copyright assignment for all contributions. Sometimes this can be the right strategy if the software might be free software is also available under commercial licenses for proprietary use. There are quite a few examples of this as a business model for the funding of free software development (e.g. BerkeleyDB of Sleepycat Software, now part of Oracle).

We recommend strongly that authors educate themselves on this topic very early in their project, and understand the different requirements, obligations, and incentives of the licenses, long before they regret decisions taken with no understanding years before. Note that you should be clear about this in your projects from the start, as significant (say, greater than 5-10 lines of code) are technically copyright of the contributor. It must be clear in a project's policies to the contributor what license terms are acceptable to your project, and therefore the copyright they are making a patch or new module available under.

Below is a discussion to try to give you a flavor of the major licenses.

Content Licensing

OLPC has started a dialog among the participant countries about what the policies should be for the licensing of educational content (of the governments, schools, teachers and students).

We expect some (possibly a combination of) Creative Commons licenses may be most appropriate for educational content.

These discussions are in early days.

Too Many Software Licenses

One of the major headaches in free and open source software are interactions between licenses: whether licenses are "compatible" or not. Relatively minor clauses in a license may conflict with requirements in other licenses, potentially making it impossible to mix code from different sources. A quick look at the OSI web sites shows there are already too many open source licenses, and clauses among them may make it hard or impossible to mix code, to everyone's loss. People now recognize this as a serious issue, and new licences are highly discouraged, by OLPC among other organizations.

Some major corporations (e.g. HP) have enlightened policies that they will only issue code under a restricted set of licenses (that of existing projects if it is a contribution to an exisiting project, or for new code, only one of the big three licenses); some other major corporations (e.g. Intel) have started to relicense previously released code under a standard license replacing the open source licenses they had used in the past, reducing the existing problem.

Incentives

Understanding that there are differing social and business incentives offered by the different licenses is worth understanding; some quite subtle. But that discussion is too lengthy to hold here.

OLPC Recommended Licenses

Different licenses are often most appropriate for different circumstances. But a high majority of these are covered by the "big three" licenses: GPL, LGPL, MIT.

New Projects

For new projects, OLPC will generally only want to host projects with one of these three licenses. The MIT license is compatible with both the GPL and LGPL.

GNU GPL

The GPL license is a "copy-left" license; in short, it obligates anyone who derives from such code to make their changes available, free of charge, to anyone else that the code is made available to. Incorporating any GPL code into a program makes your program such a "derivative work", and the terms of the GPL require that your code then become available under the GPL.

GNU LGPL

The "Lesser" or "Library" LGPL license is similar to the GPL, in that any modifications to LGPL-licensed code must be made available to anyone you distribute the modified code. The LGPL, however, allows applications to dynamically link against LGPL libraries, and if distributed without those libraries, such applications do not become derivative works of the LGPL library code. Because these applications are not derivative works, they can be licensed in some other fashion (including commercial licenses). Note that static linking is treated differently; if you have statically linked against LGPL code, you are required to make your source code available under the LGPL as well.

MIT and 3-clause BSD

Roughly concurrently with the development of the GPL and LGPL licenses by Richard Stallman was the creation of the MIT license for the X Window System. A bit later, a license was created for the Berkeley Software Distribution of UNIX. The original form of the BSD license (the four-clause version) has what is called an "advertising clause", requiring the authorship of the program to be advertised in the program and documentation. This clause conflicts with the GPL, and becomes logistically impossible with many copyright holders on the same software package. At a later date, UC Berkeley issued a letter stating that this clause was no longer enforced on any copyrights owned by UC Berkeley, to resolve this problem, and the BSD license today rarely has the advertising clause.

In practice, the MIT and BSD licences are equivalent.

The MIT and/or 3-clause BSD license is sometimes called the "copy-center" license: you can take the code to a copy center and do anything you like with it without much exception (except blaiming the author for any problems in this code you got for free).

Rather than dealing with different versions; let's keep things simple and just use the MIT license for new projects that need a license that allows any sort of use, since it never had the advertising clause problem.

Patents

Note the (L)GPL has explicit clauses around patents. The MIT/BSD license is silent on the topic of patents, though lawyers will usually agree that there is a limited scope patent grant on any patents owned by someone who issues code under and MIT or BSD license. Of course, your lawyer's mileage may vary, and you should always deal with your own lawyer.

Existing Projects

In general, if you are contributing to an existing project elsewhere, you will be required by that project to conform to that project's licensing guidelines. For example, the X Window System, for all drivers and libraries and the window system itself must be under the MIT license or equivalent; Mozilla has the MPL license and will insist upon it, and so on.

For existing projects, OLPC will host any code licensed under an OSI-approved license. If your project extends in an OLPC-specific fashion, or is a part of, an existing non-OLPC project, that project may be a more appropriate home for your code. You're welcome to use selective OLPC hosting features, such as the bug tracker and web hosting, while choosing to keep your code in the upstream project's repository.

Note that we would like you, as much as possible to make your OLPC related changes to a package of software in and as a member of that community, with their cooperation and to their requirements and standards. "Forking" projects is a last resort, and we'll look long and hard at requests for project hosting of forks of existing projects. Having said this, we're happy to host temporary source code pools while significant changes or additions to an upstream project are being made by groups of people, though usually that is best done as part of those communities. And we're happy to host wikis and bug tracking about OLPC specific applications of other projects if that seems appropriate.

Dual Licensing

Due to incompatibilities between the plethora of licenses, sometimes the only solution, particularly for libraries that many differently-licensed projects would like to use, is to license the library under two (and occasionally more) licenses, allowing the recipient of the code to choose the license.

A good recent example of this solution is the Cairo graphics library. The Mozilla project wanted to use Cairo (the MPL is incompatible with the LGPL). So the solution was to dual license Cairo.

OLPC will host projects that have this kind of licensing when appropriate.

Recommendations

Generally, for free software, the GPL (and sometimes the MIT) license is most appropriate for end user applications.

The LGPL or MIT licenses are more appropriate for libraries.