This post uses hypothetical scenarios for illustrative purposes only. It does not describe any actual client, transaction, or representation, and is not legal advice.
The simplest discipline in invention-assignment drafting is also the most neglected: a pure assignment clause captures only what the engineer creates within the scope of the engagement, and the company’s product almost always ends up depending on something the engineer brought with them. That gap — the personal library, the side-project utility module, the small framework the engineer wrote in graduate school and reuses everywhere — is what acquirer’s counsel finds in diligence and turns into a closing condition. The fix is a background IP license clause, drafted next to the assignment language, that converts the gap into a non-event. This piece is a companion to the parent post on getting equity and IP right in startup contractor and executive agreements, focused on the one clause that does the most preventive work in the IP exhibit.
The gap a pure assignment leaves
A well-drafted invention-assignment clause does exactly what its name says. It assigns to the company the inventions, works of authorship, and improvements the person creates within the scope of, or using the resources of, the engagement. The drafting language varies — “Company Inventions,” “Assigned Works,” “Developments” — but the operative scope is the same. If the engineer creates the thing on the job, it belongs to the company. If the engineer created the thing before the engagement, or creates it outside the scope of the engagement, the assignment does not reach it.
That carve-out is correct. The law does not let an employer claim ownership of everything a person has ever written or coded simply because the person took a job. The Proprietary Information and Inventions Assignment Agreement (the PIIA, walked through in detail in the post on the PIIA explained) typically includes a schedule on which the engineer lists prior inventions that the assignment expressly does not cover. That schedule is the protection for the engineer. The risk for the company is that the engineer relies on prior, non-assigned IP inside the company’s product without anybody noticing — and without the company having any contractual right to use the underlying work.
The recurring fact pattern is mundane. An engineer maintains a personal utilities library, useful enough that they reuse it at every job. On the first week at the new startup, they import the library into the codebase because it solves a small problem cleanly. The library was not created during the engagement and is not on the prior-inventions schedule (because nobody filled out the schedule with that level of granularity). Six months later, the company’s flagship feature depends on a function from the library. Three years later, the company is being acquired. The library — the engineer’s library — is now load-bearing for the company’s product, and the company has no document granting it the right to use the library.
How the gap surfaces in diligence
The scenario above is invisible while the company is operating. It becomes catastrophic during M&A diligence, because acquirer’s IP counsel runs a specific set of inquiries that surface it. Diligence on an engineering organization typically includes a request for the company to identify all material third-party and personal IP incorporated into the product, including any code written by employees or contractors prior to their engagement. Counsel will ask for the prior-inventions schedules from every PIIA on file, will compare what is listed against what the engineering team can verify about the codebase, and will ask the engineering leads directly about what came from where.
The gap is the moment that comparison turns up a load-bearing component the company cannot trace to an assignment or a license. At that point the deal has a condition: secure a license from the original author (now a long-departed engineer who may be hard to find, or who may understand the leverage they have), or rewrite the component, or carve the gap out of the representations and warranties and absorb the indemnity. Each of those paths is expensive in time, money, or both. The drafting language that prevents all of them costs one paragraph in the PIIA at the moment of hire.
What the license clause actually does
The standard remedy is a background IP license clause, drafted into the same invention-assignment exhibit that handles the rest of the IP allocation. The clause says, in substance, that if the engineer incorporates into any company product, service, or work product any IP that the engineer owns or controls and that is not otherwise assigned to the company, then the engineer grants the company a license to use that IP. The bargain is intentional: the engineer keeps ownership of their background IP (the library remains theirs), but the company gets a broad, durable right to use it inside whatever the company builds.
The breadth of the license is what makes it useful. Counsel typically draft the grant as nonexclusive (so the engineer can continue to use and license the IP to others), perpetual (it does not lapse when the engagement ends), irrevocable (the engineer cannot withdraw it later), worldwide (no territorial limit), fully paid-up (no royalties owed), royalty-free (same point, said twice for belt-and-suspenders), sublicensable through multiple tiers (so the company can sublicense to customers, distributors, and downstream parties as the business model requires), and transferable (so an acquirer gets the same rights without renegotiating). The companion representation is that the engineer has the rights necessary to grant the license and will not incorporate third-party IP without securing adequate rights for the company.
The transferability point is the one that matters most in an exit. A license that is silent on transferability defaults, in most jurisdictions, to non-transferable, which means the buyer in an acquisition cannot rely on the license without consent. Expressly making the license transferable, including in connection with an acquisition or change of control, is what allows the diligence answer to be “the license is in place, here is the clause, and it survives the deal.”
The rights enumeration is doing real work
A license to “use” software is not the same as a license to use, reproduce, modify, create derivative works of, distribute, publicly display, and publicly perform. Copyright law breaks the bundle of rights into specific exclusive rights, and a license grants only those rights it names. A poorly drafted license that gives the company only the right to “use” the engineer’s library may not authorize the company to modify it, distribute it as part of the company’s product, or sublicense it to customers — all of which are things the company will need to do as a matter of ordinary operation.
The cure is to enumerate the rights. The clause should name each of the relevant exclusive rights under 17 U.S.C. § 106 (use, reproduce, modify, create derivative works of, distribute copies of, publicly display, publicly perform, and digitally transmit) and any analogous rights under patent or other IP regimes that may apply. The enumeration looks belt-and-suspenders. It is. The reason the form drafts that way is that in fifteen years, when the acquirer’s counsel is reading the clause cold, the enumerated rights are easy to map against what the company has actually done with the engineer’s IP. A bare “use” is not.
The companion representation closes the third-party gap
The license is one half of the architecture. The other half is the representation that runs alongside it. The engineer represents and warrants that they have the rights necessary to grant the license, that the background IP does not infringe any third party’s rights, and that they will not incorporate any third-party IP into the company’s products or work product without ensuring the company has the rights it needs to use that third-party IP.
Why this matters: the license clause handles the engineer’s own background IP. It does not handle the case where the engineer drops in a snippet from a forum, or a library written by someone they once worked with, or a code fragment they copied from a public repository without checking the license. The representation gives the company a contractual claim against the engineer if the engineer brings in third-party material without authority, and it gives the company’s diligence counsel something to point to when the acquirer asks how the company manages the risk that contributors are dropping in third-party code.
This is also the natural home for the open-source compliance representation. The clause typically states that the engineer will comply with the company’s open-source policy (which the company should have, in writing), will not incorporate any open-source code under a license that would impose obligations the company has not approved, and will disclose any open-source components they introduce. The point is not to ban open-source — virtually every modern stack depends on it — but to make sure the policy decisions about which licenses are acceptable get made by the company centrally, not by individual engineers commit-by-commit.
The open-source contamination problem
The acute version of the third-party IP risk is open-source contamination, particularly involving the General Public License family of copyleft licenses. The GPL and its variants impose, as a condition of use, that derivative works distributed publicly must themselves be released under a compatible open-source license. A startup that has built a proprietary product on top of code containing GPL-licensed components without realizing it has a problem: depending on how the code is integrated, the obligations of the GPL may attach to the product itself, exposing the proprietary code to disclosure obligations the company never intended to assume.
This is where the engineer-level discipline meets the company-level policy. The background IP license clause and the third-party rep are how the company gets contractual visibility into what the engineer is bringing in. A written open-source policy — naming the licenses that are pre-approved (permissive licenses like MIT, BSD, Apache), the ones that require legal review (weak copyleft like LGPL, file-level copyleft like MPL), and the ones that require board-level sign-off or are prohibited outright (strong copyleft like GPL or AGPL for products the company distributes) — is the structural complement to the contractual representation. The acquirer’s diligence counsel will ask whether the company has such a policy and whether engineers are bound to follow it. The PIIA’s representation is part of the “bound to follow it” answer.
What the clause looks like in plain English
Stepping back from the operative language and walking through what a clean background-IP license clause actually does, in prose:
First, it identifies the trigger. If the engineer incorporates into any company product, service, code, work product, or deliverable any IP that the engineer owns or controls and that is not otherwise assigned to the company as a Company Invention, the rest of the clause applies. The trigger is the act of incorporation. Nothing happens just because the engineer owns a library — only if they reach in and use it inside the company’s work.
Second, it grants the license. The grant is to the company, of a nonexclusive, perpetual, irrevocable, worldwide, fully paid-up, royalty-free, sublicensable (through multiple tiers), and transferable license under all of the engineer’s IP rights in the incorporated material.
Third, it enumerates the rights. The licensed rights include the rights to use, reproduce, modify, prepare derivative works of, distribute, publicly display, publicly perform, and digitally transmit the licensed material, and to authorize others to do any of the foregoing.
Fourth, it makes the representations. The engineer represents that they have full power and authority to grant the license, that the licensed material does not infringe any third-party rights, and that they will not incorporate any third-party material into the company’s work without ensuring the company has the rights it needs.
Fifth, it ties into survival. The license, like the assignment and the confidentiality obligations, survives termination of the engagement — meaning the company keeps the right to use what was incorporated even after the engineer is no longer there. This is precisely the survival point flagged in the parent post: every time a substantive provision is added, the survival clause needs to be updated to name it.
The diligence test in plain terms
The way to evaluate whether the clause is doing its job is to imagine the diligence call. Acquirer’s IP counsel will ask, in some form: tell me how the company knows that all the code in its product is either owned by the company, licensed under terms acceptable to the buyer, or subject to a clean open-source license. The answer the company wants to be able to give is structural rather than anecdotal. It is: every contributor signed a PIIA that includes a present assignment of all inventions created within scope, a background-IP license covering any of the contributor’s pre-existing IP that ends up in our product, and a representation about third-party and open-source materials. The company has a written open-source policy. The company maintains a software bill of materials and conducts periodic open-source scans. Here are the documents.
If the company can give that answer, the gap is not an issue. If the company has only the assignment, the diligence path runs through individual engineer interviews and code archaeology to figure out where each piece of background IP came from. The cost difference between those two outcomes is the value of the background-IP license clause.
Where this fits in the broader hiring stack
The background-IP license clause lives in the same document family as the assignment, the confidentiality obligations, and the post-engagement restrictions. The PIIA is generally the right home, but the clause should be cross-referenced from the offer letter and the service agreement so that the offer’s IP provisions and the PIIA’s IP provisions read as a coherent system rather than two separate negotiations. The pattern is the same one the parent post recommends across the equity and IP machinery: name the concept once, define it precisely, and let downstream references attach cleanly.
For founders building the standard hire stack, the move is to confirm the company’s PIIA template contains the license clause, the rights enumeration, the companion representation, and the open-source provisions, and to have outside counsel pressure-test the language against the company’s actual product architecture rather than against a generic form. For an engineer signing a PIIA, the move is to fill out the prior-inventions schedule with real specificity, understand that the license clause is granting the company rights to anything you reach in and use, and decide consciously whether you are comfortable importing your personal library into the codebase under that bargain — or whether you would rather keep the library out and rewrite the function from scratch on company time.
For both sides, the underlying point is the same: the assignment is necessary but not sufficient. The license is what makes the IP allocation actually durable across the years between hire and exit. It is one of the highest-leverage drafting decisions in the entire hiring stack, and it lives in a paragraph almost no one negotiates.
If you are building or reviewing a PIIA template for a company about to start hiring engineers, or evaluating one you have been asked to sign, feel free to reach out to my firm manager, Magda, at Magda@montague.law, or fill out our contact form. Mention you read this post.
— John
