我应该选择哪种许可协议?

2014-09-25 09:02:06       1383    原创
摘要:发布者:Rowan Wilson  日期:2011-05-23  最近更新:2012-09-09 目前有很多自由和开源软件许可协议。虽然它们都试图达成一致,却依然存在分歧。主要区别可以分为几类,本文将重点介绍这些分类。阅读过本文之后,您就知道如何为您的代码选择许可协议了。

保持主流地位

开放源代码促进会(OSI)——一个旨在推动开源软件发展的非营利性组织——负责维护他们认为“流行并被广泛使用,或受到广泛社区支持”的一个许可协议清单。清单的目的,是为了强调这部分许可协议以满足那些初步接触开源的许可人的需要。此外,清单还可以使开源许可协议的选择更易管理。包含 60 项以上许可协议的完整清单可能令人望而生畏,它包含许多在功能上与清单中”流行并被广泛使用的“许可协议极其近似的许可协议。

使用被他人广泛使用的许可协议有很多优势。如果许可协议的条款被质疑,将会有大量与此有利益关系的许可人一致给予回应。使用一项”流行并被广泛使用“的许可协议会提高被许可人已熟悉相关条款的可能性。但是,许可人不应感觉自己“被锁定”只能使用“流行并被广泛使用“的许可协议。在所有的OSI核准的许可协议,只有大部分才具备下文讨论的部分特征。


获准版权与著佐权“Copyleft”

所有自由和开源许可协议都允许他人对您的代码进行修改,并且向第三方提供修改后的版本。您所选的许可协议可对此设定条件——明确指出哪些许可协议可用于这些修改版。这些条件可使您的代码保持自由,但也会使有些人无法重复使用您的代码。对应”版权(copyright)“的含义,这些条件有时被称为”著佐权(copyleft)“条件。

如果开源许可协议对已修改代码的许可方式没有任何要求,这种许可协议通常叫做”获准“许可协议。当获准许可协议控制下的代码仍遵循该许可协议时,修改者可以选择任意许可协议发布代码的修改版本,不论其开源与否。这意味着,获准许可代码可形成闭源产品的基础。有人认为这会使获准许可协议比著佐权许可协议更加”自由“,因为代码的修改者可以更加自由地选择许可协议。其他人则认为,不要求修改版本必须选择开源许可协议,意味着获准许可协议的”自由度“更小了。由于对自由观点的讨论——尤其是强制自由的观点——在本质上属于哲学范畴,因而不在本文的讨论范围之内。但是,值得注意的是,在自由和开源领域关于“自由“的真正含义,存在不同的观点。

举例: 作为其天体物理学研究的一部分,Anne 为记录某种复杂的数据对象创建了一项标准。此外,她还编写了代码,以建立和解析与该标准相关的文件。Anne 希望该标准能够得到广泛使用,因为有少数人使用的标准用处不大。因此,她决定在获准许可协议下发布代码。Anne 相信,允许闭源和开源项目的创建者使用相同的代码来建立和读取数据对象,会同时有助于提升该标准的理解力和效能。


强/弱著佐权

如果您要求重复使用您的代码时必须使用著佐权许可协议,您将需要进一步作出选择。著佐权许可协议从广义上被分为两种”强度“:强和弱。强著佐权条件规定,如果一个软件包含您部分代码,它在完全发布时必须作为整体适用您的许可协议。这样做的影响是,该代码所有添加部分的源代码都将可用。

另一方面,弱著佐权意味着,如果一个软件包含您部分代码,它在完全发布时某些部分必须适用您的许可协议。其他部分可在其他许可协议下发布,即使它们组成了您整个代码修改版本的一部分。这样做的一个影响是,他人对您软件添加部分的源代码可能不被作为开源代码提供。另一个影响是,人们将更容易通过向您的开源代码添加闭源组件从而使之商品化,并对外销售这些闭源组件的许可协议。

选择一个特定的弱著佐权许可协议,您还必须精准地确定,您代码的哪些部分将继续适用您的许可协议,以及哪些添加部分适用修改者选择的许可协议。包括以下三种不同层次的划分:

•模块级弱著佐权许可协议规定,软件代码的每个具有独立功能的子分区(”模块“)都要单独考虑。如果一个模块包含您的部分代码,它必须适用您的许可协议。如果不包含,代码的所有者可为该模块选择许可协议。

•文件级弱著佐权许可协议规定,根据计算机文件系统区分的每个代码和数据集都要单独考虑。如果一个文件包含您的部分代码,它必须适用您的许可协议。如果不包含,代码的所有者可选择许可协议。

•库接口级弱著佐权许可协议通常在您的代码是软件库(其他程序可通过协议接口使用的软件功能集)时使用。对您的库进行修改,在发布时就必须适用您的许可协议。使用您库里的程序,以及与您的库一同发布的程序,不需要使用您的许可协议。

举例:Barry 编写了一组 C 代码,用于检验网络连接的各网站,并生成网页之间链接的镜像文件图。Barry 打算在著佐权许可协议下发布其代码,因为他想强制获取其程序修改版的源代码。但是,Barry 又希望各种项目都能使用他的程序——部分原因是,他认为这将鼓励有益修改并优化其工作成果。Barry 决定将其程序打包成库,并使用库接口级弱著佐权许可协议 GNU LGPLv2.1 。原因是他认为,这不仅鼓励了闭源和开源项目都重复使用代码,同时也强制公开发布了对其感兴趣部分(他自己的代码及其包含的功能)进行修改后的源代码。


司法管辖区域

“司法管辖区域”指的是一个特定区域或领域及其法律体系。当某个许可协议指定了司法管辖区时,许可人和被许可人达成共识:双方应依照该区域的法律法规对该许可协议条款进行解释,如有违反该许可协议的条款,应在该司法管辖区内诉诸法律途径解决。

司法管辖区是一个重要的问题,然而值得注意的是,自由和开源软件所有者一般不会向违反许可条款者要求金钱赔偿,只是要求违约人同意遵守条款或终止使用相关代码。通常不需要真的将违约人告上法庭,尤其是需要维护公众形象和声誉的情况下。通常,只要向对方发出守约要求就很有效。如若不然,公开其违约行为也可有助于促使对方遵守约定。不是所有自由和开源软件许可协议都会指定一个司法管辖区。实际上,大部分许可协议并未涉及。在这种情况下,必要时您可选择任何司法管辖区。但是,很有可能您要起诉的人会拒绝应诉,或者因为您选择的管辖地不利于他们而提出管辖权异议。最后,部分自由和开源软件许可协议指定,司法管辖区的选择权归许可人所有,或自动认定为许可人的住所 (居住地或营业场所所在地)。

举例:Crabapple 大学希望编写有关开源发布的政策,因为这是一个大型捐助项目的前提条件。Crabapple 的律师认为政策的关键,是选定一项许可协议,作为学院许可开源软件时的优先选择。在讨论选择哪项许可协议的首次会议上,有人指出学院的保险政策不包含海外法律诉讼。因此确定了选定许可协议的基本内容,即由本地的司法机关针对由软件发布引发的任何法律诉讼行使管辖权。


专利

您或您所在的机构拥有任何软件专利吗?如果有,而且您根据自由或开源软件许可协议发布了相关代码,那么您极有可能授权一群人使用与该代码相关的专利权——即使该许可协议并没有明确说明。在很多区域,比如英国和美国,许可某人执行某项特定的操作(如复制或改写您的代码),意味着默许其采用一切必要的步骤来实现该操作。几乎可以肯定,这些模式许可的步骤几乎肯定包含了软件专利的使用。请注意,改写您代码的人不能通过扩展其功能来获取您的其他软件专利——您授权的只是包含在已发布代码对应的专利,不包括该代码可能引起的其他任何形式。部分自由和开源软件许可协议对于专利授权没有任何规定——但是,正如上文所述,这并不意味着他们未授予专利权。部分自由和开源软件许可协议明确地授予必要的专利权,以使用、改写以及发行该软件。

您所使用的自由或开源软件许可协议也可包含”专利报复(patent retaliation)“条款。许可协议的这些基本内容是,指控被许可软件使用其软件专利的人,将丧失许可他人复制、使用、改写以及发行的权利。该条款旨在防止人们不要提起此类恶意法律诉讼。

举例:Dopaska 教授创建了一个内含软件的方法用于预测民间动乱,他所在的大学认为其可取得专利。该教授希望在获准类型的 Apache 许可协议 v2 下发布这一方法内含的软件,以通过该方法的广泛使用提升其学术声誉。Dopaska 教授所在学院知识转换办公室的人员不赞成这个想法,因为他们希望获取专利,进而建立衍生公司,认为开源发布将削弱这个公司的许可收益。


增强型归属

所有的自由或开源软件许可协议指定,任何人发行或改写软件都必须在其发布内容中署名软件的原作者。部分自由或开源软件许可协议更进一步要求这种认可必须采取特定的形式或者出现在特定情形中,例如在每次软件运行时出现在用户界面。这种规定有时被称为“增强型归属(enhanced attribution)”或“勋章授予(badgeware)”。

举例:Edward 创建了一个可以在文档中醒目得显示文字出现频率的工具。Edward 推测该工具可能会获得广泛应用,但不是大部分用户从事核心业务所需要的基础工具,从而支持一个付费的许可模型。实际上,Edward 真正想要的是宣传其推广咨询业务及相关代码。Edward 决定在普通公共属性许可协议 v1 下发布其工具,因为该许可协议在每次软件运行时强制显示 URL、图案和表明归属性的词汇。Edward 随软件一起提供其咨询网站的 URL、LOGO 和品牌标语,以便用户在使用和重复使用其代码时可帮助推广其业务。


隐私漏洞

如果有人改写或完善您的代码,创建在线服务或者内部解决方案,大部分自由和开源软件许可协议并未规定,改写版或增强版代码的源代码必须对外发布。大部分自由和开源软件许可协议规定发布的条件是源代码已发布。通常,在网络上提供服务,使用代码,或者在某个机构内部配置代码,都不被认定为这些许可协议定义的代码发布。

自由和开源软件社区中的部分成员,认为这些也被称为”应用服务提供商(ASP)漏洞“或”隐私漏洞“的现象有待解决。他们的观点是,为公平起见,所有受益于代码的人都必须通过他们的工作回馈社会,即使严格意义上来说他们并没有发布代码。为了解决这个问题,部分自由或开源软件许可协议将源代码发布作为代码发布、内部配置和/或使用软件提供网络服务的前提条件。尤其当这种代码是网络服务的基础代码或者可能在内部使用。

举例:Fareeda 打算新设一项业务,即给用户提供一种可以将其社交网络上的照片制作为复杂幻灯片模式的音乐视频。她发现了一个在 GNU Affero GPL v3 下授权的开源软件,可提供一种简便的方法处理其网站与多个外部网站接口的需求。通过对该许可协议的深入研究,Fareeda 发现,如果她修改了该协议授权的代码并如愿将其作为网络服务的基础使用,根据该协议条款的强制规定,她必须同时将修改部分的源代码提供给服务用户。Fareeda 现在必须确定,她的商业模型是否会被这种潜在责任影响,究竟是受益,还是受损。


不宣传

部分自由和开源软件许可协议明确禁止使用作者的名字,来推广基于该作者代码提供的产品或服务。

举例:作为公共资助项目的一部分,Gerhentz 大学创建了一组自动随显示屏大小调整用户界面的代码。学院希望公共资金能够同时在开源和闭源软件方面将公共利益最大化,因此打算在一个获准类型的开源许可协议下发布该代码。但是,Gerhentz 不希望这被视作其对包含其代码的产品的一种支持,因为他们认为这可能会损坏学院的声誉。因此,他们最终决定使用 BSD 许可协议,既允许该代码被广泛地再利用,又限制利用其进行宣传推广。


结论

本文讲述了各种自由和开源许可协议之间的部分关键区别,目的是帮助您选择将何种许可协议应用于您的代码。文中的示例详细地说明了您在选择过程中应该考虑的要素,并将其具体化。但是,您应注意到,没有一项许可协议可以将每种功能进行整合。因此,为了选取一个现有的许可协议,放弃一个或多个功能还是很有必要的。为实现这一点,按重要性顺序评级您所需的功能是一个有用的方法。OSS Watch 可帮助您选择最适合您所需特性的许可协议——快来联系我们吧。


延伸阅读

链接:

•开放源代码促进会的许可协议分类 [http://www.opensource.org/licenses/category]

•GNU LGPL v2.1 [http://www.gnu.org/licenses/lgpl-2.1.html]

•Apache 许可协议 v2 [http://www.apache.org/licenses/LICENSE-2.0.html]

•普通公共属性许可协议 v1 [http://www.opensource.org/licenses/cpal_1.0]

•GNU Affero GPL v3 [http://www.gnu.org/licenses/agpl.html]

•BSD 许可协议 [http://www.opensource.org/licenses/bsd-license]


本文由 OSS Watch 原创并经由Creative Commons Attribution-ShareAlike 2.0 England & Wales license许可证发布。

沪ICP备15046442号
蝉知1.6