Live data from Hacker News

Deleting Software I Wrote Upon Leaving Employment of a Company

law.stackexchange.com

51–60 of 75 posts

Re: Deleting Software I Wrote Upon Leaving Employment of a Company

#51
post #5

Earlier quoted context omitted.

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 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 a…

>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.

Re: Deleting Software I Wrote Upon Leaving Employment of a Company

#52
post #49

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

Better yet, let them hire you when they need support for it. You can ask a lot more than when you are employed.

Re: Deleting Software I Wrote Upon Leaving Employment of a Company

#53
post #35

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…

> too impatient to set up an internal AWS resource using the more time-consuming channels 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

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.

Re: Deleting Software I Wrote Upon Leaving Employment of a Company

#54
post #51

Earlier quoted context omitted.

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 a…

>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…

"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.

Re: Deleting Software I Wrote Upon Leaving Employment of a Company

#55
post #34

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…

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.

Re: Deleting Software I Wrote Upon Leaving Employment of a Company

#56

The top comment is interesting: > 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 co…

> 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…

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".

Re: Deleting Software I Wrote Upon Leaving Employment of a Company

#57
post #35

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…

> too impatient to set up an internal AWS resource using the more time-consuming channels 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

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.

Re: Deleting Software I Wrote Upon Leaving Employment of a Company

#58
post #35

Earlier quoted context omitted.

> too impatient to set up an internal AWS resource using the more time-consuming channels 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

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. Wh…

> wildly unreasonable and unqualified 'devops' guy who had a lock on the whole system

Yeah, tell me about it.

Re: Deleting Software I Wrote Upon Leaving Employment of a Company

#59
post #34

Earlier quoted context omitted.

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 provi…

This. Shadow IT is a symptom, not the disease.

Re: Deleting Software I Wrote Upon Leaving Employment of a Company

#60
post #34

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…

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.

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.
Post reply on HN