Will Hudson by any other name smell as sweet?

Breakdown in Hudson, Oracle talks may lead to name change for Java project

What's in a name? Apparently, every thing.

That's one of the take-aways from the apparent fallout of talks between the Hudson software project within Java and Oracle, as reported by Hudson developer Andrew Bayer earlier this week.

According to Bayer, the discussions appeared to be going rather well, as Hudson representatives tried to work out their differences with Oracle, stemming from a conflict late last Fall that appeared to culminate in Oracle calling for a possible fork of Hudson--a continuous integration platform that assists building and testing software builds in Java. Yes, Oracle, not Hudson.

The conflict began when Hudson developers, frustrated with the performance of hosting their project on the Java.net infrastructure, decided to migrate their work to GitHub. The move came after a miscommunication about a planned internal migration from older Java.net resources to Java.net's Kenai system left Hudson developers unexpectedly locked out.

When they discovered that their access to the Hudson source code was suddenly blocked for no apparent reason, the Hudson development team was upset. Eventually, miscommunication was discovered, but not before Hudson founder Kohsuke Kawaguchi put forth the proposal that since the mailing lists were already being migrated, and with yet another problem with Java.net, why not just finish the whole move and get the source code off Java.net and onto GitHub?

Hearing no major objections from the rest of the Hudson community to Kawaguchi's proposal, the Hudson team made plans to switch their code repositories over to GitHub on November 30.

But the Hudson code still sits on the Java.net servers--due in large part to a response from Oracle Sr VP of Tools and Middleware Ted Farrell, who basically informed the Hudson team that Hudson needed to stay on Java.net for the sake of the larger Hudson user community, which hadn't been heard from yet about a move to GitHub. In his message to the Hudson team, Farrell stated that Hudson would stay on Java.net, and any move to host it elsewhere would be considered a fork.

In Bayer's post, he made it clear that Oracle and the Hudson team seemed to be backing away from the edge:

"These talks have in many ways been fruitful--we came to working agreements with Oracle on the project infrastructure (such as mailing lists and SCM repository location), code review policy for Hudson core, and perhaps most significantly, a governance structure for the project going forward. Some issues are not yet entirely resolved, such as questions on restrictions on third party dependency licenses," Bayer wrote.

Unfortunately, one issue remained a huge sticking point.

"But one issue, which we feel is the most significant issue of all, one for which we now believe no resolution is possible: the rights to the name Hudson," Bayer stated.

It seems that Oracle (via its acquisition of Sun Microsystems), holds the trademark on "Hudson" in the US and EU and is unwilling to give up those rights. The Hudson team, concerned that eventually, despite Oracle's verbal assurances, Oracle will retract the naming rights for Hudson on a whim, is resolute in their stance on this issue.

"In short, we'd be living under a sword of Damocles, regardless of the goodwill of the individuals we've been negotiating with at Oracle--Hudson as a project would be beholden to Oracle's whims for its continued use of its own name, and we believe that's not viable," Bayer wrote.

For their solution, the Hudson project has proposed to take the extraordinary step of renaming Hudson to Jenkins and will ultimately transfer the ownership of that trademark to the Software Freedom Conservancy.

Further, the Jenkins team proposes to move the the code for their project away from all Oracle-owned and -hosted servers and will create an interim governance board for the project, "consisting of three members--myself, [Hudson founder] Kohsuke [Kawaguchi] and, if Oracle elects to remain involved, Winston Prakash, the Oracle engineer working on Hudson," Bayer indicated.

It should be emphasized that this is not a proposed fork: Bayer himself stressed that if Oracle is willing to continue to work on the project under these new terms and the new label, then there is no fork. If Oracle opts to develop Hudson on their own, separate from Jenkins, that would be a fork.

None of this is a done deal yet. Oracle has its own proposal to put forth soon, for which the Hudson community is waiting. Most of the Hudson community, including Kawaguchi's employer CloudBees, is supportive of the Hudson/Jenkins proposal and is urging Oracle to join the new Jenkins community (or relinquish the Hudson trademark).

On the surface, this seems like an overreaction to what would seem to some a minor detail. Why is such a big deal being made about the trademark, particularly when the Hudson community's response is to [insert ironic pause here] change the name?

The argument is more deep-seated than that. This is about one community member unfairly holding control of a project over the wishes of the rest of the community. The Hudson community believes that it's not right for Oracle to presume that just because Hudson was started at Sun/Oracle, when Kawaguchi used to work there, then they should try to dictate terms on what Hudson can and can't do.

Are they right? Is Oracle asking too much? Or are the Hudson developers not taking into account the amount of time and resources Oracle has put into Hudson?

Whatever the outcome of this issue, I think this is a discussion every open source project working with a corporate benefactor must have. Governance is not something to take lightly, and if a project wants independence or a company wants more control, then those rules need to be set up as early in the project's formation as possible.

When firmly set, bylaws and governance give all parties recourse in situations like these.

Top 10 Hot Internet of Things Startups
Join the discussion
Be the first to comment on this article. Our Commenting Policies