不懂开源协议惹的祸：SkyWalking拒绝针对唯品会 Saturn 项目的插件需求

Saturn 是 fork 自 ElasticJob，并更改了版权信息，这是一个非常严重的许可证问题。基于 ElasticJob 的原始许可证 Apache 2.0 ，所有文件的 header 都应该保留，即便他们修改了代码。所以，无论你或是任何人想要做这个插件，我们都不能正式接受它作为 Apache SkyWalking 的一部分。如果你认识他们，请联系他们。只有在他们纠正了许可证问题，并且回滚了所有的 header 之后，我们才能支持他们的新版本。

我们联系吴晟了解相关情况，根据他的说法，他在查看 Saturn 源码时，发现项目实际上是 fork 自当当网的 ElasticJob。

ElasticJob 采用的 Apache 2.0 开源许可协议。根据 Apache 2.0 协议的要求，衍生项目需要在源码中有明确标识，说明此项目是 fork 自 ElasticJob ，一般就是在使用到的源码上保留原始附加版权信息，方可进行二次分发。

也就是说，Saturn 需要保留原项目文档中的版权 header 说明，声明当当的原始版权。但吴晟发现，Saturn 项目大部分文档中并没有声明版权归 ElasticJob。

这相当于，Saturn 复制了一遍 ElasticJob 的源码，并自行修改，但没有很好地尊重 ElasticJob 的版权。严格来看，类似“抄袭”源代码行为。

此时 Saturn 要提交给 SkyWalking，SkyWalking 认为它在“开源”约定上是不合规的，就拒绝了。

吴晟表示，Saturn 想要更正这个问题，工作量会非常大，首先需要把所有来自 ElasticJob 的源文件全部退回当当的 header，在库里声明，这是基于当当版本 ElasticJob 二次分发的一个版本。更正后需要重新发布一个 release 版本，“基于这个 release 版本，SkyWalking 肯定是可以接受它的插件到官方库的。之前的所有版本都不合规，如果不修正，那么实际上就是一直存在版权问题，不仅影响自身在开源上更好地发展，也会给其它准备和已经使用了它的项目带来困扰。”

不过吴晟认为，Saturn 应当没有“抄袭”源码的初心，因为 Saturn 的代码库中有标注一个致谢信息，说明项目来自当当的 ElasticJob，并感谢软件核心开发者/发起人张亮。（编者注：ElasticJob 已经捐赠给 Apache 基金会，版权也随之属于 Apache 基金会）

所以可以假定 Saturn 并没有故意隐瞒项目来源于 ElasticJob 的事实，假装原创，但由于它是一个 fork 项目，所以必须按照协议要求，保留原始版权声明，而不是只在结尾致谢。

整件事情对于开发者来说很有教育意义，尤其是在做开源开发时，必须要了解开源协议。开源软件本身的存在就是为了给用户自由，开源协议虽然各有不同，但最基本的要求往往都是尊重软件版权。

Saturn 没有正确保留版权声明，致使目前所有版本都不合规，对自己和使用它的项目都造成了一定的影响。

近期也有一例不符合 Apache 2.0 协议引发的事故。6 月，云计算解决方案服务商博云，因为使用了 SkyWalking，却未按照 Apache 2.0 协议的要求，在显著位置说明项目使用了 SkyWalking，被 Apache 基金会披露。事后博云方面回应称，他们对外一直公开说是基于 SkyWalking，并没有把 SkyWalking 装扮成自己产品的意思，“我们这次干事干的粗糙了。”

从 Saturn 的库和博云的回复来看，两件事或许都是不懂协议造成的。

两件事涉及到的 Apache 2.0 协议是 ASF 在 2004 年发布的，属于宽松型协议。今年 5 月，《大教堂与集市》的经典中文版本译者卫剑钒用一句话总结了 Apache 协议的要旨：“要留我的名，改哪了你得说！”，并解读 Apache 协议精要：

你可以随便用！不会因版权和专利找你麻烦的！

本作品就这样了，我不会负任何责任的！你想负责你可以负，但别拉上我！

“授权只是给你使用，并不是授权无限制地剥夺人家的著作权”，吴晟表示，fork 了别人的东西时，不能改掉别人的 License 声明，这应该属于强制性的东西。

实际上，声明版权只是协议的一项基本要求，一些更严格的协议，如 GPL 会要求采用了 GPL 协议软件的整个软件包也必须开源。现在，通过 OSI 认证的协议已有近百个，虽然这可能会使开源软件的使用变得复杂，但也保障了开源软件及其作者的基本权益。违反开源协议轻则会被公开批评、重则会导致项目因合规问题无法登上更大的开源舞台，甚至有可能引发诉讼。

开发者在使用一个开源软件时，首先要做的，或许就是去了解它的开源协议。