从Copyright到Copyleft，聊聊版权与开源协议
4月26日是世界知识产权日，很多人或许会觉得这和软件开发没什么关系，但事实上，开源软件大多受到知识产权法中著作权法（Copyright，也称版权）的保护。
开源软件虽说开放了源代码，但是用户在使用、修改、再发布时，必须要遵守软件中规定的开源协议（也称开源许可证/开源License），否则可能构成侵权，惹上官司。
随着计算机软件的激增，其著作权保护愈发重要。同样在26日，《中华人民共和国著作权法修正案（草案）》提交十三届全国人大常委会第十七次会议审议。
修正案中有多处直接涉及计算机软件的修正：如在第十条的出租权中明确包含计算机软件的原件或者复制件权利；修正后的第五章“著作权和与著作权有关的权利的保护”中，第四十八条处加入对计算机及其系统或者网络的完全性能进行测试条例。
虽然修正案还未最终确定，但这也显现了加强软件法律保护的趋势。今天，我们就来谈谈计算机软件开发、使用中涉及的一些权利问题，以及这些问题的源头和当下的新争议。
Copyright 和 Copyleft：开源著作权和开源协议
提到 “Copyright”，大家可能还会想到自由软件之父 RMS 提出的“Copyleft”反版权思想。“Copyleft”最初是为反对商业软件而生，但它并不是放弃版权，“Copyleft”中的“Left”，不使用英语中“保留”的意思，而是指“Left（左）”，与“版权（Copyright）”中的“Right（右）”具有镜像的关系。
二者的区别可总结为：“Copyright”指软件的版权和其它一切权利归软件作者所私有，用户只有使用权，没有其它如复制、重新修改发布等权利。而“Copyleft”的特点是仅有版权归原作者所有，其他一切权利可以与任何人共享。
首先，计算机软件作者都可对自己的作品享有著作权“Copyright”。
著作权源于信息时代早期，最初指印刷出版之权，是印刷术发明催生起的复制（Copy）权（Right）。后来随着科学技术发展，种类渐增，逐渐开始保护文学作品作者权利、作者的表演权利等等。1994年，计算机程序被明文提出应该作为文学作品受到保护，1996年这一规定被世界知识产权组织在全球范围内推行。
注释：1994年4月15日，关贸总协定乌拉圭回合各缔约方在马拉签署了《与贸易有关的知识产权协议》（TRIPS），其第十条规定：“计算机程序，无论是原始资料还是实物代码，应根据《伯尔尼公约》（1971）作为文学作品来保护。”
1996年12月20日，世界知识产权组织通过的《世界知识产权组织版权条约》（WTC）其第四条明确规定不论计算机程序表达方式或表达形式如何，均作为《伯尔尼公约》第二条意义上的文学作品受到保护。
这为国际件计算机软件版权保护提供了统一的标准和依据。
其次，开源软件作者在拥有著作权的同时，还可以自由决定如何与别人分享自己的作品，这便是“Copyleft”所提倡的理念，也是受开源许协议所保障的权利。
“Copyleft”通常被译作“著佐权”，即通过许可证的形式，补足、辅佐著作权（Copyright）不足的版权授权，相当于一种权利与义务的契约。RMS 1983年9月创建 GNU 项目，1984年发表《GNU 宣言》，抨击封闭源码行为，也创造了“Copyleft”一词。
“Copyleft”思想脱胎于 RMS 的知识产权观——他认为知识产权是一种社会赋权，权利人应该被允许通过契约的方式，自由转让软件权利，如复制、修改、再发布的权利。所以 RMS 提出，自由软件在承认著作权的基础上，可以通过许可协议，与公众共享作品的其它权利。
1989年，RMS 与一群律师起草了世界上第一个开源软件协议——GNU 通用公共协议证书（GNU General Public License, GNU GPL ）。证书的序言体现了“Copyleft”的思想。
一是承认软件的著作权；二是提供许可协议，来获得复制、发布、修改的法律许可。用户可以获得权利人通过许可证放弃的权利，但也必须遵守许可证的规定才能行使，如果不遵守开源软件规定，便是侵犯了开源软件著作权，其著作权人就有权要求对方停止相关行为及其他。
至此，“Copyleft”一词有了实际载体。而这也是现在开源许可协议既可以保护开源软件作者著作权，又可以为开发者提供修改、再发布权利的法律思想源头和基础。
开源软件及协议的发展
基于“Copyleft”思想的 GPL 现在是使用最为广泛的许可证之一。
这个许可证在开放源代码的前提下，几乎可以说是“最大程度”地限制了使用者——它不仅要求用户再修改的软件要开源，而且如果用户将 GPL 许可证下的软件添加入专有软件，那么新组合的软件也应当全部适用于 GPL 许可证，也就是说，组合里所有的软件都必须开源。
因此，GPL 被称作是带有“传染性”的许可证。越来越多的开源软件支持者认为，我们应该向更加宽松的许可协议靠近，不应该在许可协议上做过多限制。
但 RMS 认为，GPL 才是真正保护了所有使用者的自由。因为 GPL 协议可以规范使用开源软件的用户继续开源，从而维护源码开放使用的自由。
RMS 是自由软件运动的领导者之一，被称为“自由软件之父”。在组织人力起草 GPL 协议之外，他最为人们津津乐道的成就还有创建 GNU 项目以及成立 FSF 自由软件基金会。
现在我们常说的 Linux 其实是指 Linux 内核加上 GNU 套件，即 GNU/Linux，这是全世界尤其是超级计算机中使用率最高的底层操作系统。RMS 曾向媒体要求，在采访他的时候，要用“GNU/Linux”称呼操作系统，而非 Linux。
RMS 执着于解放软件，一直致力推动软件和世界自由，这让外人觉得他脾气执拗古怪。也有人问他，参与自由软件运动多年，到底收获了什么。他说，“我比较感兴趣的是，世界得到了什么。我对我的人生很骄傲，因为我人生的一半，都在为自由奋斗，抵制人们做不自由的事，虽然我们还没达到胜利的目标。”
这个“胜利的目标”，在很多开发者看来，是不切实际的。1998年，Eric Raymond 发表《大教堂与集市》一书，为开源奠定文化理论基础。Raymond 以及他的追随者认为，RMS 和 FSF 在推动自由软件的时候，受意识形态影响太深，与现实脱节。而为了自由软件尽可能大范围地取得成功，应该侧重提供源代码的实用价值，而不是过多的讲究共享和道德哲学。
很快，Raymond 邀请了十几个自由软件社区著名成员开会（当然，不包括 RMS），讨论决定用“开源软件”来代替“自由软件”。1998年，Raymond 和 Bruce Perens 成立了开源促进会——OSIA，这个组织后来主导了开源运动，并定义了开源软件，其中也对许可协议做了一定规范：
OSD：自由再发布；以源代码的形式再发布；派生作品，即使用同款开源软件协议，不同协议之间也可以兼容；作者源代码的完整性，自己修改的程序用不同的版本号与原始的做区分，软件用户有权知道作者是谁；个人或团体不受歧视；开源软件程序可以被使用在任何领域再发布许可协议，新增软件不得添加新的条款；许可证不得只用于特定产品；许可证不得限制其他软件；许可协议必须是技术中立的。
随着开源运动的扩大，以及开源软件定义的明晰，许可协议对开源软件的促进、保护作用愈发凸显，其种类也在不断增加。《大教堂与集市》的译者卫剑钒在近日发布的一篇文章中，形象道出许可证的机制和作用：
我允许你们XXX，我许可你们XXXX，你们可以XXXX，但是，你们必须XXXX，如果你们XXXX了，你们就必须XXXX，对了，对于XXXX这些情况，我可不负责。
你要同意，就用，不同意就别用。如果你用了，但违反了许可证的要求，我可能会告你啊！
国内近期有一起计算机软件著作权诉讼案，涉及开源软件和许可协议。2019年12月，北京高级人民法院对被告柚子（北京）科技有限公司、柚子（北京）移动技术有限公司、与原告数字天堂（北京）网络技术有限公司侵犯计算机软件著作权纠纷做出终审判决。
起因是两被告公司的 APICloud 软件复制及修改了原告数字天堂公司 HBuilder 软件中的三个插件，这些插件采用了 GPL 协议。如前文所述，按照 GPL 的规定，只要使用了 GPL 下的软件，就必须全部开源，但 APICloud 并没有全部开源，于是引发诉讼。
最终，法院认定，柚子科技公司、柚子移动公司的 APICloud 软件复制及修改了数字天堂公司 HBuilder 软件中的三个插件，侵犯了著作权人数字天堂公司对软件作品享有的复制权和修改权等权利，判令被告停止侵权并赔偿71万元。
此案是中国 GPL 诉讼第一案，其判决被认为对开源软件诉讼实践有重要意义，这对之后类似案件的审判有较高参考价值，对国内开发者使用开源软件也有指导意义。
国际上在实际判例中承认开源许可协议的法律效力来得更早。2008年，美国联邦巡回上诉法院首次在判决中主张了开源许可证的著作权协议。原告 Bob Jacobsen 采用 Artistic 许可证，发布了自己的开源软件。被告 Matthew Katzer 使用了该软件，但是却未履行许可证中规定的著作权声明义务。最终，被告被认定违反 Artistic 许可证的行为是侵犯了原告的著作权。
声明作者的著作权，基本可以称作是开源许可证的“入门级”协议，在此基础上，许可证还规定了使用者是否可以将其拿去商用、是否可以打着原作者的名义营销等等。此前，有人将较为流行的几种许可证做了一个划分：
上图中的几个许可证仅是目前较为流行的，在这之外，通过 OSI 认证的许可证还有近百个。一项调查显示，许可证逐渐被认为是开发人员在决定使用某个开源项目时最需要考虑的事项，因为没有开发人员愿意在不知道接下来将如何发展的情况下，开始使用新的软件包。
许可证种类和规定的多样性导致软件合规变得复杂，不过目前已经有一些工具可以初步降低这一门槛，比如 Linux 基金会推出的许可证使用规范工具 ACT、Gitee 的许可证引导功能。
一些争议
在软件开发过程中，围绕软件法律保护产生了多种争议。
一方面，许可证应该规定哪些权利义务、应该走向宽松还是限制被广为讨论。另一方面，人们是否应该为软件的设计思想申请专利也引发了开发者之间的对立。
许可证种类渐增的当下，人们愈发渴望更加宽松的开发环境、和更简洁的协议。大量软件从限制性许可证转到宽松许可证。
Blackduck 数据显示，从 2009 年到 2015 年的六年间，宽松型 MIT 许可证的份额上升了15.7%，Apache 的份额上升了12.4%；而 GPL v2 和 v3 的份额则下降了21.4%。GitHub 2015年发布的许可证使用情况报告显示，MIT 协议使用率最高，两年前的一项研究也得出了同样的结论。
然而，追求宽松又带来新的问题。
MIT 是现在使用最广泛，又最为宽松的许可证。开发者只要保留原作者的版权和许可，便可以随意使用，包括出售源码。这时，原开发者就可能会面临“别人都能拿着我的软件出去售卖，我徒留版权有何用”的窘境，此刻大概只有用“自由与分享”的理想做注解了。而如果想避免这种状况，开发者可以更换更为严格的许可协议，或者不开源。
此外，近年还出现开源公司被云厂商“寄生”的情况，云厂商直接将开源厂商的开源能力作为云环境下的商业服务，而不回馈开源社区，挤压开源厂商业务，致使其陷入生存困境。这迫使许多开源软件又从宽松型许可证转向更严格的协议，甚至直接闭源。
更有甚者，认为开源软件应该脱离现有的著作权法，拥有一部属于自己的《开源法》：以著作权法为主的知识产权法是后工业时代和前信息时代的产物，它赋予人们对其创造出来的信息—电影、软件等作品、发明等技术方案、产品设计—进行垄断的财产权。但软件存在的意义应该是作为解决实际问题的工具，真正核心的特点是工具性、功能性，而非表面上的作品性。这时就不再适用著作权法，而是应该新建《开源法》。
实际上，除了著作权和许可证，还有一部分软件，尤其商用软件可以同时受到专利法的保护。我国法律规定，计算机软件专利保护期限为从申请日起算20年。著作权保护期为作者有生之年加死亡后50年；法人及其它组织的作品，其法律规定的相关著作权的保护期为50年。
区别于著作权对软件本身的保护，专利权保护计算机软件体现在保护软件的设计思想。比如，一个软件构思，可以通过不同的编程语言来实现。著作权保护的是已经写出来的整套编程，而专利权则保护编程语言背后的构思。
所以，一个软件可以同时享有著作权和专利权，开源软件也可以在开源之前，先为软件设计思路申请专利。
一些开源协议允许开源软件享有专利权，如 Mulan PSL v2第2条规定：每个“贡献者”根据“本许可证”授予您永久性的、全球性的、免费的、非独占的、不可撤销的（根据本条规定撤销除外）专利许可，供您制造、委托制造、使用、许诺销售、销售、进口其“贡献”或以其他方式转移其“贡献”……Apache 2.0等开源协议也有类似的规定，而诸如 MIT 的一些协议，并未涉及专利问题，其是否存在默示的专利限制，还有待解答。
为软件申请专利的流程更为复杂，但是其法律约更多，对软件开发和共享造成更大阻力，因此催生了反软件专利的运动。
反软件专利的支持者认为，软件创新也不需要外界强力来推动，即不需要专利法去刺激创新。
这也引出了以上争议背后的焦点问题——究竟什么样的知识产权保护，才能最大程度推动整个计算机软件世界的创新与发展，而不是仅仅关注当下，或者某个体的既得利益？