从转载阿里开源项目 Egg.js 技术文档引发的“版权纠纷”，看宽松的 MIT 许可该如何用？...

作者 | 苏宓、彭慧中

出品 | CSDN（ID：CSDNnews）

开源迅速发展的这两年，很多内部问题逐渐凸显出来，如安全、版权、协议使用等。

近日，来自V2EX社区中一位开发者 @an168bang521 发布的一篇题为《想问下懂法律的老哥们，摘抄阿里开源软件 Egg.js 技术文档内容算不算侵权》的文章，引发开源届不少开发者的热议与关注，当项目团队成员发布的技术文档所遵循的开源协议遇上文章版权，该遵循哪种使用规则？其二者是否会有冲突？外部的开发者怎么做才是合法合规？又该如何避免开源项目的开发者和开源使用者之间的矛盾？

为解答这些极具争议的问题，CSDN 开源直播栏目《开源圆桌派》邀请到 OSCAR 开源共读发起人、LF APAC 开源布道者团队主席李建盛（适兕），《大教堂与集市》译者卫剑钒，Zilliz 合伙人&开源布道师顾钧，以及开源之道北京活动主持人、开源爱好者郁志强，从法律、许可使用的角度分享开源协议 MIT 的具体使用，帮助更多的开源开发者“普法”与“避坑”。

转载技术文档引发的侵权争议

想必很多前端开发者，对于阿里巴巴团队研发的企业级 Node.js 框架 Egg.js（以下简称 Egg）并不陌生。截止目前，Egg 在 GitHub 上 Star 数为 17.9k，Fork 数为 1.7k。在研发之初，其开发团队的愿景便是希望“由 Egg.js 孕育出更多上层框架，帮助开发团队和开发人员降低开发和维护成本”。

今天的争议点也是围绕开源 Egg 技术文档的使用展开。

首先，回顾事件始末，还要从 2018 年开始说起。

2018 年 4 月 5 日，作为 Egg 核心开发者之一，“天猪”（昵称）在知乎上发布了一篇关于 Egg 的使用指南帖子——《当 Egg 遇到 Type，收获茶叶蛋一枚》（https://zhuanlan.zhihu.com/p/35334932）。其内容详述了使用 TypeScript 开发 Egg 过程中遇到的一些影响开发者体验的问题，并附上了开发规范和问题的解决方案。

此内容发布之后，吸引了不少 Egg 框架使用者的点赞与分享，仅是在知乎平台上，这篇文章的点赞数达到了 270+。

由于这篇文章反响不错，Egg 项目团队觉得可以将其集成到官方文档中。于是不久后，这篇文章合并到了 GitHub Egg 的官方文档中（https://github.com/eggjs/egg/commits/2.29.3/docs/source/zh-cn/tutorials/typescript.md）。

没想到，“隐患”也就此埋下。

四年之后的 5 月 26 日，正如文章伊始所述，开发者“an168bang521” 在一篇帖子中提到，自己收到了一个知乎用户委托公司的邮件，告知自己的个人网站擅自使用了知乎的作品，侵犯了知乎的信息网络传播权，并要求采取相关的补救措施。

an168bang521 被告“侵权”的内容，正是天猪的那篇《当 Egg 遇到 TypeScript ，收获茶叶蛋一枚》及同样发布在 GitHub 官方文档上的内容。

在收到“授权委托书”时，an168bang521 感到十分不解，其表示，“网站文章来自 GitHub Egg 仓库以及 Egg 官网，且 Egg 使用了 MIT 许可协议，该协议允许任何人使用和操作代码，自己也是在这个协议下进行操作的，因此不算侵权。”

通过邮件沟通，对方给出的回复是，「该篇内容的版权方属于天猪在知乎上的个人账户，而他是以个人身份告这位网友」。

值得一提的是，GitHub 上的 Egg 开源项目使用的是主流的开源许可之一的 MIT。相对其他常见的 GPL、BSD 等软件许可协议，MIT 更为宽松，其允许任何人免费获得软件和相关文档文件副本的许可，不受限制地处理本软件，被许可人有权利使用、复制、修改、合并、出版发行、散布、再许可和/或贩售软件及软件的副本，及授予被供应人同等权利。

那么问题来了，一边是需要遵循发布的媒体平台协议，一边是需要遵循 GitHub 平台上 Egg 所使用的 MIT 许可，同一篇内容发布在两个平台时，到底应该依据哪一种平台规则呢？

an168bang521 也在帖子上表达了他的疑惑：“以个人的身份告我侵权，是否属于维护他的正当权利？如果是属于走着正当权利，我可以把文章删掉，甚至我还可以专门写一篇文章挂在首页上赔礼道歉。”

作为另一当事人，天猪则显得有些被动，其表示，自己是在 an168bang5 发布帖子的第二天在被各路网友“讨伐”中，才知道自己身处“舆论的漩涡”。由于邮件是因为该专栏是授权给媒体平台了，自然也使用了该平台的版权服务，当它检测到文章被未授权就被转载时会自动发送侵权通知，而自己本人并不知情。

他表示，“这么多年来，遇到希望转载的人，他基本上都是免费授权的。唯一的要求就是：事先通知过他本人获取授权，并注明原文出处，不要破坏文章结构以及加太多广告。”针对此次事件，他并不想追究侵权。

而开发者 an168bang521 也表示发帖的目的并非针对文档作者本人，因为 MIT 争议空间较大，涉嫌侵权的内容目前已经做了全部删除和下线处理。

仅有 40% 的开发者知道不同开源协议之间的区别

至此，两位开发者之间关于侵权一事已达成和解，但是这件事给其二人心中都留下了一些疑问。

来源：an168bang521 帖子

来源：天猪帖子

事实上，这也不仅是这两位开源开发者的顾虑，据 CSDN 发布的《2021-2022中国开发者调查报告》显示，当问及开发者，对开源协议了解有几何时，发现近三成的开发者仍然不懂开源协议。在进一步探究时，仅有 40% 的开发者知道MIT、GPL 与 Apache 开源协议的区别。

这意味着绝大多数开发者处于模糊和完全不懂的迷茫中，这同样引发了我们的反思与思考。在本期《开源圆桌派》直播对话栏目中，来自 4 位开源届的一线专家也将为我们深度揭晓开源协议的普及现状与使用的那些事。

郁志强：当前开源社区成员对开源许可的了解情况如何？

卫剑钒: 开发者成长为开源开发者，这是一个需要不断普及的过程。一开始很多人版权意识比较弱，也不去看很多开源许可证，而后经历很多诸如此类的事件，从而不断地了解与学习，久而久之，大家才会有这样的意识。就开源领域而言，在我们的学校教育以及工作的文化教育体系中，往往都缺乏版权意识培养，导致不了解的人很多，这个属于正常现象，也希望以后会越来越多的人了解版权、许可的知识。

顾钧：我们的项目是用 Apache 2.0 进行开源的。开源的时候，在 GitHub 上整个项目的代码仓库包含了软件本身以及文档，同时也涉及一些技术 Demo。这些 Demo 有时候可能是一篇技术文章，其中会包含代码和脚本，让初使用者可以跟着一步一步地复现 Demo 中涉及的案例。这意味着整个代码仓库所包含的内容，不仅仅只有代码，还会有文档、博客、测试报告等。

然而，这样做往往会带来一些问题，就 GitHub 网站而言，由于信息显示方式的影响，当开源开发者提交代码时，页面可能就显示了最初创建代码仓库时所选择的主要许可。但是，在提交过程中，代码仓库有好多不同的目录，每个目录可能都有不同的协议，有的项目也会引用一些第三方的项目，而第三方项目所遵循的协议可能是 MIT、LGPL，不一定就是 Apache 2.0。

其实当前很多开发者也会存在误解，即当他们看到 GitHub 上显示该代码仓库是某一种协议时，会误以为里面包含的所有内容都是遵循这样的协议。事实上并非如此，代码仓库的每个目录下面都有可能是不一样的协议。因此，当我们浏览或使用尤其是综合性的代码仓库时，都需要留意一下所引用的内容，情况往往比较复杂。

郁志强：在同一代码库中，我们是不是可以选用多个不同的协议，在同一个项目的代码和文档以及相互的约束之前，在一些系列协议里是否有相关的规定呢？

卫剑钒:  虽然这种我见得不多，但在大型项目中会存在这种情况。当一个项目中存在不同的模块、文档时，应该用显著的方式将使用的不同协议标注出来，而不应该让开发者自己去查找。不过，现实情况下，大多数项目还是以单一的协议居多，另外即使是项目中引用了第三方模块，建议开发者能够明确说出来，原来所遵循的协议是什么，兼容以后使用的协议又是什么，这样都是可以的。

如何避免潜在的侵权事件发生？

郁志强：代码仓库怎么构建，怎么确定协议？

适兕：开源，大家最倡导的一个理念就是开源是一个来自全球协作的集体产品。所谓集体产品，作为编程人员都知道，最终是以某一个文件的方式去展示某个作品的许可，其中的许可就是指作者希望别人如何去使用。

从协作的角度，如果软件各部分不冲突，整体就可以使用一种授权方式，又或者可以让大部分的文件使用某一种许可，小部分使用另一种许可。事实上，软件每一个版本都可能重新发布许可，当然这个很少见，但如果你去观察，你会看到例如像 Python 编程语言这样的庞大项目中，每隔一个大版本就会重新定义一下自己使用的协议。因此，作为开发者，在构建代码仓库时，可以先对软件项目的过去历史要有所了解，因为很多项目是一个多人协作的产物。

郁志强: 在上述事件中，开发者 an168bang521 这样转载的行为，以及版权是如何判定的？

卫剑钒：从他们各自发表的文章中可以看出来，这位开发者原先没有说明文章来源，直接复制粘贴他人的文章，这种做法有些欠妥。即使文章是在 MIT 协议下发布的，但也需要注意 MIT 协议是有前提条件的，即注明版权信息，而且还需要附上 MIT 协议。这样的做法才符合 MIT 协议的要求，显然在事件中，原开发者有些步骤缺失了。

顾钧：大家可能在实操层面都会误认为：只要是在 MIT 协议下发布的内容，就可以非常自由地去分享，但实际上并非如此。在开源世界当中，我们经常可能会用双重许可的方式去发布同一个内容，比如这篇文章在 GitHub 上遵循的是 MIT 协议，而在知乎上遵循的是更为严格的 CC 协议（知识共享许可协议，Creative Commons license，又叫 CC 协议）。如果想要用更为自由的 MIT 的方式去转载内容，就必须要很明确地表明这是在 MIT 协议下分享的，不然可能就会造成误解，会被误认为违反了更加严格的 CC 协议。

还有例如像 Mexico 这样的开源项目，它既有 GPL 同时也有商业版的 License。有些公司在使用过程中可能做了 Mexico 的二次开发，但依旧想保持闭源的状态，那么其可以通过购买商业版的 License 使得自己二次开发之后保持闭源。因此，一个项目有多个许可是完全有可能发生的，同时我们也需要注意自己是在哪个许可下使用所需要的内容。

相对宽松的 MIT 协议究竟应该怎么用？

郁志强：MIT 协议里允许的操作空间是什么？是否可以不经过原作者同意直接使用 MIT 协议下的文档？

卫剑钒：MIT 协议一共包括三段说明：

• 第一段表达的是如果你满足我的要求，你就可以拥有使用、拷贝、修改、合并、发布等这些操作的权利，但前提是必须得满足协议中的条件；

• 第二段所注明的条件就是需要附上版权信息及 MIT 协议。事实上，使用者附上 MIT 协议全文或者附上 MIT 的链接都可以的。

• 第三段有个很重要的部分就是免责声明，它明确了这个软件是“AS IS”的，“AS IS”的意思就是“就这样的”，售出 ( 或免费提供 ) 后一概不负任何责任，“别再找我，就这样了”，简单来看，就是如果出了问题可以让原作者免责。

MIT 其实非常宽松，操作也非常简单，但要求就是要把版权方和这个协议放上去。我在《从 MIT 协议谈契约精神》一文中，也详细地翻译了 MIT 协议的说明。

郁志强：开源中的协议和版权是否是有冲突呢？

适兕：最近写《开源之史》的过程中，我查阅了很多资料，给大家分享一下。其实 MIT 协议是所有开源协议里最早的一个协议。1973 年，当软件被纳入到著作权的范畴以后，倘若想要让软件在市面上流行，就必须写协议声明。因此就诞生了最早的 MIT 协议。

版权的发明在开源协议前，可以追溯到 18 世纪、19 世纪。自从文艺作品如雨后春笋般冒出后，版权的立法也应运而生并逐渐趋于完善。而开源协议在几百年后才出现，是建立在已有的著版权基础之上的，它没有否定我们传统的版权。不管是 MIT 许可，还是 GPL 许可，包括后来的 Apache 许可等，都是在版权的基础上另外加入了软件的特性，比如可以分发、复制、修改等，所以许可协议可以看作是版权之上的一个扩展。

郁志强：从 License 运用的角度来说，MIT 协议的使用方面是不是也有可以改进的地方？

适兕：其实文档对于一个项目来说很重要。我建议用户手册、产品说明等这些文档应该跟项目代码分离开，并采用不同的许可来授权。并且，从一个商业角度考虑，你甚至可以把项目文档用来卖钱，因为开源软件是不收取许可费的，但可以收取成本费或培训费，最初最早的商业模式就有通过把文档拆出来，从而进行商业化活动的。这样的模式给我们的启发是：我们把软件项目和把文档说明分开做成不同的项目，并配以不同的许可，这样或许对所有人来说都是有好处的。

卫剑钒：能分开固然很好，但我看了此事件中涉及的项目，它没有分开且估计也不太好分开的。但如果作者能够明确地说明，我的代码都是用 MIT 协议来声明，而文档全都使用 CC 协议，可那也是完全可以的，当然这还得看作者自己的想法。不过，目前 Egg 项目与很多项目一样，其代码仓库中既有代码也有文档，这也很正常，但是文章内只有一个许可的话，我们只能认为它的代码与文档都是用 MIT 这一个许可协议。

一般来说，我们常见的开源许可更多地还是针对源码做束缚，虽然许可上称适用于源码以及相应的文档，但它关注的主体还是代码，它不像 CC 协议这样主攻文档，通过此事件，我觉得以后可能会有更多的作者注意到这个问题。事实上，项目中的文档更多还是和代码密切相关的文档。上述案例中涉及到文章文档也不太像是一个和代码无关的，也无法能够做到与代码完全脱离开的一个文档。

顾钧：我认为那篇技术文章，其实用 CC 或者 MIT 协议都可以。但有时，出于原创内容在搜索引擎上的排名角度来考量的话，很多原创作者都希望自己的排名能够在搜索引擎上更靠前一点，而对于这种诉求，不管是在 MIT 协议下还是 CC 的协议下，尽管转载人按照许可的规范来做，但搜索引擎也不会理会这一套规则。所以，如果想要采用一种让大家都满意的转载方式，就需要你在 HTML 当中设置原文链接，这样，搜索引擎也能知道这是转载，那么原文的权重排名就会更高一点，我觉得这种情况下原创作者也会更满意。​​​​​​​

开发者如何培养自身版权意识？

郁志强：或许大家的版权意识还有待提升，大家怎么看待这个问题？

适兕：这个问题引发的辩论是：开源的内容到底存不存在剽窃一说？

我认为这是存在的。

作为一个现代文明的受益者，我们所有的接触的知识，其实都是前人留下的。当前所塑造的东西，几乎都是从前辈手里学来的。那么，从哪儿来学到的内容，把原著标出来就好了。这就避免了剽窃的存在。因为开源并不是“无主”的开源。尽管有些成果放在公有领域，那也是有原作者的。使用者应该保持一个敬畏之心，引用别人的内容，不管是一个词或者是一句话，都应该注明出处。

卫剑钒：我觉得这个是一种素质的养成。大学生写毕业论文的时候，一般都会要求在最后附上参考文献，因此这个是一个基本素质。例如我翻译《大教堂与集市》的时候，也学习了很多别人的内容，但我在翻译时，我会用全新的语言，加入了自己的理解来编写，而不会把别人东西成段成段的抄上，那样可能就会侵犯版权。有了版权意识，你就不会犯这样的错误。本质上这是一种风险意识，放在企业当中就叫做合规意识。

郁志强：大家是从什么时候开始有版权、许可意识，又是如何培养这种意识的？

适兕：我认为，当我不想跟别人一样，并且有意愿去做原创作者的时候，便自然而然地形成了尊重版权的观念。因为你不想被别人侵犯版权，那么首先自己就应该遵循这套规则，不去侵犯别人。想要别人尊重你的前提是先懂得如何尊重他人。在选择成为一个创作者的时候，大家就应该懂得，尊重创作者的方式就是要尊重他的版权。

郁志强：作为开源领域的从业者，应该怎么去更好地掌握和了解版权协议？

顾钧：在我的工作中，一方面会引用别人的代码库，另外一方面我们的代码也会被别人引用。所以我们可能会更关心协议这块，并且会梳理这些代码库的许可协议以及它们的兼容性，同时还要保证我们自己的项目始终能以 Apache 2.0 的协议发布。

因此，当开发者使用一些新的开源软件时，第一步除了评估代码质量之外，还要根据自己的情况评估不同许可证的要求和所要遵循的义务。以我们这些云服务公司为例，我们会基于开源软件去构建自己的云服务，也会有一些开源软件对商业模式有限制。

因此，当你使用这些软件的时候，要弄清楚究竟要拿它来做什么，这样就不容易违反别人发布代码所使用的许可证。

郁志强：不久前，软件自由保护协会（Software Freedom Conservancy，SFC）起诉北美电视厂商 Vizio 获得成功，法院判定 GPL 既是许可也具有法律效力。在大家看来，未来 GitHub 上的许可是否可以作为法律依据？

卫剑钒：我认为是可以的。在国内也有很多判定许可是一种合同，法律基本上认可，因此这份“合同”具有法律效力。如果违反合同上的条款被起诉，肯定会败诉的。

顾钧：开源的许可证是符合合同的基本要素，当然它和我们传统意义上认为的合同的差别在于：传统意义上认为要达成一个合同，需要双方签名，才能确定合同生效。但是在开源许可及 CC 许可的模式下，尽管看起来大家没有签合同，但这个合同是存在的。当你开始使用这个许可下的内容时，就默认要去遵守这份合同的要求。

郁志强：作为过来人，大家对新时代下的开发者有什么样的建议？

适兕：我觉得我们需要转变观念和心态。时代不一样了，我们不仅仅是尊重别人定的许可，更重要的是思考如何加强交流和提高创新。开发者人人都要有“领导者”的意识。

开源许可中的哲学就是鼓励创新、鼓励交流。当你能够提交一个好的模块，甚至是在下一个版本中成为“领头羊”时，就会发现自己贡献得越多，收获越多。开源许可本身的规则不是去防范什么，也并不是筑了一道高墙来阻止大家学习与进步。

在这个时代，我们必须进行团体作战，也必须让知识“流动”起来。这时，你的署名是你在这个团体中获得别人尊重的关键。GPL 以及 MIT 等许可为什么伟大？是因为它们鼓励我们团结协作。我们拥抱开源、尊重这些许可的哲学，就是需要成为团体中的贡献者，并以一个积极的心态去倡导这些规则。如果你想投机取巧，那么就会因为这个规则而受到“诅咒”。这个规则的厉害之处就在于，如果你是想把别人的东西占为己有，那么你就将被这个开源世界所抛弃。

顾钧：今天，软件发展得如此迅速，和开源软件的大规模的普及，以及大家都愿意加入到开源社区当中是分不开的。对于我们国家来说，在软件相关的关键技术或者关键产品上还可以进一步提升。在这种情况下，希望我国的广大的开发者都能够积极参与到国际的开源社区当中去，去提升我们国家在开源技术方面的影响力以及领导力，在国际舞台上大放异彩。

参考链接：

https://zhuanlan.zhihu.com/p/520119900

https://www.v2ex.com/t/855289