Software licensing: Difference between revisions

From OLPC
Jump to navigation Jump to search
(..)
(redirect & merge)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
#redirect [[Licensing]]
<center>'''<big>Open software licensing</big>'''</center>

First, you should understand what we mean by [[OLPC on open source software|Software Freedom and open source software]], and [[Content|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) [http://creativecommons.org/ 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.
[http://www.opensource.org/licenses/ 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 [http://www.opensource.org/licenses/gpl-license.php 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" [http://www.opensource.org/licenses/lgpl-license.php 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 [http://www.cairographics.org/ 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.

Latest revision as of 09:14, 14 August 2007

Redirect to:

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Software_licensing&oldid=58986"