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 …
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.
> 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.
Lee never said that. The case in point involves Tim Fox who worked on it in company time on company equipment. Contract law enforcing ownership of such code is well established in most 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.
Re: But this isn't about the code...
This isn't THAT uncommon. The same thing happened to Kohsuke Kawaguchi, he gave up the name "hudson" and now run the Jenkins CI project. He forked, everyone followed.
Large emergent systems route around damage.
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.
So if I read it right VMware paid him to develop this? Then he left the company and wanted to take all the admin rights & domains with him?
Surely since VMware paid for it, then they keep the admin rights, they keep the domains...
and if he doesn't like it, he can always fork a new project if he doesn't like the way VMware are going to take it...
I'm with VMware on this one..
If he had developed it all on his own time, thats a different matter entirely..
You haven't read it right at all.
He wrote the project initially, before he ever worked for VMware.
VMware then 'bought' the project, by employing him and making him sign over ownership of the project and his pre-existing contributions to it as a condition of employment.
VMware then employed him to work on the project.
He decides to leave the company, VMware assert their ownership of his works he previously assigned to them.
He should never have signed over his work to them, or have been aware that signing his work over to them meant it was no longer his.
Thanks for the clarification, hadn't had enough coffee yet!
re: You haven't read it right at all.
Tom 38 wrote:
He wrote the project initially, before he ever worked for VMware.
BUT the article says:
"To be clear, VMware funded the creation and development of Vert.x"
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?
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?
I thought that "pre-invention agreements" related to agreements prior to invention; not agreements w.r.t. prior inventions or copyrights.
This Harvard Journal of Law & Technology article seems to support my interpretation:
But I am an engineer, not a lawyer.
Tim Fox should just fork Vert.x and take his community with him.
Or he could continue as a contributor. The article does not say that VMware have banned him, they just seem to be asking for control of their trademark, domain etc. that they paid for.
Re: Fork It
It's not about the code, it's about control of the developer community.
Yeah, fork it.
Create on github a separate project called vert.ks, inform contributors of the change. Let vert.x disappear for lack of maintenance. That is what Open Source is about…
Possibly, learn in the process that VMware is better than you at maintaining the project, and that contributors will not move.
Re: Open source
You just used the phrase "Oracle went evil". That implies that there was ever a time when Oracle weren't evil. I suppose this is possible. I just find it hard to get my head around the concept...
Always make sure there's a copy elsewhere
When developing an Open Source project, you should always make sure that at least one exact copy of the Source Code exists somewhere else, as far beyond the control of your employer as possible.
That way, you are good to go with a fork if the worst happens.
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.
You have to feel some sympathy for VMware
From the article they funded the development, they encouraged it, it seems they should retain a significant interest.
However as usual the Lawyers got involved and went in strong.
You have a feeling it would all have gone better if they had all got round a table.
Vert.x created whilst at VMware
Vert.x was definitely created *after* Tim joined VMware. He was previously at RedHat, working on HornetQ, then joined VMw.
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
Re: That's not open source
You are absolutely right, but then when did anyone expect Matt Asay to know much about the GPL, or in this case Apache Licence?
- 'Windows 9' LEAK: Microsoft's playing catchup with Linux
- Game Theory Half a BILLION in the making: Bungie's Destiny reviewed
- Review A SCORCHIO fatboy SSD: Samsung SSD850 PRO 3D V-NAND
- Was Earth once covered in HELLFIRE? No – more like a wet Sunday night in Iceland
- Every billionaire needs a PANZER TANK, right? STOP THERE, Paul Allen