Software written off the clock that does not compete with the employer is not only not the property of the employer, but any contract attempting to gain such ownership is unenforceable.
Many businesses even actively encourage their developers to contribute to open source projects.
Which likely means your "free time" code you decided to do to make your job easier now belongs to your employer since they asked you to write it (albeit indirectly in this situation).
Will anything come of it for trivial stuff? Probably not, but that doesn't mean it's ok.
Unless you have something in writing saying otherwise, best not to mix stuff like this because one day you might wind up on the wrong side of an army of lawyers.
Especially when you have problem A at work, then some time later write "generic code" that solves problem A, then some time later "import" the code to your dayjob to solve problem A. And double so if nobody else ever uses this generic code and you never use it for anything else.
As an industry we talk a lot about flexibility, particularly in scheduling and when we do our work, but you can't have it both ways. You can't be doing laundry and mowing the lawn and going grocery shopping in the middle of the work day because it helps you think or it helps your programming process, but then make the argument that because you wrote this code at 6 PM on a Sunday it's yours and not your employers, when you committed it to your employer's git repo Monday morning. Not with a straight face, at least.
I want to be clear, I'm all about getting shit done during the day. If I need to get a haircut at 2:30 PM, I will. But I'm also not pretending that my employer's code is mine or that I have any right to publish it.
Some contracts stipulate that anything you write while employed is owned by your employer. (I'm settled in that this is unethical, but it's reasonable to comply.)
But let's suppose there's no such stipulation.
You get an idea while at work. Everyone gets ideas. You take your brain home with you (I hope) and start developing that idea. You think it's generally useful and doesn't depend on any or reveal anything about a trade secret or other proprietary work, nor reveal anything about them.
Is it your choice to contribute that idea to your employer or to use it in an open source or some other unassociated project? Why or why not?
Is it OK if you never use it for any of your employer's projects?
If not, then is it OK to wait until after your employment to develop that idea on your own or for your next employer or even turn it into your really awesome startup that definitely won't fail? (I think all of you are willing to do the first, and most of you the second.) Why does that change the ethical quandary, or why doesn't it?
Alright, so your employer specifically asked for this solution and you wrote one on the clock but it was minimal, maybe you didn't have enough time to make a more elaborated one, and you write a better one and did one of the above with it. Is that OK?
I don't think this question is all that cut and dried.
That is different than solving common business problems at home, then when asked to solve them at work just copy/pasting those solutions and assuming you retain rights. Contributing that to your employer under that situation is no different than just working on salary - and you have not given the employer the option of rejecting those contributions.
But anyway, I focused mostly on ethics. The specific situation you describe is ethically dubious, I agree, but I'm interested in where the line is and it's just not as clear as some are suggesting.
Copyright law is its own can of worms and is not the same as what's ethical. But, it does govern risk and practicality.
It's hard for me to imagine how you could lose rights via copy pasting the code. Making a new release with a new license doesn't invalidate the rights you already had.
Publishing code sounds like a way to prove it already existed, and nothing more.
I think there's nothing wrong if you have a brilliant idea that happens to be useful to your employer to make some agreement that you work on it in your own time and grant the employer the use of the code. But you can't just do this unilaterally, and if you do don't expect the employer to take your side.
Just as you should have the right to decide what copyright to sell and what not the employer should have the right to assume they own the copyright to the code they paid for, unless stipulated otherwise.
I highly doubt that this is true, at least in the US. Can you cite case law?
You can write a contract granting ownership of all the songs a musician performs, or all the books a writer writes during a specified time period. Why shouldn't the same be true of programmers and code?
Whether these are enforceable or not doesn't matter because a lone developer is not going to go up against an army of corporate lawyers to find out.
I would argue those are exceptional cases. Outside of these prestige brands, you get a lot more leeway.
I have. I got an extra $130k out of it.
It's a work of art. Even this comment is a violation of the agreement, since I don't own the copyright to anything I do apparently, either in or out of the scope of my employment, so therefore I can't give Y Combinator a license to display this comment.
I even talked to the company's legal team about the absurdity of the agreement & they were unwilling to budge.
The relevant portion of the agreement, for your reading amusement: https://pastebin.com/ZF9MEkfG
Completely false. Most people sign job contracts without thinking too hard. And side projects just aren’t important for the majority of programmers, so why would they care?
This is an even stronger case than anything being discussed in this thread. Oracle claimed to own code written by their own employees on their clock and still lost this case. Google won their claim of fair use.
That's exactly and explicitly what an MIT licensed open source project would fall under: fair use by the employer and nobody owns it despite the original author also happening to work for said employer. Authorship is distinct from ownership. As well, there's the notion of role vs identity. You can act under the role of an employee to fork a public repo for your employer's purposes, yet act under the role of the upstream author to have published something more generic in the past without knowledge of your employer's future use case. Your identity is irrelevant. The only thing that really matters is that the public repo does not contain code proprietary to any business. It's on the employer claiming the code is proprietary to prove it. Examples from the article would be those data science functions, the UI they wanted, etc.
Do people not realize why these licenses exist in the first place? What do you all think they were doing over there at MIT to draft up such a license?
There are two questions here:
1) Can the employee use the code at work?
2) Who owns the code?
In Oracle v. Google, not even actual ownership impeded fair use. Nobody really owns the code on a public repo, so there's your answer to #1. The employee can use the code they authored and published to the world without any issues.
Now for question 2...
> what we’re talking about
What you're talking about.
You're correct that Oracle v. Google does not give any clear answers on ownership. For that you have to rely on the license applied to the project. It's simple. If you publish a project under a permissive license and your project does not contain anything proprietary, nobody owns it. Employment contracts don't have anything to do with this situation.
But, what does it really mean to "own" code? What is owned? The concept or the literal sequence of chars? It seems to be the latter which Google showed is trivially sidestepped by rewriting the code behind an API. Thus ownership is pointless in software unless it's closed source and proprietary, which is the opposite of a fun little Excel clone, amateur video game, etc.
The only thing enforceable about an employment contract is the clause about terminating an employee for working on side projects on the company time and/or with company property such that it takes away from productivity towards their work. I don't think anyone is talking about that or would even think of doing that though.
By all means try stuff out with some hobby project but don't be an idiot and tell your employer you've reused 'their' code (or at least, code in their codebase) for other clients. Either get an agreement up front or keep it secret.
A contract that grants your employer copyright to code you wrote and used in their codebase is easily enforceable. An exception would be code you wrote before the contract, but in that case using the code without some kind of agreement up front is still dangerous.
If that code touched their work laptop (which it did since he showed it), it's now company property.
That code most likely belongs to Uber legally, but they probably don't care that much.
Which is, you know, hard to argue against if you wrote the code during your employment and copied it into the code base you were hired to work on.
The next day you download it onto your work laptop and use it to solve problem X. I don't think there's any reasonable interpretation where your company now owns it.