Constitutional affairs legal affairs

Workshop: Legal aspects of free and open source software 
____________________________________________________________________________________________ 
 
39
and the more so if they choose a strong copyleft one, such as the EUPL is supposed to be, 
they want to exert control on the legal conditions of their software when it is included into 
other software. By leaving a backdoor open that allows the software to be relicensed under 
a license of different nature, the expectations of the copyright holder are somewhat 
“betrayed”. 
Another way to introduce compatibility with other software, where compatibility does not 
exist, is to use exceptions. An exception is an added condition that lessens the copyleft 
effect of (most frequently) strong copyleft licenses, to make them compatible with certain 
other licenses. One of the most used exceptions is the linking exception. As reported 
above, linking is a widely used form to include libraries into larger works without 
commingling software, keeping some level of separation at least at source code level. A 
linking exception would permit to link software licensed under two incompatible licenses 
and to distribute the resulting larger work under the conditions of the other linked software. 
Adding a linking exception is obviously permitted only if the decision is taken by the 
copyright holder(s) of the entirety of the concerned software, and it is akin to adopting a 
weak copyleft license. Indeed, the GNU LGPL v.3 is now construed as an exception to the 
GNU GPL v.3 license. The GNU GPL v.3 actually includes a framework to allow adding 
exceptions, which can be more restrictive than those of the “vanilla
57
 GPL” (in certain and 
limited cases) or more liberal. In case more liberal exceptions are added, it is optional to 
the downstream recipient to remove them and to distribute their works under the original 
version of the GPL.
58
  
In conclusion, when a project is reported as being licensed under a given license, in order 
to identify the legal regime that actually applies to it one must consider at least whether: 

 
The license adopts a compatibility list or the software is dual- or multi-licensed; 

 
The license and/or the copyright holder allows relicensing under certain circumstances 
(for instance: it is permitted to relicense the software under a newer version); 

 
Additional permissions, or exceptions, apply. 
 
3.
 
SAME LICENSE, MANY “BUSINESS MODELS” 
Discussing commercial exploitation and monetization (if any) of Free Software and/or how 
software development is financed is outside the scope of this work. However, some 
discussion about the social and economic environment where Free Software is made is 
useful, in the light of the additional legal effects involved in following certain models as 
opposed to others. 
In reality, under the general heading of “Free Software” or “Open Source Software”, the 
matrix of combinations of different characteristics can be very complex. We just mention 
the most relevant axes in this multi-dimensional space. 
3.1  Cathedral against the Bazaar (very few or only one vs. many 
developers) 
A frequent misconception of those who approach Free (or open source) Software for the 
first time is to believe that it is a way to allow distributed creation  of  software  by  many 
different developers that work in an unorganized, chaotic way, maybe in their garage, to 
produce something that is half backed, incomplete and inherently difficult to use.  
Contrary to that, development of Free Software is not necessarily different from 
development of software licensed under proprietary conditions. The fact that certain 
software is Free Software simply allows many more degrees of freedom and choice. Choice 
creates many different approaches. 
                                                 
57 “Vanilla” is Computer Sciences jargon and means “original as it came from the source, untouched”. The Oxford 
English Dictionary accounts it as “having no special or extra features; ordinary or standard”. 
 
http://oxforddictionaries.com/definition/english/vanilla?region=uk&q=vanilla 
58 See the GNU GPL v.3, Section 7 at 
http://www.gnu.org/licenses/gpl.html
  

---

Policy Department C: Citizens' Rights and Constitutional Affairs 
____________________________________________________________________________________________ 
 
40
Perhaps the first discussion of one of these choices has been made by Eric S. Raymond in 
his work “The Cathedral and the Bazaar. Musings on Linux and Open Source by an 
Accidental Revolutionary”.
59 
In this essay, Raymond analyses the differences between the 
centralized, rigid and structurally coherent development of GNU, Emacs and GCC by the 
Free Software Foundation, and the more fast-paced, loosely engineered, and chaotic 
development of Linux. The two models are indeed at the extreme and both are – judging 
by the results – quite functional and successful. 
One of the differences between the cathedral and the bazaar models is how copyright is 
dispersed (in the case of the bazaar) or whether it is kept by a relatively close number of 
holders, because contributors are also a small number. Bringing the concept further, 
consolidation of copyright into a single entity is also a possibility. This can be done by not 
allowing others but the original copyright holder to contribute, or through assignment. 
Indeed, the Free Software Foundation strongly urges the assignment of all the code 
committed to the GNU project to itself so that there is ideally only one entity legally 
entrusted with the management of copyright.
60
 This can be advisable (provided that the 
assignee deserves a high degree of trust) for a number of reasons, one of which being the 
possibility to take fundamental decisions as to management of copyright, such as adopting 
a new license or using the ownership of the software as a title to proceed in court against 
trespassers. 
The possibility of taking (or keeping) tight control of the entirety of the software in a 
project by retaining copyright ownership has been used in different circumstances to 
achieve models which can be considered hybrid between proprietary and Free Software, as 
it is the case with dual licensing and “open core” strategies, which will be discussed in the 
next two chapters. 
3.2 Dual 
licensing 
“Dual licensing” (or “multi-licensing”) is a licensing model where software is distributed 
under more than one license at a time. We have seen how this can happen in order to 
overcome potential incompatibilities in linking or mixing software. However, using dual 
licensing as a way to monetize Free Software has peculiar consequences. Dual licensing 
under a Free Software (most frequently a strong copyleft) license and under a proprietary 
license is one of the options. 
The rationale behind dual licensing is that if software is licensed under a strong copyleft 
license – therefore a license that does not allow proprietary exploitation of the derivatives –  
albeit being free (at no cost), its use would bear conditions that could be unacceptable to 
certain potential downstream developers. These developers, for instance, might want to 
utilize the copylefted software in their derivative software in a proprietary way. In order to 
be permitted to do so, they need to be released from the copyleft conditions and therefore 
they can be in a position to pay a monetary price for this privilege. This can be described as 
“buying an exception” to copyleft. 
The more burdensome and far reaching the conditions are – and the more valuable the 
software is – the higher will be the incentive for seeking the exception. Since in order to 
grant an exception the licensor must control the entire copyright of the software, there is a 
high  chance  that  this  will  only  be  possible  in the case of a “silos” development model, 
where everything is made internally by the licensing entity or contracted by it, and such 
entity therefore holds the entire copyright of the software.  
Yet the licensing, even in this concentrated development model, creates two interesting 
additional side effects compared to an equivalent proprietary development, from the point 
of view of recipients, as a result of two characteristics of the Free license, namely that: 

 
software can be “forked” 
                                                 
59
 http://www.catb.org/~esr/writings/cathedral-bazaar/
  
60
 http://www.gnu.org/licenses/why-assign.html
  

---