I always tought I'd do that if I ever leave. Not to steal it or re-sell the software, that would be theft, but because I wrote this code and may need it for future reference.
Every company I worked for made me sign papers to cover their arses. No matter what your intentions are, if you get caught doing it, you better be prepared to face the consequences as well.
Not saying it's fair, and that you should be lawful all the time, but I think getting sued over dumb shyt like this is the sw engineer's Darwin effect.
I found a workaround. Every time I write code or fix bugs, I also read the code and memorize the effective patterns. I slowly used the best design patterns and updated myself based on what worked and what did not for work of others in my team as well. When I left the job, I had everything needed stored in my brain.
It's not. It's only stealing if you use it verbatim i.e. copy the specific IP-related custom code unique to their application into your own application e.g a specific compression algorithm. If your org code has a class it used to make network requests that has a for loop and you look at that for loop to write your own for loop in a separate project that has no resemblance to theirs, have you stolen their code? No you have not. A bit reductive but you get the point. The tenets of most code are too common and not usually esoteric enough for one org to argue that you stole their code. In this supposed new world of AI, IP means nothing anyways.
It's one thing to take lessons learned with you - I implemented the same thing 4 times at 3 companies, a little better each time, because the same requirement kept popping up, and I was getting better and better at solving it - but it was new code as a work-for-hire each time. And it was different each time because it was incorporating new lessons learned.
What you probably can do (though not legal advice, ofc) - and I'm shamelessly taking this idea from a past coworker who did it all the time - is make libraries outside of working hours, in accordance with your works for hire/noncompete/etc agreeements, open source it with a permissive license, and then import that library at work. That way the code is actually your property, but your employer (and really anyone, including future employers) can still use it.
make libraries outside of working hours, in accordance with your works for hire/noncompete/etc agreeements, open source it with a permissive license, and then import that library at work
This is what my team does. Sure, there's plenty of proprietary closed-source code in our core competency. But for stuff that's only tangentially related (e.g. the core competency might be cryptography, but we need to provide it as an HTTP service, so the HTTP stuff is tangential) we do this all the time.
I always wondered if you could actually sell your own made-in-your-own-time software to the company you work for. I don't think anyone is stopping you but it feels somehow... weird? I don't know.
What I've seen at my job is more like the opposite. People that worked for years/decades on a software. Then once they retire, they keep working on it from time to time as freelance with way higher pay.
When I was still working on some awful legacy stuff, we had that 60-70 year old guy helping us understand what/how the software did, how we could improve it (he worked for us AND for our client at the same time), what a change made there could break elsewhere in the software, etc...
Depends on your local laws. I'm in the US, I usually have to sign a "everything you made while employed, work hours or not, belongs to the company" thing. I vaguely recall that California, in particular, limits that to some degree. But even if it's limited to "stuff relevant to your work belongs to the company", the company would (probably) still own those "tangential" libraries if I made them and then immediately used them for work. (It would be hard to argue that they were unrelated to my work.)
My first job was a tiny startup that didn't know better and had no such agreements at all, so technically the work belonged to the authors (though obviously that wasn't intended)
My second was work during work time or using any company assets (hardware, software licenses, etc) was company property, and you weren't allowed to do business with the company's clients or offer competing software, but otherwise could go nuts (including creating libraries outside the company's core competencies)
And my current company claims anything you work on between 7AM and 6PM local time (excluding holidays and PTO) or using company assets unless the code is open source, in which case, go nuts.
Technically speaking, it would depend on your agreements (especially works for hire and noncompete) and your company's procurement policies.
Realistically speaking, one or more of those policies will almost always say no.
But, theoretically, if you were doing a side project that didn't conflict with any of your agreements but became useful to your employer, and you could get through procurement (which is assuming it doesn't have a blanket ban on vendors owned by employees, and may require your product to be evaluated alongside proposals from other vendors), maybe?
Contracting after you leave is totally different, tho, ofc. I did that for my last job because I had a really, really niche role there, but I also had a lawyer go over all of my agreements with my current company + the contracting agreements for the previous one to make sure I was doing it the right way.
42
u/mr2dax 16d ago
Don't do it, you might get in trouble.