Contributions and the Latest Generation

Simon Phipps wrote a particularly interesting article on project governance in the “GITHUB generation.” The article is very good reading, and thought-provoking.

In it, he articulates, among other things, the case against contribution agreements. He observes that it is becoming more common to use he outbound license as an inbound contribution agreement. (“license in = license out”) This has long been the approach of free software purists, and of course the Linux project, and it does have the virtue of transparency. When the license in equals the license out, the project does not enjoy superior rights to the rest of the world. Projects that use contribution agreements are sometimes not transparent about the consistency with which CLAs have been required, or whether special exceptions have been granted for some contributors, and that can cause disenchantment with the project management — at least among those attuned to IP diligence issues. From time to time I have been set the task to figure out who has contributed to a project on what terms, and it can be difficult and disappointing to try to do this.

The question of the use of contribution agreements — to use or not to use — is in part a matter of semantics. Of course, not having a contribution agreement works well when the license is a permissive one. In fact, most contribution agreements are very similar in scope to permissive licenses — or a bit more restrictive. For instance, a common term in CLAs is that the contributor promises the contribution is original code. For “license in= license out” paradigms, that is handled by a separate document called a “developer certificate of origin.” Some CLAs require the project to re-license only on open source terms. This is a very mild sort of copyleft requirement, that is intended to reassure contributors that their contributions are not merely being assimilated into the Borg of a proprietary development project. But if the project is, for instance, a not-for-profit foundation, this issue would be addressed by limitations in the scope of the organization’s charter. The IRS is likely to be far more effective in preventing privitization of foundation-run projects than any contribution agreement could be. After all, the contribution agreement only has the force of copyright (and contract) law, and the IRS can send agents to your door. So in sum, using a permissive license as “license in = license out” is probably just as effective as a contribution agreement, if your goal is to maximize the flexibility and transparency of the project. (Except for the question of retaining individual contributor notices, which is a topic best left for another day.)

But it’s hard ot read an argument against contribution agreements while I am, coincidentally, embarking on yet another relicensing project. When the project uses a copyleft license, eschewing a contribution license means the project only has one chance to get its licensing right. Using a copyleft license as a contribution agreement means the outbound license can never be changed. Phipps suggests that the “version plus” approach solves this problem — e.g. contributing under GPL v2 or any later version allows one to change to a later version of the same license. But of course, that doesn’t help if the project community wants to move to a more permissive license, like LGPL or even BSD or Apache. Many projects tend to move to more permissive licenses over time, for two reasons. First, the trend over the last decade has been to prefer more permissive licenses. This is one of the characteristics of the “GITHUB generaltion,” as I mention below. Second, as code becomes outdated over time, there may come a point when there is no longer any compelling reason to keep licensing it under restrictive terms, as no one will be interested in enforcing the conditions anymore. When that happens, the conditions become economic dead weight that no longer serve anyone. Projects can only change to a less restrictive license if they have used a contribution agreement.

If they have not, and want to move to more permissive terms, they need to undergo a relicensing effort — going back to all the contributors to get permission to use the new terms. Relicensing projects are a chore, as anyone who has executed one can attest. There is always a point where one is looking at 20 lines of code, for which the author is unavailable (or never admitted to his identity in the first place), and wondering whether humanity is really best served by re-writing that code to avoid copyright infringement claims that are, in all likelihood, more theoretical than real.

The need for relicensing crops up sometimes, in particular, whether the initial license chosen by the project is idiosyncratic, or simply one of those open source licenses that is not a sterling example of the craft of license drafting. (They shall be nameless here, but are easy to pick out — just see what relicensing efforts have been mounted and you will find out which of these mystical creeds people are trying to forget they ever used.)

Another interesting implication of the article is the notion that the latest generation of developers has little patience for licensing issues. I think this is true in spades. The average coder who puts code up on GITHUB couldn’t care less about open source conditions, contribution agreements, copyleft, and the like. I am not sure that dispensing with contribution agreements is the answer, but it’s a good argument for moving to CC0 (the Creative Commons public domain dedication). These days, I am more and more inclined to tell clients that if they really want code used as broadly as possible, and don’t honestly have any plans or budget for license enforcement, they should consider public domain instead of permissive licenses. I guess that advice is against my interest, seeing as I have spent a lot of time advising clients on license compatibility issues and re-licensing efforts. But so be it. We should remember that license conditions are forever (or at least as long as copyright protection, which seems to be on a slippery slope into forever these days), and we need to consider whether we really need to bind the two generations beyond us to license conditions that may, in the year 2100 or so, seems like relics of a lost era.