Selling Your Own Company Your Code

Question

I work for a large software company. On the contract I'm currently working on, I have to work with a grossly inefficient legacy application that we simply don't have the budget to fix, but which is very important to our customer.

Just for fun, over the course of a few months, I wrote a new, much improved version of it at home on my own time, without using any existing code from the company's project (i.e. I own the code).

How can I get this new thing I wrote into our project? I hate working with this crappy application at work, but at the same time I don't want to necessarily give away something I wrote on my own time.

How does one bring this up to their project manager (e.g. I have this code I wrote on my own time, I'll sell you it for x dollars/some other compensation), or is this considered a frowned-upon practice? Should I expect to give away my code for free in cases like this and hope for a pat on the head?

P.S. I want to try and keep this generic, so let's assume anything I signed when I was hired, such as a non-compete, doesn't keep me from doing this kind of thing.

EDIT: I'm talking about selling my company the code, not licensing it out and supporting it on my own as my own product.

---

UPDATE 3/6/2009: I got in touch with SEVERAL attornies. There are a lot of legal issues with doing this, which I will explain in detail below. By worrying about these legal issues, you should have already thought about the possible repercussions outlined by many of the posters below, and decided to go ahead and sell/give away your code to either your company or your customer (I will cover all scenarios).

Problem #1: You Can Get Sued

Note that for this problem, I am referring to "customer" as the person you are selling code to, whether it is your company or your company's customer.

It was kind of funny, because one of the first things mentioned was the Bratz case; the same one that @Michael Itzoe mentioned in a comment in @Kristopher Johnson 's post (look here for details on the case). The important part of the article is this:

The ruling, issued in federal court in Riverside, followed a jury's finding that Bratz designer Carter Bryant developed the concept for the dolls while working for Mattel.

In a nutshell, I would be making myself legally vulnerable, because the customer could argue that I created this program using the knowledge from their internal proprietary systems. In my case, I could argue that, if I made the program generic enough, that it could be applied to anyone, and would only work for them with some configuration. And I might win, but I would have to deal with courts and legal fees and attorneys and taking time off to do all that, and it could end up just being a general pain in the ass. So, this is something to keep in mind.

Now, this probably wouldn't be an issue if I only wanted to sell it to the customer. They would give me a cease & desist, and I could take it to court, or just get rid of the code or whatever. But if I wanted to/started to license it out to other companies, it could end up being a big deal, especially if there's a lot of money involved. The customer would likely want a piece of that pie, and thanks to Bratz, there would be legal precedence for them getting it and shutting me down in the process.

Problem #2: If Your Customer Is The Government, You Are Fucked

I neglected to mention in my post that my customer is the government. If your client is in the private sector, then problem #2 will likely not apply to you and you can probably skip this section. However for me, this brought up some legal and bureaucratic issues.

As I found out, selling code to the government is very messy. There are conflict of interest issues between you, your company, and the government. And depending on the agency (especially if it is going on a classified network), it may need to go through a formal approval process, which, unless your code can prove that P = NP, is probably not worth the effort.

Scenario 1: Selling the government your code

Even with the problems above, this can be done. But there are a couple things to think about.

You see, the government generally doesn't just like to buy a product by itself, it wants support with it also. And if you don't want to offer that, it might be an issue. And if you do want to offer it, you may find yourself being pulled between your company and the government for your time and, depending on the complexity of your code, may actually not be physically possible given the number of hours in a day. You could hire a support person full time if you want to go that route, if the money you got was good enough.

The other issue you might face is actually getting the money. Many times the government can't alter or add money to an existing contract. So your company acting as a proxy salesman (i.e. government adding x dollars to the contract and your company giving your x dollars) may not work if the contract is fixed price. You would need to sell directly to the customer and get a check from them. The agency may or may not like this if you are "just some guy", as opposed to a company.

Scenario 2: Giving the government your code

If you decide you just want to get this code into production so you don't have to deal with the "old way" of doing things anymore, and not deal with money, this can actually a bigger problem than selling it.

I found out it is illegal to do work for the government for free. Yes, it is actually a felony to do work and not charge for it. Unless your company was paying you contract money to do this work, you can't just give it away. The only way to do this would be to open source the code under some license. However this can also lead to issues stemming from Problem #1.

NOTE: If you are an independent contractor working on a contract that exists between the company you're contracting to and that company's customer, and you are just brought in to work on it but are NOT a W2 employee of the company the contract exists with, you may be able to get away with this (again, with possible problems stemming from Problem #1).

Problem #3: The Code May Not Be Yours

As mentioned by some of the posters below, this will depend on your country's and state's individual laws, but depending on your scenario, you may not even own the rights to the code you've written. Bottom line: get a lawyer.

Conclusion

The best way to go is to get your company to pay you overtime to work on this project, and not do it on your own time, because it has the least amount of legal ramifications.

This is the route I'm going to try and go.

You will have to show your company and/or the customer that them spending extra money on you will save them x dollars. Show them the bottom line, because it's all they'll be interested in. In the case of a fixed price contract (i.e. the customer will not give you more money), the company's hourly rate for you will simply decrease to allow for you to have more hours.

In any other case where you already have something written, if you still really want to try and sell or give away your code, do not do this without an attorney, period. There are way too many issues (some of which I'm sure none of us thought of) that can come up. Keep in mind that there are a ton of different situations out there and depending on yours, as with many things, Your Mileage May Vary.

Answer 1

I have actually done this in the past. From my experience it wasn't worth it. I pulled it off in 2 weeks of programming.

But then I was tied to the project for MUCH longer than I ever wanted to be. Eventually I quit because they kept pushing new requirements into the scope.

I never made the agreed upon price ($40k short).

Answer 2

From a strategy standpoint I'd suggest approaching them with the idea of you working extra time/off time to do what you've already done. In otherwords do not let them know you've done this already.

They are the only buyer for what you've done... and they know that. Knowing you've done the work the question becomes "what's the least he'll take for it". Knowing you might do the work the question is "how much will it take to interest him in completing the work". Two different questions with different answers.

Some problem areas you'll need to think about:

• Testing. How will this fit in the schedule and how much time will it take? The buyer can use this to drive your prices down.
• Documentation. What's been done/not done? Same thing as before... insufficient documentation drives the price lower.
• Training. How long to bring other developers up to steam on the changes.
• Politics. How will the other team members react?
• Career growth. This will be your baby as long as you're at the company. Is that what you actually want?
• Legal. Could be a pot of trouble if you try and sell it to anybody else.

Also exactly how can you show the buyer that the new and improved system is actually new and improved? Sure you think the code is all shiny and nice... but they don't care about that. They care about costs and profits. How will this save $X thousands? How will this earn them more revenue? Can they reduce staff if they use the new system by laying off 1 or 2 programmers or 3 of 4 clerical staff? Would you be comfortable with that?

All in all if you'd asked before starting I'd have recommended against doing it :)

Go slow. Don't get upset if they are not interested. Don't quit your job over this. Don't get bitter over this at work. Don't throw it in their faces every time the old system fucks up. If you make a stink about this you're going to end up going nowhere at this company.

Answer 3

In your position I would just give the code to them. Your real problem is going to be switching to the new code.

You're going to need to provide testing and proof that it works.

At your next review/salary meeting I would bring it up that you did this all on your own time.

To justify a bonus or salary raise I would not raise the amount of time you spent on it as a major issue - the real factor for them is what does it do for THEM. Make the case for how much easier it is to work with and maintain and how much less overhead and less expensive it will be to deploy and maintain.

Trying to "sell" them your code is not a good idea. It sends the wrong message.

EDIT:

as for sending the "right message":

I would bring it up exactly like you brought it up here.

• you can't stand working on the existing code, broke, unmaintainable, blah blah blah
• you took action to do something about it - your own initiative and completed it on your own time
• You think it can benefit the client and your company (and give reasons)
• You want to promote this without stepping on the toes of people who might have a vested interest in the legacy crap code. They may resent you and try to derail it/your career if you make them look bad
• promote yourself and the benefits of your new code
• add it to your list of items to bring up at your next review

Be professional about it and be positive about it without being too negative about the other code. Just mention facts -how it was hard/expensive to maintain, etc - provide details with time spent, lines of code, etc.

let us know how it goes!

Answer 4

There are a lot of legal details that determine to what extent the company might claim ownership or other rights to the code you did on your own time:

• What are the laws of the country, state/province, etc.?
• Are you an employee of the company, or working as an independent contractor?
• What trade secrets, patents, etc. may be involved?
• Did you refer to any of the company's documentation, source code, or other materials while doing the work?
• Could you have written this on your own time without knowledge gained while on company time?
• How much contact have you had with the customers?
• If necessary, how will you prove that this work was done entirely on your own time with your own equipment and without any company resources?

You definitely need to consult a lawyer before making a move.

I agree with those who suggest that trying to "sell" this to your employer is likely to be more trouble than it's worth, and it could backfire. It's better to try to use this to improve your salary, position, and future prospects.

Answer 5

Depending on your country and state, the company could own what you created, even if you didn't sign anything asserting otherwise. You'll definitely need to consult an attorney before you even begin negotiations.

Answer 6

Here's the thing. It's about value.

If you give better value than what they have, and allow the company to get more done with less effort (savings in labour, process, etc) they would be crazy to look past it.

You must price this on value, not the hours worked and at your hourly rate. It's what they would pay someone else. You designed this on your own initiative, if they had proactively asked you to they might have been able to pay you your normal salary.

Sell a license of this to your company. At the going rate.. or maybe 20% off if you like them and you guys treat each other well. They have afforded you learning about the industry and they get something totally custom for them, built by someone who knows their business and how it needs to work.

Consider support, training, tech support arrangements and how they might work. In one way they are additional revenue streams, they are also additional responsibilities.

You don't need to talk to them about selling it to others in some ways. Mention it, but don't focus on it. The more you do, the more they'll worry. Ultimately, it might come out, so it's best to be clear on your intention that you have no plans to, but you may sell it to others one day.

If you enjoy a good relationship, you can consider giving them some features 6-12 months before the rest of the customers, so they're always ahead of the curve. I handled it this way and everyone was really happy as I wasn't going to go out of business or stop working on the product. My client actually saw it as a group of companies supporting one product and them all benefiting from it. Among his competitors he looked good to them in some strange way. In that case though, it wasn't a highly specialized piece of software with trade secrets, but it was just for their industry..

Let us know what ends up happening!

Answer 7

I noticed in your post that you suggested that you were a contractor... If you are a self employed contractor, you may very well not have to worry about anyone else owning any product that you developed while employed by them. But, if you are a contractor for a contracting company, it would still be possible that you have an employment agreement with them much like you would if you worked directly for your current client.

Regardless of the direction you take this, it would probably be a good idea to figure out how much $$$ you think is at stake here. If it is a good amount, say $50K or more, it probably wouldn't hurt if you created your own LLC and seek some small business consulting of some kind just to make sure you do not have anything to be worried about.

Also, if I were in your shoes given where our economy is today, I might just consider giving my product away to the company for an agreement that my contract is guaranteed at the current pay rate for x amount of months.

Answer 8

Possible workaround of selling the code to a third party who you then introduce to your company?

Answer 9

I actually have a friend who's in the process of doing this right now.

The company has a legacy system that is total crap. It's not just old, it was badly designed in the first place. Almost every atomic operation requires dozens of keystrokes and will at best take all day to complete a task, at worst give everyone carpal tunnel.

So he took it upon himself to extend and improve the various processes with his own code. I think his situation helps to simplify your problem. In his case he wasn't even hired to write software, he was hired for data entry. He taught himself to write code and wrote it all on his own time just to make his own job easier. Now he's in the process of selling/giving this to the company so that all the other data entry folks can be more efficient.

I think it simplifies the issue you mentioned because he's not really concerned with legalities and I don't think he needs to be. It's a simple case of economics and the facts are these:

A) He wasn't hired to write software, so they didn't pay him to do this

B) He wrote it on his own time

C) It makes everyone more efficient and saves the company a large and measurable amount of money

D) They don't HAVE to buy it if they don't want to

As far as I'm concerned A + B = they have no claims to his technology unless they want to negotiate for it. C + D = they'd be stupid not to buy it, depending on price, but if they don't want to, he hasn't made things any worse than they were before.

Taking the initiative and just OFFERING a better solution shouldn't be discouraged, and isn't illegal. The problem is, small minded manager types will typically do one of two things in this situation:

1) Fear change and totally dismiss the new process, especially because it didnt come down from above

2) Try to exploit the new technology to improve performance and make themselves look good without compensating the employee

So I would say you try to sell it to them, but I guess tact is going to be pretty important depending on who you end up dealing with.