Constitutional affairs legal affairs



Yüklə 228,85 Kb.
Pdf görüntüsü
səhifə16/45
tarix11.10.2017
ölçüsü228,85 Kb.
#4288
1   ...   12   13   14   15   16   17   18   19   ...   45

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 


Yüklə 228,85 Kb.

Dostları ilə paylaş:
1   ...   12   13   14   15   16   17   18   19   ...   45




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©www.genderi.org 2024
rəhbərliyinə müraciət

    Ana səhifə