短语 “开放源码许可证”由许多协议组成，这些协议广泛而公平地授予了版权（软件本身固有的）许可证，并尽可能地降低了限制。本文是本系列两篇文章中的第一篇，描述版权的宗旨，并解释开放源码许可的意图。本系列的第二篇文章探讨了个别的许可，比如 GNU Public License 和 Apache License。本文是本系列两篇文章中的第一篇，描述版权的宗旨，并解释开放源码许可的意图。本系列的第二篇文章探讨了个别的许可，比如 GNU Public License 和 Apache License。
       
这不是法律意见
本系列旨在向读者介绍开发源码许可的基本知识。不管是开放源码许可还是版权，在法律上都还不是固定的。在本系列文章发表之后，它们都还会不断发展演变，从而纠正本系列中的一些废弃或错误的细节。
此外，发表本系列文章所涉及的作者或编辑都不是经过许可的律师。本系列没有想要作为法律意见。因此，您在作出关于版权问题的决策之前，应该向律师咨询，而不要根据本系列中的信息进行决策。

在 17 世纪，英国政府就面临了海盗的不断威胁。事实上，在不到 10 年的时间里，Barbary Coast 海盗就抢劫了近 500 艘商船，霸占船只，将船员和乘客卖为奴隶。这些盗贼肆无忌惮，经常掠夺甚至残杀沿海的居民。
但是，海盗并不是当时惟一的盗贼。1436 年 Johannes Gutenberg 发明的活字印刷术大大简化了书本的印刷和盗版。利用活字印刷，苏格兰剽窃者大肆 “掠夺” 英国书商，以低于原来价格 30-50％ 的价格大量出售盗版。
所以，到 1662 年，就有了许可证法（Licensing Act），1710 年，安妮法令（Statute of Anne）对之进行了改进，1774 年，Donaldson v. Beckett 做了进一步的阐明，英国国会提出了 “版权” 的很多现代概念，版权授予作者或者创造性作品的所有者 某些专有的权利。
具体来说，国会提出了 “版权” 作为复制的权利。安妮法令规定，只有作者或者作者适当指定的代理可以在某个特定的（实际的）印刷厂重印某本特定的书籍，然后再销售给公众。实际上，“版权” 授予作者一个合法的专利权，其他人未经授权而重印书籍就是违法。
但是为了折中 1662 年许可证法对作者的过分偏袒，安妮法令的制定者们选择了把作者的专利权限制为 21 年。有了 Donaldson v. Beckett 中的这个期限，安妮法令认为，在 “版权” 过期之后，相应的作品就变为不受限制的了，即一般的公众都可以自由利用，任何出版商也可以自由复制。换句话说，在作者的 “版权” 过期之后，作品就进入了 “公共领域” —— 这是 1774 年之前所没有的一个新的引人注意的概念。


版权（仍然）是基本的
现在，安妮法令成为法律已经近 300 年过去了，版权的基本宗旨仍然是相同的，作者版权成为创建新作品必不可少的推动力。实际上，版权自 1720 年以来不断进行大的扩展，以包含新兴的技术，从而保护各种创造性作品的革新，保护作者合法的专有权利。
例如，1886 年的 International Copyright Act 授予作者翻译作品的专有权利，1911 年的 British Copyright Act 把版权扩展到保护录音带和建筑作品。（类似地，美国 1909 年对 Copyright Act 的修订，将版权扩展到保护音乐以及所有原创作品。）更近一点，1976 年美国对 Copyright Act 的修订，将版权扩展到保护未出版的作品，并编写了 “正当使用” 的条款。1998 年，美国的（受尽诽谤和误解）Digital Millennium Copyright Act 给予船体设计以保护，并允许计算机用户为维护目的而对计算机程序进行临时复制（还可做其他修改）。版权现在保护照片、影视剧本、图像（比如说在 Adobe Photoshop 中创建的）、印刷品、Web 页面、声音效果、电影，等等。
当然，版权现在也已扩展为保护软件，软件也是另一种形式的著作权（尽管宁愿是单独的一种形式）。与保护作家、画家和音乐家的权利一样，版权也授予软件程序的作者某些专有的权利。（版权通常叫做消极权利，因为它限制其他人可以对作品做什么。）



软件开发人员的特权
具体来说，软件开发人员（像其他作者一样）的特权包括：
产生作品副本并销售这些副本的权利，包括电子副本和可执行的二进制文件
创建派生作品 的权利（这样的作品基于一个或多个预先存在的作品，并被认为是原作者的初始作品）
将版权所授予的权利销售或指派给其他人的权利
注意： 版权还给创作者提供其他权利；参见 U.S. Code, Title 17。另外，作者可以是个人，也可以是一个小组。如果是后者，并且作品是整体创建的且旨在作为整体使用，那么该作品叫做联合作品，版权所提供的权利由小组控制。
根据这些权利，软件的作者是软件惟一的所有者，可以全权控制代码如何复制、销售和重用。有趣的是，作者不能放弃版权提供的任何权利。但是，作者可以根据自己的意思选择转移或者许可任何现有的权利，整个地或者单独地。




代码许可
术语许可（license） 本质上就是允许（permission）。版权持有者或者许可方（licensor），授予另一个人或实体 —— 被许可方（licensee） —— 特定的权限使用作品，一般是在一定的期限内、在特定的区域内（比如全世界、北美或者西班牙）使用，并付给一定的补偿，包括金钱补偿。如果补偿中包括金钱，那么许可方可以要求一次性支付，或者特许权（royalty），或者二者的组合。

术语许可 也通常用于指规定许可方与被许可方之间协定的（法律）文档。因此，软件许可（software license） 是一个协定，指出软件可以如何被使用。例如，一个专有软件许可可能允许用户运行程序，但不能查看源代码。

短语开放源码许可 是指很多协定，用于尽可能广泛、公平且具有最少限制地许可软件固有的版权。无疑，您肯定听说过创建于 1993 年的 Berkeley Software Distribution (BSD) 许可，这是第一个开放源码许可。其他著名的开放源码许可包括 GNU General Public License、Apache License 和 Sun Microsystems 的 Common Development and Distribution License。实际上，Open Source Initiative (OSI) Web 站点 上列出了 50 多个开放源码许可。
这些开放源码许可中的每一个都被修改为满足特定种类内容（例如，有些针对软件，有些针对文档，还有一些针对图像或数据）的特定目标，因此术语也各不相同，但是它们都有五个基本意图（摘自 attorney Lawrence Rosen 的 Open Source Licensing: Software Freedom and Intellectual Property Law，并与权限一起使用）：

被许可方可以为任何目的自由使用开放源码软件。
被许可方可以自由复制开放源码软件，并可以自由发布这些副本，无需向许可方支付版税。
被许可方可以自由地创建开放源码软件的派生作品，并可以自由发布这些作品，无需向许可方支付版税。
被许可方可以自由访问和使用开放源码软件的源代码。
被许可方可以自由地组合开放源码软件和其他软件。

正如前面所提到的，作者不能放弃软件中的权利，只能对权利进行转移或许可。这里，所有以单词 “被许可方” 开头的意图声明了，每个特定权限只在许可的条款下被授予。被许可方可以同意条款并接受规定的权限，或者放弃使用软件。
意图 1 很简单，但是它的范围很广，也很微妙。开放源码软件不要求被许可方审计使用、证明任何应用程序，或者记录部署。
意图 2 也很清楚，但是其中没有说出的内容仍然很重要：与意图 1 一样，意图 2 也不阻止开放源码软件的销售。所以，尽管您可以自由地创建并发布副本，但是您也可以不受限制地销售这些副本。
回忆一下，派生作品是基于预先存在的作品的作品，但是仍然被认为是新作品。意图 3 建立于前两个意图之上，确保许可方不会对创建和发布新作品的特权收费，也不会对派生作品强加任何限制。
软件作品的派生作品很少能够在不利用初始作品的底层源代码的情况下创建出来。意图 4 规定，开放源码软件是透明的，可以作为源代码免费获得。
最后，意图 5 建立在前面的意图之上，允许被许可方将开放源码软件与其他软件混合起来。但是更重要的是，意图 5 没有对用户强加限制。用户可以将开放源码软件与其他任何软件混合和匹配。
所有这些意图都是肯定的，不会阻止许可方或被许可方强加附加的条款。例如，许可方可以要求互惠 —— 即被许可方必须根据他同意的相同条款提供软件 —— 并仍然保持开放源码软件。被许可方可以通过销售软件获利。许可方可以在多个许可下提供软件，也许有一个许可是开放源码的，有一个是专有的。无疑，尽管后一个许可不是开放源码许可，但是开放源码许可不排除其他同步的许可条款。
尽管可能有些骇人听闻，至少有 50 个 OSI 已批准的许可，但是这些许可互不相同，以适合许可方的内容、目的和需求。（即使这样，OSI 还是承认太多了，并希望将批准的许可减少到 6 个或 7 个。）GNU Public License 认识到，开放源码软件许可的目标不同于 Apache License，但是两个许可都深深根源于版权（和合同）法，并殊途同归，尽管使用的是不同的方法。



选择版权许可
       
并不是所有的开放源码软件许可都是相等的
尽管所有的开放源码许可具有类似的意图，但是每个许可一般都通过不同的方法达到其自己的目标。一个许可可能会毫无限制地授予权利，而另一个则会有很多限制。换句话说，不会仅仅因为您可以在一个应用程序中下载、编译和链接两个开放源码软件包，就意味着您可以合法地组合代码。在某些情况下，一个开放源码软件许可的特定性可能会与其他一个或多个许可的条款不兼容甚至相反。
本系列的第二篇文章将进一步探讨兼容性问题。同时，在您混合和匹配来自不同开放源码项目的代码之前，请向律师咨询每个开放源码许可。
如果您想要开始一个开放源码软件项目，或者想要在开放源码许可下发布现有的软件，请考虑以下几点：
您的作品在任何方面受到阻碍？例如，您的作品从其他作品交付而来？如果这样的话，作为被许可方，您同意了哪些条款？您能够保证您具有授予给被许可方的所有权利吗？
谁拥有（或将拥有）软件的版权？作品是（或者将是）联合作品吗？
您想要访问您的被许可方的改进吗？如果是的话，您想要互惠如何起作用？
您想要利用自己的开放源码软件卖钱吗？如何做到？
除了这些以外，您还必须考虑很多很多的因素。根据您的项目的范围和规模，您可能想要求助合格的法律顾问，帮助您解决所有的问题。
相反，您可能会发现一个现有的开放源码许可刚好满足您的项目需求。OSI Web 站点上有很多的选择，很多软件公司现在可能已经有了自己的开放源码许可。例如，开发了 Berkeley DB 的 Sleepycat Software 和 MySQL 数据库的创建者 MySQL AB 都创建了 “双重许可”，即在慷慨的开放源码许可条款下向社区提供开放源码软件，并在商业许可下向公司提供获利软件以用于产品和生产环境中。

2006 年 1 月 05 日
开放源码许可为开放的源代码的传播提供法律基础。本系列由两部分组成，本文是第 2 部分，探讨开放源码许可两种最流行的形式，即学术许可和互惠许可，并将描述接受每种许可的条款的被许可方的义务。
       
这不是法律意见
本系列旨在向读者介绍开发源码许可的基本知识。不管是开放源码许可还是版权，在法律上都还不是固定的。在本系列文章发表之后，它们都还会不断发展演变，从而纠正本系列中的一些废弃或错误的细节。
此外，发表本系列文章所涉及的作者或编辑都不是经过许可的律师，作者也不是 IBM 的被许可方。本系列没有想要作为法律意见。因此，您在作出关于版权问题的决策之前，应该向律师咨询，而不要根据本系列中的信息进行决策。
有一个流传很广的传说，说三明治（sandwich） 是 John Montagu 发明的，他是 Fourth Earl of Sandwich。这个故事说，Montagu 整天忙于赌博，连正经吃饭的功夫都没有，所以他把一片烤牛肉放在两片面包之间，以免弄脏手指头和牌。唉，有时候懒惰也能带来发明呀。
不管三明治的这个传说是真是假，但是不可否认，即使最偶然的发明，也可以产生巨大的影响。再想想活字印刷、火药、三明治、内燃机、灯泡、电话、晶体管和 Internet。
无疑，Internet 的发明对于大家尤其是我们这一代来说是体会最深的，这很大程度上是因为它还处在发明当中，并且在非常短的时间内就迅速普及，影响到商业、通信和文化等领域，有好的方面，也有坏的方面的影响。Montagu 如果还在的话，一定会喜欢浏览器的。
同样，如果您在阅读本文的话，您可能很感激 Internet 对软件开发带来的改变。源代码已经出现在电子公告牌上和某些 Usenet 新闻组中很长时间了（在 1986 年，您还能在其他什么地方下载最新版的 Rogue？），但是快速和全球化的 Internet 才使共享 流行起来。
也许相对于支持 Internet 的协议、主干线和服务器来说，开放源码许可 更加促进了源代码和思想的交换。实际上，Internet 的许多最基本的应用程序 —— Linux®、Apache、MySQL、Perl、PHP（“LAMP” 堆栈）—— 都是通过开放源码许可提供的。开放源码许可试图尽可能广泛、公平且具有最少限制地许可软件固有的版权。
开放源码许可的意图
具体来说，所有开放源码许可都有五个共同的基本意图（摘自 attorney Lawrence Rosen 的 Open Source Licensing: Software Freedom and Intellectual Property Law 一书，并与权限一起使用）：

被许可方可以为任何目的自由使用开放源码软件。
被许可方可以自由复制开放源码软件，并可以自由发布这些副本，无需向许可方支付版税。
被许可方可以自由地创建开放源码软件的派生作品，并可以自由发布这些作品，无需向许可方支付版税。
被许可方可以自由访问和使用开放源码软件的源代码。
被许可方可以自由地组合开放源码软件和其他软件。

所有这些意图都是肯定的，都不会阻止许可方或被许可方强加附加的条款。实际上，Opensource.org 上列出了 50 多个各不相同的经 Open Source Initiative (OSI) 批准的许可，各自都有自己的机制、要求和限制。
50 个许可确实是一个不小的数目，但是大多数都可归为两类：学术许可 和互惠许可。
学术许可，比如 Berkeley Software Distribution (BSD) 许可，允许软件用于任何目的，而不要任何的回报。通过学术许可而获得的软件可以被自由地修改、销售、重新发布、再次许可，以及与其他软件组合，但是其他软件许可可能会阻止这种组合。（尽管学术许可最初是由大学创建的，以向公众许可学术作品，但是广义来讲，遵守该许可的许可方和被许可方不一定都要是学术机构。）
互惠许可，比如原型的 GNU General Public License (GPL)，也允许软件用于任何目的，但是要求派生的作品必须在完全相同的许可条款下被再次许可。与学术许可一样，在互惠许可下许可的作品也旨在用于公共用途（common good）。但是，互惠许可更进了一步，以确保所有后续的派生作品也可用于公共用途。




学术许可
在学术许可下提供的软件本质上是一个 “赠品”，您可以无任何阻碍地使用它，并且可以在您选择的新的许可下再次许可您的派生作品。
BSD 许可是一个学术许可，Apache Software License 和 MIT License 也是的。后者尤其简单，但也例示了学术许可（为了简单起见，MIT License 的保证条款和关于软件保证的任何讨论都被省略了）：
MIT License 摘要
Copyright (c) 年份，版权持有者
权限被免费授予给任何获得该软件副本及相关文档文件（简称为 “Software”）的人，以无限制地处理 Software，包括没有限制使用、复制、修改、合并、出版、发布、再次许可和/或销售 Software 副本的权利，并允许 Software 被提供给的人这样做，但必须遵守以下条件：
上面的版权注意和这个权限注意都应该包含在 Software 的所有副本和固有部分中。
确实，MIT License 的条款与开放源码许可的五个意图非常一致。单词权限 意味着许可；短语免费 是指不要给许可方任何补偿；包括没有限制使用、复制、修改、合并、出版、发布、再次许可和/或销售 Software 副本的权利 这个条款允许复制、源代码访问（“修改”）、组合（“合并”）、重新发布甚至获利（“销售”）。包括不限制再次许可的权利 这个短语尤其重要：它允许被许可方进行许可，但是并不要求被许可方非得这么做。而且，被许可方可以设置再次许可的条款 —— MIT License 不强加任何限制。要包含版权注意的条件在所有被许可方头上强加了一个小小的义务，但是反之不然。




互惠许可
在所有开放源码许可中，GPL 是使用最广泛、影响最强大的。GPL 由 Free Software Foundation 的 Richard Stallman 编写，它要求软件开发人员同意并向其他软件开发人员提出一个契约：“您可以自由地使用该源代码，但是如果您修改它并选择以任何形式发布您的修改，那么您必须在该契约的条款下将您的源代码提供给其他人。”
具体来说，GPL 指出：
GNU 许可摘要
您可以修改程序的副本或者它的任何部分，从而基于该程序形成一个作品，并复制和发布这样的修改或作品，那么不管是作为整体还是部分包含或者派生自该程序或其任何部分的作品，都应该在该许可的条款下作为整体免费许可给所有第三方。
这些要求适用于整个修改的作品。如果该作品的一些可识别的部分不是派生自该程序，那么它们当然可以被看成是独立的作品，因此，当您将这些部分作为单独的作品发布时，该许可及其条款不适用于它们。
但是当您将这些部分作为一个基于该程序的作品的一部分发布时，那么该整体的发布必须遵守该许可的条款，该许可对其他被许可方的权限被扩展到整个作品，因而作用于每个部分，而不管它是谁编写的。
整个 GPL 内容很多，但是上面两段给出了它的基本思想：
被许可的软件以源代码的形式提供（根据其他条款，也可能以其他形式提供）
被许可的软件可以被用于任何目的
被许可的软件可以被自由地修改以及与其他软件组合，以创建派生的作品
被许可的软件可以被重新发布
与 MIT License 一样，GPL 也满足开放源码许可的所有条件。它的互惠只是一个附加的约定。
您可以销售在 GPL 下许可的软件吗？当然可以。例如，您可以下载 gcc，为您喜欢的 Linux 风格编译它，并将二进制代码卖给其他人。但是，即使您做了改进，您也必须以源代码形式提供软件。
您可以在自己的软件中包含 GPL 软件吗？可以，但是您的义务取决于您是如何包含代码的。如果您从 GPL 代码和您自己的代码发布一个二进制版本，那么重新创建该二进制版本所需的所有源代码都必须是可用的。但是，如果您的软件是一个合成作品 —— 由独立的部分组装而成，一些是您自己的代码，一些是在 GPL 下提供的代码 —— 那么只有 GPL 代码必须是可用的。至少根据 Linux 的创建者和主要架构师 Linus Torvalds 所说，针对 GPL 代码 —— 也即针对 libavl（这是用于平衡二叉树的 GNU 库）—— 链接的代码也不要遵守互惠。




使用开放源码许可
尽管 MIT License 和 GPL 都是有效的开放源码许可，但是它们通过不同方法达到各自的目的。并不是说其中一个比另一个要好，它们只是适用于不同的目的而已。
但是这呈现出这样一个问题，即一些开放源码许可与另一些许可不兼容。奇怪的是，即使模块 A 和模块 B 都是用 C 编写的，并且可由任何编译器容易地混合，但是模块各自的许可可能会阻止它们的组合。
如果在自己的项目中采用开放源码的代码，请根据您已经同意的所有许可，认识到您作为被许可方的所有义务。在合成作品中混合来自不同许可的代码一般来说不会出现问题。每个独立的作品保留它自己的版权和许可，而合成作品本身一般是在打包者选择的单独许可下作为整体发布的。
派生作品更加复杂。例如，如果您采纳和合并了通过互惠许可而许可的软件，那么根据这个许可的排他条款，您的派生作品必须重新被提供。显然，根据 GPL 而许可的代码不能与在不同互惠协定下许可的其他代码相混合。
但是，GPL 代码可以自由地与 BSD 和 MIT License 代码混合。不幸的是，GPL 的作者们主张（转述，而不是引用），Apache License 是不兼容的。同样，所有开放源码许可并不是相等的。如果您需要采纳由不同开放源码许可控制的代码，请咨询合格的法律顾问。





在自由的空气中享受 自由
GPL 的反对者认为该许可是违反宪法的。其他人则攻击 GPL 的互惠。有一个人甚至起诉 Free Software Foundation，向其索赔，理由是 GPL 试图将软件价格定为 $0，影响了原告作为开发人员的生活。
但是开放源码许可不是平凭空发明的法律。相反，正如本文所展示的，开放源码许可切实建立于版权法的基础之上，并力图表达所有者的希望，以尽可能广泛地共享代码。没有法律规定您一定要将您的代码许可为开放的源代码，也没有法律规定您必须同意开放源码许可的条款。您可以自由地选择：构建、购买或者借用。现在越来越多的开发人员选择借用（并借出），使得开放源码在任何意义上都成了一个契约。