8 ms·

Deleting Software I Wrote Upon Leaving Employment of a Company

89 points by azeemba 3y ago

caleparsons 3y ago
[dead]
bell-cot 3y ago
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.
- armada651 3y ago
  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.
  - woutersf 3y ago
    I agree. Put a modal in it, the trial period is over, contact x for renewall.
    - lodovic 3y ago
      That would probably be seen as an attempt to ransomware though
      - deleted 3y ago
        [deleted]
  - nerbert 3y ago
    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.
  - cstrahan 3y ago
    > convince management of the value 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 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.
- raynr 3y ago
  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.
  - bell-cot 3y ago
    Yep. 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.
bhaney 3y ago
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?
- swatcoder 3y ago
  If it was written on site during work hours to facilitate assigned work, it'd be uphill battle to argue it wasn't work peformed for the employer.
  - mirashii 3y ago
    However copyright assignment still defaults to the creator, so it's still worth asking whether there were IP assignment clauses in the employment contract.
    - jeromegv 3y ago
      The creator in that case is the company. It defaults to them.
      - NSMutableSet 3y ago
        In California, it depends on whether you used equipment that belonged to your employer or not. In this case, a computer.
        mbreese 3y ago
        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.
bee_rider 3y ago
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…
- travisgriggs 3y ago
  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.
- exodust 3y ago
  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!
qiqitori 3y ago
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.
- Ferret7446 3y ago
  Hypothetically you're right, the situation is not clear cut. But if you're ever asking this question, then your intent 99% makes you liable. Substitute "code" with "documentation" and it becomes even more obvious.
  - deleted 3y ago
    [deleted]
tunesmith 3y ago
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.
- blencdr 3y ago
  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.
  - Leo_Germond 3y ago
    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.
    - rcxdude 3y ago
      This. Shadow IT is a symptom, not the disease.
HorizonXP 3y ago
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.
- Ferret7446 3y ago
  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
ironmagma 3y ago
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.
sciencesama 3y ago
Unsupported software slowly fades away, just add more hoops and permissions !! Also check where it is hosted !
KingOfCoders 3y ago
Better sell them maintenance.
rented_mule 3y ago
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.
- deleted 3y ago
  [deleted]
- captainkrtek 3y ago
  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..
- smcin 3y ago
  Not "license to quit", "quit to license"...
- em-bee 3y ago
  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.
rendall 3y ago
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.
madsbuch 3y ago
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 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.
- brnt 3y ago
  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.
  - em-bee 3y ago
    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.
- ThrustVectoring 3y ago
  > 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. https://www.copyright.gov/circs/circ30.pdf https://www.copyright.gov/circs/circ30.pdf
HermanMartinus 3y ago
My best take would be to offer to sell it to them. If they say "sure", great, however if they say "no, we already own this" so be it.
ThrustVectoring 3y ago
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.
Taniwha 3y ago
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
- memen 3y ago
  Better yet, let them hire you when they need support for it. You can ask a lot more than when you are employed.
nitwit005 3y ago
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.
greatgib 3y ago
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.

89 points by azeemba 3y ago

[dead]

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.

armada651 3y ago
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.
- woutersf 3y ago
  I agree. Put a modal in it, the trial period is over, contact x for renewall.
  - lodovic 3y ago
    That would probably be seen as an attempt to ransomware though
    - deleted 3y ago
      [deleted]
- nerbert 3y ago
  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.
- cstrahan 3y ago
  > convince management of the value 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 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.
raynr 3y ago
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.
- bell-cot 3y ago
  Yep. 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.

bhaney 3y ago

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?

swatcoder 3y ago
If it was written on site during work hours to facilitate assigned work, it'd be uphill battle to argue it wasn't work peformed for the employer.
- mirashii 3y ago
  However copyright assignment still defaults to the creator, so it's still worth asking whether there were IP assignment clauses in the employment contract.
  - jeromegv 3y ago
    The creator in that case is the company. It defaults to them.
    - NSMutableSet 3y ago
      In California, it depends on whether you used equipment that belonged to your employer or not. In this case, a computer.
      - mbreese 3y ago
        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.

bee_rider 3y ago

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…

travisgriggs 3y ago
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.
exodust 3y ago
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!

qiqitori 3y ago

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.

Ferret7446 3y ago
Hypothetically you're right, the situation is not clear cut. But if you're ever asking this question, then your intent 99% makes you liable. Substitute "code" with "documentation" and it becomes even more obvious.
- deleted 3y ago
  [deleted]

tunesmith 3y ago

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.

blencdr 3y ago
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.
- Leo_Germond 3y ago
  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.
  - rcxdude 3y ago
    This. Shadow IT is a symptom, not the disease.

HorizonXP 3y ago

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.

Ferret7446 3y ago
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

ironmagma 3y ago

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.

sciencesama 3y ago

Unsupported software slowly fades away, just add more hoops and permissions !! Also check where it is hosted !

KingOfCoders 3y ago

Better sell them maintenance.

rented_mule 3y ago

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.

deleted 3y ago
[deleted]
captainkrtek 3y ago
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..
smcin 3y ago
Not "license to quit", "quit to license"...
em-bee 3y ago
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.

rendall 3y ago

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.

madsbuch 3y ago

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

brnt 3y ago
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.
- em-bee 3y ago
  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.
ThrustVectoring 3y ago
> 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. https://www.copyright.gov/circs/circ30.pdf https://www.copyright.gov/circs/circ30.pdf

HermanMartinus 3y ago

My best take would be to offer to sell it to them. If they say "sure", great, however if they say "no, we already own this" so be it.

ThrustVectoring 3y ago

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.

Taniwha 3y ago

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

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

nitwit005 3y ago

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.

greatgib 3y ago

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.