Saying “Copy” Was A Screw-Up

Transamerica ReflectionWhy is a song that I play digitally or a book I read electronically subject to extensive controls that are not considered appropriate to records or books? It’s because they are subject to licenses that can’t be applied by the seller to the physical works. Why can those licences be imposed on digital works? Because the use of digital works is considered subject to copyright, whereas the use of physical works is not. Why is that? Because the act of instantiating the work for use has been described as “copying”, allowing the rules surrounding copyright to be used as a threat to back up arbitrary license terms controlling use.

When I buy a physical work, the act of selling it “exhausts” all the control over normal enjoyment of it that arises out of copyright and the entity who created it no longer has a say on how I enjoy it – they can’t demand I accept a license as a condition of use.  But with a digital work, because each act of instantiation-for-use is called “copying” rather than some other name analogous with the physical world like “wrapping” or “inserting”, we’ve created a hook for the idea that a new act controlled by copyright law has taken place after the first sale of the work.

The control of the work is thus never considered exhausted and the copyright administrators are able to absolutely and indefinitely control use, including uses that save backups, uses that involve networks, uses that involve passing the work to a friend temporarily or to anyone permanently, uses that enrich society without endangering the author. All uses you’d naturally expect from something you had bought.

Controlling Culture

This control over those enjoying and using cultural works was neither precedented nor anticipated by legislators, so the basic law involved includes no attempts to balance the needs of society and of creators of works where digital works are concerned. Instead, the only limit on the controls imposed on users is the imagination of the businesses administering copyrights. The focus of that imagination is naturally the maximisation of income and control, even to the extent of creating scarcity artificially where it does not otherwise arise, so that the maximum number of control points exist for monetisation.

But even worse, the penalties the law provides for breaching those fanciful licenses are also unbalanced. They’re intended to punish people who unlawfully mass-manufacture, not those whose cultural enjoyment breaches some unreasonable-but-legal license. As a result they unjustly — but legally — apply overwhelmingly disproportionate punishments to ordinary citizens.

The licenses so devised are complex beyond the understanding of the untrained, they include arbitrary terms and restrictions, they are frequently and arbitrarily changed. All of these dimensions happen without any need to balance the needs of culture or citizens, since neither is a stakeholder for the copyright administrator. There’s no backlash because there’s little expectation of enforcement; all the same, automated enforcement is becoming increasingly common.  When a market is controlled by unrestrained licensing rather than by statute that’s a clear DNA marker for malaise.

So where did we go wrong? We mistakenly allowed the technical term for moving bits between buffers to be assumed to be equivalent to the term used by authors and other makers for creating a new original work for sale. They simply aren’t the same act, and the laws that have accidentally bled from mass production into cultural enjoyment are simply not fit for that purpose – how could they be?  When we said “copy”, we screwed up and it’s that error that really needs fixing.

[A revised version of this was posted to ComputerWorldUK on March 7, 2013]

☆ Mozilla peut-elle apporter l’unité à l’open-source ?

La nouvelle licence open-source de Mozilla est bien plus qu’un simple ravalement de façade. Elle pourrait créer de nouvelles possibilités pour l’unité de la communauté du Libre.

La première semaine de janvier 2012 marque un jalon discret mais important dans le mouvement de l’open-source, grâce à la publication d’une deuxième version de la Mozilla Public License (MPLv2) et sa validation en tant que licence libre officielle. Quand bien même beaucoup n’y voient qu’un énième détail juridique, cette publication est importante à deux titres : le procédé par lequel on l’a élaborée, et l’objectif pour lequel on l’a créée. Il s’agit d’une licence qui a pour but l’unité.

Rédaction et révision de cette licence se sont déroulées selon un processus très ouvert, dans lequel Luis Villa a joué un rôle prépondérant. Organisé en majeure partie dans des forums publics, le débat a conduit à de nombreuses modifications du texte. Luis est entré en contact très tôt avec l’Open Source Initiative, a accepté les retours du groupe de révision des licences, puis obtenu sans mal l’approbation du conseil d’administration.

D’autres articles sur cette nouvelle licence se sont concentrés sur les modifications de la partie « patent peace » (NdT: la paix des brevets) et autres ajustements des clauses (adieu, Netscape !), mais le changement le plus important apporté par la version 2 de la licence Mozilla est à mon sens l’inclusion d’une compatibilité particulière avec la GPL (GNU General Public License). Par le passé, le projet Mozilla jonglait avec un système complexe et peu clair de triple licence afin de composer avec les univers des licences copyleft et non copyleft. De manière générale, les autres utilisateurs de la MPL (et ses nombreux clones rebaptisés) ne prenaient pas cette peine, et par conséquent certains codebases se sont retrouvés exclus de toute collaboration possible avec l’immense univers des logiciels placés sous licence GPL.

Selon un procédé inédit que la Commission européenne a inauguré pour la licence publique de l’Union européenne (EUPL), la MPLv2 inclut des clauses permettant à un projet de stipuler, de façon optionnelle et explicite, sa compatibilité avec d’autres licences, en particulier celles de la famille GPL. À mes yeux, la MPLv2 représente une mise à jour d’envergure de la famille précédente des v1.x, justement grâce à cette compatibilité explicite avec la GPL, laquelle offre pour la première fois une passerelle praticable entre les paradigmes permissifs et copyleft. Elle ne satisfera pas les puristes des deux mondes, mais propose avec pragmatisme une nouvelle solution aux projets open-source appuyés par des entreprises. Celles-ci pourront disposer d’une communauté qui produit du code sous licence permissive tout en fournissant à cette même communauté un moyen d’entretenir des relations avec d’autres communautés travaillant sur du code sous licence copyleft.

Avec le déclin continu du business model de la double licence (ce que d’aucuns nomment « exceptions commerciales au copyleft »), il devient de plus en plus évident que les licences permissives sont importantes pour les entreprises commerciales qui contribuent à l’open-source. De la même façon, l’écosystème GPL ne disparaîtra pas, aussi les conceptions qui reposent sur une opposition idéologique – y compris celles qui prônent l’élimination de tout code sous GPL – sont néfastes pour toutes les entreprises.
Je salue l’arrivée de la MPLv2, un pas en avant vers l’unification de la cause commune de nombreux développeurs open-source. Bravo, Mozilla !
[Traduction par/Translation by Rico Moro – thanks! The original article was posted to ComputerWorldUK]

★ On Copyright Aggregation

Monarchs on EucalyptusA collaborative activity dubbed Project Harmony is now under way between corporate and corporate-sponsored participants in the free and open source software communities (not to be confused with the Apache Java project of the same name). The project seeks to harmonise the various participant and contributor agreements – collectively termed “contributor agreements” by some – used by many open source projects.

The goal of the project’s initiators is to reduce the legal costs of analysing paperwork faced by companies contributing to open source projects. Initiated and sponsored by Canonical, meetings have already been held several times under the Chatham House Rule, including one recently during LinuxCon in Boston. The participants also number several people who are skeptical of the value of copyright aggregation, myself included. At the meeting I was asked to write about my skepticism; this article is the result. I’m by no means the first to tread this ground; you’ll also want to read the earlier article by Dave Neary, and the comprehensive article by Michael Meeks ends with a useful list of other articles.

What are “contributor agreements”, why do they exist, and are they a good thing?  The need often arises from the interaction with open source of certain approaches to business. They serve a need of those approaches, but they can come at a significant cost to the health of the project. If you’re starting a new project, it’s worth understanding the bigger picture before diving in with a practical guide on the assumption “everyone uses contributor agreements” because not everyone does. For good reasons.

Dual Licencing

One of the dimensions of the business of open source has been the dual-licensing business model. The name is a little confusing since there is (usually) only one open source licence used – the second arrangement is usually a proprietary license or contract exempting the customer from some of the terms of the open source licence. It can be better to describe this as “selling exceptions to the open source licence”, and it is commonly done in conjunction with the GNU General Public License (GPL) which has clauses some businesses regard as hard to accept.

Under this model, open source software is genuinely present, guaranteeing the freedoms of its users, but the business owning the copyright makes money by selling benefits such as the right to make derivatives under a different licence, commercial terms that offer additional guarantees and (most famously) anything-but-the-GPL as the licence under which the software is used. This last option means dual-licensing has often been associated with shady sales tactics along the lines of “it would be a shame if your business got infected with that evil GPL viral licence…”

Copyright Aggregation

In order to use this model, the business owning the copyright has to own the entire copyright to the software they are distributing. As a consequence, when any community member wants to add a modification or enhancement to the source code for the software, the owner demands that to do so they must also hand over their rights to the addition. To achieve this, the copyright owner makes signing of a legal document mandatory for any involvement in the community that involves co-development.

Usually called a “contributor agreement” (to the detriment of older arrangements that use that term for community participation agreements that don’t actually aggregate copyright), the document gives rights amounting to ownership of the copyright in the new work to the copyright aggregator. It may also include other clauses, such as a statement or originality (“this is my work and I didn’t plagiarise it”), a grant of patent rights and even an indemnity (“if you get sued you can blame me”). In most cases the author retains rights to their individual work in some form or receives a license back, but it’s only the aggregator who has ownership of the copyright to the whole system.

So What’s The Problem?

Open source can be defined as the co-development of software by a community of people who choose to align a fragment of their self-interest in order to do so. The commons in which they work contains software under an OSI-approved licence free from usage restrictions with guaranteed freedoms to use, study, modify and distribute it – “free software”. The community members each work at their own expense in order to achieve a shared outcome that benefits all, including themselves. When they create an enhancement, fix a defect, participate in a design, they are not “working for free” or “donating their work” so much as they are “participating in co-development”.

That favoured word “contributor” gives a clue to the problem copyright aggregation agreements cause. An open source community is an open, meritocratic oligarchy – ruled by an elite who gained leadership based on the merit of their participation and skills, open equally to anyone who does the same in the future. The presence of a “contributor agreement” that involves copyright aggregation may be a warning sign that the community using it has one member who is more equal than all the others.

Communities whose members are termed “contributors” rather than “members” or “participants” may well be unequal places where your interests are subsidiary to those of the copyright owner. They are often dominated by users and fans of the software rather than by co-developers, since the inequality makes it hard-to-impossible for a genuine co-developer to align any fragment of their interests on equal terms. Indeed, this inequality is seen by some dual-license proponents as one of the attractions of the model as they seek a community of enthusiasts and (hopefully) customers that they can exploit without competition.

Exceptions

There can be justifications for having copyright aggregation by and for a community. When the beneficiary of the aggregated copyright is the community itself (in the case of a community hosted by a non-profit Foundation), there are benefits available that may outweigh the disadvantages. These include giving the Foundation the legal right to enforce the copyright in certain jurisdictions, and the freedom to update the open source licence later. They may also include the granting of additional rights such as patent licences in the case where the open source licence does not adequately deal with patents, or to help in countries where copyright law is sufficiently different from US law that the US-centric concepts behind open source fail. Richard Fontana covered these well in his LinuxCon presentation.

Even with these benefits available, there are many communities that choose not to aggregate their copyrights – notably the Linux kernel, GNOME, Apache and Mozilla communities. The recent policy and guidelines on copyright assignment by the GNOME Foundations are especially worth reading. Having diverse copyright ownership leads to a deeper mutual trust and an assurance that the playing-field remains level. Insisting on copyright aggregation is one of the more certain ways a company can ensure the open source community it is seeding remains small and lacking co-developers. With the rise of “value add” business models such as Apache-based open core or service subscriptions, it is less necessary for the businesses involved to aggregate copyright.

Some Foundations that avoid aggregation (such as Mozilla) do have a document termed a contributor agreement but the purpose it serves might be better termed a “participant agreement” since it mainly addresses community norms and specifically avoids copyright aggregation. Indeed, there are some who suspect a motivation for using the term “contributor agreement” vaguely to describe agreements also aggregating copyright is a tactic to screen the toxicity of copyright assignments from general view.

How To Flourish

It may well be advisable to have a participant agreement for your community, to ensure that everyone has the same understanding of and commitment to the project if they are sharing its evolution. But if you want your community to flourish, eschew aggregated copyrights, or vest them in a non-profit entity representative of and open to the community. In fact, avoid any institutional inequality and focused control. Communities should be open-by-rule.

In my experience,  attempting to retain control of a project you’re starting or hosting leads to mistrust, contention and a rules-based focus that diminishes your reputation. Relaxing control will lead to the community innovating and growing in ways you’ve not anticipated, as well as enhancing your reputation. As I’ve frequently said (although less frequently been heeded): trade control for influence, because in a meshed society control gets marginalised while influence delivers success.

[First published in ComputerWorldUK]