Constitutional affairs legal affairs



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

Workshop: Legal aspects of free and open source software 
____________________________________________________________________________________________ 
 
41

 
software can be inspected, modified and adapted to the customer's needs without 
asking permission to the licensor. 
The fact that software can be forked means that downstream recipients could decide that 
they can take over the development of the same solution and continue its development and 
distribution only relying on the inbound license. This alone creates a game where there is a 
certain assurance that development will be continued even against the will of the copyright 
holder, or in case this latter is unable or uninterested in bringing it forward. This removes 
some of the uncertainties that always exist around proprietary products, including that they 
can become “orphans” or that they can follow undesirable development paths. Indeed some 
of the largest dual licensed software projects have been forked over concerns as to the 
stewardship of their copyright holder: Libreoffice has been forked from Openoffice.org 
(formerly owned by Sun Micrososystems, which was taken over by Oracle Corp; presently 
the stewardship is with the Apache Foundation) and MariaDB was forked from MySQL (the 
most successful Free Software database application and one of the most successful 
databases at all) by Monty Widenius, its original creator. Forking is indeed one of the most 
important (and feared, by the leaders of the projects) safety measure against misconduct 
or simply a rather drastic way to resolve disagreements.  
The second aspect, the freedom to modify the software and adapt it to the user's needs, is 
also interesting. Besides allowing anybody who receives the software to perform an 
independent inspection, this freedom encourages sufficiently literate users to fix bugs by 
providing patches, or even producing drivers and other tools. Because these modifications 
can be “broken” by changes in subsequent versions, it is highly efficient that these 
modifications are given upstream to the copyright holder, so that they are included in the 
development and maintained over new versions.  
This can only be done in two ways: by assigning the copyright of the modification, or by 
releasing the patch/additional software under ultra-liberal conditions, so that they can be 
included in both the Free and the proprietary version of the mainstream application without 
depending on the conditions imposed by the contributor. 
Although it is not necessarily so, it does not seem that more important contributions than 
patches and bug fixes are ever given to dual licensed projects. In fact, it is very hard to 
find dual licensed projects that receive substantial contributions, so that the development 
of those projects hardly leaves the shoulder of the main copyright holder. 
3.3  Open Core (Free core platform or infrastructure, proprietary 
outer layers) 
On the opposite side there seems to be something that is regarded as increasingly popular
which is open core. If in the dual licensing model the bulk of the software is kept and 
maintained by one single entity, and something comes from third parties only at the edges, 
in open core the fundamental technology is released freely, and the proprietary part 
happens at the edges. In other words, there is an attempt to build a shared infrastructure 
(“the core”) with differentiation and added value only occurring on the outer layers, or 
the actual implementations based on the common infrastructure, akin to standardization. 
There are examples where a common shared infrastructure is made by many independent 
companies and/or communities of developers under very liberal, non copyleft conditions. 
PostgreSQL (an increasingly popular database application) is an example: it is licensed 
under the BSD license, which allows any company to sell an entirely proprietary application 
based on it. Sometimes the common infrastructure is conversely kept under very strong 
copyleft conditions, to avoid that any forks are taken away from common development, and 
only the “outer layer” is distributed as proprietary add-ons.  
Linux can roughly fall under this category, as it is used both in the GNU/Linux incarnation 
(for the PC systems, in desktops and servers) and as the foundation of proprietary 
solutions built on the top of it; the most widely known is perhaps Google's Android, mainly 
used to run smartphones and tablets. Android is interesting also because it creates a 
middle layer of software released under very liberal condition (similar to the Apache 


Policy Department C: Citizens' Rights and Constitutional Affairs 
____________________________________________________________________________________________ 
 
42
license) that can be taken by all vendors to make their own tight-controlled versions, 
bundled with their own hardware. 
3.4 
Community vs. company controlled development 
The above examples show how proprietary exploitation and one-company development are 
not necessarily tied together. On the one extreme, FSF has strong control over GNU, but 
absolutely no proprietary exploitation. On the other extreme there is large proprietary 
exploitation through selling of copies of software with a project run under very liberal and 
non centralized ways in PostgreSQL. On yet another axis, we have bazaar-like development 
of software under strong copyleft conditions (Linux is one example, KDE is another), and 
one-company-controlled development of software under very liberal conditions (in the case 
of Android). 
Then again, it is possible to have consolidation of copyright into a single entity while 
retaining a bazaar-like development model. KDE is such an example,
61
 where developers 
are at least invited to provide an assignment to KDE e.V., through the “Fiduciary 
Licensing Agreement” (or FLA)
62
 which is a legal instrument developed by the Free 
Software Foundation Europe, and whose aim is to centralize copyright title while preserving 
the distributed nature of copyright interest – and the nature of Free Software of the code 
whose copyright is assigned. In a FLA the individual assigners are the “beneficiaries”, 
whereas the assignee, who receives a title in the software, acts as a trustee of the 
beneficiaries. 
 
4.
 
ARE FREE SOFTWARE LICENSES VALID? WHAT MAKES 
THEM ENFORCEABLE? 
The question of the validity and enforceability of Free Software licenses is not contested 
anymore. The issue has been raised several times and addressed in multiple courts which 
ruled in favour of enforceability of free software licenses. As a license is frequently 
considered as an agreement, contractual laws of various countries can work against it, on 
many grounds, like formal deficiencies, lack of consideration, consumer protection, 
language preservation laws. 
But are licenses “contracts”? 
Let  us  start  from  what  the  most  famous  family of Free Software licenses say. The GNU 
licenses have a very telling section commonly referred to as “not a contract”. The drafters 
had the issue of different contract laws very clear, and decided not to rely on any particular 
contract law in order to preserve the validity and enforceability of the license. Instead, they 
relied on the uniform law provided by copyright treaties, mainly the Berne Convention.
63
 
Those treaties grant a minimum set of protection to copyright holders, among which are 
the rights to exclude others from use, copy, distribution, modification of software. Were the 
license absent or invalid, no right would be transferred. If recipients of the software were to 
contest the validity of the license, they would automatically plead the fact that they are 
infringers of the copyright of all copyright holders. 
Most of the licenses provide a set of conditions, rather than obligations. This makes any 
contractual qualification of the license redundant,
64
 as the license can very well work as a 
                                                 
61 KDE stands for K Desktop Environment. It is one of the most popular desktop environments for GNU/Linux. A 
Desktop Environment is the part of the operating system that provides its Graphical User Interface (GUI), 
including the windows within which applications are displayed, their decorations, the “desktop” where icons 
representing various objects reside, and a number of applications, tools, snippets, utilities, configurations etc. that 
assist the user in interacting with the computer's operating system. KDE also provide an integrated suite of 
applications that are particularly designed to be executed in the KDE environment, such as personal and office 
productivity applications, an email client, a web browsers and many other utilities. 
http://kde.org
  
62
 http://ev.kde.org/rules/fla.php
.  
63 See, for a clear an concise explanation, Eben Moglen, Free Software Matters: Enforcing the GPL, I  
http://moglen.law.columbia.edu/publications/lu-12.html
  
64 As I already maintained in one of the first articles in Italy on that matter: Carlo Piana, Licenze pubbliche di 
software e contratto, in I contratti, n. 7/2006, IPSOA; available at http://www.piana.eu/repository/720_727.pdf 


Yüklə 228,85 Kb.

Dostları ilə paylaş:
1   ...   14   15   16   17   18   19   20   21   ...   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ə