OSS License Checker
Paste a dependency list (package.json, requirements.txt, etc.) or describe your software stack and deployment model. Receive a compliance memo classifying each license, mapping obligations to your deployment, and flagging critical issues. Adapted from Anthropic's claude-for-legal IP skill.
Drag & drop a file here, or click to browse
Your content stays private. What you paste or upload is sent directly to Claude (Anthropic's AI) to generate the analysis — it is never stored on our servers, logged to a database, or seen by our team. Anthropic processes it under their Privacy Policy. Treat this like any Claude.ai session: confidential documents are safe to use, but for highly sensitive matters we always recommend consulting your firm's AI use policy.
Not legal advice. This tool is for informational and research purposes only. AI outputs must be reviewed by a licensed attorney before any reliance. Do not input confidential client information. Outputs are generated by Claude and may contain errors.
What Is the OSS License Checker?
Open source software powers virtually every modern application — but using open source without understanding the license obligations can create serious legal exposure. Copyleft licenses like the GPL can require you to open-source your own proprietary code. Other licenses have attribution, patent, or compatibility requirements. The OSS License Checker analyzes your dependency list and maps the obligations to your specific deployment model.
Paste your package.json, requirements.txt, go.mod, Gemfile, or any dependency manifest, and describe how you deploy your software (SaaS, distributed binary, internal use, embedded in hardware). The tool classifies each license (permissive, weak copyleft, strong copyleft, proprietary-compatible), identifies the specific obligations triggered by your deployment model, and flags critical compatibility or compliance issues.
The analysis covers the most common open source licenses: MIT, Apache 2.0, BSD variants, LGPL, GPL v2 and v3, AGPL, MPL 2.0, CDDL, and others. It explains what each license requires — attribution notices, source disclosure, license compatibility restrictions — and whether those obligations apply to your use case.
This tool provides an educational overview of open source license obligations and is not a substitute for legal advice from an IP attorney. OSS license compliance is highly fact-specific, and complex dependency chains should be reviewed by qualified counsel. Do not paste proprietary dependency information or internal architecture details.
Example Output
How to Use This Tool
- 1Paste your dependency manifest (package.json, requirements.txt, go.mod, etc.) into the input box
- 2Add a brief description of your deployment model: SaaS (server-side only), distributed binary (users download and install), internal use only, or embedded in hardware
- 3Click 'Generate OSS Compliance Memo' and allow 25–40 seconds
- 4Review the license classification for each dependency, the obligations triggered by your deployment model, and any critical flags — then consult an IP attorney for complex situations
Who This Tool Is For
- ✓Software engineers conducting a preliminary OSS compliance audit before a product launch
- ✓Startup legal teams assessing license obligations before a fundraising due diligence process
- ✓In-house counsel triaging open source use in a newly acquired company's codebase
- ✓CTO and engineering leads evaluating whether a dependency's license is compatible with a commercial product
- ✓Legal operations teams building repeatable OSS review workflows
- ✓M&A attorneys doing preliminary IP due diligence on a target company's software stack
Frequently Asked Questions
What licenses does this tool cover?
The tool covers the major open source licenses: MIT, Apache 2.0, BSD 2-Clause and 3-Clause, ISC, MPL 2.0, LGPL v2 and v3, GPL v2 and v3, AGPL v3, CDDL, EPL, and common proprietary licenses. It also handles dual-licensed packages where relevant.
Why does the deployment model matter for license obligations?
Copyleft obligations are often triggered by distribution, not by use. A GPL-licensed library used only internally may impose no distribution obligations. The same library, if included in a binary distributed to customers, may require you to release your source code. The deployment model is the key variable.
Does the AGPL really require open-sourcing a SaaS application?
Under the AGPL v3, providing access to software over a network counts as distribution, triggering copyleft obligations. This means SaaS applications using AGPL-licensed code may need to release their own source code. This is a significant and contested area of OSS license law — consult an IP attorney if AGPL dependencies appear in your stack.
Can I use this for M&A due diligence?
This tool provides a useful preliminary overview, but M&A OSS due diligence requires a comprehensive audit of the full codebase (including transitive dependencies) and legal review of any non-standard licenses. Use this as a first-pass triage tool, not as a definitive due diligence report.