My Client Wants My Source Code and Pre-Existing Tools. How Do I Protect Them?

Two kinds of IP in every project

It helps to name the two categories clearly, because good contracts do.

Clients reasonably expect to own foreground IP, usually on payment. Background IP is where overbroad contracts cause trouble, because standard assignment language does not distinguish the two.

• Foreground IP: the new, project-specific work you create for this client, such as their custom features, their screens, their copy.
• Background IP: what you owned or developed before the project, or develop independently during it, such as your libraries, templates, frameworks and know-how.

Why the default wording catches your tools

Assignment clauses tend to use phrases like "all work product," "all materials developed or used in connection with the services," or "all intellectual property arising from the engagement." The words "used in" and "in connection with" are the danger. Your pre-existing library is used in the project, so the clause arguably assigns it. Even if a court would read it more narrowly, you do not want to find out in a dispute, and you may be unable to reuse your own code for the next client in the meantime.

The fix: a background IP carve-out plus a licence

The standard solution has two parts. First, a carve-out that says you keep ownership of your background IP. Second, a licence that lets the client use that background IP as part of the deliverables, so the client is not left with software it cannot legally run.

Most clients accept this once it is explained, because it gives them everything they actually need: the right to run, maintain and extend the product they paid for.

• The licence should be non-exclusive, so you can keep using the tools elsewhere.
• It should be perpetual and irrevocable for the delivered project, so the client is not at risk.
• It usually allows the client to modify the code as part of maintaining its product.
• It usually restricts the client from selling or distributing your tools on their own.

List what you are bringing

The strongest carve-out is specific. Attach a short schedule listing your background materials, such as "authentication module, admin dashboard starter, analytics utility library," or simply identify the repositories. Where a list is impractical, define background IP as anything you can show existed before the start date or was developed without using the client's confidential information. Keeping dated commits and version history makes that easy to prove.

Source code delivery and escrow

Owning foreground IP and receiving the source code are separate questions. A client that owns the product usually needs the source code to maintain it, and that is fair. Problems arise when contracts demand delivery of all source code, including background tools, in a form that lets the client reuse them outside the project. Deliver the full codebase for the product, with your background components included under the licence, rather than as separately assigned assets.

If a client wants assurance that it can maintain the product if you disappear, a source code escrow or a well-documented repository handover is the usual answer, not an assignment of your toolkit.

Open-source components

Most modern projects include open-source libraries. You cannot assign what you do not own, so the contract should say that open-source components are provided under their own licences. Be careful with warranties promising that "all code is original" or "free of third-party components," which you cannot give honestly. Some clients also restrict certain licence types, such as copyleft licences, and it is better to agree that list upfront.

Know-how and non-competes in disguise

Some IP clauses go further and assign "ideas, methods, techniques and know-how" developed during the project. Your general skill and experience cannot sensibly belong to a client, and a clause that tries to claim it can operate like a non-compete, stopping you from building similar things for others. Ask for a residual knowledge carve-out: you can use general skills, ideas and experience retained in memory, as long as you do not use the client's confidential information.

A worked example

Marcus, a freelance developer, builds an e-commerce site for a retailer using his own checkout module and theme framework. The contract assigns "all code and materials used in the services." A year later, the retailer's new agency sees his checkout module in another client's site and claims it belongs to the retailer.

If Marcus had carved out his background IP and granted a non-exclusive licence, the retailer would have had full rights to use and modify its site, and Marcus would have kept his module. Instead, he faces an argument that he assigned it away, and has to rely on dated commits to show it pre-dated the project.

Sample wording you can propose

"Contractor retains all rights in materials it owned or developed before the Effective Date or develops independently of this Agreement (Background IP), including those listed in Schedule A. To the extent Background IP is incorporated in the Deliverables, Contractor grants Client a non-exclusive, perpetual, irrevocable, royalty-free licence to use, copy and modify it solely as part of the Deliverables. Open-source components are licensed under their own terms."

Common mistakes

• Accepting "used in connection with the services" wording without a carve-out.
• Relying on memory rather than dated records to prove what pre-dated the project.
• Promising all code is original when it includes open-source libraries.
• Letting know-how or "methods" clauses restrict future work.
• Forgetting that a revocable licence may scare the client; make it perpetual for the delivered project.

Quick checklist

• Does the assignment cover only foreground work created for this client?
• Is background IP defined, carved out and listed?
• Is the client's licence non-exclusive, perpetual and limited to the deliverables?
• Are open-source components dealt with honestly?
• Is there a residual knowledge carve-out for general skills?
• Do rights in foreground IP transfer on payment?

Key terms explained

These terms come up in almost every negotiation over source code and tools.

• Foreground IP: new work created specifically for the client under the contract.
• Background IP: pre-existing materials and independently developed tools you bring to the project.
• Non-exclusive licence: permission to use something while the owner can license it to others too.
• Source code escrow: a third party holds the code and releases it if agreed conditions occur.
• Copyleft: open-source licences that require derivative works to be shared under the same terms.
• Residuals: general knowledge retained in memory that you remain free to use.

Protect the toolkit before the project starts

Your reusable tools are part of your business value. It takes one paragraph to protect them, and it is far easier to add before work begins than to argue about after. If a client contract uses broad "used in connection with" language, upload it and have the IP clauses checked before you sign.