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.
Your employment agreement or contract likely has some clause saying you transfer ownership, rights, etc to the organization.
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.
> 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).
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.
Ethically, I'm not sure how to slice it. I'm operating on what you wrote here rather than this specific story.
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.
There would be a difference between you publishing your code to a public repository, under a permissive license and then allowing your company to fork the codebase and do whatever with it. Under this situation, the author retains copyright, and the company has the option to decline use of the licensed code.
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.
See, that requires some argument of who it's for. Legally, copyright is established the moment something is created. (Hope you have proof.) I don't think you'd be able to claim _damages_ by sneaking your copyrighted code into the company repository, but other than that, I really have no idea how this would play out in court. It seems very risky but it's not obvious. I'd be interested in reading about cases in this middle area, if there have been any.
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.
It's not cut and dried but precisely because of that it is not a situation you should create lightly.
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.
> any contract attempting to gain such ownership is unenforceable
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?
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?
This has nothing to do with what we’re talking about. Whether Oracle owns the copyright to that code is independent of whether Google’s use of it qualifies as fair use.
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.
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.
Many programmers sign this. I directly know that at least two FAANG employers (and probably all of them), have extremely broad copyright assignment clauses in their employment agreements that claim ownership of every software you create, on or off the clock, using company equipment or your own equipment. And many people work for these companies.
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.
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?
Well sure, but how on earth are you going to claim it does not compete when you use that very code for the employer?
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.
IANAL, but even in California, if it relates to the business of the employer then they own it, even if you do it on your own time, on your own equipment. By definition, if you use that code while performing your job duties, then the company owns it. If you are in Washington State, then your employment contract can (and therefore will) state that anything you write, they own, and this is legal and enforceable. Again, IANAL.
Even if it didn't touch any company resources the company just needs to be able to claim it was created within the scope of their employment or as part of the work they were hired to make.
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.
You write code on your personal computer outside of work hours, it belongs to you (barring truly terrible and likely unenforceable contracts). Let's say you put it up on github.
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.
