Workshop: Legal aspects of free and open source software
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
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
, which can be more restrictive than those of the “vanilla
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.
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.
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
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”.
58 See the GNU GPL v.3, Section 7 at
Policy Department C: Citizens' Rights and Constitutional Affairs
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
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.
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
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
it is the case with dual licensing and “open core” strategies, which will be discussed in the
next two chapters.
“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