Governance for the GitHub generation

As more projects drop contributor license agreements, permissionless governance gains support. Here's what that means

Increasingly in today's society we expect that an individual can take action to use or improve software and a widening range of other artifacts without needing to ask permission first. In software, this is epitomized by the GitHub generation, but I believe it's a characteristic of any aspect of culture touched by the Internet. For those still trapped in the worldview of the Industrial Age, a hierarchy of mediators collects dues in return for providing permission to pass. But the Internet connects everyone to everyone else, peer to peer without discrimination.

"Permissionless governance" doesn't mean action without permission; rather, it means permission is given in advance and can be assumed. That's the governing principle of open source. OSI-approved licenses guarantee we have the freedom to use, study, improve, and share software source code, so everyone has permission in advance to solve their own problems using that software without seeking permission first.

[ Also on InfoWorld: Git smart! 20 essential tips for Git and GitHub users | Track trends in open source with InfoWorld's Technology: Open Source newsletter. ]

If open source means creating a collaborative commons by giving permission in advance, how can that best be administered? Many communities introduce steps that require permission-seeking behaviors where they aren't required. The best open source projects keep permission-seeking to an absolute minimum through the permissionless governance model -- my term for an emerging set of best practices. The summary of those practices:

License in = license out: Contributions from community participants are accepted using the same inbound OSI-approved open source license as the project uses to distribute the resulting work. No CLA (contributor license agreement) is required. This approach was named by open source legal expert Richard Fontana, now at Red Hat, and is rapidly spreading among open communities.

Developer Certification of Origin (DCO): The open source license alone does not give some commercial community members sufficient assurance that contributions are being made validly. Thus, the Linux kernel community pioneered the use of a self-certification by its members, the Developer Certificate of Origin, as part of its contribution process. Each time a developer issues a pull request, they confirm they are doing so with assent to the terms of a standard declaration of originality. The DCO does not grant any rights itself, leaving that to the copyright license attached to the code in the pull request. It does, however, proved an assurance that the contributor has the necessary rights to contribute.

OSI-approved "plus" license: One common excuse for having a CLA is that the community may at some point want to change the open source license in use. Indeed, some communities -- Mozilla in particular -- have had painful experiences changing licenses because they lacked a blanket assignment of copyright from all contributors.

That's not a problem if the project uses a modern open source license with a "plus" clause. This allows code under the license to optionally be relicensed under a later revision of the same license. Licenses such as CDDL, GPLv2, MPLv2, EPl, and others include (sometimes optionally) language permitting the license steward to issue updated versions. When a community uses a "plus" license, every contribution under the license also permits later updates to the license -- no CLA required.

1 2 Page
Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies