开源开发者 Seth Vargo 发现 Chef 公司最近与 ICE(美国移民和海关执法局)
签订了合同后,进行删库抗议,从 Chef DevOps 中撤回了他的开源项目 Chef
Sugar。后来 Chef
公司表示明年不再续签合同。然而事情并未就此而止,这引起了人们对开源道德层面上的关注。有行动者打出
#NoTechForICE 的口号,并已拟好一份 Hippocratic
License,要求将道德条款添加至开源许可证中。

目前正在进行的2019
年中国开源软件评选活动中,对于候选软件有一个要求是:使用OSI 认证的开源
License。

开源协议概要

目前开源的协议可以参考GNU组织的开源许可协议:[具体参考链]。(http://www.gnu.org/licenses/license-list.html)
现今存在的开源协议很多,而经过Open Source
Initiative组织通过批准的开源协议目前有58种:具体参考链。
下面来看几个例子:
Facebook的Github中的开源项目大部分都是使用BSD开源协议,BSD协议允许使用者修改和重新发布代码(以其他协议形式),允许闭源商业发布和销售,如果在再发布的产品中包含源码,则必须带有原来代码中的BSD协议,不可以使用Facebook的名字来做市场推广等。
Google的Android则是使用Apache v2
License协议
,这个协议和BSD类似,允许修改代码再发布,可以用作商业软件而不用公布修改之后的源码,但是这个协议鼓励代码共享尊重作者的著作权。
Linux 使用了GPL
协议,而GPL代码规定所有使用了GPL代码的代码,必须开源。如果一些商用软件采用了GPL开源协议的源码,则必须公布自己的源码。
下面是一些常见的开源许可证的介绍,具体就不多说了,自己平时不论是使用别人的开源项目还是自己开源产品,一定要记得选好开源协议。

Hippocratic License 建立在对 MIT license 的修改之上,作者 Coraline Ada
Ehmke 介绍该许可证“专门禁止使用开放源代码软件危害他人”。同时,她还呼吁修改开源定义(The
Open Source Definition)中第 5 和第 6 两条“非歧视”条款。

那么 OSI 认证的开源 License 有哪些呢,这里根据 OSI
官方分类,简单介绍一下。

开源许可证的一些介绍

Ehmke
表示,长期以来,软件开发人员已经与自己编写的代码造成的后果相脱离,但实际上,“我们创建的软件对我们所生活的世界具有真正而持久的影响”。她认为,政治和软件纠缠不清,所有技术本质上都是政治性的,不存在所谓中立立场。如果这些情况伤害到他人,我们应该做些什么?为此,她希望能够用开源许可证来进行规制。

受欢迎且被广泛使用或具有强大社区的许可证

Apache v2 License

Apache
Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似,同样鼓励代码共享和尊重原作者的著作权,同样允许代码修改,再发布(作为开源或商业软件)。需要满足的条件也和BSD类似:

  1. 需要给代码的用户一份Apache Licence

  2. 如果你修改了代码,需要再被修改的文件中说明。

  3. 在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明。

  4. 如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache
    Licence。你可以在Notice中增加自己的许可,但不可以表现为对Apache
    Licence构成更改。

Apache
Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

图片 1

Apache License 2.0

MIT License

MIT许可证之名源自麻省理工学院(Massachusetts Institute of Technology,
MIT),又称「X条款」(X License)或「X11条款」(X11 License)

MIT内容与三条款BSD许可证(3-clause BSD
license)内容颇为近似,但是赋予软体被授权人更大的权利与更少的限制。

被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软体及软体的副本。

被授权人可根据程式的需要修改授权条款为适当的内容。

在软件和软件的所有副本中都必须包含版权声明和许可声明。

此授权条款并非属copyleft的自由软体授权条款,允许在自由/开放源码软体或非自由软体(proprietary
software)所使用。

此亦为MIT与BSD(The BSD license, 3-clause BSD license)本质上不同处。

MIT条款可与其他授权条款并存。另外,MIT条款也是自由软体基金会(FSF)所认可的自由软体授权条款,与GPL相容。

开源倡导组织(Open Source Initiative,OSI)迅速驳斥了 Ehmke
的做法。他们在 Twitter 上写道:“Hippocratic
Licence 的简介可能会使某些人认为该许可证是开源许可证,根据 Hippocratic
Licence
分发的软件是开源软件。但两者都不是,我们要求您修改语言以消除混淆。”

3-clause BSD license

GPL v2

我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache
Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux,包括商业公司的linux和linux上各种各样的由个人,组织,以及商业软件公司开发的免费软件了。

GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用,修改后的代码或者衍生代码)GPL
协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题,还可以享受免费的优势。

由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,对于使用GPL协议的开源代码,商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。

其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。

Ehmke 回击:“OSI 和
FSF(自由软件基金会)不是‘什么是开源’和‘什么是自由软件’的真正仲裁者。我们才是”。随后她补充说,当前的开源结构无法禁止自己的劳动成果被
ICE 这样的组织使用,这不是一个开源许可证的问题,而是开源的问题。

2-clause BSD license

Artistic License 2.0

Artistic License,又称艺术许可协议(英语:Artistic
License),通常指最初的艺术许可协议(1.0版),是一个自由软件授权条款,主要用在官方发布的Perl解释器和大部分CPAN模块的授权。原始的艺术许可协议是由Perl的创始人Larry
Wall编写发布的。

先把 Twitter
上的争吵放在一边,我们来谈谈道德准则是否能够被纳入开源许可证。

GNU General Public License

BSD 2-Clause license

BSD允许使用者修改和重新发布代码(以其他协议形式),允许闭源商业发布和销售。

BSD鼓励代码共享的同时,要求尊重代码作者的著作权。

使用BSD协议,需要遵守以下规则:

  1. 再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议;
  2. 如果再发布的只是二进制类库/软件,则需要在类库/软件的文档那个和版权声明中包含原来代码中的BSD协议。

这并不是什么新鲜之事。例如,2009 年的 Exception General Public
License(eGPL)就曾尝试在 GPLv2
上发挥作用,试图禁止诸如军事用户之类的“例外”使用其代码。最终失败了。

GNU Lesser General Public License

Affero GPL

是一个广泛被使用的自由软件特许条款,最初由Affero,
Inc撰写。此特许条款最新版本为“第3版”(v3),2007年11月发布。Affero
通用公众特许条款是改自GNU通用公众特许条款,并加入额外条款,其目的是为了Copyleft条款应用于在网络上运行的应用程式(如Web应用),从而避免有人以应用服务提供商方式逃避GNU通用公众特许条款。

诸如 JSON license
之类的其他许可证也鲜为人知,它注明“该软件应用于善良,而非邪恶”,但没有人强制执行。

MIT license

LGPL v2.1

LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。

GPL/LGPL都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品

今年伴随 996.ICU 运动出现的 Anti-996
协议也可以说是基于道德层面。专门研究开源软件许可的律师 Heather Meeker
认为,“它已经实现了重要目标,那就是要引起人们对此事的关注”。但作为开源许可证,它还存在问题,因为“许可证中的道德条款不能用来强迫被许可人,从法律的角度来看,它们更多是一种观点的表达,而不是用于控制被许可人行为的有效法律工具”。

Mozilla Public License 2.0

BSD (3-Clause) License

BSD允许使用者修改和重新发布代码(以其他协议形式),允许闭源商业发布和销售。

BSD鼓励代码共享的同时,要求尊重代码作者的著作权。

使用BSD协议,需要遵守以下规则:

  1. 再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议;
  2. 如果再发布的只是二进制类库/软件,则需要在类库/软件的文档那个和版权声明中包含原来代码中的BSD协议;
  3. 不可以用开源代码的“作者/机构的名字”或“原来产品的名字”做市场推广。

关于开源许可证,开源法律专家、哥伦比亚大学法学教授埃本·莫格伦(Eben
Moglen)指出,根据 FSF
对自由软件的定义,对道德进行要求的许可证将违反其中有关 Freedom
zero 的规定。Freedom
zero 即出于任何目的运行程序的权利,它在四项自由权力中排在首位。

Common Development and Distribution License 1.0

Eclipse Public License v1.0

EPL允许使用者任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。

使用EPL协议,需要遵守以下规则:

  1. 当一个代码贡献者将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布,而不能改用其他协议发布.除非你得到了原“源码”拥有者的授权;
  2. EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是二进制文件的时候,你必须声明它的源代码是可以获取的,而且要告知获取方法;
  3. 当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时候,你可以将整个Project/Product以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL;
  4. 独立的模块(Separate Module),不需要开源。

图片 2

Eclipse Public License 2.0

LGPL v3

相对于LGPL v2,不仅要求用户公布修改的源代码,还要求公布相关硬件。

顶尖技术律师事务所和开源法律专家 Gesmer Updegrove 的创始合伙人 Andrew
补充说,“从广义上讲,许可人可以在许可证中包含任何他想要的条件。但是,这种限制不能包含在声称符合
OSI 开源定义的文档中”。

CeCILL License 2.1

Mozilla Public License Version 2.0

MPL是The Mozilla Public License的简写,是1998年初Netscape的
Mozilla小组为其开源软件项目设计的软件许可证。MPL许可证出现的最重要原因就是,Netscape公司认为GPL许可证没有很好地平衡开发者对
源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比,MPL在许多权利与义务的约定方面与它们相同(因为都是符合OSIA
认定的开源软件许可证)。但是,相比而言MPL还有以下几个显著的不同之处:

  • MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来,以保证其他人可以在MPL的条款下共享源代码。但是,在MPL
    许可证中对“发布”的定义是“以源代码方式发布的文件”,这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口,除了接口程序的源代码以MPL
    许可证的形式对外许可外,源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些,就为借鉴别人的源代码用做自己商业软件开发的行为留了一个
    豁口。
  • MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。
  • 对软件专利的态度,MPL许可证不像GPL许可证那样明确表示反对软件专利,但是却明确要求源代码的提供者不能提供已经受专利保护的源代码(除非他本人是
    专利权人,并书面向公众免费许可这些源代码),也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
  • 对源代码的定义
    而在MPL(1.1版本)许可证中,对源代码的定义是:“源代码指的是对作品进行修改最优先择
    取的形式,它包括:所有模块的所有源程序,加上有关的接口的定义,加上控制可执行作品的安装和编译的‘原本’(原文为‘Script’),或者不是与初始
    源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。”
  • MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定,就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。

具体来讲,又回到了上述开源定义(The
Open Source Definition)中的第 6
条“不歧视领域”:该许可证不得限制任何人在特定领域内使用该程序。

European Union Public License

GPL v3

GPL v3与GPL
v2类似。区别在于,不仅要求用户公布修改的源代码,还要求公布相关硬件。

Andrew
解释,这样做的理由是“禁止‘不允许开源软件在商业上使用’的行为。我们希望商业用户加入我们的社区,而不是被排斥在社区之外”。顺便说一下,这是自由软件和开源软件之间的核心区别之一。

Licence Libre du Québec – Permissive version 1.1

参考文章

  • Open Source
    Initiative
  • 再谈Android的许可证
  • 再谈Android的许可证(续)
  • Various Licenses and Comments about
    Them
  • git
    oschina相关介绍

“你可以制订‘禁止使用’条款,并要求被许可方在任何下游许可中都包含类似术语”,但在现实中这是难以执行的。Andrew
举了个例子:“假设按照通常的开源方式发布代码,那么很快将会出现许多副本,而你几乎无法追溯所有副本。如果代码被捆绑在某个你认为是有害的商业产品中,你也无从得知。”

Licence Libre du Québec – Réciprocité version 1.1

软件自由保护组织(Software Freedom Conservancy)执行董事 Karen M.
Sandler
也提出了自己的观点,在他看来,有选择地保留软件自由是不合适的,而且这些道德许可证会引发执行问题。更重要的是,还可以通过其他方式达成同样的目标。Sandler
建议可以为开发人员建立道德社会,或通过参与政治程序来禁止不法行为。

Licence Libre du Québec – Réciprocité forte version 1.1

对于将道德条款纳入软件许可证中,Sandler
再次强调这不是那么实际,毕竟“锤子既可以用作建筑工具,也可以用作谋杀的武器。”

主要应用场景:学校和政府等提供许可方可能会有一些特殊的问题,例如政府版权的特殊规则。

消息来源:ZDNet

Educational Community License, Version 2.0

IPA Font License

Lawrence Berkeley National Labs BSD Variant License

NASA Open Source Agreement 1.3

OSET Public License version 2.1

SIL Open Font License 1.1

Upstream Compatibility License v1.0

此类许可证不属于任何类别。

Adaptive Public License

Artistic license 2.0

Open Software License

Q Public License

Universal Permissive License

Zero-Clause BSD/Free Public License 1.0.0

zlib/libpng license

与更流行的许可证重复的许可证

该组中的许可证是优秀的,并且具有自己的追随者,但是它们被认为与现有流行的许可证完全或部分重复了。

Academic Free License 3,0

Attribution Assurance License

Eiffel Forum License V2.0

Fair License

Historical Permission Notice and Disclaimer

Lucent Public License Version 1.02

The PostgreSQL License

University of Illinois/NCSA Open Source License

X.Net License

该组中的许可特定于其作者,不能被其他人重复使用。

Apple Public Source License

Computer Associates Trusted Open Source License 1.1

eCos License version 2.0

EU DataGrid Software License

Entessa Public License

Frameworx License

IBM Public License 1.0

LaTeX Project Public License 1.3c

Motosoto License

Multics License

Naumen Public License

Nethack General Public License

Nokia Open Source License

OCLC Research Public License 2.0

PHP License 3.0

Python License

CNRI Python license (CNRI portion of Python License)

RealNetworks Public Source License V1.0

Ricoh Source Code Public License

Sleepycat License

Sun Public License 1.0

Sybase Open Watcom Public License 1.0

Vovida Software License v. 1.0

W3C License

wxWindows Library License

Zope Public License 2.o

此类别中的许可证已被较新的版本取代。

Apache Software License 1.1

Artistic license 1.0

Common Public License 1.0

Eclipse Public License 1.0

Educational Community License, Version 1.0

Eiffel Forum License V1.0

Lucent Public License , version 1.0

Mozilla Public License 1.0

Mozilla Public License 1.1

Open Software License 1.0

Open Software License 2.1

Reciprocal Public License, version 1.1

此类中的许可证已不可用。

CUA Office Public License Version 1.0

Intel Open Source License

Jabber Open Source License

MITRE Collaborative Virtual Workspace License

Sun Industry Standards Source License

Boost Software License

Common Public Attribution License 1.0

GNU Affero General Public License version 3

ISC License

Microsoft Public License

Microsoft Reciprocal License

MirOS Licence

Non-Profit Open Software License 3.0

NTP License

Open Group Test Suite License

Reciprocal Public License 1.5

Simple Public License 2.0