Source Code Licensing: What Buyers Need to Know
I wouldn’t buy source code without checking two things: what I can do with it and whether the seller can grant those rights. Access to code is not IP ownership, and white-label vs SaaS licensing permissions do not automatically allow sublicensing.
Before signing, I’d check five areas:
- Use rights: Can I modify, host, integrate, resell, and transfer the software?
- Seller’s authority: Do signed assignments and prior agreements support the rights being offered?
- Third-party terms: Are all dependencies listed, and can I meet their license duties?
- Delivery: Can I build and deploy the code, with written acceptance tests and defect remedies?
- Costs and exit: Are fees, support, updates, and rights after termination clear?
My rule: <u>get the rights and delivery promises in writing</u>. Then mark each area proceed, negotiate, or pause - and resolve missing documents or conflicting terms before paying.
Source Code Licensing: 5 Buyer Checks
Checklist: Confirm Your Commercial Use Rights
Can You Modify, Integrate, and Deploy the Code?
Request the granting clause and check that it expressly permits code changes, commercial hosting, rebranding, and integration with third-party stacks. The grant should cover every use you plan. [3][1]
Read the restrictions just as closely. Look for limits on territory, vertical, or sales channel. For each permission you need, record the granting clause, any limits, and a Proceed, Negotiate, or Pause status. [4]
Can You Resell, Sublicense, or Transfer the Software?
Check distribution rights separately for selling a finished service, white-labeling, and OEM embedding. Permission to sell a finished service doesn't necessarily allow code reuse. If you're embedding the code in a larger product, confirm that the grant covers that OEM distribution model.
Review assignment and change-of-control clauses before a sale or merger. Check whether seller consent is required, and negotiate transfer rights before an acquisition makes them urgent.
Define exclusivity by territory, vertical, or channel. Also check whether you must meet minimum revenue commitments to keep those rights active.
What Is the Difference Between Access, Licensing, and Ownership?
Use the table to check what the deal allows - not just what it's called. For an ownership assignment, verify exactly which intellectual property (IP) transfers.
| Deal type | Control | Modification | Redistribution | Sublicensing | Can the licensor license the same code to others? |
|---|---|---|---|---|---|
| Code access only | View/audit only | Not granted by access alone | Not granted by access alone | Not granted by access alone | Yes |
| Non-exclusive license | Use within the agreed scope | Agreement-dependent | Agreement-dependent | Agreement-dependent | Yes |
| Exclusive license | Exclusive rights within a defined scope | Agreement-dependent | Agreement-dependent | Agreement-dependent | No, within the exclusive scope |
| Ownership assignment | Buyer owns the specified IP | Full rights | Broad rights, subject to excluded third-party terms | Yes | No |
Once the grant matches your planned use, check that the seller has the right to grant it.
sbb-itb-8650f75
Open Source Licensing: Types, Strategies and Compliance - Jeff Luszcz
Checklist: Verify the Seller’s Right to License the Code
Once you’ve confirmed the rights you need, check that the seller can grant them.
Can the Seller Document the IP Ownership Chain?
Ask for an IP schedule that lists each code component, its owner, the rights included, and the documents showing the seller can license it. This should include signed assignments from founders, employees, and contractors.
For any included code the seller licenses but doesn’t own, request the agreement that allows it to grant the rights you plan to use. Sublicensing rights must be stated explicitly. If the code received federal funding, check whether government rights limit exclusivity or sublicensing under 2 CFR § 200.315. [2]
Next, check for earlier grants that could block the rights you need.
Are Prior Licenses and IP Claims Addressed?
Ask the seller to disclose prior exclusive licenses, liens, security interests, and pending IP claims. Compare those disclosures with the rights you’re buying. An earlier exclusive grant in your territory or industry can prevent the seller from granting you the same rights. [2]
Pause before signing if assignments are missing, the seller’s licensing authority is unclear, or prior grants conflict with your planned deployment, resale, or sublicensing. Require supporting documents and a written cure before you sign.
Checklist: Check Third-Party and Open-Source Terms
Once you confirm the seller can license the code, review every bundled component and its license.
Bundled open-source and third-party components have their own obligations. Open-source software generally allows commercial use. But modifying it, distributing it, or providing network access may trigger extra duties.
Are All Included Components Listed?
Ask for a current software bill of materials (SBOM) that covers direct and transitive dependencies, libraries, frameworks, AI models, datasets, and bundled assets. Package names aren't enough. Require exact versions, copyright holders, license texts, and applicable restrictions. Identify which terms are permissive, copyleft, commercial, or proprietary, and record their restrictions and obligations.
For models and datasets, request provenance records that show lawful collection and permission for your intended use and sublicensing. Review external API and workflow dependencies as well. Before buying, check the dependency tree for vulnerabilities and components that are no longer maintained.
Does Your Delivery Model Comply With Each License?
Review how you'll use and deliver the software: hosting it, distributing binaries or source code, modifying components, or combining them with proprietary code. The duties depend on each license and how you host, distribute, or combine the software. AGPL can require you to make source code available for network use [2].
Use this review matrix with the seller’s component-level inventory. Each actual component needs its own entry.
| Component | Version | Copyright holder | License | Modification rights | Redistribution conditions | Notices | Source disclosure duties | Buyer action |
|---|---|---|---|---|---|---|---|---|
| Permissive library | Exact release required | Record from notices | MIT / Apache 2.0 | Permitted | Preserve required materials | Retain applicable notices and license text | Generally none | Verify compliance materials |
| Copyleft component | Exact release required | Record from notices | GPL | Permitted under license terms | Covered distributed works must meet GPL terms | Retain required notices and license text | Corresponding source for covered distributed works | Check combinations and source delivery |
| Network-copyleft component | Exact release required | Record from notices | AGPL | Permitted under license terms | Meet applicable copyleft terms | Retain required notices and license text | Source may need to be offered to network users | Confirm hosted source-access duties |
| Proprietary asset | Exact release required | Identify rights holder | Seller-specific agreement | Agreement-specific | Check the rights granted in the agreement | As required by agreement | Agreement-specific | Confirm contract terms |
Require the seller to provide all notices, license texts, source packages, and compliance materials before purchase. Put the seller’s compliance obligations and required materials in writing. An inventory alone doesn't establish compliance.
Use the inventory to verify that the delivered code builds and deploys as promised.
Checklist: Test the Code and Confirm Delivery
After reviewing rights and component terms, check that the delivered package matches what you licensed. Track contract documents and code delivery separately. A repository alone does not prove you received the signed agreement, license schedule, IP representations, or component inventory. Record every required item and who verifies it.
Can You Build and Deploy the Delivered Code?
Request a repository export that includes the agreed history, branches, and build files. Check it against the licensed component inventory, and confirm that configuration templates and deployment scripts are included.
Test the build and deployment in a clean build environment, using only the supplied files and instructions. Identify missing dependencies and seller-controlled services that could prevent you from running the code independently.
Are Security Checks, Tests, and Documentation Sufficient?
Request vulnerability scans, dependency scans, secrets scan results, automated test results, and disclosures of known defects. Review the installation, administration, API, and troubleshooting documentation.
Are Acceptance Criteria and Defect Remedies Clear?
Put delivery requirements, acceptance tests for the exact delivered version, and defect remedies in the agreement. Specify the review deadline, how to report defects, correction deadlines, and your right to reject delivery if failures remain unresolved.
Confirm that the delivered version includes the features and code covered by the license. If you use escrow protection, specify the evidence needed to release payment. Escrow does not give you the right to reject delivery.
Set a defined initial support window for installation and deployment issues. Carry those dates and remedies into the long-term support and termination review.
Checklist: Review Long-Term Costs and Exit Terms
Are Support, Updates, Fees, and Continuity Terms Clear?
Once delivery is accepted, confirm the cost of keeping the software running - and what happens if the seller exits. Record all one-time fees, annual fees, and renewal increases in USD.
Define annual maintenance and what it covers, including security patches, technical support, and updates. Check whether updates need a separate agreement, even with a perpetual license. Keep customer support separate from the seller’s duties for platform uptime and bug fixes. Require a 2–5-year pricing cap or renewal schedule, and confirm who controls future updates and the release plan. [1][3][4]
Require notice, data export, and a continuity plan if the seller stops supporting the software. [1]
What Rights Remain After Breach or Termination?
If the seller shuts down or breaches the agreement, check what triggers termination, what written notice is required, and how long the seller has to fix the breach.
State whether existing deployments and customer sublicenses survive termination. Confirm your rights to keep accessing, maintaining, and supporting the code. A perpetual license lasts for the life of the copyright; term or subscription rights end when the term ends. [2]
Conclusion: Proceed, Negotiate, or Pause
Decide whether to proceed, negotiate, or pause. Record the decision, supporting evidence, unresolved terms, and who owns each follow-up. If a material issue remains unresolved, get legal or technical review before committing.
FAQs
Who is liable if the code infringes someone’s IP?
Liability for intellectual property infringement depends on your licensing agreement. A license does not transfer ownership of the underlying IP. Your contract should clearly address indemnification - protection against infringement liability.
Have legal counsel review the final agreement to define those protections. Marketplace platforms do not verify sellers’ claims or give legal advice about potential infringement risks.
Can I keep my modifications after termination?
Your rights depend on the terms of your agreement. In most standard licensing or hosted SaaS deals, you don’t own the underlying intellectual property. When the agreement ends, you typically must return or destroy all copies of the product and its documentation.
If you negotiated full source code ownership - a less common arrangement - you may be able to keep your modifications. Clarify who owns derivative works and custom extensions before you sign.
What happens to my license if the seller goes bankrupt?
If the seller goes bankrupt or shuts down, your license may be at risk unless you’ve negotiated protections to keep using the software [1]. Get a source code escrow agreement: a neutral third party holds the code and releases it when agreed-upon events occur, such as seller insolvency [1][2].
Also negotiate advance notice before the software is discontinued and guarantees that you can transfer your data. Without these safeguards, you could lose access to both the software and customer data [1][3].