Skip to content

Diversity, distributed copyrights, resilience and version control

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.

Hibernate is 72% crap

During a chat with Marshall, a JBoss Eclipse dev, we started talking about pack200, the (not new anymore) Java 5 Jar compressor. I was making the point that the Red Hat Developer Studio could loose a little fat now that it peaks at 500+Mb, or soon it would be as big as some Eclipse-based studio that tops at 2+Gb (wink). And that pack200 could be an excellent way to tackle the problem and remove the crap. Marshall ran a quick test on the hibernate tools libraries plugin and got a ~ 72% size reduction from 12MB to about 3.3MB. 72% crap removed. Not bad.
Now Eclipse has been available as packed archive since Callisto, with great success, saving tons of bandwidth from downloads. Why not have built-in Java support for loading packed Jars? Why not built-in OSGI support?

Eclipse Public License violation?

Now that I have discovered the true meaning of the EPL, I need to tell another story. Not a fun one.

Checking again the Merriam-Webster, violation yields:

Main Entry: vi·o·la·tion
Pronunciation: “vI-&-’lA-sh&n
Function: noun
: the act of violating : the state of being violated : as a : INFRINGEMENT, TRANSGRESSION; specifically : an infringement of the rules in sports that is less serious than a foul and usually involves technicalities of play b : an act of irreverence or desecration : PROFANATION c : DISTURBANCE, INTERRUPTION d : RAPE 2, : RAVISHMENT

The d: meaning is what I am talking about.

Here is my story: A few weeks ago, I downloaded some bundles that were licensed under the EPL 1.0, the Eclipse Foundation User agreement and — as some of it was made available also through the update manager– the Update Manager agreement. So far so good. These bundles are building on Eclipse.

Then shortly after that, I went to look for the source code of those bundles. On the distributor web site, I found a documentation page explaining how to connect to their public version control system. I followed the instructions and after a short while I had a fresh checkout of the entire code repository in a workspace. I was on a roll.

But hey, what? the code I had checked out did not match the downloads. Different bundles layouts, different packages and versions. Different in that they were squarely older. No big deal, I thought. That might have been just an oversight. If I were to throw stones at folks that sometimes forget to publish their code, I would probably have self-lapidated myself long time ago. So I scouted the web site to find some contact email, and sent a kind request asking for the source code of the downloads I had made. Then thing started to head south.

I was first hit with polite opposition, that later grew stronger. I tried to make the gentle case that the EPL required distributors to make the source code available. After all the EPL says :

A Contributor may choose to distribute the Program in object code form under its own license agreement, provided that: [….]
iv) states that source code for the Program is available from such Contributor, and informs licensees how to obtain it in a reasonable manner on or through a medium customarily used for software exchange.

The key words are available, reasonable and customarily: available as in “present or ready for immediate use, accessible, obtainable”; reasonable as in “within reason, fair, moderate, inexpensive”; and customarily as in “give me a zip or a pointer to a version control system”.

In the end, after a week long of some serious stonewalling, the dude agreed in principle to provide the sources in those terms:

Nevertheless, even though we believe we are under no obligation to do so, we will in good faith work to get our old source control service back up and extract out at least the last version of the old EPL source code. We are working very heads-down on getting the 1.0 version of our IDE out, as our users expect us to keep driving the user experience bar higher and higher. As a small company with very limited resources, we need to concentrate on that goal first and foremost. After we ship our 1.0, we’ll then turn our attention to extracting the archival snapshot you’re requesting.

Note that I am not talking ancient code, but stuffs that I downloaded in the first two weeks of September 2007.

But anyway, I was bloody happy and immediately asked: when? when? tomorrow? next week? I even volunteered to help with their version control woes. The reply was:

As I said in my prior email, as soon as we get our 1.0 product released, we’ll make best efforts towards getting our [version control] system reinstalled, relicensed, and reconstituted to dig out the version of the files you need.

And shortly after:

We have contacted [John Doe] and have forwarded him our email to you on the issue. At this point, we can resume our conversation until after our 1.0 release.

I am keeping the involved parties identities private for now, as I am not trying to embarrass folks publicly for no reason. I just care about the source and the EPL. But given the release pace they have been going through, this version 1.0 could be years away as far as I know. I would be happy to be mistaken though.

Am I an un-reasonable stubborn wild ass? Is waiting two weeks for source code unreasonable? Three weeks? What is reasonable here?
Or is the EPL just a joke, that everybody can ignore?

Eclipse Public License Intercourse

The Eclipse Public License is a good license. Not the best but a good compromise. It is a copyleft license, similar in intent with the MPL and LGPL. It is written in such a way that a lawyer can get comfy with it. It is most likely a good reason why so many businesses are contributing to Eclipse. It is also one of the few licenses that make reference 17 times to the “commerce” word and its derivatives. But when you check the Merriam Webster definition, suddenly everything becomes crystal clear:

“Main Entry: 1com·merce
Pronunciation: ‘kä-(”)m&rs
Etymology: Middle French, from Latin
commercium, from com- + merc-, merx merchandise
1 : social intercourse : interchange of ideas, opinions, or sentiments
2 : the exchange or buying and selling of commodities on a large scale involving transportation from place to place
synonym see BUSINESS

Stupid of me, the real EPL meaning of commercial in as in “COMMERCIAL DISTRIBUTION” is NOT 1. or 2. but 3. All is well. I want to meet the prankster lawyer that drafted that.

May plug-ins RIP, hello plugins?

The 6th edition of the Shorter Oxford English dictionary is now available. One change that has been touted: many words now *do not* require hyphens anymore. I dropped by my local bookstore to grab a copy and checked. Hyphenation is something that always bugged me :-D. I was hoping it was time to say goodbye to plug-ins and hello to plugins! Alas, I was wrong. hyphenation wins. Plug-ins will still be hyphenated for the few years to come. See that bad picture taken from the latest edition:

Blogging, back after a two years hiatus

After two years off from blogging — I used to be the editor of the now defunct Eclipse TechForge — I decided to get back at it. There are a few things that have been itching me lately, urging we to write. I like to think I am an open source wonk. So I will be speaking my heart about open source, software and technology.