Apache License 2.0 是全球使用最广的宽松型开源许可证之一，Android、Kubernetes、Flink、Cassandra 等重量级项目都在用，堪称企业级开源软件的首选。也正因“宽松”，不少开发者和企业把它理解为“可以随便用”，忽略了其中的专利条款、NOTICE 文件要求和商标限制。本文从律师视角解读 Apache 协议，重点回答一个核心问题：基于 Apache 代码产生的作品，什么情况下须遵循 Apache 协议，判定要素又是什么。
一、Apache协议的定位与核心特征
开源许可证按约束强度分两类。一类是宽松型（Permissive），代表有 MIT、BSD、Apache；另一类是传染型（Copyleft），代表是 GPL、AGPL。区别只有一个：宽松型允许修改者以其他许可证甚至闭源方式再分发，不产生“传染”；传染型则要求衍生作品沿用原许可证。GPL 的“病毒式”扩张，本质上就是这一条在起作用。
Apache 协议由 Apache 软件基金会维护，先后出过三个版本。1.0 版用于基金会内部项目，条款松散；1.1 版（1999 年）做了修补；我们常用的 2.0 版发布于 2004 年，新增专利条款、明确再分发规则、改善与其他许可证的兼容性。正是 2.0 版让 Apache 协议走出基金会，成为全球最主流的开源许可证之一。
与 MIT 的极简相比，Apache 2.0 要周密得多。MIT 的核心条款寥寥数语，Apache 2.0 则有九条正文、两个附录，从定义、版权授予、专利授予到再分发条件、贡献规则、商标、免责与责任限制，都有明文。这种“严”不在限制使用——恰恰相反，Apache 给使用者的自由度很高——而在规则本身写得完整、确定。企业要的是确定性，知道自己踩到哪里算越界，Apache 协议恰好给得出这种确定性。
从法律性质看，开源许可证是著作权许可合同。著作权人以许可协议授权被许可人在特定条件下使用、复制、修改、分发作品；遵守条件即享有权利，违反条件则许可终止，继续使用即构成侵权。这一点在国内司法实践中已被确认：广东省深圳市中级人民法院在济宁市罗盒网络科技有限公司诉福建风灵创景科技有限公司、北京风灵创景科技有限公司侵害计算机软件著作权纠纷案〔（2019）粤03民初3928号〕；最高人民法院〔（2021）最高法知民终2063号〕二审驳回上诉、维持原判中认定，开源许可协议属附解除条件的著作权合同，被许可人违反协议约定则授权自动终止。该案涉及 GPLv3，但法理同样适用于 Apache 2.0——其第8条（Termination）规定违反协议则授权终止，且设有纠正期：被许可人收到违约通知后30日内纠正违约行为的，授权恢复。GPL 3.0 第8条亦有类似机制。因此，“违反即永久丧失授权”并不准确，在 Apache 2.0 下被许可人实际享有30日的纠正窗口。
二、Apache协议的核心权利与义务
Apache 2.0 的第2条、第3条分别授予版权许可和专利许可，是协议核心。版权许可永久、全球、非排他、免费、免版税、不可撤销，涵盖复制、制作衍生作品、公开展示、公开表演、再许可和分发。专利许可同样永久、全球、非排他、免费、免版税，但范围受限——只覆盖贡献本身必然侵犯的专利权利要求，以及该贡献与所提交作品结合必然侵犯的专利权利要求。换言之，专利许可只针对与贡献代码直接相关的部分，并不覆盖贡献者的全部专利。
第3条后半段是专利终止条款：被许可人对任何实体提起专利诉讼，主张该作品或其贡献构成专利侵权（含直接、间接侵权）的，其依据本协议获得的针对该作品的专利许可自起诉之日起自动终止。这是一条“专利报复”条款——用专利武器攻击开源项目，就失去该作品的专利许可。它防止的是一边享受开源红利、一边用专利打压开源社区的行为。对企业而言，在自有产品中使用 Apache 代码前，应当评估自身专利组合，避免因起诉他人专利侵权而意外丧失正在使用的开源软件专利许可。
第4条规定了再分发必须满足的四项条件，这也是企业合规问题最集中的地方。
第一，提供许可证副本。分发作品或衍生作品时，须向接收者提供完整的 Apache 2.0 许可证。实务中常见的错误是漏放，或放入不完整版本。正确做法是在源代码目录或安装包内附完整 LICENSE 文件。
第二，标注修改。修改过的文件须加注醒目通知，说明修改事实。所谓“醒目”，是指不能把声明藏在文件角落，也不能只在某个总的说明文档里提一句。规范做法是在每个被修改源文件的头部注释中标注“本文件已被修改”及修改要点。
第三，保留声明。衍生作品须保留原始作品源代码中的全部版权、专利、商标和归属声明，除非与衍生作品无关。不少企业为了“干净”删除或替换原始版权头，这是违规的。应当保留原始声明，再附上自己的版权声明。
第四，NOTICE 文件。原始作品含 NOTICE 文件的，分发衍生作品时须在下述任一位置附上 NOTICE 中归属声明的可读副本：衍生作品随附的 NOTICE 文件、随作品提供的源代码或文档、或衍生作品显示界面中第三方声明通常出现的位置。NOTICE 只具告知性，不改变许可证本身。可以在衍生作品中加入自己的归属声明，与原始 NOTICE 并列或作为补充，但不能让人误读为修改了许可证。
除上述四项义务外，还有两个“不作为”义务。其一，商标条款（第6条）：本许可证不授予使用许可方商号、商标、服务标志或产品名称的权利，仅在描述来源和复制 NOTICE 内容时可作合理、惯例的使用。不能用“Apache”命名产品，也不能暗示基金会背书。其二，免责与责任限制（第7、8条）：作品按“原样”提供，贡献者不承担担保或责任。这是开源许可证的标配，但企业应当清楚：用了开源代码出了问题，无法向社区或贡献者索赔。
三、衍生作品的判定：哪些作品需要遵循Apache协议
效力边界问题，写在协议第1条对“衍生作品”的定义里。
定义分两层。第一层是“包含标准”：基于作品或从作品衍生而来的任何作品，无论源形式还是目标形式，其编辑修订、注释、详细阐述或其他修改作为一个整体构成原创作品的，即为衍生作品。判断要点有二：一是作品基于或来源于原始作品，二是修改、补充、注释等作为整体构成原创作品。在 Apache 代码上修改、扩展、优化而成的新作品整体，就是衍生作品。
第二层是“排除标准”，即两类不构成衍生作品的情形：一是“相分离的作品”，即与 Apache 代码相互独立、只是放在一起使用；二是“仅仅链接到接口的作品”，即仅通过接口调用 Apache 代码功能，两者松耦合，作品本身不包含也不修改 Apache 代码。
排除标准决定了 Apache 协议的边界。与 GPL 对照更清楚：GPL 下即使动态链接也可能被认定构成衍生作品。但司法实践并非“动态链接即传染”，仍需个案判断开源代码与自有代码是否“高度牵连融合成一体”——（2021）苏01民初3229号案确立的标准是，被传染部分应是与原开源软件形成密切通信、二者高度牵连融合成一体的程序，而非有数据交换即构成传染。Apache 协议则明确“仅仅链接到接口”不构成衍生作品。据此，闭源商业软件调用 Apache 库 API、动态链接 Apache 库，只要不修改库本身代码，通常不视为衍生作品，无需开源。但静态链接会将目标代码并入可执行文件，与 Apache 代码的结合程度高于动态链接，是否仍属“仅仅链接到接口”，需结合个案中代码结合程度、依赖关系判断，不能一概认为静态链接不构成衍生作品。这正是 Apache 协议对商业应用友好的原因。
当然，“仅仅链接到接口”仍有灰色地带。大量继承 Apache 代码的类、扩展其函数、深度嵌入自身架构，还算不算“仅仅链接”？这需要个案判断。我一般从四个维度综合考察。
一是代码关联程度。直接复制源代码、修改 Apache 源文件、将 Apache 代码内嵌进自身代码文件的，几乎可以确定构成衍生作品；反之，两个文件集合完全分离，仅通过 import、include 或 API 调用使用 Apache 功能，更接近“仅仅链接”。
二是架构依赖程度。软件脱离 Apache 组件即无法运行的，耦合度很高。但高耦合不等于衍生作品——Kafka、Log4j 等商业软件深度依赖 Apache 组件，仍是独立软件，不被视为 Apache 项目的衍生作品。关键在于是“建立在”Apache 代码之上的修改延伸，还是“使用”Apache 代码作为独立工具或库。前者更可能构成衍生作品。
三是功能整合程度。是对 Apache 代码核心功能作了修改、扩展或重写，还是仅利用其既有功能、在其上叠加独立的上层业务逻辑？主要贡献在于修改扩展 Apache 代码本身的，更像衍生作品；核心功能独立、仅借 Apache 代码完成网络通信、数据解析、日志等底层支撑的，更像独立作品。
四是分发呈现方式。将 Apache 代码作为独立组件随产品分发，还是将大量 Apache 代码融入自身代码至难以区分？前者接近两个独立作品的集合分发，后者接近一个衍生作品整体。
必须承认，这些维度给不出精确公式。衍生作品本就是版权法里最模糊的领域，Apache 协议已算写得清晰，但技术实现千变万化，不可能用一句话穷尽。我的执业建议是：拿不准时按保守处理，推定构成衍生作品并按 Apache 协议履行义务。Apache 的义务本就不重，履行成本低，没必要冒险。
四、衍生作品需要遵循哪些具体要求
构成衍生作品的，分发时须履行第4条全部义务，逐条对应。
其一，附许可证副本。无论是否修改，只要分发 Apache 许可代码（含衍生版本），即须附完整 Apache 2.0 许可证全文，不能只放摘要或修改版。
其二，标注修改文件。这是衍生作品场景最易出问题的环节。修改了 Apache 代码却未在修改文件上标注通知的，并不少见。仅在一份总的 README 中说明“我们修改了某些文件”不满足要求，须在每个被修改文件上加注醒目标注，规范做法是在文件头部版权声明下加一行“本文件已由[公司名称]于[日期]修改”之类的注释。
其三，保留原始声明。版权、专利、商标、归属声明一个都不能少，除非确与分发部分无关。常见误区是：“我自己重写了大部分代码，只剩一点 Apache 的，凭什么还保留它的版权声明？”答案很简单——协议要求。只要用了别人的代码，哪怕一点，就得保留其版权声明。这既是法律义务，也是对原作者的基本尊重。
其四，NOTICE 文件。这是最易被忽视、也是 Apache 特有的要求。原始项目有 NOTICE 文件的，衍生作品分发时须包含其内容；且不是只包含自己修改部分的 NOTICE，而是将所有用到的 Apache 组件的 NOTICE 合并进来。产品用了十个 Apache 项目，就要合并十份。组件多的时候，NOTICE 管理是实打实的工作量。
除四项义务外，有一点需要特别说明：衍生作品整体可以采用不同许可证。第4条末段允许在修改部分添加自己的版权声明，也可为修改部分或整个衍生作品提供附加或不同的许可条款，前提是对作品的使用、复制、分发仍符合本协议要求。据此，可将衍生作品整体以其他许可证（含商业闭源许可证）分发，只要保留 Apache 原始代码要求的声明和通知。但须注意第4条（b）（c）款的界限：修改后的 Apache 代码文件本身作为衍生作品仍须遵循 Apache 协议义务（如在被修改文件上标注修改）；第4条（c）款允许为修改部分或整个衍生作品提供附加或不同许可条款，前提是符合协议要求。因此，“新增部分可自行许可”不等于修改后的 Apache 代码也可随意许可。这与 GPL 的“传染性”形成鲜明对比——GPL 要求衍生作品整体沿用 GPL，Apache 不要求。
前提仍是：原始 Apache 代码部分的使用和分发必须符合 Apache 协议。不能因为整体改用商业许可证，就删掉 Apache 代码的版权声明、去掉 NOTICE 文件。商业许可证管的是新增代码和整体产品，Apache 代码那部分始终受 Apache 协议约束。这是企业用 Apache 代码做商业产品最核心的合规逻辑。
五、企业使用Apache协议的常见合规风险
规则讲完，看实务中企业常踩的坑。Apache 协议相对友好，踩坑的企业依然不少。
一是 NOTICE 文件遗漏。不少企业知道保留 LICENSE 文件，却不知道还有 NOTICE 文件这回事，或知道也不当回事。NOTICE 仅具告知性、不改变许可证，但它是协议明确要求，遗漏即违约。何况连 NOTICE 都处理不好的企业，开源合规管理整体多半薄弱，其他环节也难说。建议建立 NOTICE 管理制度：每引入一个 Apache 组件即检查其 NOTICE 文件，有则并入自身产品的 NOTICE。
二是商标使用不当。Apache 协议不授予商标使用权，但不少企业为显得权威，宣传时说“基于 Apache 某某技术打造”“Apache 官方推荐”。前者或许还算合理描述，后者明显越界。更糟的是把“Apache”放进产品名称，如“Apache 某某系统”，直接构成商标侵权。Apache 基金会商标政策严格，发现违规会发函纠正。商标只能用于合理描述来源，如“本产品包含 Apache Kafka 技术”，不能暗示官方背书，更不能进产品名。
三是专利终止条款触发。很多企业用了多年 Apache 代码，从没注意过专利终止条款，直到专利部门要起诉某竞争对手，才发现对方也在贡献某个 Apache 项目，而自己产品也在用同一个项目。一起诉，自己的专利许可终止，自身产品反而面临专利侵权风险。实际触发条件比这更严格，但企业至少应建立意识：提起专利诉讼前，评估是否影响自己正在使用的开源软件专利许可。
四是贡献代码时的许可证问题。根据第5条，除非明确另行说明，向许可方提交、意在纳入作品的贡献，默认适用 Apache 协议条款，包括专利许可条款。若核心专利不打算经开源贡献方式许可出去，就不要把涉及核心专利的代码贡献给 Apache 项目。Apache 基金会另有正式贡献者许可协议（CLA），主要贡献者通常须签署 ICLA（个人）或 CCLA（公司），条款与 Apache 许可证一致，但法律效力更强。
五是对“衍生作品”的误判。有企业认为只改了 Apache 代码几个文件，整个产品还是自己的，无须履行义务。这是错的。修改并分发后的文件即构成衍生作品，必须标注修改、保留原始声明。其他独立代码当然无须开源、无须遵循 Apache 协议，但修改过的那部分，该履行的义务一条不能少。
六、企业Apache合规实操建议
最后是几条可落地的建议。
第一，建立开源组件清单和许可证台账。把产品使用的全部开源组件登记造册，记录组件名称、版本、许可证类型、来源、使用方式；Apache 组件还要特别记录有无 NOTICE 文件、是否修改过源码、改了哪些文件。繁琐，但一旦出事，这是证明合规的依据。
第二，建立代码引入审查机制。开发者引入新开源组件前须过合规审查：许可证类型与产品许可模式是否兼容？有无专利风险？有无 NOTICE 文件？是否需修改源码？不能让开发者随手从网上拉代码，等被起诉才发现许可证有问题。
第三，规范 NOTICE 文件管理。每个产品建统一 NOTICE 文件，集中管理全部开源组件的归属声明。新增组件即并入其 NOTICE，移除组件即删去对应内容。NOTICE 随产品分发，可放安装目录，也可在软件“关于”页面展示。
第四，建立商标使用规范。市场、销售、产品团队都须清楚哪些词是开源社区商标、不能乱用，尤其“Apache”既不能进产品名，也不能在宣传中暗示官方背书。建议制定商标使用指南，明确允许与禁止的用法，并审核市场宣传材料。
第五，建立专利风险评估机制。提起专利诉讼或进行专利交易前，评估对自身开源使用的影响。起诉对象是某 Apache 项目主要贡献者，或涉案专利与正在使用的 Apache 组件相关时，须特别谨慎，评估是否触发专利终止条款。
第六，定期开源合规审计。产品在迭代、依赖在变化，合规风险是动态的。定期审计许可证合规、NOTICE 完整性、商标使用情况，及时纠偏。
结语
Apache 2.0 能成为最受欢迎的开源许可证之一，原因其实朴素：它在开源精神和作者权益之间划出底线，把最大的自由度留给使用者——可用、可改、可卖、可闭源，只要保留该保留的声明、标注该标注的修改、不滥用商标。这种“宽松但不松散”，正合商业环境对确定性和灵活性的双重需要。
宽松不等于没有规则。Apache 的条款不多，但每一条都有相应的法律后果。对使用开源软件的企业来说，与其研究怎么钻空子，不如在规则内把事情做扎实。开源的本质是协作与共享，尊重规则，就是维护这套协作秩序。