Feeds

Hey, open sourcers: Who's your code's daddy?

VMware's dealings with Vert.x founder should serve as a warning

The Power of One Brief: Top reasons to choose HP BladeSystem

Open... and shut So-called "pre-invention assignment agreements" are a rite of passage when joining a company. For an open-source developer, they may also be giving away the keys to an open-source project, as VMware's recent legal action against the founder of the Vert.x project shows.

While there are compelling reasons (warning: PDF) to think that pre-invention agreements shouldn't have legal force against open-source contributors, the best course of action for open-source developers may simply be to insist on keeping all open-source activity outside an employer's grasp. That is, to carve open-source contributions out of a pre-invention assignment agreement.

Your employer could say “no,” but better to know upfront than to face legal action, as Vert.x founder Tim Fox did. When he quit VMware to join Red Hat in late December 2012 he assumed his open-source project, Vert.x, would go with him. He thought wrong.

As Fox writes in a Vert.x community announcement:

In the spirit of open source and as a commitment to the Vert.x community I had expected (perhaps naively) that VMware would continue to let me continue to administer the Vert.x project after I had left their employment.

On the 28th December I received a letter from VMware lawyers (delivered to my door in person, no less!) that I must immediately give up and transfer to VMware all administrative rights over the following things: The Vert.x github project, the Vert.x google group, the domain vertx.io and the Vert.x blog.

In response I proposed that VMware give me permission (i.e. grant a license) for me to continue to use the Vert.x trademark and domain after I left their employment. This proposal was refused.

In a joint announcement from VMware and Red Hat on the Google Group, posted by Red Hat's Mark Little, the two companies indicated that they are now working out the best way to manage the Vert.x community going forward. Here's a news flash for the companies: the best way to manage the community is to let Tim Fox go back to what he was doing. Get out of the way.

Red Hat gets this. As Fox notes in the Vert.x community mailing list, Red Hat chose the opposite route with the Netty project. Responding to a commenter who proposed that "any company" would do what VMware did, asserting legal control of the Vert.x project, Fox responds:

As to "any company would do this": That's not really true. A good example of a company that _did not_ take search a path in a similar situation is Red Hat, when the project lead of Netty left RHT to join another company. Instead RHT chose to let him continue to use the name and domain after he had left the company. Now that project is a great success and has full time employees working on it from both RHT and the other company.

But while Red Hat is perhaps progressive in its management of open source issues, odds are that most employers will not be. After all, VMware is an active open-source contributor on many fronts, and has done excellent work with CloudFoundry and other projects like Spring, RabbitMQ and so on. If any company should have done well in managing Fox's departure and its implications for Vert.x, it's VMware.

It didn't. It's an example of a company still cutting its teeth on open-source mechanics. Red Hat has had a decade longer in the open-source community, and is less prone to forget that open source community is about people. It's not really about code. By shackling the legal accoutrements of Vert.x, VMware got in the way of the people of the Vert.x community contributing in their normal fashion. I doubt it will make this mistake again, and will be a better company for this experience.

To be clear, VMware funded the creation and development of Vert.x. As such, it's reasonable that it assumes a measure of involvement and even control over Vert.x. But not like this.

None of which is intended to paint VMware as evil. It's not. It's a great company that does fantastic open source work. What my article is intended to do is to alert developers to the importance of establishing boundaries for their open-source projects.

In Fox's case, this might not have helped. The project started after he began at VMware, and VMware funded his development of Vert.x. Under a pre-invention agreement, Fox clearly owes his work to VMware.

But how is this interpreted in an open source world?

Under an open-source license, code ceases to be solely owned by the author of that code. Even if they retain a copyright on that code, it's still also owned by a community. At most, a company should be entitled to the actual code contributions of their employee (or, rather, their copyrights), as well as any domains or trademarks that it paid to establish.

Such legal mechanics may not be the project itself, but they are important, and it behooves any developer to a project to find out who owns what in a project to which she wants to contribute.

Code contributors and project founders are going to move jobs. It happens all the time. Sometimes they'll go to work for a direct competitor, as Fox did in switching from VMware to Red Hat. An open-source project, even one whose foundation and development is funded by an employer, shouldn't be held hostage by that employer. Not if the project intends to be a true community project.

The best strategy in this is open, clear and written communication, as Van Lindberg outlines in his excellent Intellectual Property and Open Source: a Practical Guide to Protecting Code. If a developer is joining a project, find out who owns what. If a developer is getting paid by an employer to start and/or contribute to a project, do the same. Be open about contributions, and be clear about who will own them, including the legal structure of the project.

Fox assumed that "in the spirit of open source" VMware would let him continue to run the Vert.x project once he quit to go to a competitor. You shouldn't. ®

Matt Asay is vice president of corporate strategy at 10gen, the MongoDB company. Previously he was SVP of business development at Nodeable, which was acquired in October 2012. He was formerly SVP of biz dev at HTML5 start-up Strobe (now part of Facebook) and chief operating officer of Ubuntu commercial operation Canonical. With more than a decade spent in open source, Asay served as Alfresco's general manager for the Americas and vice president of business development, and he helped put Novell on its open source track. Asay is an emeritus board member of the Open Source Initiative (OSI). His column, Open...and Shut, appears three times a week on The Register. You can follow him on Twitter @mjasay.

Seven Steps to Software Security

More from The Register

next story
Secure microkernel that uses maths to be 'bug free' goes open source
Hacker-repelling, drone-protecting code will soon be yours to tweak as you see fit
KDE releases ice-cream coloured Plasma 5 just in time for summer
Melty but refreshing - popular rival to Mint's Cinnamon's still a work in progress
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Put down that Oracle database patch: It could cost $23,000 per CPU
On-by-default INMEMORY tech a boon for developers ... as long as they can afford it
Another day, another Firefox: Version 31 is upon us ALREADY
Web devs, Mozilla really wants you to like this one
Google shows off new Chrome OS look
Athena springs full-grown from Chromium project's head
prev story

Whitepapers

Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
Application security programs and practises
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
How modern custom applications can spur business growth
Learn how to create, deploy and manage custom applications without consuming or expanding the need for scarce, expensive IT resources.
Securing Web Applications Made Simple and Scalable
Learn how automated security testing can provide a simple and scalable way to protect your web applications.