Deleting Software I Wrote Upon Leaving Employment of a Company
law.stackexchange.com
law.stackexchange.com
So yeah, if you want to delete something that you voluntarily wrote, all you have to do is wait.
And the majority of this is only exacerbated by the complexity of the decision-making process.
I've been at a company where getting a Slack plugin approved took 8 months alone. Vendor review took a year.
These departments aren't equipped for the modern day and most want to live 10 years ago without change. Just keep with the old and vest.
Those are by far the worst software devs, not understanding the implications of their actions. But also that his manager didn't catch up this mishap
If that is the case, these broken processes will cause far more damage than that one employee.
If it caused outages and disruption, it wasn't the right thing.
I understand the temptation to just do my own thing and bypass everything to get a deliverable done and be the hero. But in the long term that's never the responsible thing to do. Follow the process to avoid disruptions like this one. If the process seems inefficient, work to improve the process to bring consistency benefits to everyone.
My manager offered to give me a 2nd laptop so others could run the system as needed.
(and yes, we had kubernetes, all the fancy cloud stuff, etc)
What made a difference was getting people in my team to stop doing it, and making it clear when things were requested and timescales and why we were not able to do it. When deadlines started getting missed, the guy got put under a lot of pressure to change the processes, and eventually the business hired someone that ultimately diminished the original guy's role.
Yeah, tell me about it.
This is the way. If a process is slowing you down, let it slow you down to a grinding halt. BUT document and communicate the reason clearly, frequently and to the correct people.
If you can attach a clear cost to the process being slow, even better.
I've worked a couple places that had an unspoken Catch-22 mantra: "ye shall not invest resources in apps that are not business critical".
So the only way to build something new was to skunkworks it until something major depended on it and you could get resources to actually productionize it.
A smart ops team should have a semi-standard "skunkworks to production" pipeline.
Hack instances are amazing for getting stuff off the ground or validating a use case when the proper channels are too burdensome to use, but they need to be migrated away from once something is critical.
- You were an hourly warehouse flunky, not any sort of professional programmer. While doing your warehouse job, you cobbled together a mish-mash of software stuff, on company computers, to try to make your job easier. With you there to fiddle and debug and update as needed, that worked pretty darn well.
- Now, you are leaving. Your layman's understanding is that the company legally owns all the software you made...as is. There ain't no "You Programming, Inc." in this situation, for your old employer to have any documentation, nor warranty, nor support contract from.
- Your suggestion is that the company delete the software, and revert to the previous procedures - which worked perfectly well. If it seemed worthwhile, a professional programming company - which could offer documentation, warranties, support, etc. - could probably duplicate the features of your stuff pretty quickly.
The goal being to convince the management of Warehouse, Inc. to order the deletion of your software from the company's computers.
This presupposes that such convincing is even possible. Many, many companies have leadership that are simply terrible at identifying value. If you've never been part of a majority of developers advocating for, if not outright begging for, some huge ROI initiative to get the green light, you are very fortunate.
There are great counterexamples, like Valve, which is known for giving developers an extreme degree of autonomy, and they benefit greatly from that approach. For each Valve, though, there are dozens of companies that manage to succeed despite themselves.
Take Microsoft, for example. One tiny, yet representative, example: the way the Windows Terminal team handled a suggestion from Casey Muratori to take their software from abysmally slow to lightning fast:
https://github.com/microsoft/terminal/issues/10362
A quote from one of the Terminal developers, dismissing the suggestion:
> I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation as “extremely simple” somewhat combatively…
Just how difficult was such an endeavor in actuality? Well, given that Casey implemented his own terminal emulator from scratch and incorporated the functionality he was proposing in a mere weekend... not a whole lot. Relatively minor effort for a huge return on investment. It took Casey explaining the concepts, then providing a working proof of concept, and finally a bunch of backlash online towards the Terminal team to get them to do the right thing for themselves and their users.
I would add that the goal isn't just to convince the company to delete the software, but rather to acknowledge and accept that there is no support, no warranty, and if things go wrong it's on their hands.
Added Point I: The value of product going in and out of even a modest-sized warehouse in a week can easily be 1000X the net worth of any of the hourly employees there. So if things went wrong - trying to recover their losses by suing Manuel McLong-Gone would be hopeless. And that might also alert their insurance carrier to an excuse for denying coverage.
Added Point II: Being responsible for all that money, no Warehouse Manager worth a pallet would want some undocumented & unsupported software, cobbled together by some former hourly employee, to be left running in his warehouse. Even as you depart, you are being loyal and industry-savvy, and making sure Mr. Manager knows about that potential problem. And how to prevent it.
The correct way to handle this is to get ahold of the CTO or a relevant subordinate in their department, and inform them of the shadow-IT situation going on at the warehouse. Most risk-adverse IT executives would have a conniption at the idea that work policies are enacted by business logic code that zero employees understand and can modify.
We were able to get it taken down and no other action was taken against him, but it was an interesting move on his part. His motivation didn't seem to be bad blood - he continued pleasant interactions with several of us, including those in his management chain, long after leaving.
Substitute "code" with "documentation" and it becomes even more obvious.
I do say "you" here, not knowing if the stackexchange poster zelembia is azeemba, nor if OP will otherwise ever see this. Some posts are like a message in a bottle, flung heedlessly into the ocean of the internet. Or like forgotten software, left to decay on an aging computer in the backroom of a warehouse. But it still must be written.
But hypothetically, it probably has no license or anything like that. Not even the “no promises of merchantability” stuff you sometimes see. Hypothetically could there be a risk to the coder? If my buggy “forklift stacking high” software says “stack that stuff up to the roof,” and gets hurt listening to it, am I on the hook? (In that case of course he never should have let anybody use it in the first place, but leaving the job provides a moment of reflection).
Realistically it doesn’t seem like the sort of thing anybody would pursue. But it is interesting to wonder about…
The employee may feel like they went above and beyond what was expected and wanted to be recognized for that. This may be the only way they get recognized.
I’m not condoning this. And I think the long term costs/price outweigh the gain of affirmation/recognition they may want. But I do believe there is an emotional calculus that goes into this.
So it's more likely the software in this case was an office admin data entry solution. When they fail, people say "oh crap" and call IT who may or may not fix it!
What it means to compete will be decided by judges and lawyers in the gray areas but probably not hard to imagine clearly problem areas and likely not problem areas. If you want to know for sure, ask a lawyer and get a contract/letter from your employer to clarify.
> If a work is made for hire, the employer or the party that specially ordered or commissioned that work is the initial owner of the copyright in the work unless the employer or the commissioning party has signed a written agreement to the contrary with the work's creator. For legal purposes, when a work is a “work made for hire,” the author is not the individual who actually created the work. Instead, the party that hired the individual is considered both the author and the copyright owner of the work.
I fail to see how doing this during hours you are paid by the company, on their equipment, and for their specific operations...wouldn't be considered a "work for hire" in copyright law.[0] The VAST majority of work done by salaried professionals during work hours, at work, which can even remotely be demonstrated to benefit the employer...is a "work for hire". IP assignment agreements are redundant, and mostly only "needed" to prevent employees from trying to claim they did it all after hours, outside of work, using zero inside information they knew from working their day job. It's generally trivially easy to show that some of the development occurred during work, on work computers, at work, using inside knowledge of the company (trade secrets).
> Section 101 of the Copyright Act defines a “work made for hire” as A) A work prepared by an employee within the scope of his or her employment, or B) A work specially ordered or commissioned for use if the parties expressly agree in a written instrument signed by them that the work shall be con- sidered a work made for hire.
Question 1: Was the work created by an employee?
Yes? Proceed to Question 2.
Question 2: Did the employee create the work while acting within the scope of employment?
Yes? The work is a work made for hire.
This seems to fall under (A). If the "bright-line" tests for (A) fail to affirmatively answer the question, then the totality of circumstances are considered via questions such as:
> Where was the work created? Did the hiring party provide the space, materials, or tools to create the work? Was the work created as part of the regular business hours of the hiring party? Was the work created during the creator’s authorized work time? How long was the relationship between the parties? Did the hiring party have the right to assign other projects besides the one under review? Could the hiring party direct the creator when and how long to work? How was the creator paid? Did the hiring party offer employee benefits? Did the hiring party remove taxes from the creator’s pay? Does the creator have his or her own business? Was the creator able to hire and pay assistants? Was the work created pursuant to the creator’s usual tasks? What skill was required to create the work?
But you weren't hired for writing that code. You were hired to do a job. The code you wrote was not part of your contract even though you made it to fulfill your other duties.
There must be a reason this clause is usually added to SW dev contacts.
If you write code (any unrelated code) during work hours - it's done on their time, they paid you for it, they own it.
If you write code(work related) even outside working hours - They own it. At best you might get some money for your overtime and such.
if you write (urelated) code on their laptops on test it on their infra outside work hours - gray area, can go either way. most likely a settlement and they get the code.
if you write unrelated code and test it with you own resources - depends on the lawyers but, in most places, it's yours to keep. If the CEO suite or senior management see value in it. Be ready to to defend it.
I did have this exact discussion when I started with a global 500 corp as I do write code for various things when needed and also write small apps for extra £. The above pretty much sums up the discussion with the UK lawyer. It's not my job to write code but I do to make my life easier. I also document it for handover if I decide to leave.
EDIT: a few typos and the below
The lawyer's advice was, if I write anything unrelated that I want to keep - publish/sell in my wife's name.
Not using company equipment can be just as bad because now there's evidence you knowingly copied company records to a personal computer to build a competing product or for personal gain.
California (and to a much lesser degree other jurisdictions) limits how much an employer can extract from an employee. The default status (with or without those clauses) though is that the employee owns the IP they produce. A warehouse worker would not have had any contractual agreement to the contrary (probably), so CA's limits wouldn't come in to play since the whole thing is handled by ordinary IP law without any agreement superceding that normal behavior.
Things get complicated a bit if there were a lot of trade secrets or whatnot that went into the software, but those restrictions would generally of the form <limit what the copyright holder can do with the software> rather than <trade secrets are involved, so magically the old employer can ignore the copyright holder>. Deleting the software or revoking access should be fine.
in general work for hire is owned by the one paying. this is also true in the EU.
the EU has clear exceptions that work done not for the company while employed, does not get owned by the company. even a contract can not override this. in the US this is less clear, and contracts can demand ownership of everything, and so often they do.
i hardly doubt that warehouse worker contracts don't also have such a paragraph. it's pretty standard. i mean it doesn't hurt to put it in the contract. so why leave it out.
even without a contract though, anything done at work in order to help your job should be owned by the company.
Live and let live, knowing that you were intelligent enough to solve a problem where others couldn't. That's a skill that is transferrable and that can't be destroyed.
> If you wrote this software during your working time (nine to five), and were paid for that time, then the company owns the software.
I don't live in the US, but copyright laws are quite homogeneous world wide. But I do have the impression that copyright is kept as long as it is not signed over.
given that the person did logistics without an employment contract, he could notice the company that he retracts all rights to use the software wrote.
Of cause that would cause havoc to the company, and they could probably counter sue that he did something incurring the liability that he was never asked to.
The US has the "work for hire" concept - if an employee creates work as part of their regular duties, their employer is considered both the author and the copyright owner.
For example, if you have employees take photographs of finished products, using company devices, on company time, and as part of their assigned duties, there is essentially zero question that the copyright owner of those photographs is the employer, regardless of whether this is explicitly lined out in an employment agreement.
The employment agreement definitely helps in that it preempts most disputes over what the employer's expectations are, but it is by no means necessary.
If you want to get really technical, something like "Copyright (c) 2024 CompanyName SE" is literally impossible by the letter of the law in these jurisdictions. Courts of course understand that this is meant to be shorthand for "The exclusive rights to use this work authored in 2024 by an unnamed party are with CompanyName SE".
But it depends, if it is running on your own work computer/session, and it is like cleaning up you data when leaving might be ok.
As a real answer, we would need to know what are the terms of the contract of this person.
His job description should be clearly stated inside and we would know if there is a kind of right/ copyright assignment to the company.
If it is not the case, and it was not in his job description , it is easy to argue that the employee legally kept the copy right and rights on the software.
So he could legally tell the employer that it is not allowed to use the software except buying it.
The only gray area is if it was done during work hours with the employer willing fully agreed to have the employee spend some time working on that.