| name | software-license-checker |
| description | 评估软件在企业内部使用场景下的许可证、授权与潜在付费要求，输出偏保守的法务预警报告与采购整理。仅用于企业内部安装、运行、开发辅助、办公或内部平台使用，不覆盖 SaaS 对外服务、嵌入产品对外分发、OEM、转售或开源义务外部触发场景。用户提到“软件是否可以商用但仅限公司内部使用”“企业内部使用是否合法”“license 检查”“授权合规”“开源协议风险”“是否需要商业授权”“是否要付费”“年付月付怎么买”等，或提供软件名称、GitHub 链接、官网 URL、包名、本地路径并询问内部使用合规时，使用此 Skill。 |
| version | 1.0.0 |
软件内部使用授权合规预警 Skill
目标
面向 企业内部使用 场景，基于公开信息做一次 偏保守的法务预警，帮助用户快速识别：
- 是否明显可用于企业内部使用
- 是否存在需要法务重点复核的限制项
- 是否因为版本、条款或信息不足而无法安全下结论
仅输出合规预警，不输出法律定性意见。
若项目存在商业授权、企业版、订阅计划、试用期、席位限制、按量计费或其他潜在付费要求，还要补充一份面向技术负责人和采购的“授权与付费整理”。
边界
仅处理以下场景：
- 公司内部安装和运行软件
- 内部研发、测试、办公、数据处理、运维辅助
- 内部系统或内部工具使用，但 不对外提供服务
明确不覆盖以下场景；若用户问题实际属于这些场景，先说明超出本 Skill 边界，再请用户改用更合适的分析方式：
- SaaS / 托管服务 / API 对外提供
- 将软件嵌入自家产品后对外分发
- OEM、转售、白标、商业再许可
- 因分发、联网服务或源码修改而触发的外部开源义务分析
默认按 中国团队采购视角 写结论，优先整理中国团队通常能直接看到的购买路径、币种和是否需要联系销售。
处理流程
1. 先收集稳定事实，再决定是否追问
优先基于用户给出的名称、链接、路径或包名识别项目，并先收集以下稳定事实：
- 官方项目名称
- 官方仓库或官网
- 可确认的许可证文本或官方许可说明
- 是否存在版本切换、双许可证或商业版
- 是否存在公开 pricing、sales、billing、plan 页面
仅在 缺口会直接影响内部使用结论 时再追问，优先问这些问题：
您说的是哪个项目？ 仅当同名项目不止一个时提问您计划使用哪个版本？ 仅当许可证存在版本差异时提问是否仅限公司内部使用，不会对外提供服务或分发？ 仅当用户描述含糊时提问是否需要修改源码，或只是直接安装使用？ 仅当许可证条款明显依赖修改行为时提问
不要为了形式完整而一次性追问所有问题。能先查明的先查明。
2. 按证据优先级调查
优先读取和引用官方来源。证据优先级与冲突处理规则见 references/source-priority.md。
付费方式、公开价格、折扣与未知项的整理规则见 references/pricing-evidence.md。
至少覆盖以下核查项：
- 当前版本或目标版本的许可证类型
- 官方是否明确允许企业内部使用
- 是否存在商业版 / 企业版 / 双许可证
- 是否发生过许可证变更，且是否影响用户目标版本
- 是否存在附加限制条款、例外条款或单独商业授权要求
- 是否存在公开可见的付费路径，例如月付、年付、按量、按席位、按设备、一次性授权、企业询价
- 是否存在公开折扣，例如年付优惠、教育/非营利折扣、限时活动
- 对于“联系销售”但未公开报价的情况，是否能明确整理为未知项而非猜测价格
常见许可证与内部使用风险判断框架见 references/internal-use-risk-rubric.md。
3. 用保守口径给出预警结论
结论使用以下三级：
低风险：当前证据显示，目标版本在企业内部使用下通常可行，未发现明显附加限制高风险：存在明确限制、商业授权要求、条款冲突，或官方信息显示内部商用需额外授权信息不足：版本不明、来源冲突、条款模糊，或仅能找到低可信度信息，无法保守地下安全结论
这不是法律意见。若证据不足，不要勉强下 低风险。
4. 何时必须整理“授权与付费”
只要出现以下任一情况，就必须在主报告之外补充“授权与付费整理”：
- 官方明确要求购买商业授权
- 存在企业版、商业版、Pro/Team/Business/Enterprise 计划
- 存在月付、年付、按量、按席位、按设备、按实例等公开计费方式
- 存在试用期、免费层限制、商用限制或超量收费
- 存在公开折扣信息，例如年付优惠、教育/非营利折扣、限时促销
- 明确写了“联系销售”“custom quote”“enterprise pricing”，即使价格未公开
如果完全未发现额外付费要求，也要用一句话明确写“当前未发现公开的额外付费要求”，不要留空。
输出要求
输出 Markdown，采用“双产物”结构：
主报告：继续输出企业内部使用授权合规预警授权与付费整理：单独附录，面向技术负责人和采购，整理公开付费方式、折扣和未知项
主报告结构如下：
# 软件内部使用授权合规预警报告
## 基本信息
- **软件名称**：
- **目标版本**：如未知，明确写“未知”
- **官方仓库 / 官网**：
- **使用范围**：企业内部使用
- **报告生成时间**：YYYY-MM-DD
## 预警结论
> **低风险 / 高风险 / 信息不足**
一句话说明结论，并明确是“企业内部使用”前提下的判断。
## 大白话简明结论
用 3-5 条短句，直接回答普通业务/采购/老板最关心的问题：
- `能不能用`：先说能不能在公司内部用，避免兜圈子
- `前提是什么`：例如是否必须购买商业授权、是否仅限试用期、是否必须锁定某个版本
- `主要风险`：只写最关键的 1-3 个风险点，例如“长期未授权使用风险高”“版本升级后许可证变化”“实际场景超出内部使用边界”
写法要求：
- 必须用大白话，少用法律术语
- 每条尽量控制在 1 句话内
- 不要把 `信息不足` 写成“应该没问题”
- 如果结论是 `高风险`，第一条就直接写清“不能默认免费商用”或“需要先买授权”这类结论
- 如果结论是 `低风险`，也要顺手补一句“前提是仅限企业内部使用/不对外分发”
## 核心依据
### 依据 1：许可证文本或官方许可页
- **证据级别**：官方许可证文本 / 官方许可说明 / 官方 FAQ
- **适用版本**：
- **对结论的影响**：支持低风险 / 支持高风险 / 导致信息不足
- **说明**：
- **来源**：
- **内容时间**：若未知，明确写“未知”
### 依据 2：商业授权或附加限制
- **证据级别**：
- **适用版本**：
- **对结论的影响**：
- **说明**：
- **来源**：
- **内容时间**：
### 依据 3：版本变更或双许可证情况（如有）
- **证据级别**：
- **适用版本**：
- **对结论的影响**：
- **说明**：
- **来源**：
- **内容时间**：
## 风险提示
列出 1-3 条保守建议，例如：
- 建议锁定当前低风险版本，避免升级到许可证已变更版本
- 建议采购前让法务复核商业授权条款
- 建议保留许可证文本、官网截图和采购记录
## 免责声明
本报告基于公开信息与许可证文本做内部合规预警，不构成正式法律意见；如涉及采购、替换成本高或长期关键依赖，建议由法务或知识产权律师复核。
如果触发了付费整理，再追加以下附录：
# 授权与付费整理
## 付费摘要
- **是否需要商业授权**：
- **是否存在公开价格**：有 / 无 / 部分公开
- **默认采购视角**：中国团队采购
- **主要购买路径**：例如官网月付、官网年付、按量计费、联系销售
## 公开付费方式
| 方案 | 计费方式 | 公开价格 | 币种/地区口径 | 适用对象 | 来源 | 内容时间 |
| --- | --- | --- | --- | --- | --- | --- |
| Free / Community | 免费 / 试用 / 限制版 | | | | | |
| Pro / Team / Business | 月付 / 年付 / 按席位 | | | | | |
| Usage-based | 按量 / 按调用 / 按资源 | | | | | |
| Enterprise | 联系销售 / 自定义报价 | 未公开 | | | | |
## 公开折扣与优惠
- **年付优惠**：
- **公开折扣**：例如教育、非营利、初创、限时活动；没有就写“未发现”
- **说明**：
- **来源**：
- **内容时间**：
## 未公开价格与待补信息
- `未公开项`：例如“Enterprise 需联系销售，官网未公开报价”
- `为什么不能直接估价`：例如“仅有 sales 入口，没有官方价格页”
- `建议补采信息`：例如席位数、部署规模、是否需要发票、采购地区、是否要长期锁版本
## 给技术负责人/采购的大白话建议
- 先直接说“是否必须买”
- 再说“如果先试，小团队更适合哪种公开方案”
- 再说“哪些价格还没公开，采购前必须补齐”
- 不要写私下谈判技巧，不要编造企业报价
自查清单
