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.

Securing Web Applications Made Simple and Scalable

More from The Register

next story
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
Apple fanbois SCREAM as update BRICKS their Macbook Airs
Ragegasm spills over as firmware upgrade kills machines
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Captain Kirk sets phaser to SLAUGHTER after trying new Facebook app
William Shatner less-than-impressed by Zuck's celebrity-only app
Do YOU work at Microsoft? Um. Are you SURE about that?
Nokia and marketing types first to get the bullet, says report
Microsoft takes on Chromebook with low-cost Windows laptops
Redmond's chief salesman: We're taking 'hard' decisions
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
prev story

Whitepapers

Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
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.
Reducing security risks from open source software
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.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Consolidation: the foundation for IT and business transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.