Skip to content

Diversity, distributed copyrights, resilience and version control

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/donkeysh/ on line 74

Bjorn’s discussion on diversity made me think seriously about the ideal structure of copyright ownership and version control for an open source project.

First point: distributed copyright ownership makes a project stronger, more resilient.

When there is a single copyright owner (a person or a company) the dude can go broke, die in a plane crash, or worse. A company may chose to change license at will, and leave the open contributors in the limbos. When the copyright is distributed among many, there are no incentive to go close source, and no dependences on one single contributor.

So what are the alternatives?
First foundations, such as Apache and Eclipse. They can be trusted as a reasonably safe custodian of the IP and the project code, as long as there is a real diverse committer community. I predict bad times ahead for project that do not have that. They will die sooner, alone in a dark alley.

Then, an alternative that comes to mind is copyright commingling. In that scheme, each contributor agrees to a license and IP policy (as we do at Eclipse), but never assign its copyright to a single entity (as many commercial sponsor of open source projects require or as Apache requires). Of course, any license changes license requires the authorizations of all the contributors, each holding a tiny bit of the copyright. Changing license is a pain, and can happen only with a consensus, but I think that is a good thing. When using permissive copyleft licenses like the Eclipse Public License, the Mozilla Public License or the LGPL license changes are rarely ever needed.

Second point: centralized version control impedes project diversity.

When using CVS or SVN, the barrier for a wannabe contributor is high to get an environment similar to that of a full committer. He/she gets only anonymous SCM access, cannot version his/her changes locally, and can only distribute a patch as a bug tracker attachment such as bugzilla. Patches go stale quick, keeping them current is a pain. When a patch is committed, any direct trace of the contribution is lost in version control history. It exists only in the patch attachment record of the bug tracker and eventual commit log comments. The commit is not done by the original contributor. In contrast, when using a distributed version control system such as git:

  • there are no differences between the workspace of a commiter and the workspace of a non-committer
  • patch application is fast and simple
  • contributions are done under the name of the patch submitter
  • complete audit trails of every contributions are available in the version control system (wink: Eclipse IP process)

The combination of copyright diversity enabled by a distributed version control can make a project stronger.

So my next open source project *will* commingle. And I will enable commingling with a distributed version control. For instance, the Maven folks are getting a taste of it.

Post a Comment

Your email is never published nor shared. Required fields are marked *