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 does standard assignment wording catch 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.

How should open-source components be handled in the contract?

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.

Which laws back up a licence of your code and tools?

Clients sometimes resist a licence because they worry about losing access if your business fails. Federal bankruptcy law addresses that worry. Under 11 U.S.C. § 365(n), if a licensor of intellectual property goes bankrupt and the trustee rejects the licence, the licensee can choose to keep its rights under the licence and any supplementary agreement for the full term, and can require the trustee to provide the intellectual property, including its embodiment, to the extent those agreements call for it. A source code escrow arrangement written into the deal can serve as that kind of supplementary agreement. Pointing a client to this protection is often more persuasive than offering to assign your toolkit.

Open-source licences are enforceable through copyright, not just contract. In Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008), the Federal Circuit held that conditions in an open-source licence, such as requirements to credit the source and flag modifications, limit the scope of the licence, so a user who ignores them can be liable for copyright infringement. When you deliver code that includes open-source components, you and your client both have to respect those conditions, which is another reason not to promise that every line is original.

Copyright law also gives you the flexibility to split rights in the first place. Under 17 U.S.C. § 201(d), ownership of a copyright can be transferred in whole or in part, and any of the exclusive rights can be transferred and owned separately. Under § 204(a), any transfer of ownership needs a signed writing. A background IP carve-out plus a licence simply uses that flexibility deliberately: the client owns what was made for it, and you keep, and license, what you brought. Recording that split in a short schedule to the contract makes it easy to prove years later.

Can a client claim ownership of your know-how?

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.