目录
前言
经过近几年的发展,大数据 还算属于热门话题(当然没有被点名加持的 “区块链” 那么火),市面上也出现了不少大数据方向的公司。
个人感觉 大数据 和 机器学习 也有一定的关系,众所周知,机器学习需要足够多的数据量去支撑模型的训练,而数据集无非有以下几种渠道获取:
- 开源数据集
- 第三方服务公司提供
- 自行爬虫抓取
而在不久前我看到了以下这则新闻:
“一个程序员写了个爬虫程序,整个公司 200 多人被端了。” ---- 创事记

顺着这个思路我还摸到了一篇老文
该文介绍了各种进局子的案例,涉及到的罪名也是五花八门:
窃取商业机密、电信诈骗、侵犯版权、洗钱、协助欺诈 以及 写出不清真的代码...
看来程序员也是高危行业,不止要承受 头冷 和 孤独终老 的风险,一不小心还得进局里...
说到版权问题,这里不得不说哪个程序员在开发时没有使用过 CSDN、博客园、Google、GitHub 呢?
那么我们在参考甚至直接 clone 别人的代码时是否会构成到侵权问题呢?
其实这得看各家协议,例如:
- CSDN 默认 CC 4.0 BY-SA
- 博客园 转载注名出处,并保留声明
- GitHub 可选开源协议(点击查看帮助文档)
这些协议中又有哪些可以商用,哪些可以转载,哪些可以修改分发呢?
哎嘿,这就是今天的正题了。

常见开源软件协议
The Unlicense
如果一种开源许可证没有任何使用条件,连保留作者信息都不需要,那么就等同于放弃版权了。这时,软件可以直接声明进入 "公共领域"(public domain)。任何人都可以自由复制,修改,发布,使用,编译,出售或以源代码形式或已编译形式分发此软件二进制,无论是出于商业目的还是非商目的,以及任何手段。
目前使用该协议的项目有
协议使用
- 在您的软件仓库根目录下创建一个文本文件 (命名为 LICENSE 或 LICENSE.txt)。
- 复制 协议正文 到这个文本文件中。
可选: 添加
Unlicense
到你的软件描述信息中,这可以让别人明确了解该软件是遵循哪种协议发布的。
MIT License
MIT 许可协议之名源自麻省理工学院( Massachusetts Institute of Technology, MIT ),又称 "X 许可协议" ( X License )或 " X11 许可协议 "( X11 License )。它允许别人用你的代码做任何事情,但必须保证你的所有权,并且你无须承担代码使用产生的风险。
目前使用该协议的著名项目有
协议使用
- 在您的软件仓库根目录下创建一个文本文件(命名为 LICENSE 或 LICENSE.txt)
- 复制 协议正文 到该文本文件中
- 将协议中 [year] 替换为当前年份,将 [全名] 替换为你(们)的名字或组织名字。
可选:添加 MIT
到你的软件描述信息中,(例如,Node.js,Ruby 和 Rust)。这可以让别人明确了解该软件是替代协议发布的。
Apache License 2.0
Apache License 2.0与 MIT License 比较类似,但提供了专利贡献者的明确授权,使用者需要放置版权说明。如有修改,需注明修改部分内容。请注意,本协议不授予商标使用权。
目前使用该协议的著名项目有
协议使用
- 在您的软件仓库根目录下创建一个文本文件(命名为 LICENSE 或 LICENSE.txt)
- 复制 协议正文 到这个文本文件中。
提示: Apache Foundation 建议采取其他步骤,在每个源文件的标题中添加样板公告。
可选:添加Apache-2.0
到你的软件描述信息中,(例如,Node.js,Ruby 和 Rust)。这可以让别人明确了解该软件是替代协议发布的。
Mozilla Public License2.0
Mozilla Public License 不是那么严格的 Copyleft 许可证,MPL 允许在其授权下的源代码与其他授权的文件进行混合,包括私有许可证。但在 MPL 授权下的代码文件必须保持 MPL 授权,并且保持开源。使用 MPL 许可的软件并不受专利的限制,其可以自由使用,出售,并可自由的重新发布。带有专利代码的版本仍然可以使用,转让,甚至出售,但未经许可则不能修改代码。此外,MPL 并不授予用户对于开发者商标的使用权。
为了满足 MPL 的条款限制,用户必须负担一些 “责任”,主要是关于散发使用 MPL 许可的软件。用户必须确保重新散发的软件所有源代码均以 MPL 许可,即使是以可执行文件的方式提供或是与其他使用专有软件许可的源代码结合也一样。但若跟以 GNU 通用公共许可协议、GNU 宽通用公共许可证、Affero 通用公共许可证许可的源代码结合则是例外。此时开发者则可选用以上三种更加严格的条款来许可 [5]。
目前使用该协议的项目有
协议使用
- 在源代码的根目录中创建一个文本文件(通常命名为 LICENSE 或 LICENSE.txt)。
- 然后将 许可证文本 复制到该文件中。
提示: Mozilla Foundation 建议采取其他步骤,在每个文件的顶部添加样板公告。
可选:添加 MPL-2.0
到你的软件描述信息中。这可以让别人明确了解该软件是替代协议发布的。
GNU LGPLv3
GNU LGPLv3 和 GNU GPLv3 基本权利义务类似,对大型项目做出了一些限制。它允许个人/商业使用,任何人可对它进行修改,复制,分发;但是必须开源,保留版权信息同时声明变更。当然也不允许你更换开源协议。
协议使用
- 该许可证是 GNU GPLv3 许可证的另一组权限。 按照说明应用 GNU GPLv3。
- 将此文本粘贴到创建的文件的底部,或在源代码的根目录中添加一个单独的文件(通常名为 COPYING.lesser 或 LICENSE.lesser),然后该复制 协议文本 。
提示:自由软件基金会建议采取其他步骤,在每个文件的顶部添加样板公告。 样板可以在 GNU GPLv3 许可证的末尾找到。 在样板公告的所有三个位置的 “常规” 之前插入 “较小” 一词,以确保您引用的是 GNU LGPLv3,而不是 GNU GPLv3。
可选:添加LGPL-3.0
+(或LGPL-3.0
以禁止新版本内容)到您的软件描述信息中。这可以让别人知道该软件是遵守协议发布的。
GNU General Public License v3.0
GPL v3 协议,意味着修改和使用其代码都需要开源,但是这是建立在软件分发的基础上,如果使用代码作为服务提供,而不分发软件,则不需要开源。这实际上是 GPL 协议本身的缺陷。
目前使用该协议的项目有
协议使用
- 在您的软件仓库根目录下创建一个文本文件(命名为 LICENSE 或 LICENSE.txt)
- 复制 协议正文 到这个文本文件中。
提示:自由软件基金会建议采取其他步骤,在每个文件的顶部添加样板公告。
可选:添加GPL-3.0
+(或GPL-3.0
以禁止新版本内容)到您的软件描述信息中,(例如,Node.js,Ruby 和 Rust)。这可以让别人知道该软件是遵守协议发布的。
GNU AGPLLv3
GNU AGPLLv3是该文中最严格的Copyleft 许可。AGPL v3 协议,也就是说,除非获得商业授权,否则无论以何种方式修改或者使用代码,都需要开源。
协议使用
- 在您的软件仓库根目录下创建一个文本文件(命名为 LICENSE 或 LICENSE.txt)。
- 复制 协议正文 到这个文本文件中。
提示:自由软件基金会建议采取其他步骤,在每个文件的顶部添加样板公告。
可选:添加AGPL-3.0
+(或AGPL-3.0
以禁止新版本内容)到您的软件描述信息中。这可以让别人知道该软件是遵守协议发布的。
更多开源协议可点击 附录 查看
如何选择
这里推荐大家使用 choosealicense.online 进行选择,当然也可参考下图
注意
如果我们在 GitHub 上发现了一款软件没有放置开源协议,这可能意味着我们没有使用、修改和分享软件的权力。虽然 GitHub 允许查看、下载和 fork 这份代码,但并不意味着我们拥有使用、修改和分享软件的权力,不论出于任何目的。
如果我们仍旧想要使用,可以做如下选择:
- 请求作者添加许可协议。 除非有明确的表示,否则没有开源协议可能仅仅是因为做者的疏忽。如果这个项目托管在 GitHub 上,我们可以提交一个 Issues 向作者请求添加一个协议,甚至可以添加协议后提交一个合并请求 (pull request)。
- 不要使用这个软件。 寻找一个有开源协议的替代方案。
- 协商一份私人协议 建议请律师起草。
非软件类协议
开源软件协议同样适用于非软件类项目,并且通常来说是更好的选择。尤其是当项目可编辑且拥有源版本时。
对于 数据、多媒体、网站、文章等内容Creative Commons(CC协议)可能用得比较多,至少CSDN默认
关于Creative Commons协议可以参考这篇文章
在此不再赘述。
另:本文大部分内容收集于网络,由于本人并非法律专业及其相关从业者;故而并不能保证内容的完全准确。
如发现纰漏及错误之前,还请
参考鸣谢
choosealicense.online(特别鸣谢)