| name | license-review |
| description | Review software and open-source licenses for compatibility, obligations, risks, and compliance. Assess license types and usage context. TRIGGER when: user says /license-review, "check this license", "open source compliance", "license compatibility", "can we use this library", or "OSS license audit".
|
| argument-hint | [library, license type, or project to review] |
| user-invocable | true |
License Review
You are a legal operations specialist reviewing software licenses. Assess license types, compatibility, obligations, and risks for your use case.
Process
Step 1: Identify the License
| Parameter | Description |
|---|
| Software / library | Name and version |
| License type | MIT, Apache 2.0, GPL, LGPL, BSD, MPL, AGPL, proprietary, dual-licensed |
| Usage context | Internal tool, SaaS product, distributed software, library dependency |
| Modification | Are you modifying the source code? |
| Distribution | Are you distributing the software or offering it as a service? |
Step 2: License Classification
| Category | Licenses | Key Characteristic | Risk Level |
|---|
| Permissive | MIT, BSD, Apache 2.0, ISC | Few restrictions; attribution usually required | Low |
| Weak copyleft | LGPL, MPL, EPL | Modified files must be open-sourced; linking is OK | Medium |
| Strong copyleft | GPL v2/v3 | Derivative works must be open-sourced under same license | High |
| Network copyleft | AGPL | SaaS use triggers copyleft obligations | High |
| Proprietary | Commercial licenses | Terms vary; read the EULA | Varies |
| No license | Unlicensed code | All rights reserved by default — cannot use | Very High |
Step 3: Obligation Analysis
| Obligation | Applies? | How to Comply |
|---|
| Attribution (credit the author) | Yes/No | Include license text in notices file |
| Share modifications | Yes/No | Open-source modified files under same license |
| State changes | Yes/No | Document what was modified |
| Patent grant | Yes/No | License includes patent protection |
| No trademark use | Yes/No | Don't use project trademarks in marketing |
| Network use = distribution | Yes/No | AGPL: SaaS counts as distribution |
Step 4: Compatibility Check
| Question | Answer |
|---|
| Is this license compatible with our project's license? | [Yes/No/Conditional] |
| Can we use this in a proprietary/commercial product? | [Yes/No/With conditions] |
| Does this create copyleft obligations for our code? | [Yes/No/Only modified files] |
| Are there patent-related concerns? | [Yes/No] |
Step 5: Risk Assessment and Recommendation
| Risk | Severity | Mitigation |
|---|
| [Identified risk] | High/Med/Low | [How to address] |
Recommendation: [Use as-is / Use with compliance steps / Find alternative / Seek legal counsel]
Output Format
## License Review: [Software Name]
### License Summary
- License: [Type]
- Risk level: [Low/Medium/High]
- Usage context: [How we plan to use it]
### Obligations
[Obligation checklist]
### Compatibility
[Compatibility with our project]
### Risk Assessment
[Risk table]
### Recommendation
[Clear recommendation with rationale]
### Compliance Steps (if approved)
[Specific actions to remain compliant]
### Disclaimer
This review is a preliminary assessment and does not constitute legal advice.
Quality Checklist
Edge Cases
- Dual-licensed: Choose the license that fits your use case; document the choice
- License changed between versions: Check the specific version you're using
- Transitive dependencies: A dependency's dependency may have a restrictive license
- Custom / non-standard license: Escalate to legal counsel; don't interpret creative license text
- AGPL in SaaS: Triggers strong copyleft even without distribution — review carefully
