给程序员的经常使用开源许可与 CC 许可简明手册

时间 2019-11-17

原文原文链接

从程序的版权说开去html

有使用 GitHub 这一类代码仓库的同窗想必都有接触过 License 这个名词, 在咱们建立开源项目的时候, GitHub 会建议为咱们的项目添加 License, 若是你和 kurisu 同样不太清楚这些协议之间的区别, 以致因而使用 MIT 许可的常客的话: joy:, 或许下面读完这些内容, 下一次在选择 License 的时候, 会有更多选择.git

本文将从 版权 (Copyright) 开始, 简述 Copyleft 的诞生, 依次介绍常见的开源协议, 例如 GPL V3, BSD 等. 在最后会介绍在博客和问答网站中常见的 CC(Creative Commons) 许可, 或许下一次你在发表博文的时候就能够在末尾加上你的 CC 许可.程序员

从 Copyright 到 Copyleft

Copyright 也就是 版权, 对于咱们独立创做的做品, 咱们做为它的创做者, 咱们它所有内容的版权. 这样能够很好的保障咱们的创做者权益. 可是在 IT 领域, 特别开源软件运动兴起后, 这种十分严格的版权制度开始凸显出它的不足.github

打个比方, 例如在 GitHub 这种平台, 咱们在一些感兴趣的项目上作二次开发后, 再发布, 这在今天是很是常见的一种作法, 可是若是时间倒退到二三十年前, 这将是一场灾难, 那时尚未 GitHub 这种平台, 咱们从论坛得到了源代码后, 进行二次创做后, 须要征求原做者意见, 包括在商业、署名、是否容许使用原做者的名字作宣传等方面都须要较好的沟通, 而后再发布. 若是这个软件很是受欢迎, 进行二次创做的人不少, 那么这将成为一场灾难...web

那么在自由软件运动中, 开源软件运动的发起者 / 组织者 理查德 · 斯托曼 (Richard Stallman) 提出了 Copyleft. 它是一种利用现有著做权体制来保障用户软件自由使用的许可方式. 用简单的话说 Copyleft 就是 用户能够在创做者的许可下, 自由的使用和分发以及修改, 这样就免去了不少的沟通成本, 而且最重要的是, 这在不反对原有的著做权法的基础上, 进一步的促进 创做自由, 与保障著做内容的传播.redis

这里比较有意思的是, Copyleft 不只名字和版权的英文 CopyRight 是反过来的, 图标也是版权标志的 C 朝向左边.express

Copyleft 起初是在由 GNU 项目 提出并使用, 到实际使用中也就是咱们在 GitHub 所选择的各类许可, 例如 GPLv3, MIT, Mozilla Public License 2.0 等等. 咱们下面将会一一介绍这些常见的许可.apache

常见的开源许可

开源许可能够分为以下两大类bash

宽松式 (permissive) 许可
- MIT License
- BSD License
- Apache License
- Do What The F*ck You Want To Public License
Copyleft 许可
- GPL
  - AGPL
  - LGPL
  - Mozilla Public License (MPL)

这些许可都有这些共同的特色swoole

用户没有使用限制, 能够作任何想作的事情
不保证代码质量，用户自担风险
用户若是将源代码再次从新发布, 必须披露原始做者

宽松式许可

MIT

MIT 许可许可来自麻省理工学院, 与 GPL 兼容, 能够与 GPL 做品融合

用户只须要遵照这一个义务, 就能够任意的使用该软件, 甚至可使用原做者的名字来进行软件促销, 又或者是能够修改源码后闭源.

全部的副本中都要包含该 License 文件 (Wiki 上说是包括著做权声明和本许可声明, 可是其实他们都写在了这个 License 文件里, 这是一个 MIT License 样例)

MIT License

Copyright (c) 2019 Amatist_Kurisu

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

复制代码

同时最初做者 (版权者) 能够根据本身的需求修改 License 原文的内容再发布, 这和 GPL 系列等许可很不一样, GPL 系列许可是不容许版权者修改 License 原文内容的.

可是由于这个特性, 因此有可能版权者会在 License 中添加更多的约束, 出现不少变种. 例如 FSF 为 ncurses 的 X11 许可 (MIT 变种) 中, 就不容许使用原做者的名字做为广告宣传或者促销. 因此对使用 MIT 许可的项目, 可能须要检查一下他的 License 内容.

到 2015 年为止, 是 Github 上最受欢迎的许可方式, 使用过 MIT License 的项目包括 Node.js, Nim, Ruby on Rails 等

BSD

BSD 开源许可的全称是 Berkeley Software Distribution , 来自加州大学伯克利分校, BSD 有 3 目前还在使用的许可, 以及 1 种已经消失在历史的长河中的许可,

已经再也不使用的许可
- BSD-4-Clause License (BSD 四句许可)
目前还在使用的许可
- BSD-3-Clause License (BSD 三句许可)
- BSD-2-Clause License (BSD 二句许可)
- BSD-0-Clause License (BSD 零句许可)

BSD 许可后面的序号表明的是这个许可有几句, 例如 BSD 4 的许可就长这样.

* Copyright (c) 1982, 1986, 1990, 1991, 1993
* 著做权由加州大学董事会全部。著做权人保留一切权利。
*
* 这份受权条款，在使用者符合如下四条件的情形下，授予使用者使用及再散播本
* 软件包装原始码及二进位可执行形式的权利，不管此包装是否经改做皆然：
*
* 1. 对于本软件源代码的再散播，必须保留上述的版权宣告、此四条件表列，以
*    及下述的免责声明。
* 2. 对于本套件二进位可执行形式的再散播，必须连带以文件以及／或者其余附
*    于散播包装中的媒介方式，重制上述之版权宣告、此四条件表列，以及下述
*    的免责声明。
* 3. 全部说起本软件功能或是本软件使用之宣传材料，都必须包还含下列之交
*    待文字：
*        “本产品内含有由柏克莱加州大学及其软件贡献者所开发的软件。”
* 4. 未获事前取得书面许可，不得使用柏克莱加州大学或本软件贡献者之名称，
*    来为本软件之衍生物作任何表示支持、承认或推广、促销之行为。
*
* 免责声明：本软件是由加州大学董事会及本软件之贡献者以现状（"as is"）提供.... <省略>

复制代码

这个许可看起来其实就是 MIT 许可再增长第三条和第四条, 可是正是由于其中的第三条致使该许可遭到反对. 全部说起本软件功能或是本软件使用之宣传材料，都必须本产品内含有由柏克莱加州大学及其软件贡献者所开发的软件, 若是这个程序只拥有一个 BSD-4 许可的依赖倒还好, 只须要一行致谢. 可是若是是依赖了大量 BSD-4 许可的软件, 那致谢名单简直就是灾难了.... 想象一下, 网站最下方很长很长的一段都是致谢名单, 而且, 这些致谢名单须要程序员本身经过脚本或者肉眼统计并添加.

1997 年的 NetBSD 版本中统计了 75 个这样的致谢. 同时这个条款于 GNU GPL 不兼容. 因此在 1999 年, 不少的 BSD 许可的版权者删除了 BSD-4 中的第三句, 新的许可被称为 BSD-3(-Clause) 或者 BSD-new.

以后在 FreeBSD 中使用的是更简单的 BSD-2 许可, 在本来 BSD-3 的基础上删除了第三句, 也就是上面 BSD-4 中的第四句. 这一版本的 BSD 许可和 MIT 许可基本一致.

以上就是 BSD 的发展过程, BSD-4 许可修改后的 BSD-3 和 BSD-2 是与 GPL 相容的许可

Apache

Apache 许可来自 Apache 软件基金会 , 起初做为 Apache 基金会下全部项目的开源许可, 后来许多非 Apache 基金会项目也是用了 Apache 许可.

Apache 许可和咱们刚刚提到的各类许可相比相对严格, 它容许用户自由使用 / 分发 / 商用 / 修改软件, 可是须要遵照下面的规范.

首先 Apache Public License 的声明不是写在 License 文件中, 因此你须要在每一个文件的开头添加一份通告, 不然就不是有效的声明相似于下面这样:

Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

或者你也能够参考 Swoole 项目, 使用自定义的通告,

/*
  +----------------------------------------------------------------------+
  | Swoole                                                               |
  +----------------------------------------------------------------------+
  | This source file is subject to version 2.0 of the Apache license,    |
  | that is bundled with this package in the file LICENSE, and is        |
  | available through the world-wide-web at the following url:           |
  | http://www.apache.org/licenses/LICENSE-2.0.html                      |
  | If you did not receive a copy of the Apache2.0 license and are unable|
  | to obtain it through the world-wide-web, please send a note to       |
  | license@swoole.com so we can mail you a copy immediately.            |
  +----------------------------------------------------------------------+
  | Author: Tianfeng Han  <mikan.tenny@gmail.com>                        |
  +----------------------------------------------------------------------+
*/
复制代码

其次, 除了要在根目录下放置 License 文件外, 还须要放置一个 NOTICE 文件, 放置通告声明以及项目中用到的所有的第三方库的名字, 最好能够加上做者名字和项目地址. 同时你必须验证这些第三方库的许可和 Apache 2.0 相容. 同时若是你修改了这些第三方库, 则要指出进行了何种修改.

最后若是你须要修改再发布一个 Apache 许可的软件, 你须要明确指出进行了何种修改.

Do What The F*ck You Want To Public License

若是修改了本许可, 必须修改许可名称

该许可基本就等于直接贡献到公有领域. 该许可与 GPL 相容.

笔者的 Kuri-su/CAPTCHA_Reader 项目最初用的 MIT 许可, 在看到这个有趣的许可后就转到该许可了: joy:.

Copyleft 许可

GPL

GPL 系列许可来自 FSF (自由软件基金会), 初衷是给予终端用户运行 | 学习 | 共享 | 修改软件的自由, 极力的避免自由软件私有化. 同时 GPL 许可也包含免责条款以及不为软件提供品质担保.

GPL 许可相比前面提到的 MIT 和 BSD 许可复杂不少 (毕竟一篇几百行的文章: joy:). 总结一下, GPL 有三个特色:

任何软件, 只要使用了 GPL 许可保护的软件 (或者第三方库), 且向非开发人员发布时, 软件自己也就自动成为受 GPL 保护而且约束的. (GPL 许可原文第 5 部分, 描述集合的那段)
若是对 GPL 许可保护下的源代码进行修改, 则修改后发布的源代码必须也使用 GPL 许可, 并且不容许附加其余限制.
使用 GPL 许可保护的软件向非开发人员发布 (二进制包) 时, 必须公开源码.(GPL 许可原文第 6 部分)

/* # 版权声明 This file is part of <Foobar>. Copyright (C) <year> <name of author> # 使用 GPL 许可声明 <Foobar> is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <https://www.gnu.org/licenses/>. */
复制代码

因此只要使用了 GPL 的包 , 就必须公开源代码, 并且也会变成 GPL 的一员. 这也就是被吐槽的 GPL 许可是一种丧尸病毒 :joy:.

除此以外, GPL 不限制商用. 甚至容许在转发完整副本时, 能够选择收取必定金额, 也能够选择提供技术支持或品质担保以换取收入.

咱们看到对于软件分发模式的商业模式 (例如微软), GPL 能够很好的约束. 可是随着 Google,AWS 等云服务商的兴起, GPL 开始出现漏洞. 由于他们自己不发布软件, 而是利用软件在云端提供服务, 但 GPL 生效的前提是 发布 软件, 这种方式绕开了 GPL 所定义的约束. 所以为了不这个漏洞, 而提出了 AGPL 许可.

AGPL

AGPL 的全称是 GNU Affero General Public License , 是对 GPL 的一个补充, 他避免了 GPL 和 LGPL 的一个漏洞. 主要针对各类云服务商.

AGPL 由 Affero 公司发起, 目前发展到 v3, 和 GPL 的版本对应. AGPL 继承了 GPL 所有的条款, 同时在此基础上增长了一条.

若是其许可下的软件与用户经过网络进行交互，那么就须要提供源代码给用户，全部的修改也一样要提供给用户。
复制代码

在本身的项目中使用 AGPL 许可发布, 基本和使用 GPL 许可发布同样, 惟一的不一样是 License 须要使用 AGPL 的 License.

LGPL

LGPL 全称 GNU Lesser General Public License, 顾名思义, 是一个弱化的 GPL 许可. LGPL 容许软件经过类库引用 (link) 方式使用 LGPL 类库而不须要开源软件的代码. 除此以外, 在其余部分保持和 GPL 一致.

经过这种方式, LGPL 减低了传染性.

使用 LGPL 的方式和 GPL 相似, 不过你须要复制一份 LGPL 的纯文本版, 放在叫作 COPYING.LESSER 的文件中.(也就是说, 整体上你须要复制两份文件, 一份 GPL 许可的纯文本版, 一份 LGPL 的纯文本版)

到这里就介绍完了开源许可, 以后咱们将介绍一下咱们常常在博客看到的 CC 许可

Creative Commons (常简称 CC 许可)

咱们经常会在一些网站上看到相似于下图这样的图标.

它就是 CC 许可声明, CC 许但是一种 公共著做权许可许可 , CC 许可规定了四种基本元素

署名 (BY)
- 用户在使用该做品的同时, 须要 按照做者指定的方式对做品进行许可
非商业使用 (NC)
- 用户在使用该做品的同时, 不得以商业目的使用该做品
禁止演绎 (ND)
- 用户在使用该做品的同时, 不得修改该做品
相同方式共享 (SA)
- 用户在使用该做品的同时, 若是你修改 (派生) 了该做品, 在散播派生做品的同时须要遵照许可,

可使用以上四种元素进行任意组合, 获得多种许可许可, 不过由于 ND 和 SA 是互斥的两种许可, 因此一般只有 11 种有效许可.

同时外加一种 CC 0 许可, 采用该许可即表明做者宣布放弃该做品的一切版权，该做品进入共有领域。:joy:

关于 CC 许可的版本

细心的同窗会注意到, 这个博客的博文也使用了 CC 许可, 后面带有 4.0 的字样. 是的, CC 许可也存在版本, 不过对于使用者来讲基本没有太大区别.

最新的 4.0 版（于 2013 年 11 月 25 日发布）不须要移植就能够适用于各地的法律，4.0 版并不鼓励移植，而是但愿能做为一个全球通用的许可方式。有兴趣的话能够查看各个版本原文, 这里给出 by-nc-sa 各版本的 CC 许可的原文连接.

一些小技巧

若是你须要在你的网站挂上 CC 许可的图标, 只须要修改下面这个 URL 的许可种类部分便可, 也就是 by-nc-sa , 一般的顺序是 by -> nc -> nd/sa ,

https://user-gold-cdn.xitu.io/2019/8/21/16cb4954959167db?w=88&h=31&f=png&s=1888
复制代码

结

除了上面到的这些, 还有 BSL, EPL 等的开源许可, 这里就不详细介绍了, 有兴趣的话能够自行 Google 了解.

网络上有很是多的关于开源许可和 CC 许可的介绍, 不过我的感受介绍的有些片面并且分散, 且本身理解的不是很明白, 但愿本身能总结并记录下来, 也但愿读者能够根据这篇文章比较系统的了解到开源许可和他们之间的不一样, 在为本身的项目挑选许可的时候再也不犹豫.

因为做者并非法律专业, 对于这些许可的了解来自互联网, 不免有错误的理解和疏漏. 有任何的错误, 欢迎到 kuri-su/KBlog 提 Issue 敦促做者修改.

PS: 撸完这篇文章, 也算是了了个心结... 每次本身的开源项目选开源许可的时候, 不重要的选 MIT, 重要的选 GPL_V3 , 文章的 CC 许可写 by-nc-nd-sa :joy:, 终于能够确定的选择本身须要的许可了 (擦眼泪).

这篇文章写的至关累... 主要本身不太懂.. 而后各类资料也比较少... 大段的都是法律文书类的.. 看的很是费劲....

Ref:

opensource.org/licenses/al…

opensource.org/licenses/ca…

zh.wikipedia.org/wiki/著做權

zhuanlan.zhihu.com/p/20641764

creativecommons.org/choose/

zh.wikipedia.org/wiki/知识共享

zh.wikipedia.org/wiki/知识共享许可…

zh.wikipedia.org/wiki/Copyle…

freetstar.com/e79086e8a7a…

choosealicense.com/

www.zhihu.com/question/51…

zh.wikipedia.org/wiki/Affero…

zh.wikipedia.org/wiki/MIT許可證

en.wikipedia.org/wiki/Apache…

univasity.iteye.com/blog/129265…

www.eclipse.org/legal/epl-2…

en.wikipedia.org/wiki/BSD_li…

zh.wikipedia.org/wiki/GNU通用公…

zh.wikipedia.org/wiki/WTFPL

www.rt-thread.org/qa/thread-4…

softwareengineering.stackexchange.com/questions/3…

www.osehra.org/wiki/how-ap…

zh.wikipedia.org/wiki/Mozill…

adoyle.me/blog/how-to…

doc.yonyoucloud.com/doc/sfd-gpl…

baike.baidu.com/item/GPL/23…

jxself.org/translation… (GPL 许可的中文译本, 翻译的十分流畅, 推荐阅读, 本博客已备份该文章)

www.gnu.org/licenses/gp… (如何使用 GPL 的 Gnu.org 官方教程)

原文首发于 kuricat.com

欢迎到 Kuri-su/KBlog 开 Issue 讨论

给程序员的经常使用 开源许可 与 CC 许可 简明手册