（一）Apache HTTP 和Apache软件基金会（ASF）

在万维网（WWW）刚刚被发明不久的1994年，美国伊利诺伊州国家超级计算应用中心（NCSA）的Rob McCool创建了一个简单的可扩展的网络服务器NCSA HTTP，由于这个网络服务器的可扩展性，它在网络中被广泛应用。世界各地的网页管理员在获得这个网络服务器的源代码后，纷纷为其开发扩展，并且修改其中的错误。1994年年底Rob McCool从NCSA离职，为了避免使这个网络服务器陷入无人管理的困境，它的现有用户和开发者纷纷集合起来成立了专门的团队以维护NCSA HTTP。1995年，Apache小组从这个NCSA HTTP的维护团队中成立，并且在1995年4月发布了Apache HTTP和Apache开源协议1.0版本。Apache HTTP秉持自由、开源的精神，鼓励全球合作。逐渐地，Apache HTTP的更新迭代速度超过了NCSA HTTP。直到1995年底，Apache HTTP彻底取代了曾经占据主导地位的NCSA HTTP。直至今日，Apache HTTP依然是全世界最广泛使用的网络服务器[1]。

Apache HTTP的巨大成功使得Apache项目组不断收到来自世界各地的反馈和代码修改建议，Apache旗下的其他项目也纷纷模仿Apache HTTP组建自己的项目组，相应的经济利益和潜在的法律问题不断增加。出于管理需要，Apache软件基金会（ASF）在1999年6月成立，基金会成立时登记为非营利性慈善组织。在接下来的一年中，每隔几个月就有一个新项目进入基金会。到2001年时，基金会决定采用孵化器的方式来接纳新的软件项目。该模式使得基金会至今依然保持非常活跃的项目增长速度。

（二）Apache开源许可证

Apache协议的最初版本1.0版本条款内容较少，与最初的BSD许可证[2]基本相同，只是改变了对应的著作权人和开源项目组的名称，并且增加了一个派生作品不得使用Apache名称的规定[3]。1997年，BSD协议采纳了自由软件基金会的观点，在更新的BSD协议中取消了广告条款[4]，形成了三条款BSD协议（BSD 3-Clause）。在2000年，Apache协议也进行了条款更新，同样删除了对开源软件派生作品的广告限制，形成了Apache协议1.1版本[5]。2004年，Apache协议做了较大的调整，发布了全新的Apache 2.0版本。

（一）Apache 1.0的主要内容和评述

Apache 1.0是Apache协议的最初版本，它仅适用于一些比较陈旧的Apache软件包，例如Apache的1.2版网络服务器。如前文所述，Apache 1.0与BSD协议基本相同。它允许开发者使用或再分发受保护的软件，无论开发者采用源代码格式还是二进制代码格式，都必须相应地复制或者保留受保护软件的版权声明、协议条件和免责声明[6]。另外，所有提及受保护的软件的使用或特征的广告材料必须表明这个产品包含Apache项目组开发的开源软件，并且该软件用于Apache HTTP项目[7]。Apache 1.0也严格控制对于Apache名称的使用，除非经过书面许可，否则开发者不得将Apache相关名称用于派生产品的名称之中[8]，也不得用Apache服务器、Apache项目组来宣传派生作品[9]。在许可证的最后，Apache 1.0也参照BSD协议规定了免责条款。

Apache 1.0奠定了Apache协议的基础，其对于开发者的义务要求主要集中在发布开源软件的版权声明、许可证条件和免责声明上，对于软件接受者如何使用开源软件的限制很少，开发者只需要尽到“标注”义务，不擅自使用Apache相关名称即可自由使用开源软件。

（二）Apache 1.1的主要内容和评述

Apache 1.1在2000年被Apache基金会通过，其条款与1.0版本相比主要的变化在第三条。Apache 1.0版本第三条规定了所有提及受保护软件的使用或特征的广告材料必须显示以下认可声明：“本产品包含由Apache集团开发的软件用于Apache HTTP服务器项目（http://www.apache.org/）”[10]，且这一声明的重要性在Apache 1.0 的第六条被再次重申，任何形式的再分发都必须保留这一声明[11]。Apache 1.1版本删除了原本第三条和第六条的规定，1.1版本的第三条规定了如下内容：再分发材料包含的最终用户的登记文件（如有），必须包含下列认可声明：“本产品包含由Apache集团开发的软件（http://www.apache.org/）”，或者本认可声明可以出现在软件中那些第三方认可声明通常出现的地方[12]。

Apache 1.1对于开发者使用了开源软件的广告材料不再严格要求展示归属声明，而是改为只要在再分发材料中的最终用户的登记文档（The end-user documentation）中放置声明，或者在那些能够展示第三方认可声明的软件中直接展示声明即可（Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear）。相较1.0版本，1.1版本更加灵活宽松，1.1版本删除了被认为是非常多余的广告声明条款。此类广告条款在业界曾经引起了广泛的争议，被戏称为“令人反感的广告条款”，原因在于开发者在分发使用开源软件时，并非完全复制其中的广告声明条款，而是会将其中的“This product includes software developed by the University of California”，更换为其他的开发者，这就导致了后续开发者需要引用大量的权利归属声明，GNU的Richard Stallman称其曾经在一个开源软件的广告材料中，数到多达75个权利归属句子，光这些句子就占据了整整一页[13]。因此，Apache 1.1删除这个多余的广告条款，可谓一种有益的改进。

（三）Apache 2.0的主要内容和评述

Apache 2.0相比前两个版本有较大的更新和扩充。首先，在形式上，Apache 2.0在开头增加了概念定义条款，区分了原始作品、派生作品、单独作品的概念：在Apache协议下获得的作者的作品，无论以何种格式存在，均为原始作品。将原始作品进行编辑、注释、阐述、或者其他修改后，可获得基于原始作品的派生作品。单独作品是与原始作品或者派生作品分离，或仅仅是通过链接或通过名称与原始作品、派生作品绑定的作品[14]。

其次，Apache 2.0明确了其授予的许可内容，在著作权许可方面，根据Apache 2.0的条款和条件，每一个贡献者在该许可证下授予被许可人永久的，全球的，非排他的，免费的，免税的，不可撤销的著作权许可，许可包括复制、制作派生作品、公开展示、公开表演、再许可、分发原始作品和派生作品，以源代码或目标代码形式[15]。

在专利许可方面，Apache 2.0增加了贡献者对软件接受者的专利许可，根据该许可证的条款和条件，每一个贡献者在此给予被许可人永久的、全球性的、非排他的、免费的、免税的、不可撤销的（许可证另有声明除外）专利许可，许可包括制造、委托制造 、使用、许诺销售、销售、进口以及其他形式转让作品。前述专利许可仅限于贡献者可授权的专利权权利要求，授权的权利要求必然会被贡献者提交的“贡献”或“贡献”与原始作品的组合所侵犯。Apache 2.0还有关于专利授权终止的规定，如果被许可人针对任何实体提起了专利诉讼（包括诉讼中提出交叉请求或反请求）声称原始作品或者某一个已经纳入原始作品的“贡献”对被许可人构成直接侵权或帮助侵权，那么本许可证曾经给予被许可人的任何专利许可均会在被许可人提起诉讼之日被终止[16]。

再次，Apache 2.0关于软件接受者的主要义务规定在第四条“重新分发”中，对复制开源许可证、表明修改、保留声明进行了具体规定。被许可人依然无权擅自使用Apache相关的商号、商标、服务标识或产品名称[17]。

最后，Apache 2.0扩充了免责声明和责任限制的内容，其第七条特别明确许可方仅仅按原样提供原始作品（每个贡献者提供其贡献也是如此），不提供任何明示或暗示的保证或状态，包括但不限于任何所有权、非侵权、适销性或特定用途适用性的保证或条件。被许可人单独负责确定使用或重新分发原始作品的适当性，并承担与执行本许可证下许可行为相关的任何风险[18]。其第八条进一步对贡献的责任进行限制，即使该贡献者已被告知损害的可能性也无需对损害承担赔偿责任[19]。

Apache 2.0相较于前两个版本，明确了著作权许可的内容，增加了专利权许可的内容，其对被许可人的义务规定以复制开源许可证、表明修改、保留声明为核心内容。

（一）Volcengine Inc.火山引擎Apache许可证事件

2022年1月28日，Apache SkyWalking官网发布声明，称Volcengine Inc.(火山引擎) Application Performance Monitoring-Distributed Tracing (应用性能监控全链路版)以非法方式重新发行了 Apache SkyWalking的SkyWalking Java agent开源软件，违反了Apache 2.0许可证。

Apache SkyWalking是一个分布式系统的开源APM（Application Performance Management应用性能管理软件），通常用于对企业系统进行实时监控以实现企业对应用程序的性能和故障的全面了解，解决分布式架构下的问题定位和性能瓶颈问题[20]，是 Apache 软件基金会的顶级项目。

Apache SkyWalking提到的违反开源协议的火山引擎是字节跳动旗下的云服务平台，为抖音、懂车帝、Keep等知名软件提供服务[21]。Apache SkyWalking在官网声明中表示其在1月28日收到了一份匿名举报，发现火山引擎拥有一个名为Application Performance Monitoring-Distributed Tracing (应用性能监控全链路版) 的云服务程序。Apache SkyWalking下载这个程序之后，发现其与Apache SkyWalking开发的名为SkyWalking Java agent的开源软件几乎相同[22]，从而确认Application Performance Monitoring-Distributed Tracing (应用性能监控全链路版)的发布行为实质上是适用Apache 2.0许可证的SkyWalking Java agent 的再分发行为，应当遵守Apache 2.0许可证的规定。但是­火山引擎最终发布的软件中，删除了SkyWalking Java agent所有包的名称，没有保留 Apache 软件基金会的标题（header）、开源许可证和 NOTICE文件。

在SkyWalking发出此声明后，2022年1月30日SkyWalking收到了火山引擎的APMPlus开发团队的答复，火山引擎的APMPlus开发团队承认其违反了许可证的规定并采取措施进行弥补。火山引擎承认其发布的APMPlus产品是一个基于Apache SkyWalking agent的分支（a fork version），本质上也是对开源软件的一种再分发行为。

（二）Beyond Microservice（博云）Apache许可证事件

2020年6月，SkyWalking的Apache项目负责人向思否（SegmentFault）中文技术交流平台[23]提供消息称云计算解决方案服务商“博云”在使用开源项目 Apache SkyWalking 时，违反了该项目声明的 Apache 2.0 开源许可证规定。SkyWalking项目负责人声称博云的BeyondMicroservice的宣传视频中，一些APM相关的UI组件、布局以及显示的指标信息，都和SkyWalking 6.6与Sky Walking 7完全一致[24]。SkyWalking认为，尽管按照Apache 2.0的规定，博云可以自由修改SkyWalking 6.6与Sky Walking 7并且重新整合UI，但是应当在对BeyondMicroservice进行宣传时，展示其包含了SkyWalking这个适用Apache协议的开源软件作为其中的一部分。但是博云在产品的宣传材料中，并没有对上述情况进行说明[25]。事件发生后，博云公司在2020年6月19日在搜狐网官方账号上发布《博云积极与Apache SkyWalking项目合作的声明》，承认由于宣传工作失误，公司发布的微信宣传稿未能在相关位置显著标明Apache SkyWalking，公司网站上一段短视频未能显著标注使用了Apache SkyWalking的情况。以上问题已于当晚立即得到改正[26]。

（一）判断开源协议的版本

开源软件合规项目工作的第一步永远是判断开源软件适用协议的种类和版本。开源协议的更新通常都会解决前一个版本中隐藏的问题，有时通过自我迭代研发出全新的条款，有时则借鉴其他开源协议的条款。如Apache协议1.0与1.1的差异并不明显，但是与2.0比较则差异巨大，因此进行开源软件合规工作的第一步工作是明确具体的Apache许可证的协议版本，进而根据协议版本确定需要合规工作的具体依据。

（二）评估开源软件的应用风险

开源协议大多带有复杂的免责声明和责任限制条款，此类条款对于保护开源代码的著作权人和贡献者至关重要，因此往往被要求复制或保留在再分发的派生作品中。但是此类免责条款由于其“格式性”而常被忽略，例如Apache 2.0的第七条规定：许可方仅仅按原样提供原始作品（每个贡献者提供其贡献也是如此），不提供任何明示或暗示的保证或状态，包括但不限于任何所有权、非侵权、适销性或特定用途适用性的保证或条件[27]。需要注意的是Apache 2.0协议并不对代码的所有权负责，这意味着虽然开发者可以根据协议使用开源代码，但是依然存在着侵犯他人著作权或者专利的风险。笔者建议企业在使用Apache 2.0的开源代码时，尽可能选用Apache基金会孵化的项目代码、大型公司发布的开源代码或业内广泛使用的开源代码。此类开源代码由于具有基金会或知名企业背书或经过长期市场检验，侵权风险较小。而冷门、小众的开源代码则风险相对较大，需要慎评估后决定是否使用。

（三）对后续开发成果的开源/闭源选择

Apache协议属于宽松型开源协议，其并不要求开发者对基于开源软件的派生作品继续进行开源，因此基于Apache 2.0开源代码制作而成的派生作品，该派生作品的开发者有权决定是否继续开放其修改后的派生作品的源代码。

1、开源/闭源的选择

将开发成果开源并不意味着开发者放弃对代码的权利，开源仅意味着其他开发者可以在遵守协议的前提下获得部分著作权和专利（如有）的许可。

开源与否涉及到企业对于平衡商业利益和公共利益的考虑，对自身的研发成果进行开源尽管看起来是企业让渡了部分商业利益，但是这一促进公共利益的技术分享行为，可以使全球的开发者共同参与该开源项目，更快地发现和修复软件项目缺陷，提升产品性能，从而提高企业在业界的声誉，使企业得以宣传自身的开源软件项目，提高相关开源软件项目的知名度和影响力。

2、采用Apache 许可证开源的范例

目前，笔者了解到的国内知名的选择Apache2.0许可证开源的项目有华为的OpenHarmony项目[28]，百度的自动驾驶Apollo[29]项目等。前述开源项目均获得了公众的普遍好评，取得了良好的社会效果。

（四）根据开源协议的版本，严格履行开源许可证项下规定的义务

Apache协议为宽松型开源协议，其核心义务为保留原始权利声明和免责声明、声明修改、展示权利归属声明等。如果不履行相应的协议义务而被第三方投诉或著作权人发现，则将要面临授权终止、行业内的谴责和负面评价，甚至应付软件侵权诉讼。下文将对Apache协议三个版本的合规要点简介如下：

1、Apache 1.0

如果企业适用的开源代码适用Apache 1.0，则无论企业采用源代码格式还是二进制代码格式分发开源代码，都必须相应地复制或者保留受保护软件的版权声明、协议条件和免责声明[32]，以及如下认可声明：“本产品包含了由Apache集团开发的用于Apache HTTP服务器项目（http://www.apache.org/）的软件”[30]。

所有提及受协议保护的软件的使用或特征的广告材料必须表明这个产品包含Apache项目组开发的开源软件，并且该软件用于Apache HTTP项目[31]。除非经过书面许可，否则开发者不得将Apache相关名称用于派生产品的名称之中，也不得用“Apache服务器”、“Apache项目组”来宣传派生作品[33]。

2、Apache 1.1

如果企业适用的开源代码适用Apache 1.1，原则上标明复制或者保留受保护软件的版权声明、协议条件和免责声明的义务与1.0相同，如果再分发材料包含最终用户的登记文件（end-user documentation），还必须包含下列认可声明：“本产品包含由Apache集团开发的软件（http://www.apache.org/）”，或者本认可声明可以出现在软件中那些第三方认可声明通常出现的地方[33]。

3、Apache 2.0

如果企业适用的开源代码适用Apache 2.0，则分发原始作品的源代码或目标代码时，无论发布于何种媒介，都必须给后续的被许可人一份Apache 2.0协议的副本[35]。

如果企业对原始作品进行了修改从而生成了派生作品，那么企业在分发派生作品时，首先应像再分发原始作品一样，复制一份开源协议的副本。其次，如果企业对原始作品进行了修改，则应当在任何修改的文件中附上一个显著的声明，表明修改的存在[36]（如下图）。

火山引擎APMPlus产品最终对开源代码修改情况的说明[37]

当企业以源代码形式分发派生作品时，必须原封不动地保留原始作品的源代码中的著作权、专利、商标和权利归属声明，除非某些声明同派生作品的任何部分都无关[38]。例如某些声明对应的原始作品的部分已经在派生作品中被删除，则此类声明无需再放置在派生作品的分发中。

如果一个原始作品的分发内容中包含了一个《声明》文本文件（“NOTICE” text file），那么企业在分发任何派生作品时，必须一起发布一个《声明》文本文件中的《权利归属声明》（attribution notices）的可读副本，除非某些声明同派生作品的任何部分都无关。前述《权利归属声明》的可读副本至少应放在以下位置之一：1、放在属于派生作品的一部分的《声明》文本文件里。2、如果与派生作品一起提供，则放置在派生作品的源代码或登记文件中；3、放置在派生程序所产生的显示内容中，在一些第三方通知通常出现的地方。《声明》文件夹中的内容仅作提供信息之用，不构成对开源许可证的任何修改。例如，在前述火山引擎的案例中，在更新后的APMPlus产品中就在如下位置新增了SkyWalking的许可证和NOTICE（如下图）[39]。