GPL software is considered property and not commons (public domain). Like all copyleft licenses, the GPL is a license which claims ownership over a creative work. The GPL builds upon copyright law and not contract law like i.e. End User License Agreements (EULAs) or Terms of Service (ToS) do.
To ensure User Freedoms (to build and maintain a community of equal opportunity and social solidarity; this is the main goal for the Free Software Movement), FSF advocates copyleft ownership; more specific the GPL license. The FSF used this license to meet that goal. In their view, this is necesarry since laws allow software to evolve from the public domain into proprietary software. So given current laws, ownership is necesarry in order to have User Freedom. But is the GPL the right tool for Free Software?
You can say that the GPL fights copyright with its own weapons by claiming ownership. However, the ownership of the copyright is completely hollowed out by the GPL license. All privileges that the copyright law entitles a dev to, are given away by him by using the GPL. The GPL uses copyright law, but flips it over to serve the opposite of its usual purpose. Instead of fostering privatization, it becomes a guarantee that everyone has the freedom to use, copy, distribute and modify software or any other work. Its only “restriction” is precisely the one that guarantees freedom — users are not permitted to restrict anyone else’s freedom since all copies and derivations must be redistributed under the same license. Copyleft claims ownership legally only to relinquish it practically by allowing everyone to use the work as they choose as long the copyleft is passed down. The formal claim of ownership means that no one else may put a copyright over a copylefted work and try to limit its use. This is a proven and sustainable solution to make software free.
So the copyright owner has absolutely no advantage compared to anyone else interested in reusing and /or redistributing his code, beside the fact that he also made sure that:
- the code can be relicensed in future;
- the code can be sold in future.
The problem is that using the GPL, User Freedoms are dependable on the copyright holders due to ownership; GPL only covers the redistribution rights and not all aspects related to ownership. Since commercializing is also part of the freedoms, it is obvious that not only the legal aspects in regard to copyright should be covered to ensure User Freedoms but also social, human and economic aspects related to ownership. Ownership can have (and eventually will have!) contradicting implications to Users Freedoms (this is known as “The Tragedy of the Commons”: This metaphor illustrates how individual’s interest conflicts with the common interest.). So besides having other problems (i.e. Software-as-a-Service loophole; in short, under GPLv2 you could create a derivative work and run a website based on it, but not share the changes since you weren’t technically distributing the software.), GPL software cannot comply with the spirit of Free Software just by itself! It’s just a license.
This makes sense, since the GPL doesn’t exclude commercializing the software. So in fact, it is very important to look at the GPL and make a distinction between private and not-for-profit projects.
The rest of this blogpost will focus on GPL software and not-for-profit projects.
So ownership of Free software is a difficult area, and one that is resolved simply by the Linux kernel project. The code belongs to everyone and no-one, and the copyright for each individual piece of code belongs to the original coder. Every contribution has a ‘Signed-off-by’ line from the author of the contribution (and possibly other intermediate parties in its way to the core code) plus a ‘Developers Certificate of Origin’ policy (see point ’12. Sign your work’ in Documentation/Submitting Patches on any recent kernel source tree). (Nice fact: The system to manage this process is created by Linus Thorvalds himself written source version system GIT). In case of the Linux kernel, any future reassignment of the license of the code requires the agreement of every other contributor.
Characteristically, the Samba project has a much more forthright policy of refusing to accept copyright that is assigned to a commercial entity, and avows that contacting individuals “is much easier than contacting a company.” The Squeak project is another example of distributed copyright and the Squeak developers spent the last four years getting in touch with its contributors to approve a change of license.
Awareness of this issue has been highlighted by MySQL, OpenOffice.org and the sale of Sun Microsystems to Oracle. For their different reasons both MySQL and OpenOffice.org have practised copyright assignment. In the case of MySQL this has allowed MySQL to offer both GPL’d and proprietary versions of the code. This dual licensing forces any developer who wishes to contribute into a position of either giving up their rights and allowing their work to end up in commercial software, or creating a fork of the software with their changes. In essence it creates monopolies which can only be broken via forking the software. The classic example of this in the wild was OpenSSH, because the original SSH was initially an OSS project and then the authors pulled it and changed the license. But the OpenBSD folks forked the last OSS version and created OpenSSH. But also Canonical (creator of Ubuntu) http://aseigo.blogspot.com/2010/09/copyright-assignments-gone-wild-or-why.html
This is why software organizations (like the Free Software Foundation) and companies who manage open source software, require every contributor to assign the copyright of their creation back to them. That way there remains a single copyright holder thereby making future licensing decisions very easy to make and execute. But a single entity which owns all code, is also an great threat to the free software movement since many of us consider GPL software as community projects. But it isn’t, due to ownership. Governance can make sure this ownership is completely hollowed out and giving the code back to the commons (the community).
There isn’t a uniform solution for this complex matter. Depending on personal interest and type of project, a dev has to decide about his ownership of his code. If his code serves the public interest and the owner is trustworthy, he can decide to hand over his rights to the code.
Besides above mentioned aspects related to FOSS Software & ownership, there is another very important consideration. Successful Open Source software finds it’s success in its’ community. When starting a project, a few devs share a vision about their software: a liberal license and an Open Source development model (i.e. Git, Google Code, Sourceforge). A community forms along with norms of behavior and guidelines (governance) for contributing back to the solution. Becoming successful, meaning there are more devs and users but also the intellectual and creative work embodied in the software products represents more and more value, implies there is more communication and decision-making needed to ensure the software’s long-term survival and it’s original goals. Earlier examples in this article show what can happen if such risks aren’t dealt with from the start of the project.
A common way to solve this problem is setting up a democratic community Foundation to manage a successful free software project and to ensure User Freedoms. Besides, you can handle the financial side of distributing software and you can organize the community while the essence of such a Foundation should be to protect Users Freedoms by donating ownership (and not only the redistribution rights) to the community. Moreover, the social, human and economic aspects of ownership should be covered by the Foundation. This is a natural evolution of a successful FOSS project and it brings you back in the GPL paradox (Freedom vs. ownership) whether you like the Free software ideology or not 😉
So, since to GPL is not the right tool to enforce the ethics related to the Free Software Movement, things change when this software is managed and distributed from within a Foundation.
Solution?
This paradox is a thread to the FOSS Movement. Since a license can not guarantee User Freedom by itself, it is essential that a governance body oversees the human, social and economic aspects related to ownership and communities. This is ignored only at great risk to the software, its users and those who empower the development of the software.
The solution is related to four essential policies covering issues related to the GPL Paradox: ownership model, copyright assignment, relicensing policy and the rules of the governance body. Those rules are formalized in statutes(strategic), bylaws (tactic) and procedures and policies. Important part in this is about the reallocation of the profits, how to deal with conflict of interest of sponsors and members/liasons, voting, etc.
However, there is no uniform solution to those threads yet. First, let’s dig into the ownership model and copyright assignment of some well-known FOSS projects. The issues around copyright assignment and free software have always been a controversial topic and have played a major part in many forks in free software projects. What are the options for Free Software projects?
Option 1: Complex ownership (distributed copyright)
Copyright is defined by national law and international treaty, and can be automatically awarded to the author (with a couple of exceptions such as work for hire) as soon as a work is published.
However, imagine the logistical and legal nightmare if everyone retained the copyright to code contributed to an open source project, especially if some decided to choose their own compatible license. This model is called complex ownership. It has some drawbacks:
- should the terms of the copyright need to be defended, it is much easier for a single entity to do so rather than relying on the cooperation of the entire group of contributors, who may or may not be available. (although Busybox prooved enforcement is possible)
- individual developers aren’t protected from exposure to liability in the case of a copyright or patent infringement suit.
This model is used for Linux, the mother of Open Source. It is proven successful for other large, community style projects but I believe for smaller software it shouldn’t be used.
Option 2: Copyright assignment
Most projects have a policy related to contributions to the projects. There are essentially two options to consider:
| Contributor License Agreement (CLA) | A CLA does not assign copyright to the entity. It empowers a trusted third party to act on contributors’ behalves without removing any of their original rights while simultaneously setting out firm boundaries on what those third parties are allowed to do. (Such as: “they can’t change the license to a non-Free one.”) A CLA has the following characteristics:
Examples of it in use include FSF/GNU, Python Software Foundation, Apache Software Foundation, MySQL and Gnome (recently renewed), Dojo Foundation and Fedora. KDE even has a seperat relicensing policy on top of their optional Fiduciary License Agreements (FLA). |
| Contributor Assignment Agreement (CAA) | The difference between a CAA and a CLA is that in a CAA the contributor assigns all or most of the copyright in the contribution over to the project maintainer. The project maintainer then licences back to the contributor the licence to exercise all rights associated with the copyright material and the contribution.A key benefit of the assignment of copyright over licensing is that where the project maintainer is the single owner of copyright, the project maintainer alone can take legal action to enforce its copyright for blatant infringement. However, Busybox prooved it is possible to enforce GPL with a complex ownership structure. The Free Software Foundation, for example, insists on this model if they are to take action on behalf of a project.The second major benefit to having a CAA as opposed to a CLA if the project needs to be re-licensed. A number of projects encounter problems with their initial license and seek to re-license the project. Examples include the artistic licence used by the Perl community. It can be difficult to foresee all the potential requirements of a licence ahead of time, however, simplified ownership structure of the copyright makes relicensing, if necessary, considerably easier. The flipside of this benefit is that some might view this possibility as a barrier to contributing or securing contributions from third parties (e.g. Universities and Partner’s clients). Also relicensing can be used to move away from the original license (i.e. commercialize) |
(Some projects use a copyright waiver for small contributions, and yet others don’t require much for very small changes.)
If the ownership of a piece of code is assigned to a third party, be it a corporate or a non-profit, that third party is usually given the right to release the code under another licence, now or at a later stage, and the licence may not always be open source or free. Code that is ‘owned’ becomes an ‘asset’ that can be re-used and sold. Copyright assignment can unify a project under common ownership, or it can be misused to impose control (e.g. selling or relicensing). Either way, without a relicensing policy, it always is risky to assign copyright to a single entity. Like the FSF, I believe assigning copyright to a single entity is the way to go, but it should be vested in a community-managed, transparent, non-profit organisation and in return you should have a guarantee of how those rights will be managed (including termination of said rights should the other party break that guarantee).
One-sided handing over of your work and rights, it is reasonable to question the integrity, stability and actions of the organization to which you are handing it. Organizations such as the FSF, have traditionally been thought to be good stewards of this trust; although the transition to GPLv3 has diversified views here.
There are some Foundations doing a great job. They own the source code, they have a democratic nature and they are setup to ensure the User Freedoms.
XBMC Foundation, WordPress Foundation and many other Free Software projects misuse this complex matery for building their own IPR, misleading and abusing the community. SFLC even advise to keep ownership out of this Foundation and thus the setup of this Foundation is a farce for User Freedoms; GPL and all kind of Open Source software licenses are already providing all necessary tools except the solution to deal with the side-effects of ownership. A 501(c)(3) status doesn’t solve this; public bylaws do. Bylaws can give additional conditions to ownership and it can exclude for-profit motives. SFLC should demand this from their customers and FSF should actively promote this all over the internet!
Stay tuned! The future is bright….
“Whenever there is a conflict between human rights and property rights, human rights must prevail.” – Abraham Lincoln
Common Media Traderz 
Thanks for this. Very useful for the project I’m involved in.
LikeLike