It's more likely it'll work out like how a situation recently worked out at my employer. We had an employee that was too impatient to set up an internal AWS resource using the more time-consuming channels, so he set it up in our hack-stuff AWS account under his own user account. Our teams found it useful, and began to rely on it. He got laid off. Ops deleted all his user-related stuff, including accidentally deleting the tech he wrote that we found useful. They were unable to restore it, and it broke our CI/CD and caused a bunch of problems.
So yeah, if you want to delete something that you voluntarily wrote, all you have to do is wait.
So, this happened somewhere I worked, and I disagreed with it too, but it happened because the time consuming processes were taking months for basic things from the wildly unreasonable and unqualified 'devops' guy who had a lock on the whole system.
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.
> 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.
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.
Coming from the ops side of the fence, who should be opposed to this, it's also often the only way things get done.
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.
I had a solution for a production data sanity check solution that worked better than the one in production, however the architects were making it difficult to deploy it, even temporarily. It was just a script.
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)
Hard disagree. These are the people using their time wisely, and it's hilarious in some sense that the company shot itself in the foot by laying them off, ironically by using a tool to automate it. It's a bad thing to help increase productivity all of the sudden? It was a poor decision by management that reflects a culture of treating workers like arbitrary units that can be generated or destroyed with no consequence. Downside is that the rest of the team got some fallout, but it's not like they're not paid for the time anyway.
The failure here is on the manager/ops team for not seeing the critical project running on the hack instance and providing resources to stabilize it.
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.
> It's also possible the company has processes that make doing the right thing take so long it's infeasible.
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.
This is a CISO's nightmare fuel. Shadow IT is a real pain, consisting of systems with no ownership, no control, and possibly a tight link with the inner IT system.
And the majority of this is only exacerbated by the complexity of the decision-making process.
And yet, most IT will see it as an opportunity for locking down systems and policies, instead of the call for help shadow IT is: people want systems that are reliable, efficient, and adaptable to rapidly changing business needs. Providing them is part of the core mission of IT, and they're failing at it in some companies. One anecdotal example: I'm responsible for doing trainings at my company. If I see someone providing trainings on their own, creating their own class material, using their own platform... basically wasting company resources; I don't consider it shadow training but I take it as an indication that A. they have a need B. are very willing to work to achieve it and C. I'm not filling up that need properly, maybe not even communicating correctly about it. I take ownership and I don't play vigilante. When IT are providers, helpers to the employees, instead of self-appointed inquisition on a mission to purify the systems and its users, it works for the best.
At my company IT wants funding before you even talk to them. After you play the shell game it’s months and months before a half baked solution is cobbled together. So we have Shadow IT, our own Linux servers, JIRA, git, and now a couple off the shelf SaaS products we can configure ourselves and skip IT all together.
IANAL, but "would it be legal for me to delete..." is the completely wrong approach here. Instead...
- 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.
Or, if you're more of the entrepreneurial mindset, convince management of the value of the software and offer that they can pay you to keep improving it.
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:
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.
Or, if you're more of the entrepreneurial mindset, do one last update of the software to introduce a pay-as-you-go/SaaS model with your credit card in, and when you're leaving, you remove your credit card info.
IAAL but likely not in your jurisdiction, and I agree with this, because the biggest "legal" concern I would have as the linked OP is the company coming back and blaming me for some software I wrote that was out of my job scope entirely.
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.
Unlikely to be legal - you aren't authorized to delete software in use on company computers (regardless of whether management currently knows it is in use), and the software you wrote is likely a "work for hire" done during work hours in the course of your duties (again, regardless of whether management currently knows about the software and how it gets used by front-line workers).
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.
I saw something that was sort of the inverse of this. A teammate quit with zero notice in a 3 AM email. In that email, he indicated he'd made the decision to open source all the code that he had written in his last year or so with the company. It was in a public github repo in his personal account. The company had a lot of open source, but this was never expected to be part of that.
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.
Reminds me (tangentially) of when a coworker got let go, proceeded to open source code that I solely wrote (just some internal tooling), but editing the files to show he authored them. Think he was doing this to help find a new job by posting projects on GitHub. Company proceeded to contact him and the rest is history..
somewhat related: at one job that was working with GPL software, i managed to get them to add a provision into my contract that stated that all code i wrote at the company would be published under the GPL. that way the company still owned my code but i would be allowed to take it and reuse it, and potentially do what your teammate did.
There are a lot of comments saying that the situation is clear-cut and the guy is commiting a crime. But that's BS, this situation isn't a normal situation at all. Also, intent matters. If I delete some old code that I think I no longer need, to free up space or even to get my home directory into an OCD state, I'm not liable for destruction of company property even if I accidentally got rid of something that might have been useful. In fact, it could be argued that when leaving a workplace you should maybe make sure that you don't leave behind any customer data that should be deleted.
Just leave it. It could lead to a contract for you down the line. Or kudos. Or, nothing, but you've made coworkers' lives a little bit easier. I doubt there would be legal consequence for deleting it, unless the company were feeling vindictive, but if they are, now you have a headache for no good reason.
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.
My gut says, for this sort of thing: why delete it? Let them have it, there’s no upside to deleting it. Who cares, right?
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…
I think there is an upside. Or at least a perceived upside.
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.
Good point, but realistically if harm is caused due to unsafe warehouse stacking, there is a human employee behind that error. The exception might be automated stacking software, which would need to be licensed and done properly.
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!
There's a lot of answers stating that if the code was written by an employee during work hours, it's automatically owned by the company. Is that true? My understanding is the author would still retain copyright unless they've already entered into an agreement with their employer that anything they build during work hours is owned by the company. That kind of thing is pretty standard in employment agreements for software engineers, but for warehouse workers?
However copyright assignment still defaults to the creator, so it's still worth asking whether there were IP assignment clauses in the employment contract.
You're also legally bound not to compete with your company. You can't work for Google and build a search engine "on your own time". you can't work for Nintendo and make a game on the side.
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.
Not just a computer... equipment could be anything needed in the course of developing -- or testing -- the software. I'm thinking of something like a warehouse management tool and you interfaced with a barcode reader or something like that.
You're quite wrong about copyright assignment as it pertains to "works for hire".
> 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?
>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.
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.
"You were hired to do a job." --- It's not as black and white as that. You're paid for your time and expertise for a number of hours/day. You do get as job description but that is just for reference. That is the "minimum" for your job in most companies. Things can be added or removed as the job progresses.
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.
Using company equipment to produce the copyright work also gives the company a strong case for ownership of the IP.
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.
just because there is something in the contract, doesn't mean it would not also be true without a contract.
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.
Personally, I don't see this situation as being that different than how people might make jigs, modify tools, make checklists, etc. to make their job easier/more efficient/safer.
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.
Checklists are a good example. If you made checklists and shared them to improve efficiency, would it be tort to take every single copy of that checklist just before you leave the company? Probably
If you want to do this because you're pissed at the company and want to screw them over, don't ...... the best thing you can do is to leave, and leave them with this piece of software that no one understands and no one supports, eventually it will become a mill-stone around their necks, trust me ... that's the best revenge
> 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.
It's important to separate copyright, right of use and ownership. In Europe, copyrights are often not transferable: you will have forever written that line after all. What is transferable, and implicit or explicit in a work contract, is the right of use. Usually the employer has and exclusive right to use, and usually they won't relinquish it upon your leave.
i think the distinction is better described as copyright vs authorship right. you can sell the right to copy, but you can't give up the right to have your name associated with your work.
> But I do have the impression that copyright is kept as long as it is not signed over.
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.
It's mostly a distinction without much difference. In jurisdictions were copyright is non-transferable, it will always be with the natural person who created the work. But all these jurisdictions allow transferring exclusive rights of use, so that's what happens instead.
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".
My opinion is that deleting the thing is a very dangerous move.
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.
I wonder if there are any actual legal liabilities opened up by companies for touting "ownership this, ownership that" regarding engineers owning their code, when they obviously don't actually want that.
All they probably have to do is tell their IT department about the unsecured system they apparently still have access to. They'll likely do the most straight forward fix and shut it off.
So yeah, if you want to delete something that you voluntarily wrote, all you have to do is wait.