How to explain to client that you can't give them some of the source

Question

We have a number of AS/Flex components that we've built over time and improved upon. They've been turned into components so they can be reused in different projects and save us time. So you can think of them as part of an in-house framework of sorts.

We're now realizing that it doesn't make sense to release the source code for these components to the various clients as part of the project, because technically this code isn't really owned by the clients.

So my question

• When a client comes to you, how do you explain to them that you can't give them the full source code for those components. The client doesn't understand the difference, he just expects you to give them all the code for the site that he paid you to do. He doesn't understand that this code has taken you a lot longer to write than what he's paying for his site. But since he doesn't understand, he would get turned off and thinks you're ripping him off or something.

• How do you handle this situation? What do you tell clients upfront? Do you advertise it on your site from the very beginning? How do you handle their objections so they still hire you?

• As a side question, how often do you give AS and Flex source code to your clients? In the case when the code doesn't have any in-house components that you reuse in several projects, and in the case when it does have in-house components.

I'd also like to hear from people who've worked at creative agencies since they're most likely have run into that issue already.

Answer 1

I'm not a business person, but generally these things are specified in the contract. If your contract stipulates that you provide the client with the source code at the end of the project, then at the very least, you should be providing them with swcs of your components so they can recompile the code if necessary. If you don't want to share your code with the client, then that too is something that you'll need to specify up front.

Answer 2

Just explain that you can not provide the source for external libraries that you used on his project to make the bid cheaper for him. He would not expect the source from a 3rd party vendor that you used in his project, just try to explain this is the exact same situation.

Answer 3

I'd explain to my client how the world works. I'd use examples, analogies and metaphors.

This isn't a software-development issue, this applies to all products. Some things are sold as black-box, and some things are sold as a clear-box containing black-boxes inside it.

Lets say you wish to buy a house. You pay the engineer and the architect for their work, and you gain the documents they produce. These documents contain information that relies on other pieces of information, which you do not gain. For example, the engineer may use huge steel bars in his plans. The engineer's specifications determine the qualities that each steel bar must have, but they do not specify how the steel bars are created. Buying house plans doesn't buy you the plans for creating the house's building blocks. With softwre it is pretty much the same: you don't get the source code for the .NET framework when you buy a .NET application "with sourcecode included". What you do get is the .NET documentation, specifying how to work with the framework (and not specifying how the framework does what it does).

The amount of examples is actually endless, because - as stated above - this is the way the world works.

Build your own analogies to fit your scenario. Explain to your customer where the infrastructure ends and his owned solution begins.

quoo is right about the need to specify these in the contract. The contract is the legal backbone of the deal. But i'd like to emphasise the fact that pointing at the contract should be a last resort. If you can give your client a reasonable explanation such that lets the client understand why things are the way they are, you won't need to wave the contract (which speficies only the way things are, without the motivation, explanation, etc.).

Answer 4

Your contract should make clear that components developed by you are licensed to the client for use as part of the project and only the project(s) you did for them. Of course, you'll need to determine the exact language for yourself and the situation, but if you're repeatedly using these components in your projects, you really ought to have some sort of boilerplate for just this situation.

Answer 5

Intellectual property issues should be covered upfront as part of the contract. I'm not a lawyer but common practise is to specify:

• Which components are provided by third parties and refer to their licensing terms
• Which code will be produced as part of the contract.
• Whether you license or sell various intellectual property rights.
• Licensing terms.

Intellectual Property laws` are complex and diverse, they differ from country to country. Depending where you're and where your customer is the licensing terms might need to change. As an example, reverse engineering viewed differently in different jurisdictions.

Apart from third-party components and software bits you don't want to sell, nor give an exclusive license for you'd probably want to be able to exhibit and distribute the works as part of your company portfolio. This latter activity would also need to be covered within the contract.

Having a well written contract prepared up front will save a lot of misunderstanding and unnecessary negotiations. You'd probably need just one template you could use for all your customers. So my advice really is "talk to a lawyer".