开源License

作者: 乔伯 | 来源:发表于2016-03-05 20:11 被阅读1894次

    作为一个开源爱好者,我们经常会写一些开源的软件或者工具在网上分享,或者为一些其他的开源软件贡献一些自己的力量,但是对于开源许可(License)是有很多种的哦,每一种是有不同的约束的,在法治国家是具有法律约束的。

    概念

    首先我们来了解一些基本的概念。

    贡献者(Contributors)& 受益者(Recipients

    贡献者(Contributors)指的是对某个开源软件或项目提供了代码(包括最初的或者修改过的)发布的人或者实体(团队、公司、组织等),按照参与某个软件开源的时间先后,可以分为 初始贡献者(Initial Contributor)和 后续贡献者(Subsequent Contributors)。

    受益者(Recipients)指的是开源软件或项目的获取者,也就是那些用了这个开源软件的人,后续贡献者(Subsequent Contributors)也属于 受益者(Recipients)之列。

    源码(Source Code) & 类库(Object Code

    源码(Source Code) 这个好理解,就是指各种语言写成的源代码,通过Source Code,结合文档,有了源码我们就可以了解各个开源软件的具体细节,也可以做很多的修改。

    类库(Object Code)就是指的由源码编译过后生成的“类库”,当然很多语言不需要编译,那源码本身就是类库。

    其实分清楚这两个概念还是挺重要的,有些开源协议,对 “你发布的是哪种Code的时候应该怎样”,有着明确的约束。

    衍生模块(Derivative Module)& 独立模块(Separate Module

    衍生模块(Derivative Module) 指的是,依托或包含“最初的”或者“从别人处获取的”开源代码而产生的代码,是原“源代码”的增强(不等于增加)、改善和延续的模块,意为衍生模块。

    独立模块(Separate Module)指的是,参考或借助原“源代码”,开发出的独立的,不包含、不依赖于原“源代码模块”,意为“独立的模块”。

    理解这两个概念的目的在于,很多开源许可对涉及到商业发布的时候,会有哪些是衍生的,哪些是独立的,有着明确的商业发布规定。

    开放源码促进会(Open Source Initiative

    这是一个组织,简称OSI,叫做开放源码促进会,1998年2月份由Bruce Perens and Eric S. Raymond创立,旨在推动和促进开源软件的发展。现在开源软件的蓬勃发展跟这个组织的倡导是分不开的。官网是opensource.org

    经过这么多年的发展,现今存在的开源许可很多,而经过Open Source Initiative组织批准的开源协议目前有76种,后面可能还会再增多的,列表在官网上有,还有一个介绍也比较全面的

    常见协议

    我们常见的开源License:BSD、Apache、GPL、LGPL、MIT、MPL都是Open Source Initiative组织批准的,而且他们对于受益者有着不同的约束,如果要开源自己的代码,最好也是选择这些被批准的开源License。

    BSD License

    BSD是Berkeley Software Distribution的缩写,叫做伯克利软件发行版,它出现在上世纪70年代,那个时候是一个UNIX操作系统的衍生版本,为了发行它的这个操作系统,他们起草了BSD License。

    这个License给了使用者很大的自由,基本上使用者可以自由的使用,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布。

    对使用者也有约束:

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

    举个栗子:你用开源代码(A)修改或做其他增添之后,产生了产品B,这时候,你对B的控制由你自己决定,你可以用任何协议再开源,也可以闭源商业发布。但是因为如果B中包含了A或A的一部分,那你在B产品的版权声明中提到你有使用到 A,并且附带上 A 的开源协议。而且不能做商业推广的时候将B 冠以原开源作者的名义以促进商业推广。

    其实这几个规则约定的目的也只是达到一个目的:是他人的东西,别人以BSD开源了,你就不能不做任何声明而占为己有,更不能用他人的名义来做商业推广,你只对你自己的东西拥有绝对控制权。

    当然后面随着BSD的发展和系统衍生发行,BSD License也有了多个版本和衍生版,比如BSD 3-Clause "New" or "Revised" License (BSD-3-Clause)BSD 2-Clause "Simplified" or "FreeBSD" License (BSD-2-Clause)

    Apache License

    这里就需要提一下Apache Software Foundation(ASF)这个组织了,中文我们一般叫 Apache软件基金会,最早这个组织还只有Apache这一个主要开源软件,所以基金会起草了Apache License 的1.0版本,随着后面的发展,很多的开源软件加入了基金会,本着鼓励代码共享,推动软件开源的原则,基金会修改了这个License,放宽了最初许可里边的一些约束规定,于是 有了 Apache License1.1和2.0的版本,1.0和1.1是老早之前的事情了,现在流行的都是Apache License 2.0 (Apache-2.0)

    该License和BSD License类似,鼓励代码共享和尊重原作者的著作权,同样允许代码修改,再发布(作为开源或商业软件)。

    需要满足的条件也和BSD类似:

    1. 需要给代码提供一份Apache Licence
    2. 如果你修改了代码,需要在被修改的文件中说明。
    3. 在衍生的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的Licence、商标、专利声明和其他原来作者规定需要包含的说明。
    4. 如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可,但不可以对Apache Licence的要求进行更改。

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

    MIT License

    Massachusetts Institute of Technology简称MIT,也就是大名鼎鼎的麻省理工学院,最早于1988年由MIT起草,跟BSD类似,作者只想保留版权,而无任何其他了限制。

    也就是说,你必须在你的发行版里包含原许可协议的声明,无论你是以二进制发布的还是以源代码发布的。商业软件可以使用,也可以修改MIT协议的代码,甚至可以出售MIT license (MIT)的代码。

    GPL

    GNU General Public License简称GPL ,第一个版本起草于1989年2月,这个License旨在 代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。目前使用该License最为我们熟悉的估计就是Linux了。

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

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

    同样经过长时间的发展,它也有有好几个版本,比较流行的是GNU General Public License version 2.0 (GPL-2.0)
    GNU General Public License version 3.0 (GPL-3.0)

    LGPL

    GNU Lesser General Public License简称LGPL,因为GPL实在是太严苛了,很多商业公司其实对这个协议是不太认可的,所以为了让商业公司也能使用,设计了LGPL。

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

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

    简单点说就是商业软件可以使用,但不能修改LGPL许可的代码,改了人家的代码你也就要开源。

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

    经OSI批准的有两个版本:GNU Library or "Lesser" General Public License version 2.1 (LGPL-2.1)GNU Library or "Lesser" General Public License version 3.0 (LGPL-3.0)

    MPL

    The Mozilla Public License简称MPL,1998年初Netscape公司的 Mozilla小组为其开源软件项目设计的软件License。

    MPL许可证出现的最重要原因就是,Netscape公司认为GPL许可证没有很好地平衡开发者对 源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比,MPL在许多权利与义务的约定方面与它们相同。

    MPL许可证允许免费重发布、免费修改,但要求修改后的代码版权归软件的发起者 。这种授权维护了商业软件的利益,它要求基于这种软件的修改无偿贡献版权给该软件。这样,围绕该软件的所有代码的版权都集中在发起开发人的手中。但MPL是允许修改,无偿使用。

    商业软件可以使用,也可以修改Mozilla Public License 2.0 (MPL-2.0)协议的代码,但修改后的代码版权归软件的发起者。

    各种License对比

    其实这样来看一点都不直观,需要一定的理解能力去理解,其实针对几个方面我们可以总结一下。

    项目 描述 解释
    License and copyright notice 许可和版权信息 在代码中保留作者提供的许可和版权信息
    State Changes 声明变更 在代码中声明对原来代码的重大修改及变更
    Disclose Source 公开源码 代码必需公开。如果是基于LGPL协议 下,则只需使用的开源代码公开,不必将整个软件源码公开
    Library usage 库引用 该库可以用于商业软件中
    Hold Liable 责任承担 代码的作者承担代码使用后的风险及产生的后果
    Use Trademark 商标使用 可以使用作者的姓名,作品的Logo,或商标
    Sublicensing 附加许可 允许在软件分发传播过程中附加上原来没有的许可条款等

    各License的约束

    对于No license 的情况,你保留所有权利,不允许他人分发,复制或者创造衍生物。当你将代码发表在一些网站上时需要遵守该网站的协议,此协议可能包含了一些对你劳动成果的授权许可。比如你将代码发布到GitHub,那么你就必需同意别人可以查看和Fork你的代码。

    在许多国家,默认版权归作者自动拥有,所以Unlicense协议提供了一种通用的模板,此协议表明你放弃版权,将劳动成果无私贡献出来。你将丧失对作品的全部权利,包括在MIT/X11中定义的无担保权利。

    License 要求 允许 禁止
    BSD <ul><li>许可和版权信息</li></ul> <ul><li>商用</li><li>分发</li><li>修改</li><li>私用</li><li>附加许可</li></ul> <ul><li>责任承担</li></ul>
    Apache <ul><li>协议和版权信息</li><li>声明变更</li></ul> <ul><li>商用</li><li>分发</li><li>修改</li><li>私用</li><li>专利授权</li><li>附加许可</li></ul> <ul><li>责任承担</li><li>商标使用</li></ul>
    MIT <ul><li>许可和版权信息</li></ul> <ul><li>商用</li><li>分发</li><li>修改</li><li>私用</li><li>附加许可</li></ul> <ul><li>责任承担</li></ul>
    MPL <ul><li>公开源码(全部)</li><li>协议和版权信息</li></ul> <ul><li>商用</li><li>分发</li><li>修改</li><li>私用</li><li>专利授权</li><li>附加许可</li></ul> <ul><li>责任承担</li><li>商标使用</li></ul>
    GPL <ul><li>公开源码(全部)</li><li>协议和版权信息</li><li>声明变更</li></ul> <ul><li>商用</li><li>分发</li><li>修改</li><li>私用</li><li>专利授权</li></ul> <ul><li>责任承担</li><li>附加许可</li></ul>
    LGPL <ul><li>公开源码(修改部分)</li><li>协议和版权信息</li><li>库引用</li></ul> <ul><li>商用</li><li>分发</li><li>修改</li><li>私用</li><li>专利授权</li><li>附加许可</li></ul> <ul><li>责任承担</li></ul>
    No license <ul><li>协议和版权信息</li></ul> <ul><li>商用</li><li>私用</li></ul> <ul><li>分发</li><li>修改</li><li>附加许可</li></ul>
    Unlicense <ul><li>N/A</li></ul> <ul><li>商用</li><li>私用</li><li>分发</li><li>修改</li></ul> <ul><li>责任承担</li></ul>

    开源软件的区分图

    开源授权许可的区别

    其实这里还有一个需要注意的,那就是专利授权,这可能会引起法律问题。比如BSD、MIT在License里边就没有明确专利授权的声明,这就让采用这种License授权的开源软件有可能存在专利授权的争议。GPL-2.0、LGPL-2.1虽然有专利相关的规定,但没有明确指出专利授权与其如何被利用的方式,这点容易产生争议,GPL-3.0就明确了专利授权,就不会存在这个问题。所以公司商业软件使用开源软件需要注意License的版本和里边的具体的描述,当然我们在采用License的时候也可以附加许可。

    你会选择哪种开源授权许可?

    参考:
    http://opensource.org/licenses/alphabetical
    http://choosealicense.com/

    https://www.mozilla.org/en-US/MPL/1.1/
    http://www.openfoundry.org/tw/legal-column-list/8914-patent-clause-in-foss-licenses
    http://blog.csdn.net/techbirds_bao/article/details/8785413
    http://www.oschina.net/news/27273/main-os-license-comparison

    相关文章

      网友评论

        本文标题:开源License

        本文链接:https://www.haomeiwen.com/subject/txzokttx.html