直接答案：Apache License 2.0（SPDX 标识 Apache-2.0）是一种经 OSI 批准的宽松开源许可证。它通常允许个人或企业使用、复制、修改、再分发和商业化代码，也不要求你公开自己独立编写或修改后的源代码；但再分发时必须履行许可证文本、版权、修改说明和可能存在的 NOTICE 归属要求。它还包含有边界的专利许可与专利诉讼终止条款，并不授予商标权，也不是“拿来随便用、什么都不用保留”。
重要边界：本文是面向开发者的许可证阅读指南，不是针对具体项目的法律意见。模型权重、数据集、代码、文档、商标和第三方依赖可能分别使用不同条款；商业发布前应以仓库中的实际文件和专业法律意见为准。
Apache 2.0 允许什么、要求什么
| 问题 | 一般结论 | 必须继续检查 |
|---|---|---|
| 可以商业使用吗 | 可以 | 第三方依赖、商标、专利与行业合规 |
| 修改后必须开源吗 | Apache 2.0 本身不要求 | 组合中的 GPL/AGPL 等其他许可证 |
| 可以闭源分发吗 | 一般可以 | 保留许可证、版权、修改与 NOTICE 要求 |
| 获得专利许可吗 | 对贡献者可许可且与贡献相关的必要专利权利有明确授权 | 范围并非贡献者的全部专利 |
| 可以使用项目名称和 Logo 吗 | 许可证不授予商标权 | 项目与 ASF 的商标政策 |
| 软件有质量保证吗 | 通常按“原样”提供且排除担保 | 你对客户作出的合同承诺 |
先判断行为：使用、修改与再分发不是同一件事
| 典型场景 | Apache 2.0 的核心关注 | 仍需核对 |
|---|---|---|
| 个人或公司内部运行 | 许可证本身通常不要求公开修改 | 是否向外包、关联方或客户实际交付；内部政策与合同 |
| 只提供服务器端 SaaS | 没有 AGPL 式专门网络开源条款 | 是否同时下发网页代码、SDK、客户端、模型或下载文件 |
| 分发未修改源代码 | 提供许可证副本并保留相关声明 | 上游 NOTICE 和第三方组件 |
| 分发修改后的源代码 | 除上述义务外，修改文件要有显著变更说明 | 衍生作品范围与新增文件的许可选择 |
| 分发二进制、容器或设备 | 仍属于需要准备许可证与归属材料的交付场景 | 第三方许可证入口是否对接收者可访问 |
| 仅调用托管 API | 通常适用服务条款而非取得服务端代码许可 | 输入输出权利、数据保留、品牌和使用政策 |
“分发”是否发生以及某个组合是否构成衍生作品，可能取决于事实和司法辖区。本文不替具体交易下结论。工程团队应先画出真实交付边界：哪些文件离开组织、由谁接收、通过什么介质、能否继续复制，再让法务将事实映射到许可证。
再分发时的四项核心义务
1. 附上 Apache 2.0 许可证文本
许可证第 4 条要求，向他人分发作品或衍生作品时，应向接收者提供许可证副本。ASF 的应用指南建议在发行包顶层放置名为 LICENSE 的文件并包含完整英文许可证文本。中文翻译可以帮助阅读，但 ASF FAQ 明确说明翻译不具有替代英文原文的法律效力。
2. 保留相关版权、专利、商标与归属声明
源代码形式再分发时，应保留与作品相关的版权、专利、商标和归属声明，但不包括与衍生作品任何部分无关的声明。不要把“宽松”理解为可以删除作者与许可证信息。
3. 对修改过的文件给出显著说明
如果你修改了上游文件，需要让修改过的文件带有显著说明，表明你更改了它们。实务中可在文件头、变更记录或补丁说明中记录，但具体形式应确保接收者能够识别变化，不应伪装成上游原始版本。
4. 正确处理 NOTICE
如果上游发行物包含 NOTICE，衍生作品的分发通常要在许可证规定的位置，以可读形式保留其中与产品相关的归属内容。NOTICE 不是用来添加新许可证限制的地方，也不意味着每个 Apache-2.0 项目都必然有 NOTICE。先检查上游包，而不是机械生成空文件。
| 第 4 条要求 | 工程证据 | 常见失败 |
|---|---|---|
| 提供许可证副本 | 发行包中的完整英文 LICENSE，安装器或产品内可访问入口 | 只放网页链接、摘要或非权威翻译 |
| 标明修改文件 | 文件内显著说明、补丁记录或能对应到文件的变更清单 | 只在 Git 历史中有记录，但交付包无法识别 |
| 保留相关声明 | 版权、专利、商标与归属清单 | 自动删除所有文件头或作者信息 |
| 处理上游 NOTICE | 保留与衍生作品相关内容并放在许可允许的位置 | 机械删除、机械新增限制或生成无意义空 NOTICE |
| 附加自己声明 | 与上游归属分开，并明确不改变许可证 | 把产品条款塞进 NOTICE 以限制上游许可 |
ASF 的源文件头与版权政策主要约束 ASF 自己的发行流程，并不自动成为所有第三方项目的额外条款；第三方应以许可证原文和自己上游包为准。ASF 的发行政策仍很适合作为完整发行物如何同时携带 LICENSE、NOTICE 与第三方材料的实践参考。
专利条款到底保护了什么
Apache 2.0 第 3 条提供贡献者到接收者的专利许可，但范围限定为贡献者拥有或能许可、且会因其贡献单独或与作品组合而被实施的专利权利要求。它不是对贡献者全部专利组合的无限授权，也不能保证世界上不存在第三方专利。
如果接收者发起专利诉讼，主张作品或其中贡献构成专利侵权，许可证规定相关专利许可可能自诉讼提出之日起终止。旧稿把它写成“对任何贡献者提起诉讼，所有专利授权自动终止”过于宽泛；应回到第 3 条的具体触发对象与范围。
Apache-2.0 与 GPL 的“兼容”不能反向理解
ASF 的GPL 兼容性说明称，Apache-2.0 代码可以纳入 GPLv3 项目，并由组合后的 GPLv3 条件约束；但这不表示 GPLv3 代码可以直接纳入仍要作为 Apache-2.0 发布的 ASF 项目。ASF 同时指出，Apache-2.0 与 GPLv2 不兼容，原因涉及额外的专利终止等要求。
因此“兼容”不是“两种许可证随便互换”，而是带方向、版本和组合结构的判断。看到依赖写着 GPL-2.0-or-later、GPL-3.0-only 或带例外条款时，应使用完整 SPDX 表达式并由专业人员复核，不要只把所有 GPL 归成一个标签。
AI 项目最容易踩的三个坑
仓库许可证不等于所有资产许可证
一个 AI 仓库可能让推理代码使用 Apache-2.0，却给模型权重附加社区许可证，训练数据仅允许研究用途，示例图片还来自第三方。下载前应逐项检查 LICENSE、模型卡、数据卡和使用政策；遇到陌生概念可先从站内AI 词典确认它描述的是代码、权重、数据还是服务。
依赖树可能引入不同义务
你的主项目使用 Apache-2.0，不会自动把依赖重新许可为 Apache-2.0。发行前应生成软件物料清单，记录直接与传递依赖的版本、许可证和 NOTICE，并针对强 copyleft、非商业、研究限定或来源不清的组件单独审查。寻找项目官方仓库和模型卡时，可从AI 导航进入，不要把聚合页标签当作许可证原文。
“可商用”不等于“可用品牌背书”
Apache 2.0 第 6 条不授予商品名、商标、服务标志或产品名称的使用权，合理描述作品来源除外。ASF FAQ 还特别提醒，修改后的产品不能用名称造成 ASF 创建或背书的误解。公司名称、Logo、项目名和应用商店标题要单独核验商标政策。
如果使用的是 ASF 项目名称或 Logo，还应查看ASF 商标政策。对于非 ASF 的 Apache-2.0 项目，则应查对应权利人的品牌指南；许可证第 6 条本身不会替你授予品牌使用权。
上游免责声明不会替你免除客户责任
许可证第 7、8 条通常以“原样”提供作品，并排除担保及一定范围的责任；但你在销售合同、服务等级协议、隐私承诺或产品说明中可能自愿承担新的义务。第 9 条允许在提供支持、担保、赔偿或其他责任时收取费用，但承担者只能代表自己，不能代表其他贡献者作出承诺。商业团队因此要把“上游不给保证”和“我们对客户保证什么”分开审核。
例如，开源组件的作者不保证适销性，不代表你的成品可以忽略产品安全、消费者保护、数据合规或行业监管。许可证回答的是版权与相关授权条件，不是完整的上市合规清单。
用一张资产台账避免“代码开源，权重受限”
| 台账字段 | 示例 | 验收目的 |
|---|---|---|
| 组件身份 | 包名、模型、数据集、图片或字体 | 避免遗漏非代码资产 |
| 来源与版本 | 原始 URL、提交/文件哈希、获取日期 | 锁定真正审查的对象 |
| 许可证表达式 | Apache-2.0、MIT OR Apache-2.0 等 | 区分“或”“且”与许可证例外 |
| 附带文件 | LICENSE、NOTICE、模型卡、数据卡、商标政策 | 保留完整权利与义务上下文 |
| 修改与组合 | 是否改上游文件、静态/动态链接、是否再打包 | 判断交付义务与兼容性 |
| 交付位置 | 容器、设备、下载包、SDK、前端或仅服务器 | 确定接收者能否获得规定材料 |
| 审批记录 | 负责人、日期、问题、结论与到期复查 | 依赖升级后能够重跑 |
SPDX 的许可证列表提供标准短标识和机器可读入口；更完整的物料清单可参考SPDX 3.0.1 规范。SBOM 能帮助发现组件和许可证，但不会自动判断衍生作品、专利、商标、数据权利或具体法域结论。
按第 4 条生成一个可复核的再分发包
Apache 2.0 的再分发义务集中在第 4 条，但实际交付时不能只放一个 LICENSE 文件就结束。先确定交付物包含哪些上游作品或衍生作品，再为源代码、二进制、容器、SDK、客户端和设备镜像分别生成归属材料。第 4 条允许以源代码或对象形式再分发，但必须满足适用条件；对象形式的归属信息可以放在文档、源代码分发或软件正常显示的第三方声明界面中。
| 第 4 条检查项 | 要放入交付物的证据 | 常见错误 | 复核方法 |
|---|---|---|---|
| 许可证副本 | 完整 Apache License 2.0 文本，接收者可访问 | 只写 SPDX 标识或只放网页链接 | 离线解包也能找到许可证文本 |
| 修改说明 | 被修改文件有显著变更声明 | 只在总版本日志写一句“有修改” | 抽样打开修改文件检查声明 |
| 现有声明 | 保留与衍生作品相关的版权、专利、商标和归属声明 | 格式化代码时批量删除文件头 | 与上游发行包做可重复差异 |
| NOTICE | 若上游包含 NOTICE，保留其中相关归属，允许追加自己的声明 | 把 NOTICE 当许可证全文，或删除竞争方名字 | 逐项标注来源、相关性和放置位置 |
| 新增代码许可 | 可为自己的修改或整体衍生作品增加不同条款，但不得改变上游 Apache 部分的合规义务 | 用新 EULA 宣称上游声明不再适用 | 让法务和构建产物同时复核 |
“显著说明”没有规定唯一模板，但应让接收者能识别哪些文件被改过。NOTICE 也不是无限扩张的广告位：第 4 条说明 NOTICE 内容仅供信息，不修改许可证；新增声明不能被解释为改变 Apache 2.0。ASF 的应用指南还区分源文件头、LICENSE 与 NOTICE 的用途，发布系统应按项目实际文件生成，而不是从另一仓库复制模板。
专利授权与终止要按触发关系阅读
第 3 条不是贡献者全部专利的无限授权。它覆盖贡献者能够许可、且因其单独贡献或贡献与作品组合而必然被侵权的专利权利。专利终止也不是“双方发生任何诉讼就失去许可证”：文本指向接收者提起专利诉讼，并主张作品或其中的贡献构成直接或共同专利侵权的情形。具体争议仍需专业律师结合司法辖区和事实判断。
| 问题 | 条款能支持的谨慎结论 | 不能直接推出 |
|---|---|---|
| 授权来自谁 | 每个贡献者授予其有权许可的相关专利权利 | 所有第三方专利都已清除 |
| 范围是什么 | 限于贡献本身或贡献与作品组合必然涉及的相关专利主张 | 贡献者全部产品和专利组合均获许可 |
| 何时可能终止 | 对作品或贡献提出特定专利侵权诉讼时，针对该作品的专利许可可能终止 | 商标、合同或普通商业纠纷自动触发 |
| 许可证能否替代检索 | 不能；高风险产品仍需专利尽调和合同分配 | 采用 Apache 2.0 就不存在专利风险 |
Apache 2.0 与 GPLv3 的兼容性也要按方向理解。ASF 说明 Apache 2.0 软件可进入 GPLv3 作品，但组合后的整体分发要遵循 GPLv3；这不代表 GPLv3 代码可以反向按 Apache 2.0 重新许可。可同时核对OSI 的 Apache 2.0 许可证页与 ASF 的兼容性说明，具体组合仍要检查代码边界、链接方式、例外条款和实际分发。
AI 项目必须按资产层逐项审计
AI 仓库最常见的误区是把根目录 LICENSE 当成所有文件的统一授权。代码可能是 Apache 2.0，模型权重可能使用社区许可或研究许可，训练数据可能只有访问条款，评测集可能禁止商用，文档和图片可能保留版权，名称和 Logo 还受商标政策约束。API 服务条款与下载权重的许可证也不是同一份文件。
| 资产层 | 要保存的原始证据 | 发布前的问题 | 输出决定 |
|---|---|---|---|
| 代码 | 仓库 LICENSE、文件头、依赖锁文件与提交哈希 | 哪些文件被修改、哪些依赖进入交付物 | 许可证与 NOTICE 包、修改说明 |
| 模型权重 | 模型卡、权重许可、附加用途限制与版本 | 是否允许商用、再分发、微调和托管 | 允许、限制、需授权或拒绝发布 |
| 数据与评测集 | 数据卡、来源、授权、隐私与删除要求 | 是否拥有训练、展示和再分发权利 | 保留、替换、匿名化或停止使用 |
| 文档、图片与示例 | 各自版权与许可 | 是否被容器、网站或安装包一起交付 | 归属、替换或移除 |
| 品牌 | 项目和 ASF 商标政策、合作协议 | 产品名或 Logo 是否暗示官方背书 | 更名、加免责声明或取得许可 |
| 托管服务 | 平台服务条款、数据处理与地域条款 | 是否与本地权重许可混写 | 单独的供应商与数据风险记录 |
技术团队可把站内模型选型与验收方法中的任务清单扩展为许可证清单；训练框架可参考Megatron Core 指南区分框架代码、依赖和模型资产；语言任务可结合自然语言处理指南列出数据、评测集和输出。上述页面只帮助建立资产边界，不替代逐项读取原始许可证。
发布前的可执行流程
- 锁定实际发布物：源代码、二进制、容器、模型权重、数据、文档和素材。
- 为每一项记录来源、版本、提交哈希、SPDX 标识和原始许可证链接。
- 读取上游
LICENSE、NOTICE、模型卡与依赖清单，不只看 GitHub 标签。 - 标出修改过的上游文件，并保留适用的版权与归属声明。
- 在发行包或产品界面提供第三方许可证与 NOTICE 的可访问入口。
- 扫描传递依赖，处理许可证不兼容、未知来源和重复打包。
- 对专利、商标、数据、隐私和出口等问题分别评估；许可证扫描不能替代这些审查。
- 保存本次审查记录，并在依赖、权重或素材更新后重新运行。
若团队还没有 SBOM 流程，可从美国 NTIA 的软件物料清单资料理解最小字段和生态背景，再选择工具。扫描结果应进入人工例外队列：未识别许可证、双重许可、源代码与二进制不一致、包名相同但来源不同，均不能由“自动通过”覆盖。
本地模型部署还涉及量化格式与衍生权重，可结合AI 教程专题理解技术流程，并用推理硬件与部署验收识别运行环境和交付物；许可证判断仍以每个项目实际附带的原始条款为准。
SaaS、容器和客户端为何不能用一句话判断
Apache 2.0 没有 AGPL 式的专门网络交互源码提供条款，所以只在服务器内部运行 Apache 2.0 组件，通常不会仅因用户通过网络访问就触发第 4 条再分发义务。但真实产品往往同时向用户发送 JavaScript、移动客户端、桌面程序、SDK、模型文件或容器镜像；这些交付行为要分别判断。外包部署、私有化交付和向关联公司提供镜像也可能受合同、组织边界与当地法律影响，不能只看“没有公开下载”。
| 场景 | Apache 2.0 初步判断 | 继续追问 | 建议证据 |
|---|---|---|---|
| 纯服务器端 SaaS | 网络使用本身没有专门源码公开要求 | 是否下发前端代码、SDK、文档或模型；依赖是否含 AGPL | 部署清单、依赖树、响应资源清单 |
| 向客户交付容器 | 通常属于对象形式再分发，应处理第 4 条 | 镜像内有哪些操作系统包、模型和第三方组件 | 镜像 SBOM、LICENSE/NOTICE 包、构建哈希 |
| 移动或桌面客户端 | 随客户端交付的 Apache 组件需保留适用材料 | 声明入口是否离线可访问，商店页面是否足够 | 安装包扫描、第三方许可界面截图 |
| 私有化源码交付 | 源代码再分发同样适用第 4 条 | 修改文件是否有显著说明，客户合同是否冲突 | 源代码清单、差异报告、交付签收 |
| 仅调用第三方 API | 通常不等于获得或再分发其服务端代码 | SDK、响应数据、缓存模型和服务条款另行适用 | API 条款版本、SDK 许可证、数据处理记录 |
合规入口还要可用。只把许可证放在临时网页，离线设备或客户归档后无法访问，可能无法满足接收者获得许可证副本的实际需要。容器和设备发布应在构建流水线中自动导出第三方组件清单，并由人工复核高风险、未知和多许可证组件；自动扫描器只能发现线索，不能决定衍生作品、专利范围或合同冲突。
如果团队不确定某个交付是否构成分发，应把技术事实完整交给法律顾问：谁向谁提供了什么文件、以何种方式、是否可复制、是否收费、包含哪些修改与依赖。不要只问“我们是 SaaS，是否不用管许可证”，因为缺少交付物和组织边界时，任何笼统回答都可能误导。
三个常见问题
只在公司内部使用，也要公开修改吗？
Apache 2.0 本身没有要求你因内部使用而公开修改。真正需要重新检查的时点通常是向客户、合作方或公众分发源代码、二进制、容器或设备；同时还要看公司内部是否存在外包交付、集团共享和其他合同安排。
通过网络提供 SaaS 算分发吗？
Apache 2.0 没有像 AGPL 那样设置专门的网络交互开源义务，但 SaaS 仍可能向用户交付客户端代码、SDK、容器或下载文件，也可能混入其他许可证。不能只凭“服务跑在服务器上”就跳过完整依赖清点。
可以删除上游 NOTICE 中的所有内容吗？
不能机械全部删除，也不必机械全部照搬。许可证要求保留与衍生作品相关的归属通知；应逐条判断相关性，并确保放置位置满足第 4 条。对归属是否相关存在疑问时，保留审查记录并寻求专业意见。
资料来源与纠错
许可权、再分发条件、NOTICE、专利、商标与免责声明以Apache License 2.0 英文原文为准；如何放置 LICENSE 与处理 NOTICE 参考ASF 应用指南；翻译效力、修改后命名、专利范围和 GPL 兼容性说明参考ASF Licensing FAQ；开源许可证资格与 SPDX 标识参考OSI 批准许可证目录；历史背景参考Apache-2.0 历史页。资料复核日期：2026 年 7 月 19 日。
编辑复核与纠错记录：本文由兰塞 AI 编辑流程于 2026 年 7 月 19 日复核。旧稿整篇乱码，并把专利授权描述成无限范围、把终止条款写成对任何诉讼都触发，还用“赠送土地”“相互保证毁灭”等比喻替代法律边界，已全部删除。本次 A 级候选重写增加第 4 条再分发证据、专利触发关系、GPL 兼容方向、AI 资产分层、容器/SaaS/客户端边界、SBOM 台账、商标边界与三张原创图；本文仍不对任何具体项目作合规结论。本站的来源、更新与纠错原则见关于本站与编辑规范。
正式发布前将再次检查 Apache、ASF、OSI 与 SPDX 页面是否发生条款、地址或解释更新；若具体项目的许可证、NOTICE、模型卡或服务条款变化，必须以项目当时随附文件重新审计，不能只更新本文日期。审计结果应保留版本、哈希、责任人、批准记录并定期持续复核。
