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 …

COMMENTS

Those who have signed contracts which even MENTION code contributions should carefully audit all their contributions to anything, no matter when, where or how those contributions take place. It's quite easy to know if you are writing code and distributing it or not.

And those who publish code under an open-source license better have permission from the entity that OWNS that code (doesn't mean the same entity that wrote it!) or they will be in serious trouble and cause trouble for others. There is no distinction in law between distributing GPL code that your employer claims to own and didn't give you permission to GPL, and someone who takes an internal company project - say, their latest proprietary software - and makes it public on the web for people to download and even encourages them to download it with a "fake" license agreement. Both are the same legal incident and just as likely to end up with fines, sackings, jail or whatever is deemed appropriate in your jurisdiction - so consider writing GPL code on company time, or after having signed a company contract about your code contributions, exactly the same as just giving away Microsoft Office to newsgroups if you worked at Microsoft. Though you *might* be able to obtain permission from companies to do that (lots of companies give things away, from Serif giving away their DTP software for years, to other companies giving away their ancient versions, to companies - yes, letting you give away their original source code, like Quake) the two things are viewed as essentially the same act.

This isn't anything "new" or exciting here. If you have signed a contract regarding code that you write, then it's up to YOU to enforce that contract to the best of your ability, which includes CHECKING what you are doing at all stages and not just assuming that your (possibly-soon-to-be-ex-)employer will always allow it.

In the same way, if you sign a contract that says that the furniture in your office is the company's, you better not have a yard sale or giveaway from your office when you leave without checking with someone in authority on that contract first.

The biggest problem with mentioning open-source is that everyone assumes that somehow the law applies differently to it than everything else. Companies and end-users assume that "Free" means they can do what they like with it, and some coders assume that they are somehow exempt from copyright law because of it or don't need to audit their contributions. That's NOT how it works. Open-source code is a property like any other - and needs appropriate permission to do most things on it. The contracts/licenses may give you that permission implicitly or explicitly or not at all, but it is that permission that is still required.

"There is no distinction in law between distributing GPL code that your employer claims to own and didn't give you permission to GPL, and someone who takes an internal company project - say, their latest proprietary software - and makes it public on the web for people to download and even encourages them to download it with a "fake" license agreement."

Even if it were legally the same (highly arguable), a judge is likely to view the two scenarios quite differently.

"lots of companies give things away"

Oh come now. A company isn't "giving away" stuff you have worked on in your own time on your own equipment. It has no moral right to that stuff anyway. The real lesson here is don't sign a contract that's so ridiculous as to assign things you work on in your own time to the company - or, if you do, accept that you have done that, and don't start a freakin' OSS project.

Anyway, as Asay points out high up, such contracts are often unenforceable depending on jurisdiction, giving further lie to the idea that it's "legally just the same" as selling pirated MS Office if you work for MS, which is illegal in all jurisdictions.

And thus simple facts mean you should audit ALL code you write, whenever and wherever, if you've signed this sort of contract (which he had). Hell, technically using a company pencil to sketch the idea might somehow "infect" the code (and companies complain about the GPL!).

And, yes, although there is a lot of jurisdiction, contract, fairness, common-sense, and direct judicial decision-making here, it doesn't mean that it's "clear-cut". In fact, the opposite. If a judge has to decide an issue for you, even if it means having to get a lenient judge over a by-the-book judge, that's NOT clear-cut - and it means that the legal issue is still there - the individual circumstances may differ, but in the law the "crime" committed is identical (copyright infringement because of an inadequate license to allow you do to distribute said copyrighted material).

In the same way, running a red light by accident leaves you open to a case of EXACTLY the same charge as someone who does it deliberately. The judge might side with you (notice: MIGHT), but it's not clear-cut, not something you should give assurances on (i.e. telling someone you'll be out of court in ten minutes and/or that you will be in Monday morning to do your normal taxi job, etc. - the same as giving others code that you tell them you had a legal right to assign the GPL license to!), and not something that you can guarantee - ESPECIALLY if you have signed a piece of paper in the past that clearly lays out your employer's side of the argument.

Common-sense is all well and good, but if it ran the legal systems of the world, there'd be a lot less lawyers.

But this isn't about the code...

While I completely agree with the need to get release of company code as open source approved by the company (as my employers are happy to do for my trivial stuff), none of this is about code. Its worse than that: its about marketing and public identity of the project and associated community...

Re: But this isn't about the code...

This isn't about code or control of the project (per sa), it is about the "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.", namely the assets which the project uses.

In none of the articles/postings I've seen has it been said that VMware have asked Tim Fox to stop managing the community or contributing to the project. By not having administrative control say of the domain vertx.io, he may no longer have control over where it is hosted and on what it is hosted, but he doesn't need that to manage the community and their contributions to the project.

Reading this article neither VMware nor Tim Fox actually come out of this very well: VMware for failing to properly manage their assets and Tim Fox for not ensuring clarity when he departed VMware. Tim is also unclear as what arrangements were agreed with RedHat over vert.x.

Basically my interpretation is that open source projects need to review the ownership and agreements covering key project delivery assets.

contracts which MENTION code contributions

From a review of several contracts in my possession, I suspect that the typical contract doesn't explicitly mention 'code', also I think a focus on the IPR/pre-invention clause is too narrow.

Looking at my contracts, I can see that the following clauses all impact on my ability to participate in an open source project across separate employments: Sole/exclusive employment, IPR/Invention, Confidentiality. Hence it would seem that contributors to open source projects should be up front with their employers and get dispensations for their open source contributions. Perhaps what is necessary is for the open source community to draw up a standard/proforma dispensation so that contributors need only to add employment details and names of projects.

re: You haven't read it right at all.

Re: re: You haven't read it right at all.

Also, the article says:

"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."

???

If Tom 38 can't demonstrate that the article is factually then I'd say VMware have the right to retain the work. However, under GPL, wouldn't Fox be free to fork it for himself anyhow?

@vagabondo

Hmm, interesting. The whole point of the article however is about "pre-invention agreements", which are agreements about assigning ownership of works created prior to joining the company, where as your quote infers that the works were created after joining.

I don't know which is correct. If VMware did fund the creation and development of Vert.x, then what the fuck do pre invention agreements have to do with this story?

Re: Always make sure there's a copy elsewhere

You can only do that legally if the copy you have only contains code that was been publicly released, using code that has not been released under license would be a breach of copyright at the least.. Given that github was used to host the public code base that is the code base to use if you wanted to continue to work on or even fork. I'm pretty sure that any developer working on a github hosted project would have kept their working and personal git copies up to date with the public one and once a developer has stopped working on it any references to company internal reportistory should be removed even if their admins are slow to react.

Vert.x created whilst at VMware

That's not open source

"Under an open-source license,code ceases to be solely owned by the author of that code"

Round-objects: I wrote the code, I own the code (unless my employer says otherwise) - I choose to distribute the code to other people under the GPL but I still own it and I may choose to sell commercial versions to certain customers