Client wants source code, but it contains a lot of shared code I reuse with other projects

contractnegotiation

I have a client who would like me to deliver the source code with a developed application binary. They originally said nothing about source code, but they recently said they need it. The contract is not finalized. They agreed to the work, did not sign, and then came back with this clause.

The issue is: I have a code base I've created over the years and used as a template for most of the applications I write. It is far larger than the scope of the project.

I also intend to use it for a product, so I really don't wish to provide it for a relatively small project.

I'm guessing this is not the first time that this has happened in this industry. What is the best way to circumvent this issue? I'm guessing things like shared libraries could help.

Best Answer

The first thing to keep in mind is that source code has value separate from the binaries. It is perfectly reasonable to either refuse to sign a contract that requires source code delivery, or to insist on extra payments for source code delivery. Contracts are two-way documents. Do not let the other part dictate what is required just because they are "big companies" and "do this all the time". First, decide what you are willing to deliver and how you want to be compensated. Then take their contract to a lawyer and work out what needs to change. Then, you negotiate.

Don't do what a lot of young people do when they start contracting. Don't just sign because it seems like they have lots of experience and you don't. That's a good way to get ripped off.

Look into why they want the source. They may want it so they have the option of using another developer later on. Or they may want it just because they are afraid you might get hit by a bus and suddenly they'll be left with binaries that they cannot improve. If it is this second case, look into a Software Code Escrow Service. These services hold the source code in case you go bankrupt or otherwise are unable to maintain the software. This may satisfy both your desire to keep your code proprietary to service other customers and their desire not to be left holding the bag with an unmaintainable set of binaries if something bad happens.

Related Topic