“Free cooperation has three definitions: It is based on the acknowledgment that given rules and given distributions of control and possession are a changeable fact and do not deserve any higher objectifiable right. In a free cooperation, all members of the cooperation are free to quit, to give limits or conditions for its cooperative activity in order to influence the rules according to their interests; they can do this at a price that is similar and bearable for all members; and the members really practice it, individually and collectively.”
—Christoph Spehr, The Art of Free Cooperation
In the industrial information economy the outputs are owned by the company that produces them. Copyrights and patentable inventions produced by employees are transferred to the corporate owner, either directly or via the ‘work for hire’ doctrine, which treats the acts of individuals as extensions of the employers will.
Collaborations amongst small groups often use similar proprietary methods to control the benefits arising from their outputs, but parcel out ownership amongst collaborators. In larger-scale settings, however, the very concept of ownership is turned on its head: where proprietary strategies seek to exclude use by others, these approaches prevent exclusion of others from using.
In the traditional workplace, the labor relationship was set out in a legally binding manner, whose terms were clear although imbalanced. In the digital era however the distinction between the time and space of work and that of play is ambivalent, and those dedicating their energy are often not employees. Licenses play a role partially analogous to that of the labor contract. Cases where volunteer contributions were subsequently privatized, such as Gracenote's enclosure of the Compact Disk Database (CDDB), have demonstrated the risks inherent in not confronting the ownership question (the takeover and commercialization of the IMDB is another less dramatic example).
The two principal licensing schemes used in free software and free culture production today reflect this. The GNU Public License, stewarded by the Free Software foundation, guarantees the rights to use, distribute, study and modify, provided the user agrees to abide by the same terms with any downstream outputs. Creative Commons (CC) licenses are more diverse, but that most commonly employed within large scale collaborations, the BY-SA (Attribution and ShareAlike) license, functions in the same manner. However, amongst individual users and small-team production there continues to be wide use of CC licenses, which permit distribution but bar commercial use.
This licensing approach creates a system where rich repositories of data artifacts are available for reuse, also commercially, for those who abide by the rules: commons on the inside, property to the outside. Following Spehr, we can see that this strategy of preventing exclusive ownership allows anyone disagreeing with the direction taken by a project to leave without having to sacrifice the work that they have invested, because they can bring it with them and take up where they left off.
Such configurations are useful for a second reason. In traditional proprietary organizations the disgruntled have three options: exit, loyalty—putting up with it-, or voice—speaking out in opposition (the terminology is Albert Hirschman’s). Because speaking out often incurs awkward conflicts and the possibility of stigmatization or expulsion, it is heavily disincentiv. Once the power of ownership is contained, however, one can leave the collaboration without abandoning the project, and the pressure to withhold criticism and disagreement is correspondingly attenuated. This can encourage conflicts to be played out in a potentially useful manner within a project, and makes exit an act of last resort.
Although this licensing protects participants’ access to the outputs, there is always a cost to leaving: loss of any recognition and visibility already attained, technical infrastructure, and the consumption of energy through acrimony.
There have been many successful software forks over the years, demonstrating that the guarantees actually work. In some cases the second project supersedes the original, in others a period of separation is sufficient to cool tempers and reconcile differences, culminating in a reunification around new terms.
The disruptive force of forking is greater in an environment whose default is to maintain code in centralized, collaboratively maintained repositories such as Subversion. Entry and exit in the project implicate both a division of participants and the need to erect new infrastructural support. The popularization of distributed version control systems such as GIT, Bazaar and Mercurial is changing this default (as discussed above in Multiplicity and Social Coding), and creating more situations where the autonomous development of code, and the possibility of its repeated collaborative merging are rendered more explicit. One could say that the future is one where the fork, a separated initiative, is the basic state, always awaiting its moment of reintegration.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.