Governance for the GitHub generation

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.

OSI-approved license with patent clause: Another excuse for having a CLA is that contributors need to grant patent rights in addition to copyrights. Using an OSI-approved open source license with a clause describing the handling of patent rights obviates this need.

Distributed Version Control: The most common version control systems from the early years of open source ironically introduced a permission-barrier to participation in the community. Today’s use of distributed version control systems like Git neatly avoids this problem. Everyone is free to make their own copy of the source and improve it any way they wish. They can then offer other developers their improvements by making a pull request.

This approach has two “permissionless” benefits. First, each developer can proceed on their own copy of the code yet still benefit from integrating their changes smoothly. Second, the version control system maintains a detailed history of who made which change and (since each pull request will be accompanied by a rationale for the request) why the change was made. Instant provenance tracking with added design history.

This combination appears to meet all community concerns:

1. It maintains distributed ownership.
2. It gains the best available statement of good faith from contributors without unnecessarily creating liability.
3. It allows future license change within bounds acceptable to existing contributors.
4. It ensures predatory patent practices are proscribed.
5. It tracks the rationale for each commit, often with a detailed discussion.

In addition, it avoids creating any “permission points” where a bad actor could gain the leverage to abuse the project. Such permission points themselves negate the permissionless flexibility derived from software freedom through open source licensing.

This five-point approach is already in use by the Eclipse Foundation and others, and I believe we will see more and more projects following the example of Node.js and JBoss by going permissionless in the future.

This article, “Governance for the GitHub generation,” was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.