Software companies
Separating shared code when you sell a software product line
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
To carve out a shared codebase when selling a product line, inventory every module the product depends on, classify each as sole-use, shared, platform, third-party or customer-specific, then assign sole-use code to the buyer and give whichever side does not own a shared module a license to it. Decide the commit history and engineering records at the same time.
Key takeaways
- Shared code cannot sit with two owners at once; one side owns it and the other gets a license.
- Classify modules by who depends on them after closing, not by which team wrote them.
- Code written by contractors may need a signed assignment before the seller can transfer it.
- Decide early whether the buyer receives full commit history, filtered history or a fresh snapshot.
- Engineering records such as reviews and issues need an owner in the purchase agreement, just like the code.
Why shared code is the hard part of a product line sale#
Shared code is the hard part of a product line sale because the buyer needs it to run the product and the seller needs it to run everything else. Authentication libraries, billing connectors, PDF report engines, sync clients, design systems and Terraform modules are typical examples, and in a monorepo they are often imported by several products at once.
Sole-use code is comparatively easy: it moves with the product. The work is in the modules both sides will keep using, and in the build tooling, pipelines and signing keys that hold the product together. A CTO who maps these early gives the deal team something concrete to negotiate instead of a late surprise in confirmatory diligence.
Step 1: inventory what the product line actually uses#
The inventory starts from what the product line actually loads and calls at runtime, not from the org chart. Team ownership drifts over years, so a module labeled as belonging to the core platform team may in practice exist only for the product being sold.
Generate the first draft from tooling, then have the engineers who know the product correct it. Record each dependency with its path, owning team, recent committers, license and the products that import it.
- Build manifests and lockfiles, such as package.json, pom.xml or go.mod, for direct and transitive dependencies.
- Import graphs inside the monorepo to find internal packages the product pulls in.
- Runtime calls to shared services, databases, queues and feature-flag systems.
- CI/CD pipelines, container base images, infrastructure-as-code modules and deployment scripts.
- Third-party and open-source components, with their licenses and any notices you must carry.
- Customer-specific branches, forks and configuration that exist for named customers.
- Secrets, certificates and code-signing keys the product needs to build, ship and run.
Step 2: classify each module before anyone negotiates#
Each module falls into one of a few classes, and the class largely decides its treatment in the deal. Agree the classification internally first, because a disputed module is far easier to settle before the buyer's counsel sees a schedule.
| Module class | Example | Usual treatment | Watch for |
|---|---|---|---|
| Sole-use | The product's scheduling engine | Assigned to the buyer | Hidden imports from other products |
| Shared, mostly serves the sold product | A report engine built for it, reused elsewhere | Assigned to the buyer, licensed back to the seller | Scope and duration of the license-back |
| Shared, mostly serves retained products | Single sign-on and billing libraries | Kept by the seller, licensed to the buyer | Whether the buyer may modify and sublicense |
| Platform service | Hosted notification or search service | Transition services, then replaced | A replacement plan with clear milestones |
| Third-party or open source | Frameworks, UI kits, parsers | Not assigned; each party complies with the license | Copyleft obligations and commercial license transfer limits |
| Customer-specific | Custom integrations for one account | Follows the customer contract | Customer ownership or consent rights |
Who owns the code you are about to assign?#
The seller can only assign code it owns, so ownership is checked module by module before the schedule is final. Section 201(b) of the Copyright Act, 17 U.S.C. 201(b), treats the employer as author and owner of a work made for hire unless a signed written agreement says otherwise, which generally may cover code employees wrote as part of their jobs.
Contractors are different. According to Copyright Office Circular 30, commissioned work becomes a work made for hire only when it fits one of the categories listed in the statute and the parties signed an express written agreement, so code from freelancers and agencies usually needs a written assignment. Pull every contractor and agency agreement that touched the sold modules and have counsel confirm the assignment language.
Step 3: decide what to assign and what to license#
The assign-or-license decision follows a simple rule: the party that will maintain and evolve a shared module should own it, and the other party gets a license. When the answer is unclear, look at where future changes will come from rather than where past commits came from.
Expect each side to fork the shared module after closing. Neither party is required to share later fixes unless the agreement says so, which matters for security patches in a common library. Some sellers agree to share security fixes for a defined period; others prefer a clean break.
The license terms deserve their own negotiation, covering field of use, exclusivity, sublicensing, change of control and whether either side may use the code to train or evaluate AI models. Silence on AI use invites a later dispute.
Step 4: split the repository and its history#
The repository split is where code and records separate, and the main decision is how much history the buyer receives. Full history helps the buyer understand why the code looks the way it does, but commit messages and review comments often mention retained products, customers and internal plans.
Most teams choose one of three routes: full history for the sold paths, history filtered to remove references to retained products, or a fresh snapshot with history kept by the seller and made available on request. History-filtering tools can extract the sold paths into a new repository, and secret scanning should run on the result before it leaves your organization.
Do the same for issue trackers and review tools. Jira projects, GitHub or GitLab pull requests, Confluence spaces and support tickets that concern the sold product need an owner after closing, and the purchase agreement should say whether the seller may keep a copy for legal, audit or other internal purposes.
Illustrative: splitting a monorepo for an inspection product#
Illustrative: a fictional software company sells work order software to commercial elevator contractors and is selling its inspection reporting product line. Both products live in one GitHub monorepo with a shared authentication package, a PDF report engine and an offline sync library.
The inventory shows the report engine was built for inspections and reused by work orders, so it is assigned to the buyer with a license back to the seller. Authentication and offline sync stay with the seller and are licensed to the buyer, with sublicensing allowed to the buyer's hosting providers. A contractor-built sync component turns out to lack a written assignment, and the seller obtains one before signing.
The buyer receives filtered history for the sold paths and the matching Jira projects. The seller keeps a read-only archive of the full repository and its pull request reviews, and the purchase agreement records that the seller may use its retained engineering records for internal purposes, subject to the buyer's confidentiality in the assigned code.
How SourceX treats engineering history after a carve-out#
SourceX treats engineering history after a carve-out as an ownership puzzle before anything else. Its Rights stage, part of the SourceX five-step transaction, reads the purchase agreement and any license-back to see which entity may license which repositories, reviews and issues, and whether code assigned to a buyer must be excluded.
If a package proceeds, the SourceX Evidence Packet records provenance, including which repository or archive the records came from and whether they predate the split, alongside licensing rights, permitted use, the privacy record and release authorization. The fit check itself asks only for descriptions, for example which repositories exist, how far back they go and which record types they hold.
Frequently asked questions
Does the buyer need the full commit history?
Not always. Full history helps with debugging and understanding past decisions, but it can expose retained products and customer names. Many deals deliver filtered history for the sold paths, with the seller agreeing to answer questions or provide specific history on request for a defined transition period.
Can either side assign open-source components?
No. Open-source code stays under its own license, and each party must comply with that license independently after closing. The schedule should list the components and their licenses so the buyer can confirm notices, attribution and any copyleft obligations in its own distribution.
Should shared libraries become a single upstream both sides use?
Rarely. A shared upstream needs governance, release coordination and a support commitment between two companies that are no longer aligned. Most carve-outs fork at closing and, where security matters, agree a limited period of security fix sharing instead.
Can the seller keep a copy of code it assigned to the buyer?
Only if the agreement allows it. Sellers often keep an archival copy for legal, tax and audit purposes, with confidentiality and use restrictions. Any wider use, such as development or licensing, needs a license back that names that use expressly.
What about code signing keys and package registry accounts?
Plan them like any other asset. Decide which keys transfer, which are rotated and which stay with the seller, and move package registry namespaces, app store listings and domain names under a documented handover checklist before the buyer's first release.
Sources
- 17 U.S.C. 201(b) provides that in the case of a work made for hire, the employer or other person for whom the work was prepared is considered the author and, unless the parties have expressly agreed otherwise in a written instrument signed by them, owns all of the rights comprised in the copyright. Source
- Copyright Office Circular 30 explains a work made for hire arises either when an employee creates the work as part of regular duties, or when a work in certain statutory categories is created under an express written agreement with a party specially ordering or commissioning it. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.