developer.law / Knowledge
What is background technology?
The code you reuse across clients — and the one clause that decides whether it stays yours.
The plain-English answer
Background technology is everything you bring to a project rather than build for it.
If you have been shipping software for more than about a year, you have some. The auth scaffolding you have stood up eleven times. The deployment scripts. The component library you keep pruning. The data-migration utility you wrote once at 2am and have quietly reused ever since. None of it was written for the client in front of you. All of it will end up in what you hand them.
Four buckets, roughly:
- Code you own outright — internal libraries, boilerplate, generators, starter repos, snippets carried between jobs.
- Tooling and process — CI configuration, testing harnesses, infrastructure-as-code, the deployment pipeline you drop into every engagement.
- Know-how and patterns — architectural approaches and implementation techniques you have refined across clients. Harder to point at, easier to lose.
- Third-party components you license — open-source dependencies and paid libraries. Not yours to assign in the first place, which is its own problem if the contract says you are assigning everything.
The reason this matters is arithmetic. If a contract assigns "all intellectual property created or delivered under this agreement" and says nothing else, and you deliver a repository containing your reusable auth module, you have a defensible argument that you did not intend to assign the module — and no clean way to prove it. You will spend more establishing that than the module is worth.
What it means for your business
The default rule works against you here
Under US copyright law the creator owns what they create. That sounds protective, and for background technology it mostly is — but the protection evaporates the moment you sign an assignment clause broad enough to swallow it.
Note the asymmetry with employees. Work created by an employee within the scope of employment belongs to the employer automatically. For independent contractors, "work for hire" is far narrower — it applies only to nine categories of commissioned works defined by statute, and custom software is not one of them. That is why every serious client contract contains an express IP assignment: without one, the client does not own what they paid for.
So the assignment clause has to exist. The question is how wide it reaches.
The definition is where the real negotiation happens
Both sides agree background technology should be carved out. They disagree, substantially, about what counts. This is the fight, stated plainly:
| The developer's position | The client's position | |
|---|---|---|
| Timing | Anything I built before or during the engagement | Only what existed before the engagement started |
| Relatedness | Anything not developed specifically for this client | Only what is unrelated to this client's project |
| What they get | A license, scoped to their deliverable | Assignment of as much as possible; a broad license to the rest |
| Burden | Client shows an item was built for them | Developer identifies and schedules each item up front |
The timing row is the one that decides real disputes. If you build a generic rate-limiting utility in week three because the project needed rate limiting, is that background technology or foreground IP?
Under the developer's definition, it is background technology — it is broadly useful and was not built to the client's specification. Under the client's definition it is foreground IP — it did not exist before, and they paid for the hours that produced it.
Neither reading is unreasonable. Both are common. What is unreasonable is signing a contract that does not say.
What the client actually needs — and why giving it costs you nothing
Here is the part developers often get wrong by over-defending: a client who licenses rather than owns your background technology has a genuine problem to solve, and it is fair to solve it.
They need to keep operating the software after you are gone. They need to hire someone else to maintain it. They may need to sell the company, and a buyer's counsel will ask whether the product depends on a license that can be revoked.
So the license you grant should be perpetual, irrevocable, worldwide, royalty-free, and sublicensable — sublicensable so it survives an acquisition. Giving all of that costs you nothing, because none of it stops you from using your own tooling on your next ten projects.
What the license should not be is unlimited in scope. Grant it for use within the deliverable — to run, maintain, modify, and extend the work you delivered. Not a general right to extract your library and use it in unrelated products. Not a right to redistribute it as their own. The distinction between "you may use my tooling inside the thing I built you" and "you may have my tooling" is the entire ballgame, and it is one sentence.
Residuals: the clause about what is in your head
Some agreements include a residuals clause — the right for your people to use general knowledge, skill, and experience retained in unaided memory, even after exposure to a client's confidential information.
For a shop that does similar work for multiple clients, this is worth asking for. Without it, a client can argue that your next project reused something you learned on theirs. Residuals draw the line between general expertise, which you keep, and their specific confidential information, which you do not get to reuse regardless.
Expect resistance. Clients with real trade secrets often strike it, and that is a legitimate position rather than a hostile one.
Make payment the trigger, and back it with the repo
A carve-out protects what stays yours. It does nothing about the rest of it if you never get paid.
Two mechanisms, and you want both:
- In the contract: IP in the foreground work transfers on receipt of payment in full, not on creation and not on delivery. Until then the client holds a limited license to evaluate the work — enough to run acceptance testing, not enough to ship it and stop returning your calls.
- In the infrastructure: develop in a repository you control and transfer or grant access on payment. A contractual condition you would have to sue to enforce is worth considerably less than a permission setting you control.
The second one is the one lawyers forget and developers already know how to do. Use it. And say so in the contract, so that operating the repo this way is a term of the deal rather than something you did unilaterally that looks like leverage later.
How to write the carve-out
A workable structure has four parts:
- A definition of background technology that states the timing rule explicitly — before and during the engagement, excluding anything developed specifically for the client.
- An exclusion removing background technology from the assignment clause, phrased so it controls over the assignment language rather than sitting alongside it.
- A license grant — perpetual, irrevocable, worldwide, royalty-free, sublicensable, and limited to use within the deliverable.
- A schedule, if the client asks for one, listing the material items. Keep it descriptive by category rather than exhaustive by file, and say that omission from the schedule does not waive the carve-out. An exhaustive list becomes a trap the moment you forget something.
Where developer.law fits
Every client agreement we build for software shops carries the background technology carve-out by default, drafted from the developer's side of the table:
- Solopreneur — $49/mo — a lawyer-built client agreement with the carve-out, the deliverable-scoped license, and IP transfer conditioned on payment in full. For freelancers and solo shops.
- Consultant — $69/mo — everything above, plus subcontractor agreements that assign your subs' work to you before you promise any of it to a client. If a sub keeps their own background technology and you did not know, you have promised something you do not have.
- SMB — $99/mo — the same protection across unlimited clients and subcontractors, for shops running several engagements at once.
If the client insists on their own paper, that is common and not automatically bad. Our attorneys will negotiate any form, and the Lawyer Scoping add-on covers unlimited questions about a specific clause when you want a read before you sign.
We're lawyers, remember? Please read this important note:
Story LLP is a law firm, and Story's lawyers built Aegis to deliver better, standard legal services at scale so founders can choose between top-tier specialized lawyers and standardized process automations that replicate those lawyers according to their needs and budget. By definition, a standardized process may not be perfect for you. Please review our Policies page to better understand the difference, as well as how we use AI and how we manage conflicts, privilege, etc.
As a law firm, we must screen clients for conflicts of interest, and we treat all correspondence with clients seeking legal advice as privileged and confidential to the maximum extent possible in consideration of any conflicts. However, Story's law firm or our Attorney Allies do not represent you or your company as your lawyer, do not have an attorney-client relationship with you or your company, and do not provide you with legal advice absent a formal Engagement Letter signed between you and the Story LLP law firm. Please don't confuse the free knowledge we offer on this site with legal advice for you.