Slashdot Mirror
Open Source Code In a Closed Source Company
An anonymous reader writes "I have code that I've written for my current company that I'd like to open-source. The only problem is that my company has the usual clause that says that anything I write belongs to them. Now that they've decided to abandon my code for another product that replaces its function, I'd like to continue working on my project as well as open it up to the world. The easy part is cleaning it up and posting it on SourceForge and Freshmeat. The hard part is making sure that I am free of any legal complications in the future. I've looked online to try to find a legal document I could present to my employer to get them to sign off on it, but I'm not having any luck. Has anyone else been in this boat or can refer me to some legal documentation that may help out?"
As parent says, they own the code. If they want to abandon it they still own it and don't automatically abandon rights to the code.
Ask them if they are prepared to release the code and if not, why not.
If their major concern is laibility, then get the code signed over to another party who will shield them from liability. THis might be yourself or EFF or whatever.
If they still won't well you're screwed as it is theirs.
Engineering is the art of compromise.
Print the code you want to release, pedantic I know, but legal folks like paper. Draft a simple document that says the attached code is going to be released under XXX license (whatever you can agree on with them) and that the company agrees to the action and that any derivation/modification to the released code is copyright the respective author going forward (your choice of license probably will take care of this for you).
Affix the license, the document, and the code. Have a legal officer of the company sign the document, initial all the pages of code and the license in front of a notory, and have the notory do their thing and seal it.
Should work for any trivial amount of code. As was joked about in another post, I doubt you'd want to try this with Ballmer and the Office code base, but if you think your company will let you get by with it in the first place, its probably enough. The key thing is that you've got their sig and its notorized properly so you can't be sued later for releasing their IP into the public spotlight without permission cause lets face it, once the code is out there, they aren't going to put it back in the bottle, they at best will sue you for releasing it.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
You need a laywer, sir.
Sorry dude, you're out of luck. The code is still theirs. Their ownership of it is not predicated on whether or not they actually decide to use it.
You can always ask them if they'll give it to you. I've done this successfully. If they really have no interest in it, they might be willing to discard it.
We are the fire that lights our world.. and we are the fire that consumes it.
Who modded this flamebait? Its the reality of the situation, its not 'his code' it is 'the companies code' if he wrote it under what would be considered time they paid him for. If he did it completely off work resources and outside the scope of work, its another story, but it was obviously written with knowledge of a work requirement since they were using it, that implies work resources were put in on it even if its nothing more than 'my company needs this' because he had inside knowledge. If you don't like these terms, don't sign the employment contract or negotiate the right to do your own work outside the company under your own license. Thats what I did. The only catch is that my company has the right to use any code I develop while I work for them (but outside of work) for their own products, including modifications. Which works entirely fine by me as it means my CVS repository is backed up on servers at my office as well, the versions stay in sync because I make sure that any changes that need to be made to my code get done in my free time and imported back into the repository at work. We both benefit. They get free code, I get to work on things without fear of being hassled about it later. I must admit though, the owner of the company I work for treats his employees as if they are his own children, so this is probably not your typical setup at but its been that way at the 4 small companies I've worked for.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
I would suggest starting any project by building on another project that is already open-sourced therefore the GPL or whatever license would mean that your new project is automatically in the public domain.
Oh, come off it man. There's all kinds of stories posted on slash relating to IP and the Law. Plus this guy obviously doesn't know anymore than the rest of us, so maybe he's just looking for another goob that's been there. I think there's been some good advice around here. Personally, I'd go to a paralegal, but I don't think he's looking to spend any cash. So, someone that might have personal experience is really the next place to go. If you don't like it why not just GTFO?
Under the influence of Post-Cyberpunk Gonzo Journalism
I do this all the time, in fact most of my open source code was done on someone else's dime.
Your situation is going to be tricky because you (I assume) don't have a precedent of doing it (they didn't hire you based on your other open source work) and don't have any agreement in place. I also assume you are a permanent employee instead of a contractor (it can be easier to open source work as a contractor in some countries).
The above stuff isn't critical, but it smooths the process.
What's tricky for you is there aren't any good BUSINESS reasons for them to do it either.
If either your code, or the code that replaced it, is profit-impacting then forget it. No sane company would open source a profitable codebase, nor will they risk releasing an old product that you could then take and create a competitor.
The best arguments for open sourcing in a company that isn't a software company are:
1. Having other users means free testing, free reports, maybe some free patches. In rare cases, it means you become the industry standard/leader in an area (and control is good, from a company perspective).
2. Because you will continue working on the project after you leave them, they in effect continue to retain you as an employee without having to pay you.
Those are the direct benefits, there's more reasons (mostly more subtle).
Sadly, neither of these apply in your case.
You are in effect dumpster-diving in their repository, asking for charity. And your work on that codebase could well distract you from your new one.
It might be possible, but it's going to be damned hard.
Good luck though.
Perhaps its a new reader trying to get involved with the community (and perhaps asked several places to try and get the most eyes)? It is true that these things have been discussed liked crazy on /., but largely only in terms of lawyers and copyright laws. I don't recall anyone recently posting how to interact with their bosses on the matter. I'm sure there needs to be some level of documentation, but what does that consist of exactly? You'd want to make sure its documented so that if it is open-sourced and becomes popular, no one can come back and say "I didn't authorize this! It's all ours!". But what sort of documentation? Was it a long process, or was it as easy as getting someone to sign one paper saying "Program X is hereby released under the GNU GPL -- signed, The Big Guy, Some Company" and so took all of 30 seconds? Someone here may have dealt with it and can offer some advice that may be more reasonable that someone on the GPL forums, whom only knows what the license says but has never actually bargained with a boss or CEO to get something released.
And if nothing else, its polite to give help when you can. Responses such as yours are a big reason people don't like to learn about Linux or technology in general; whenever they attempt to get involved and learn, they just get yelled at for being newbies and told to go elsewhere. The open source community may have lost a genius member just now because you decided to be a jerk and therefore put off the asker from even wanting to write open source software anymore.
Just remember this next time you have a question about anything (which is inevitable). I don't want to hear it when you're stuck with no answer because everyone yelled "Get lost! You should know the answer."
According to the original poster, the company is developing new code to replace the same function. So it's like asking the company, "Would you like the code you paid for to be competing against your new product?"
E pluribus unum
So, here's a theory - how about just asking?
I work for a large software company (about 10,000 employees) and have released a couple of things into open source. We use Linux / MySQL / Apache / Spring / etc in a big way. A colleague and I wrote some MySQL utilities and some other bits and pieces, but the code we wrote didn't really give away competitive secrets, so I went to my management and asked - and they said "yes".
My company has contributors to at least a half-dozen open source projects that I know of. For example, se use Apache Camel and we contribute. It makes sense for us to share, because the sum of what we get back from the community is more than what we put into it individually (and we give away no secrets).
Now, if the code you wrote is something a competitor could use against your company, don't both asking, you already know the answer.
Alan.
If fact it could even hurt a competitor.
If the company decided to dump a project because they are moving out of that business arena, but the competitor is still staying in that arena, then opening up the code will dilute the competitor's position.
Engineering is the art of compromise.
NJice rant. Too bad it has nothing to do with the question at hand. The questioner specifically said the code was written for work.
More than likely, your idea is property of that company. Not only the code you wrote while you were there, but any ideas that you formed during the same period.
For example, I had an idea while working for one company. It was to be an internet monitoring software, that would watch multiple points across as many providers as we could manage, map out the traceroutes, and show not only the common peers that those traceroutes passed through, but would effectively show when any peering point was having problems.
They grabbed hold of it, and offered me 5% of the "profits" of the company. That's the day I stopped working on it.
Technically (if they remember), they still own the idea. If I were to start working on it again for a commercial venture, they could lay claim to it. It's not a matter of what was written, but the idea behind it.
You may win in court, but it will be a long drawn out court battle that you probably can't afford to gamble with. If you win (which you may), you may win a lot. If you lose, you're going to lose a lot. Not only your legal fees, but their legal fees, and whatever the judgment is against you, as well as your intellectual property.
My advice is, when you have another great idea for something, STFU. Don't tell them anything. Wait until you're no longer under any sort of contract, and then "start" your development on it. You can start working on it on the side, but be very very careful that there's nothing to document that you were working on it during the period that your contract with another company is under effect.
You may want to re-read your contract too. It may not cover just what you conceptualize while as their employee, but anything for a period (6 months to a year, I've seen in various contracts) belongs exclusively to them.
Serious? Seriousness is well above my pay grade.
Your company only owns what you wrote for them using their resources, the stuff that's on their drives. They don't own what's in your head. My advice: Re-write it and open source it.
when you can write a different way of doing it with new code that uses a different way of doing it on your own time, that isn't like the old code or the code they replaced it with?
I am sure that over time your coding has improved, and you might be able to find a different way to do the same thing that isn't the same as your old code or the code they used to replace it.
That is unless your employment contract states that even coding you do on your own time still belongs to the company. If so, wait until your contract is over, or the employer changes the contract to allow you to write code on your own time that belongs to you and allows you to open source it.
As long as the new code you write doesn't use code from the old code or the code that replaces it, nor is it written on company time or the contract doesn't somehow prohibit you from writing it so it isn't the property of the company you work for, you should be able to write open source code.
The old code can't be that good, as they replaced it with different code. Chances are that you can find a better way to do the same thing with different code that doesn't violate any contract you have with the company.
Anyway I agree with others, you should be talking to a lawyer instead of Slashdot.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
according to the original poster the company is replacing the original code with a new product that replicates it's function. which seems to mean they are replacing custom code with a purchased solution.
My keyboads not woking popely.
"Insightful"?
It isn't anything at all like "Would you like the code you paid for to be competing against your new product?"
He mentions nothing at all about the code being income-generating, something the company actually cares about, or that they are developing new code to replace it.
They are going to "abandon my code for another product that replaces its function" by which he probably means he wrote some code to solve a back-end problem that has nothing to do with what the company does to make a profit, and now they are scrapping his pet project for a product from a vendor.
He believes enough in his solution that he wants to keep it and doesn't want to see it die.
You make a lot of assumptions there. Perhaps all of this code was meant only for internal consumption (like the vast majority of code written in the world), so competition is irrelevant? Or perhaps the reason for replacing the code is that requirements have changed, and the two projects are in fact substantially different?
Perhaps the original poster can clarify. Meanwhile I wouldn't jump to conclusions.
The problem is that 'Lawyering' has achieved critical mass. It's pervasive enough, and effective enough, that if you choose to forgo an advocate in any dispute, you lose. period. The other party is going to lawyer up and in the contest of lawyers vs. no lawyers, you're not going to win. Even if your case is obvious, you're still going to lose because you can't articulate its obviousness in the language of the court.
Therefore, if you know you're going into a situation in which there is a nontrivial chance of a dispute developing, it's unfortunately necessary to consult an expert to make sure you're not exposing yourself to unnecessary risk.
Can you be Even More Awesome?!
Actually, I think the situation is actually much worse than this.
There are lots of reasons beyond code quality that a company might choose to outsource some program functionality of variable degrees of goodness. Perhaps there's better support, perhaps it's cheaper than developing and maintaining it internally. Perhaps the new module has similar functionality but the vendor provides it as a part of something with greater overall scope (in my past lives, a lot of internally written code existed to provide a subset of functionality of something that would have been prohibitively expensive to license because of all the stuff we wouldn't have used!).
If I had developed function x for a company and that module was being replaced, it's not a far stretch of the imagination that I would continue to work on code in that general area. Depending on how "black box" the new functions are, I might even see the internal workings of the licensed code. Even if I never saw the implementation, I would certainly see the interfaces and architecture.
If that's the case, then my involvement with a similar open source project is potentially quite toxic. The open source project is tainted by contact with somebody's proprietary work. Certainly, the external vendor isn't going to be appreciative of what's going on, despite any statement of good intent on the part of the programmer.
And this programmer is still an employee of the company that's bought the license, almost certainly including terms to honor the intellectual property. So, it's not only a matter of the external vendor being mad at an individual working on an open source project, this person is an employee of a licensee, and the licensee granted permission and transferred copyright on what is becoming a competitive product.
On top of that, if the employee wants to continue to actually work on the open source project, they're in continued violation of their contract because what they develop belongs to the company.
This one is so easy that it's a total no-brainer. If they release the original code for somebody to open source, then they are open to liability and litigation. The well-meaning but naive employee will probably lose their job. Or they can just say "no" and have no hassles.
The only way that you'll get this sort of copyright release from management is if it's dead-ended work - the company isn't working on it anymore and nobody else is either. And, I imagine that most companies would probably go even farther than that and say that the employees that worked on this code probably can't work on the open source project anymore either.
Now, if it meets these criteria - it's really being cut loose for the benefit of previously uninvolved parties, then it really has the possibility of being positive for the company without downside.
If you never never go, you'll never never know will ya?
+1 take it to the company and try your luck, they can only say yay or ney, right?
(BTW, only a truly terrible employee would be worried about mentioning this to a coworker, Harmonious Beach, let alone worry about mentioning to co-workers. and if it made an employer uneasy, probably time to get the fuck out of whatever business Harmonious Beach runs... do you run your business as some kind of fiefdom? or would you be happy to surround yourself with yes-men like the emperor with his new clothes? ( http://en.wikipedia.org/wiki/The_Emperor's_New_Clothes ) )
I did something similar a few years ago, for a company I felt equally warm about. I hope you have got all of that in writing though.
:)
When our little company got merged into a bigger one, their lawyers tried to take my code. I pointed out my modified contract, and told them no way! They came back and said they would keep using my code, but only if I accepted liability for their use of it. I told them they were still welcome to continue using my code, but at their own risk, or, of course, they were free to strip it out entirely if they weren't happy. If they hadn't agreed at that point, I was going to request full commercial licensing fees from them (they had been using it for free up to that point, and I had sold commercial licenses to many other firms). They agreed
Anyway, moral of the story is that no matter how good your relations with the company, you can't guarantee you will always be dealing with the same people, so get it in writing!
Hey, another lawyer :)
But I concur. There is too little information to go on to give any counsil beyond general observations.
That said, business reasons include a lot more than just money. Worker satisfaction is another reason, often overlooked. If pitched right to his company, an essentially worthless (to them) piece of code can have a positive effect on morale.
It can also be used for free publicity: require a "sponsored by [company]" tag somewhere in exchange for releasing the code. However, never attach the name of the company to the software without their express consent!
the pun is mightier than the sword
You seem to be under the impression that nothing in the world ever changes, this is an observation which is obviously incorrect. For example if Hertz initally have the best deal for rental cars there's no guarantee that in a years time Avis won't have improved it's offerings and be able to do you a better deal.
Blindly assuming that one is better than the other and discouraging anyone in your company from actually finding out if thats the case is a a good example of moronic stupidity.
Why do people always say these questions don't belong on Slashdot? This question is the perfect example of how Slashdot *actually* works vs. how people *imagine* it works.
The question: I want to open source some code I wrote for work that the company is scrapping.
Expected Slashdot answer: Just do it! Don't ask The Man, he'll only push you down... OSS FTW!!1!
Actual Slashdot answer, overall: It's possible, but you definitely don't have the rights to that code, and it's probably not in the company's best interest to give them to you... so it probably won't hurt to ask, but chances are you'll need to find another project.
Included in that actual answer: details from other developers who've been in the same situation, and comments from actual IT lawyers who work with these issues.
So -- wrong place?
Yes, none of this is "official" legal advice (though about as close as you can get for free & online), and if the questioner wants to try something risky, he should pay to get that legal advice... but now he knows what "risky" even means in this situation (he didn't know before) and has some idea of if it's worth pushing for it (probably not).
So: can we just hash out a new feature for Ask Slashdot postings? Have the editor just flag the question as "responses might contain legality discussions"... and automatically include regular disclaimer text saying "reminder: comments in this discussion are not legal advice." Or add a checkbox to the reply form, next to "No Karma Bonus" and "Post Anonymously", called "Include Not-Legal-Advice Disclaimer"?
Then we don't need to fill the comments with all of these disclaimers and warnings, and the actual lawyers don't have to worry about someone pointing back to their comment as "rendered legal advice" and holding them responsible for it being a complete and accurate answer. And (this is not a response to the parent) we can start smacking down the people who always post "Don't ask Slashdot - get a lawyer!" to every single Ask Slashdot story, looking for cheap karma.
...if you're like most of the 'business owners' i've ever met, you probably think you're the only one who knows how to do things... That should be modded insightful. Seriously. Yes, every business owner does think he knows how to do it better than the other guy. That is why he started the business. And it can't be otherwise.Please consider the possibilities here: when starting a business, you can do it worse, or the same, or better. Nobody in his right mind will start a business with the belief that he will do it worse. Nor will anybody start a business to do just doing the same as the other business, for the other business is established and thus has a head start. You only start a business if you believe that you can do it better in some manner...a better location, a cheaper supplier, a better product, more efficient software...whatever it is, the owner believes that it is better. If he is right, he makes money. If he is wrong, he goes broke.
It is a self-reinforcing process. A person starts a business with a certain idea, and if it makes money, he concludes that it does so because he was right.
Thus all businesses are founded on some proposition. They all have some core belief that defines who or what they are. It is just the inevitable result of the process by which they come into existence. It is almost like a religion.
I'm rather surprised at the vehemence of the responses to my original post, as if the responders thought that I was in favor of businesses being the way they are. I'm not - and never said that I was. I merely described how things are. Sorry if you folks don't like it, but please don't shoot the messenger.
About my business: Among my peers - other business owners in the same type of business here in the same city - I'm known for being the most flexible, and the easiest to work for. That is because I know that I have my biases and beliefs that underlie my business philosophy, and I know that they may well be irrational. And I tell my employees when I offer to hire them that there are certain ways we do things here, and that alternatives are heresy. So they know from the start what can be argued and what cannot.
The really dangerous boss is the one who thinks that he doesn't have a bias, who tells you that he will consider any alternative. Then, when you do say something that challenges some core belief that he didn't realize that he had - or does not want to admit that he has - he turns vicious.
The biggest problem with what you posted is the assumption that being right in the past (about how/when/what to launch as a new business) inherently makes your future opinions more likely to be right.
I have to admit, I rolled my eyes when I saw the text of your letter agreement. I hope that no one else uses it.
First, your agreement might fail if there were a dispute since there appears to be no consideration for the assignment of rights. There's not even the nominal $1 token-consideration (even if that would have worked). Without consideration there is no agreement; no agreement means no assignment of rights. That said, you could probably argue that your offer at the bottom would be parole evidence of consideration, but that's outside the four corners of your letter agreement. However, like most attempts, your letter agreement fails to get the business deal right and probably fails for that reason.
Second, from a writing perspective, it uses a funky tense and lacks timing. Is this the agreement or was the agreement sometime prior and this is just a follow up letter (this letter is confirmation). That's just sloppy. If this is just a confirmation, which terms would govern? And, when did the transfer actually occur?
Third, you make a very common mistake sometimes called "elegant variation." Is this an assignment [first sentence], a license [second sentence], or a sale (transfer of something tangible) [third sentence]? Those three things are not necessarily synonymous.
Finally, while I do agree that nothing fancy is necessary to effect a transfer, you haven't done it very well.
The best thing that can happen is you get the code. The worst is that they say no.
Actually the worst that can happen is that you have to redesign it again.
They dont have copyright on your idea, so if they say no, do a complete rewrite in a different language or direction. It's different they cant sue you or squat.
I did that on several projects I created, I sell them though, It's boring vertical market stuff for large sales forces and of zero interest to the community.
Do not look at laser with remaining good eye.