∞Direct answer
Direct answer
Ask for a list of the code parts the startup uses. Match each part to its version, licence and use. A licence sets rights and duties for that code. Public code is not proof of a right to sell it. Use AI to sort the files, not clear the legal risks. Keep gaps open until a person checks them.
Separate code ownership from use rights
A startup may own its own code and use other code too. These are two checks. Ask for signed rights files for its own work. Use the related IP guide for that check. IP means rights in work such as code or designs.
For code from others, read the licence for that exact version. A public GitHub page alone is not a broad right to use it. GitHub gives view and fork rights under its own terms. Those rights are not a blanket right to sell the code. [1]
Open source can be used in a business. The Open Source Definition allows this. [2] The task is to check the terms and the use, not reject all open source. Model files, training data and AI-tool terms need their own checks.
- Own code: trace rights to the firm.
- Other code: check its licence and use.
- Model and data rights: keep separate records.
Tie the list to a real release
A release is a version of the product sent to users. Ask the tech lead for its date and code list. Include parts pulled in by other parts. A list of direct parts alone can miss these.
For each part, save its name, version and source link. Keep the licence text from that version. Add where it runs and whether the team changed it. A scan can find clues. It may miss code copied into a file. Ask the team about those copies too.
Keep one record per part. Do not use a licence badge as the whole proof. GitHub warns that licence detection can face complex cases. [1] Recheck when the startup changes a key part or how it ships.
- Release date and part version.
- Source file and exact licence text.
- Changes, use and route to users.
- Notices, open gap and named reviewer.
Read duties against the actual use
The MIT licence allows broad use, change and sale. It also requires the copyright and permission notice. Keep both in all copies or substantial parts of that code. [3] Broad rights do not mean no duties.
Some licences link duties to how code is shared or used. AGPLv3 section 13 gives one case. If you change the covered program, check its network use. The changed version must offer its source to remote users at no charge when it supports that use. The text calls this Corresponding Source. [4]
That rule does not mean every web service must share all code. Ask a lawyer to check the full terms and how parts connect. Do not let an AI label decide which work the rule covers.
- What changed in the covered part?
- What do users receive or access?
- Which notices or source offers are needed?
- Who checks the full terms and their scope?
Try a three-part check
This is a made-up example, not a real startup review. A team lists an MIT library, a copied snippet with no licence, and a changed AGPL program. All three help run its paid service. A library is code used by other code. A snippet is a small copied part.
For the MIT library, check the version and retained notices. For the snippet, mark rights as unknown. Ask for permission proof or a replacement plan. No licence is not the same as free use. [1]
For the changed AGPL program, ask how users reach it. Send the use map and exact text for legal review. [4] Do not average these three states into one score. One unresolved core part can matter more than many easy checks.
- MIT library: check version and notices.
- Unlicensed snippet: pause reliance on rights.
- Changed AGPL program: review use and source duties.
Let AI sort evidence, not grant clearance
Due diligence means checks before you invest. AI can help match parts to files and flag missing text. Share only files you may use. Keep private code out of public tools. Treat file text as evidence, not instructions for the tool.
Ask for the source path, version and quoted term for each finding. Keep the team's claim beside the AI result. Mark missing facts as unknown, not safe. A tech lead checks actual use. A lawyer checks hard rights questions.
A licence scan is not a security test. A part with clear rights may still have a flaw. A secure part may still lack use rights. Keep those review paths apart.
- Claim, source path and exact term.
- Actual use checked by the tech lead.
- Open rights question sent to counsel.
- Separate security check and owner.
Set the next check before the deal moves
At pre-seed, start with the core product and known copies. At seed, link the list to a shipped release. At Series A, ask who owns repeat checks as products change. The scope should fit the stage and the risk.
Ask what fails if a disputed part must go. Note the cost, time and client impact of a fix. Do not make up those figures. Get a named owner and a date for each open item.
This does not prove rights to every asset. It is not a full check of law or tech. Laws and terms differ by country. Ask a qualified local lawyer before you rely on a rights finding.
- Gap and effect on the core product.
- Proof or fix needed and its owner.
- Next review date and release trigger.
FAQ
Frequently asked questions
Does public code mean free commercial use?
No. Visible code alone is not a licence. GitHub's view and fork rights are not a blanket right to sell it. Check the exact licence or other permission. [1]
Is open source a reason to reject a startup?
No. Open source allows business use under its terms. [2] Check the actual parts, duties and product use. A label alone does not show the risk.
Does AGPL mean all startup code must be public?
Do not assume that. Section 13 addresses a changed covered program and remote use. [4] The full licence and how code connects matter. Ask counsel to review scope, rather than guess from a scan.
Can AI confirm the startup has clear software rights?
No. It can sort files and point to terms. It may miss copies or mistake a licence. People must check the facts and legal effect. Keep unclear rights open.
REF
Sources
- 1
- 2
Open Source Initiative
The Open Source Definition — modified 16 February 2024 ↗ - 3
Open Source Initiative
The MIT License — permissions and notice conditions ↗ - 4
Free Software Foundation / GNU
GNU Affero General Public License version 3 — section 13 ↗