In which I work an example of how important ICLA gravitas is to adopters of open source software.

Disclaimer

As always on this blog I speak only for myself and not for my employer, the organizations and projects I work with, etc.

Background

Sometimes open source projects require contributors to submit Individual Contributor License Agreements, by which contributors shield the contributed-to project and its adopters from liability and risk by guaranteeing that they will only make contributions that copyright restrictions etc. allow them to make.

Sometimes open source projects insist further that these Individual Contributor License Agreements be agreed to by means involving physically printing and signing the document, for additional gravitas, rather than allowing something lower hassle.

There are tradeoffs in all things. The least-risky intellectual property posture for any project is to simply not exist at all. Give up. Go home. Of course, that's not a very productive or satisfying posture -- so a project navigates the tradeoffs, accepting some risk to exist and have contributors and make progress.

The least-risky copyright posture for any would-be open source contributor is to not contribute. Of course, that's not very productive or satisfying. So a contributor navigates the tradeoffs, accepting some risk to exist as a contributor, to make progress, to accomplish anything in this short mortal life.

A formal contributor license agreement that one must physically print and sign is a way to rub a would-be contributor's nose in the fact that, in terms of licensing, they'd brave less risk if they just took their marbles and went home. One cannot fail to live up to guarantees if one makes no guarantees.

Perhaps a project requires would-be contributors to do this printing and signing, does this nose-rubbing, because of the improved confidence and comfort it gives would-be adopters of the project.

This is a parable of how would-be adopters in practice engage with these tradeoffs.

The parable

Once upon a time a world-class university undertook to reinvent its home page on the web.

The particular time was around now, and so the university faced many compelling options in available open source frameworks, templates, and supports for building usable, responsive, accessible web sites that delight users.

How to choose among them?

First, the university considered implementing the new site using AngularJS. In digging deeply into it, the university determined that Google was allowing contributors to agree to the Individual Contributor License Agreement by clicking through a form on the web rather than by physically printing out and physically signing a document. The ICLA process lacked sufficient gravitas for the university to be comfortable. There's Risk. It might be the case that someone clicks through without understanding or without really having the permissions the ICLA requires, and then would contribute code to the project to which someone else owned copyright, and then the university would adopt this code and thereby come to violate someone's copyright. After all, when it comes right down to it, those contributors probably aren't really technically allowed to contribute. If only that contributor had been made to physically print a piece of paper.

Thus discouraged, the university then looked around for an alternative front end development framework, and hit upon Foundation. Since Zurb has vastly more assets to protect from suit than does Google, Zurb takes the care to require its contributors to physically print the ICLAs they are agreeing to.

Thus it came to be that the university eschewed AngularJS and instead adopted Foundation in support of its website update project.

The parable revealed

Just kidding.

Foundation doesn't actually require its contributors to agree to an ICLA at all. If you were picking development frameworks based on ICLA signature process gravity, well, you wouldn't pick Foundation.

AngularJS does require contributors to agree to an ICLA, but it's a lower-hassle process of completing a form on the web, no physically printing and singing required for individual contributors.

Please sign our Contributor License Agreement (CLA) before sending pull requests. For any code changes to be accepted, the CLA must be signed. It's a quick process, we promise!

For individuals we have a simple click-through form.

AngularJS enjoys plenty of adoption.

The point

There are tradeoffs in all things.

Signed agreements, and additional gravitas in the process for signing those agreements, do not come costlessly.

Choosing tradeoffs that burden would-be contributors to an open source project reduces contribution. Is what's gained from this tradeoff worth it? Well, it depends.

NodeJS, for instance, adjusted these tradeoffs to stop requiring CLAs, valuing lower barriers to contribution more than valuing clarity in how to blame the contributor when the contributor wrongly contributes.

One measure of whether the burdens are worth it is whether their effects are valued by the adopters of the project. Adopters would signal their discomfort with lax ICLA process by not adopting Foundation and would signal their need for physical printing and signing of those ICLAs by not adopting AngularJS.

Tradeoffs in all things.

Post image credit: Talus on Flickr, via cc-by-nc-2.0.