How can I reuse generic code for consulting between companies?

Question

I am employed full time for company X and approached by company Y to do consulting services to write embedded C for them. While I know the basics of conflicts of interests and the big no-no's of sharing proprietary information, company knowledge and proprietary algorithms, I do have some questions regarding basic generic items that I need to reuse:

• Software architecture: I have a personal preference of layering application, abstraction layer and hardware drivers. I don't want to have to do something different and it is not proprietary to the company. Would this be a problem if shared?

• Generic functions: table look ups, sine/cosine functions, parsers, etc. I wrote all this code myself. Can I copy-paste this or do I have to rewrite, insert random spaces, change indentation, var names, table sizes, etc?

• Function naming: I use a specific naming convention, e.g. MATH_Sin(). However, compiled to a DLL, company X can find a MATH_Sin() function available in company Y's DLL and assume that I copied their code. Do I need to rename all functions to hide any similarities?

• Public knowledge turned into source code: say you find an algorithm on an paper that describes how to search for a pattern in a string and you turned the paper content into source code. Again, would a copy-paste be a no-no here too? Rewrite changing a few things or completely dismiss and find for another way to do it? In the end it is an implementation of public knowledge.

I asked around my peers and I cannot get a straight answer on what to do. Software is digital and very traceable and can always be traced back to the developer.

Thanks.

Update: I have approached my manager and HR and they strongly discouraged me to pursue this. They claimed that by using the same skill set (embedded programming or programming in general) for another company, there will be always the opportunity for company X to challenge myself or company Y. I asked then what would NOT be considered a conflict of interest and they answered "You could invest in a restaurant...". Seriously?

Company X is a very large corporation. There is no negotiation between employer and company, there is no acceptance of open source/licensed code and it seems they believe they own me and my skill set. While I do agree with some of their reasoning, I do not agree that they own my education and, while employed for them, I can't make use of my basic skills for other endeavors. Therefore I have decided to follow the advice below and open source all my personal code that does not belong to the company nor was written using company equipment or company time. I won't be making money or signing contracts, but at least I can keep my personal code and continue developing my career outside this restrictive environment.

Thanks for all answers. Hope this serves as a reference for others pursuing the same goal.

Answer 1

If you billed the time for developing some code to a particular company, then you're stuck - that code belongs to them and you can't take it with you.

If you have built up a library of your own code on your own time, and you want to be able to reuse it in different projects to boost your efficiency, one solution is to release that code under a permissive license, which you can do by just writing "License: LGPL" or whatever in a comment in the header.

You might think that this would lose you your competitive advantage, because someone else might just pick up your code and start using it, but

1. You will always be the one best able to make use of your own code, and

2. Just because the code is licensed for free use doesn't mean you have to post it on your website somewhere for the whole world to steal.

Answer 2

This is bordering legal advice and this site is not really definitive source if you need accurate info. While switching jobs a while ago, this very same question popped into my head and I did a bit research, but take whatever I say with a grain of salt.

1. If you are a full-time employee, the code written on company time belongs to that company.

2. You need to be very careful about "developing on your own time". A lot of companies consider any code written while employed by them to also be owned by them. A while ago Joel wrote a very good write up about this exact topic. He does raise good points that in some cases companies include in the contract that any code you produce while employed with them is theirs. After all we are salaried and don't have set hours. I might be special case, but for me most productive time is 12am to 5am. So how do you prove what constitutes "company time"?

3. When switching from one job for another, I left a relatively large personal collection of code behind. I never even considered taking any of that code because a) it's probably not the most ethical thing to do in the world and b) I've read enough stories to steer completely clear of anything that involves my previous employers code. However, when I started working in my current company, I found that the first 3-5 months I've spent rewriting a lot of what I already wrote once. It felt weird because even though I wasn't looking at the old code, I knew it well enough where I could easily duplicate something that would look very similar. After doing a bunch of reading, I could only conclude that while company X owns the copyright, they don't own your brain. You are free to write the same thing as many times as you want as long as it can never be physically proven that you had company X's code in front of your eyes while working for Y. In light of that, I would advise against simply changing white spacing and variable names.

In my case, I ended up writing a lot of it from memory but at the same time, since I've worked with previous libraries for years, I knew where they were lacking or were a pain to work with. So when I switched to company Y, I also took the time to rebuild this code from scratch but with extra embedded experience.

I'm not looking forward to doing this with my next job, but the only thing I can think of is in the future before accepting an employment contract, finding a position with the company whose management is not completely against open source anything. I think I would be leaning towards companies, who wouldn't mind if non-business related libraries could be released under MIT license.