Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I know the company you work for owns the code and obviously you will get arrested if you try to sell it. But is it uncommon for developers to keep a personal copy of the code they wrote (for future reference)?
Apparently this guy was sent to prison for copying source code.
But is it uncommon for developers to keep a personal copy of the code they wrote (for future reference)?
I don't know how common it is, but common or not, it's still a bad idea.
Programmers often operate in the mindset that solving the same problem twice is a waste of time. We try to design our code to be reusable (sometimes). We build libraries of classes and functions to reuse at some point in the future. We sometimes even give our code away so that nobody else will ever have to write code to solve the same problem that we just did. So it may be understandable to want to take "your" code with you when you move from one job to another. But you still shouldn't do it, for the following reasons:
It's not your code to take.
The code you wrote for your former employer is part of the business they built. Their code is part of their competitive advantage. Sure, competitors could write their own code to solve the same problem, but they shouldn't get the advantage of building on work that your employer paid for, owns, and didn't authorize you to take.
If they have any sense at all, your new employer doesn't want any part of the code that you took from your former employer. The more you "refer" to work you did for some previous employer, the more you put your new employer in legal jeopardy.
If you ever accidentally let it slip at New Employer that you've still got a copy of the stuff you did for Old Employer, your boss at New will probably realize that you'll take a copy of their code when you leave for some other job. That might not sit well with him or her.
Even if you're not cribbing actual lines or just vague ideas from your old stuff, just having your old stuff in your possession could raise suspicions that you might be using it for something. Imagine that Old Employer sues New Employer, and as one of a small handful of employees that moved from Old to New, you suddenly find yourself giving a deposition. None of you actually copied Old's code into New's product, but the lawyer in front of you asks: "Mr. SuperFoo, do you now or have you at any time since leaving Old Employer had in your possession a copy of any code that you or anyone else wrote while working at Old Employer?"
You don't need the code that you wrote last month, last year, or longer ago. You solved the problem once, and now you know how to solve the problem again. Or, you may know how not to solve the problem -- your new implementation will be better because you have experience.
There are better ways. It's hard to go back and learn anything useful by reading old code out of context. A diary or journal that describes what you learn, ideas that you have, etc. is far more useful later on.
Even if Old Employer knows that you've got their code and is OK with that, you still don't want it! The only thing that can come of having it is a 3am phone call: "Hey there, SuperFoo? How are you doing? Listen, you've got a copy of our stuff, right? Look, we've got a problem with the system, and we've narrowed it down to a couple files that you wrote that our new guy just doesn't understand. I know it's late, but could you walk him through SuperDuper.pl?"
Let it go. You don't need it.
for (int i=0; i < N; ++i) in my code, it surely is not illegal to use it elsewhere at another company...
I always keep a copy of the code I write and take it between jobs. Subsequent employers never get to see/run the code, but I use it as a reference at home: 'Ah yes, didn't I do something similar to that on Project X?'.
Is this legal? Depends on jurisdiction and circumstances, but it is fairly common. Morally, I have no problem with it, providing you aren't simply giving code to new employers... It's a reminder and a demonstration of what you have done, rather than a free resource for your employer.
[The flip side of this is the inevitable shame that comes along when you look at older code: 'What was I thinking?? Why on earth did I do it that way??']
This is a very bad idea. That code doesn't belong to you (legally speaking) and having possession of it can get you into a lot of trouble. This becomes even more true when you move to a new job and still keep that source code around. Even worse if it's a competitor. Your company would not be happy if you had access to their source code when you don't work for them anymore.
It's all about managing your risk. It's obviously expected that you retain things from a previous employer that you can use somewhere else. This is why they make your sign non-compete clauses that last X months/years after you leave them, however having possession of the code makes you more vulnerable to someone accusing you of blatantly copying the company's code (even if you didn't, and just used the same ideas). Is having the code worth managing this risk?
Surely the useful stuff you got from writing the code is not the exact syntax; it's the knowledge you gained. It's probably not worth dealing with all this legal stuff.
It's not uncommon.
I have a copy of almost1 every piece of code I've written professionally, and certainly all the code from my current projects, regardless of who wrote it2. Along with the code I have a huge pile of legal paperwork clearly defining what I can and cannot do with it. Just having the code is not the same as trying to profit from the code.
That said, it's a legal issue, and legal issues tend to be extremely complicated and localized. If in doubt, you really need to talk to a lawyer. I may keep my code around, but I'm 99% certain I won't get in trouble for doing so.
1 What's missing is mostly what I didn't care to archive. Only one small project's code is missing because of legal reasons.
2 Nature of the projects and my role in them, I'm one of the guys that need to have at least an idea of what goes where, even if I wasn't involved in building a specific module.
I see your arrested Chinese man and raise you with a "code is not property, therefore cannot be stolen".
Ref.: Code 'not physical property', court rules in Goldman Sachs espionage case
With that said.
Here's a simple question for you. Go to your boss and tell them: "I have a copy of all code I wrote while I worked here. Only code I wrote, not other peoples. This is for my own education, and I will never give it out".
Their next actions will dictate (yes, that word does exist in North America/World) if you are in the wrong or right in their eyes.
Regardless of your own "ethics", you work for an employer. If they deem that what you are doing is wrong, then it is wrong based on their ethics. As they pay you, and you are employed by them, then it is in your court to either agree with them, or disagree, which could get you fired.
Now it's a question of integrity. I've let a previous employee's take some of our code, but I have vetted all of it first.
Just because you believe you are in the right, does not make you in the right. Usually software developers sign contracts when they are employed. If you signed one, you need to live by your word.
is it uncommon for developers to keep a personal copy of the code they wrote
Answering the question directly, I'll say in my experiences this is uncommon. The exception to this that I have seen is people who do a lot of freelancing and they keep the code on hand for their client's future maintenance and enhancement projects, and I would imagine that this is clearly stated in the contract (though I am not in the habit of reviewing my friends' freelancing contracts, so who knows). People I know who work in larger companies have never admitted to keeping code from former employers.
I know I wouldn't because I can't think of a single situation where it would be useful (not to mention that I'm pretty sure my current employer prohibits such things - I would just have to look up the documents to be certain). The code I've written/fixed is usually so specific to a particular business requirement that I can't imagine it ever coming up again in the future in such a way that it would be easier to re-use the old code than write new code.
Back in the day it was common for developers to have their personal library of routines that they would use to solve problems at the current job. The source would stay behind when the developer left, but any enhancements also went with him.
This resulted in a win-win situation. It was also just a subset of all the code written.
Of course most of what was in personal libraries would be in standard libraries today.
Under an employer to employee relationship in most parts of North America it is illegal to transfer or transmit digital material (i.e. source code) from your employers equipment without prior legal authorization from the employer.
Part of the legal laws relating to the definition of an employee in the work place, is the description that the employee does not provide his/her own working equipment unless otherwise stated in the employee contract, with exception to trades which require the employee to purchase their own equipment (i.e. construction worker).
Most employment laws in North America define the employer as the principal risk taker in an employee to employer relationship. The employee is paid for his/her time while the employer provides materials, equipment and controls the work related activities of the employee.
At what time during this relationship does it make it OK to steal valuable material from the employer, who has paid for and taken risk in having said material created?
The key problem with this was the question "source code that you wrote?". No sir, it is not you who wrote it. Under guidance of your employer it is them who wrote it. You are just the hired hand who typed it out. There is no court in North America that will side with you should your employer take legal actions to secure their property. Just copying the source code to a USB thumb drive can get you into hot water.
With that said, if an employer allowed you to use your own equipment (i.e. laptop) or transmit the material, then it's a different matter. The employer must notify you upon termination that any materials should be returned/destroyed.
Just thought I would post this answer, because it seems like some people thought this was a gray area. I really don't think if you're a developer, that you should be going around the Internet posting that you keep copies of employer's materials. I mean, you clearly already knew the answer to this question because you created a new member account just to ask this question. ;)
I've done this in the past a few jobs ago.
However I've never once gone back and looked at it. I've occasionally reused ideas and things I learned but I've not once found a reason to go back and look at the code.
So I wouldn't bother any more. It's legally dubious, and I've never actually found it useful in practice.
Sure. I like to keep a copy of all the work I do - whether it's writing code or otherwise. Call it a scrapbook, if you like. Breaking the rules? Perhaps.
The comments about competitive advantage are irrelevant unless your next employer is a direct competitor. If you move from a phone company to a software house, or from a game developer to a database developer, it doesn't matter. If you're actually planning to reuse code - well, that's a different story.
Interestingly, you often hear about web developers bringing a "box of tools" with them, with a standard set of JavaScript libraries and CSS stylesheets. But I haven't seen that mentioned here.
I have just recently deleted all the old code I kept from my previous employer. I only kept pieces of code that I thought were good for future reference. I've actually found that I've moved on considerably since I left and I've never referred to the old code. I've found/discovered/learnt far better ways of solving the same problems.
It was a nice little trip down memory lane though :)
I think there needs to be a distinction between a design-pattern and actual code (copying line-by-line)
Writing down some psuedocode something like - this is a great way to lazy load X in Y is one thing. Writing down all the code is something else.
With your employer's permission publish the neat re-usable code as open source projects for other people to use. Then your employer can also benefit from contributions by other people to this code.
This way you can keep the code legally, build a public portfolio of code you've written and the code can benefit other people.
For a different number of reasons, like working from home, you might as well already have a copy, and I for one wouldn't go deleting these after a job, why do that? It doesn't go against my beliefs or something.
But, regarding using it, it is not so useful as a blog post!
Bottom line: write your code, blog about the problems you've faced and how you solved them (especially when it's generic and broad stuff), and don't mind to keep a (possibly encrypted) souvenir from the last job.
In finance the CFA addresses this issue. You are not allowed to take information related to clients or your work for the company (in this case code). But nothing prevents you from memorizing what you can and then writing it down later.
Not sure how legitimate that is, but I think your best bet is to leave your source code but write down your ideas and how you did it as soon as you get home. Stealing is stealing and in court all they are trying to find out to decide is if you copied the code or not.
If you are saving your code with the goal of reusing it later, I have two issues with that:
If the code is domain specific, it is probably also proprietary. Anyway, no two businesses or problems are exactly alike and trying to fix one problem with the solution for another is not a good pattern.
If the code you are saving solves a common problem, you should question your approach. Why are you spending a lot of effort to solve a common problem when they are likely existing (and better) open source solutions?
If you believe that you have the best solution to a common problem, you should really try to share you code publicly on a public repository and/or code blog when you write it, not keep it to yourself. Your boss should not object to sharing a generic library or force you to reinvent the wheel (if he does, find a new job).
If you are saving your code because you want to show it to a potential employer or to improve your skills, I suggest you contribute to an open source project instead.
I haven't yet kept any code that I've done for employers. Freelance stuff I've kept (it can be hard to support a client if I lose my code).
However, I'm considering keeping the code that I have made for this employer. The reason is that I'm a web developer, and I've developed a lot of client-side things that look rather pretty. I didn't design them, but I implemented them and often came up with the idea. I would like to keep a copy of this stuff to build an online portfolio. As we all know, sites don't last forever, so I can't realistically count on my work staying online. Having a backup copy would allow me to have a portfolio online.
I know that designers often keep copies of their work (even if it was work for hire) for portfolio purposes.
I'm not sure what the legality of this is (it is not explicitly mentioned in my contract).
but what are your thoughts on this? Please don't openly invite a conversation on your answer by introducing another question. You tell us if we should keep a copy of all the code we write. You can improve the answer by editing it.
Well, for developing the business logic for my company, I can't keep the code because it's illegal & personal property of the company. As the developer, I know how to develop that logic, so I can keep that logic in my mind. Basically by default it is stored in your mind, and if you need it next time, then automatically you should implement the logic/better logic than the previous one. It's the human nature & intelligence. :)
But the issue creates when you develops some utility logic, they are re-usable & always important, you may need it frequently in different projects. So you should want to keep it with you.
I have an alternate solution to that. Just create a without source/documentation JAR for thos utilitiess and add it as an external third-party JAR in your project. Probably by doing this you can confirm your responsibility as well as your self satisfaction that you have the code ;)
I don't keep code for a simple reason: The company paid me to write the code for them. I give them my code, and they give me my paycheck. The guy who made my lunch, does not get to keep part of it for themselves, why would code be different?
Also, the point made before, I walk out of job, all those headaches stay there, new job, new start, but with a bit more experience and understanding of the types of problems in that old job's domain.