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

Question

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.

Answer 1

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.

Answer 2

"No" is a perfectly fine answer, actually it's an incredibly useful answer which for some reason I can't understand is very underrated.

"Hi, we have suddently decided we just want source code too, free of charge."
"Hi, no."

It's not that difficult, really.

Then, if they wish to pay egregious amounts of money over what they already owe you, you might give them a trimmed version of your application, which includes only the sources they actually need, and taking care they get absolutely non-exclusive rights.

Don't complicate simple things.

Answer 3

Your question is, "what is the best way to circumvent this issue?" But what do you see as the issue? Others have correctly pointed out that it's a matter of negotiation: everything has a value, and it's up to you give the client a price for providing what's asked for.

But you must also carefully consider—and write into the contract—the implications of providing the code. Is it just so the client can see it? Can the client modify it? And in particular, would you consider giving your client exclusive rights to the code base you have created over the years and is used as a template for most applications so that you can never again use it yourself in the future?

You need to ensure the contract explicitly states who has rights to use the code, and in what ways.

Answer 4

Remember that any source code requires a license. If you hand over source code, the company can use the source code to do anything that the license allows, and anything beyond that is copyright infringement. So if you hand over source code, you would have a contract that makes absolutely clear that you retain the exclusive copyright of the source code, and exactly what uses of the source code are allowed. And of course source code + license wouldn't come for free.

A major company would be unlikely to infringe your copyright, because being caught would cause a major damage to their reputation, apart from financial damage. On the other hand, paying out for software with no guarantee that any problems can be fixed in the future, might be unacceptable for the client.

Answer 5

Earlier I usually provided the source code (libraries and all) under a MIT license to the client. If your libraries are well organized you only provide the needed files/resources for that particular client but nothing more. I think that is fair for both me and the client. However there was always the issue of new code written for that particular client under contract that was not part of the library before. So I started to discuss the issue with the client before starting the project. Some clients wanted ownership of that code, some don't (I always gave negative incentives, like higher prices for those who do). But, really for some clients that discussion was very confusing and sometimes I ended up talkin for 3 or 5 different people (including their lawyer) just to get the project approved.

So now all my libraries are part of a custom framework I always use to develop and I explain the client that I will use this framework but that the framework is a different product with a different license. (Sometimes I use "software components" when explaining because "framework" may be unkown to them). I always provide the code of the used files under a MIT license and (because all the code is well organized) the low level code (even the new) remain in the framework (to be reused by me and by them) but the code relating to their application only is for them to keep under their own terms (that code most probably would be useless for me to reuse in another project). Of course all that is properly written in the contract. I think this is fair too.

The key is: "these components are a different product" and all is written in a contract before starting.

So yes, you idea about using shared libraries may be right. However, I ask you, why don't you provide them the source code you used, under a license that will allow them to reduce their risk? I think that would be fair.

Answer 6

The way to deal with this is to negotiate.

If they want source code, then they should be prepared to pay for it, and it is up to you to decide how much that should be.

On the other hand ... if they are not prepared to pay what you want, they may decide to "take their business elsewhere".

Welcome to the world of business :-)

---

And when you talk to prospective customers in the future, be sure to mention this issue early on ... to avoid wasting everyones' time.

---

It is also worth noting that what you are doing is anathema for open source developers, and for (educated) customers who are looking for open source solutions.

Answer 7

This may be too late for you, in that you may already have agreed contractually to do this, and you could have agreed to mutually incompatible terms with different customers.

There are two ways in which you can provide your customers with your source code. Ownership of the copyright and licensed.

Some customers will want ownership of the source code. This means, at the end of the process they will pay you money and you will in exchange give them copyright copyright of the code you create for them. One reason for this is if they see significant potential for intellectual property in the source code, and may want to value this on their company balance sheet. In this scenario, you will have no entitlement to continued use of that source code for other projects, unless you also obtain a license from your customer giving you this entitlement.

If your customer is buying an 'off the shelf' product from yourselves, they would expect to be receiving a license to use the software, not ownership of the source code. They should be expecting that you are selling the same (or similar) software to many other organisations, and that they are hopefully benefiting from a lower cost of purchase due to the wider customer base.

However, the situation in this question is a mishmash of the two.

Here is what I would want to be able to do. I would grant your customer a license to use (and modify) your shared code. If quizzed by the customer, I would point out that this is shared code that you have already used in multiple projects and have current bids in place for future work that are based on you continuing to use this work. point out that this has resulted in less time on this project for your customer and that they have paid a lower price as a result. Like other shared libraries of code used by the project, they have a license in place to use this code, and to allow other development teams to develop this, and other projects based on this library. However, if they would rather ownership of all the code, you are willing to create a replacement, but this would be an additional charge.

Depending on what you have already committed yourself to, you could be having to write a replacement functionality for free, or giving away your source code.

Remember, there are different types of libraries. The Standard Template Library in C++ is a good example of a library that is included at a source code level and is compiled into a project executable that may be quite similar to how you have used your common code.

Answer 8

If you use a third party with the software that you deliver, chances are that you don't have the source code for this third party. You will still deliver the software to the company with binaries of the third party. The code that you developed as a framework shared in all your projects is exactly like third party even if is owned by you. In this case, the company have exactly the same risk with the binaries of your framework than with the third party. Why in this case would you give to the company the source code of your framework. You can provide to her a good API documentation with a licence agreement and that it. If your code contain the next big thing that will revolutionize the industry, it's another story but it's generally not the case.