Workshop: Legal aspects of free and open source software
____________________________________________________________________________________________
37
weak copyleft is compatible with strong copyleft, and with proprietary and non
copyleft only to some extent;
strong copyleft is not compatible with weak copyleft, with no copyleft and with
proprietary software outbound licenses. Moreover, different strong copyleft regimes are
almost assuredly incompatible with each other.
49
It is time to define what weak and strong copyleft mean.
The model described at the beginning of this paragraph is a very simplified model, the
reality is far more complex. Instead of rewriting each and all of the very basic functions
that are almost invariably found in a program (like opening a file, saving a file, displaying
an error message, etc.), programmers reuse libraries of software, concentrating only on
the central part of programming.
50
A library licensed under the GPL would trigger copyleft
over the work in which it is used. Developers, including the FSF when it first started
releasing the libraries of the GNU C Compiler (gcc) or the GNU C libraries, or glibc, felt that
this was too far reaching. They were confronted with the need to produce libraries that
could be included in any kind of outbound-licensed software. Therefore a special license for
libraries was conceived, the Library GNU Public License, or LGPL. The LGPL differs from
the GPL because the scope of its copyleft is limited to the library itself, not to the entire
software which results from the inclusion of the library, or “the larger work”. In other
words, instead of covering all the derivative work, the copyleft effect only covers the
modifications to the original work. Because of the diminished effect of the copyleft
provisions, the LGPL was renamed as “Lesser GPL”. This lessened copyleft effect is
commonly referred to as weak copyleft. The full copyleft is referred to as “strong
copyleft”.
2.2
How many licenses are there? The proliferation issue
So far a very limited number of licenses have been described: the BSD/MIT in the non
copyleft area, the LGPL in the weak copyleft area and the GPL in the strong copyleft area.
Other projects have created their own licenses, all of which roughly can be put under the
three categories of Free Software, as outlined earlier.
The most popular ones are probably:
the Mozilla Public License, used and “stewarded” by the Mozilla Foundation, the
entity behind Firefox and many other projects; it is a weak copyleft license.
the Apache Public License, used and stewarded by the Apache Foundation, the entity
behind the Apache web server; it is a non copyleft license.
These licenses cover the large majority of software out there. But there is a very long tail
of other licenses, frequently project-specific and seldom used outside their namesake
projects.
The Open Source Initiative (OSI),
51
the organization which collects a list of licenses
compatible with the “Open Source Definition”,
52
lists roughly 70 approved licenses, but the
full list of used licenses is easily one order of magnitude longer.
This phenomenon is often referred to as “proliferation”. Proliferation is considered a
problem for Free Software due to its three main consequences:
49 See further below for a more detailed discussion of this point.
50 In C programming, the most paradigmatic example, all these libraries are called upon at compiling time and
produce different software objects, that are linked together and written in a big executable file (statically linked)
or made available alongside the executable file as “dynamically loadable” libraries that are linked when needed by
the operating system when they are needed at execution time (dynamically linked). This is a source of
complication as to whether using a dynamically linked library creates a derivative of said library, but the
discussion of how this works in practice is very sophisticated and exceeds the purposes of this paper, also because
it is a source of disagreement between experts in the field.
51
http://opensource.org
52 The Open Source Definition is a list of ten characteristics that must be present in a license to qualify as “open
source”. Operatively, this list can safely be considered equivalent to the four freedoms of Free Software.
Policy Department C: Citizens' Rights and Constitutional Affairs
____________________________________________________________________________________________
38
Incompatibility. With more licenses and more licensing conditions, the odds of
software released under legally incompatible licensing conditions increases
exponentially. This reduces the chances to reuse software in the commons, by creating
reciprocally incompatible commons.
Uncertainty. More licenses means less chances that the scrutiny of the courts validate
the working of a particular license. Moreover, while the most used licenses undergo the
analysis of legal experts and very detailed discussions amongst them as to what is the
scope, validity, meaning of their language, often even before their official release, the
seldom used ones are more likely to be totally untested.
Confusion, increased transaction costs. Free Software is supposed to reduce
“friction” in sharing and reusing software. The more licenses are relevant to a given
project, the more it is difficult to assess whether said project complies with the
conditions of each and every license, or to predict the legal outcome of combining
different software.
It is apparent from the above discussion that any decision to create a new license, instead
of using one of the most popular and thoroughly tested, needs to be taken with due care,
because the advantages of creating something that is (in the eye of the drafter) perfected
is easily outweighed by the systemic disadvantages of creating yet a new license.
2.3 The case of EUPL, relicensing permissions and the exceptions
In this light, I have been very sceptical about the decision of the EU authorities to create a
new license, namely, the EUPL.
53
On the one hand, I understand the rationale behind it, on
the other hand, it suffers from the same disadvantages discussed above in terms of
proliferation. Moreover, being a purportedly strong copyleft license, it would be outright
(and both ways) incompatible with the most widely used copyleft license, the GNU GPL, and
very likely incompatible with many others. This was well understood by the drafters, who
decided to use a clever solution to avoid the EUPL being cut off from software development
in combination with a large share of the software publicly available.
The EUPL adopts an express compatibility list. This overrules some compatibility
problems by allowing a larger work containing EUPL code to be “relicensed” under another,
otherwise incompatible, license. In other words, the EUPL recedes in front of incompatible
licenses, by allowing the incompatible license to become the outbound license of the larger
work. In all practical terms, while this can be regarded as a workable solution, the
possibility to relicense the software means that the legal conditions actually applied by the
downstream developers can be different, and less protective, than those expected. For
instance, among the compatible licenses listed in the Annex to version 1.1 of the EUPL
there are weak copyleft licenses, like the Eclipse Public License,
54
or non copyleft licenses
like the Open Software License.
55
In a way, the compatibility list makes software licensed under the EUPL multi-licensed. This
is not per se something to be rejected, as long as the consequences of this being multi-
licensed are well understood and predictable. For instance, the GNU GPL has the option to
include a clause “or any later version”. If this clause is added, then the recipient of the
software can, without asking a permission from the upstream copyright holder, relicense
the software under a newer version of the same license which has been issued by the
official steward of it (so far the Free Software Foundation), as it happened with the
publication of version 3.0. The same possibility is given by the Mozilla Public License.
56
The
difference between these cases and that of EUPL is that the "any later version" clause only
applies to later versions that follow the same strong copyleft regime. When it comes to the
EUPL, however, its compatibility list makes it possible for software licensed under a strong
copyleft regime (i.e. under the EUPL) to become subjected to weak copyleft, or even to
non-copyleft. It is reasonable to assume that if copyright holders choose a copyleft license,
53 EUPL stands for “European Union Public License”
http://joinup.ec.europa.eu/software/page/eupl
54
http://www.eclipse.org/legal/epl-v10.html
55
http://opensource.org/licenses/OSL-3.0
56
http://www.mozilla.org/MPL/2.0/
See Section 10
Dostları ilə paylaş: |