开源协议
前言
如果你经常使用 github 或是 gitee,在每次新建仓库时,它们都会提示你选择开源许可证。如果是自己平时写的一些小工程的话,一般都不会添加开源协议(毕竟不是课设就是实验)。不过,如果你看过一些开源软件中的开源协议,你会发现开源协议的种类五花八门,各类协议中有着许多奇奇怪怪看不懂的名词,不同的协议对于项目有着许许多多的约束限制。因此,我们还是很有必要了解一下开源协议。
OSI 开放源代码促进会
开放源代码促进会(Open Source Initiative),又译开放原始码组织,是一个旨在推动开源软件发展的非盈利组织。 1
OSI 作为标准机构,提出了开源的定义。开发者、用户、公司和政府可以围绕由开源促进会批准的许可证商标和程序建立的信任纽带进而开展开源合作。2
OSI 批准的协议(许可证)
开源的定义
开源不仅仅意味着能够获取和查看源代码。开源软件的分发条款必须符合以下标准。3
Free Redistribution
重分发需要免费
Source Code
程序必须包含源代码,并必须允许以源代码和编译形式分发
Derived Works
许可证必须允许修改和派生作品,并且必须允许它们在与原始软件许可证相同的条款下分发
Integrity of The Author’s Source Code
除非许可证有额外许可,否则需要保证作者源代码的完整性
No Discrimination Against Persons or Groups
许可证不得歧视任何个人或群体
No Discrimination Against Fields of Endeavor
许可证不得限制任何人在特定领域使用该程序
Distribution of License
该程序所附的权利必须适用于所有重新分发该程序的人,而无需这些方执行额外的许可
License Must Not Be Specific to a Product
许可证不得特定于某个产品
License Must Not Restrict Other Software
许可证不得限制其他软件
License Must Be Technology-Neutral
许可证必须是技术中立的
开源协议的作用
开源协议规定了你在使用开源软件时的权利和责任,也就是规定了你可以做什么,不可以做什么。开源协议虽然不一定具备法律效力,但是当涉及软件版权纠纷时,开源协议也是非常重要的证据之一。4
截至 2023 年 10 月,OSI 批准的开源协议 114 个。其中,木兰-白玉兰开放数据许可协议 Mulan Permissive Software License v25 是中国首个开源协议。
开源协议浅析
预备知识
在正式介绍部分开源协议之前,我们需要对一些名词做出一定的解释。
宽松许可证?公共许可证?7
所谓的宽松(Permissive)许可证和公共(Copyleft,又译著佐权、著作权属左、复制左等。但 Copyleft 不是反著作权运动,不主张废止著作权,也不是公有领域6)许可证,其实是根据开源协议授权限制的严格程度进行的划分。
但是严格或宽松并没有一个明确的划分标准。笼统的来说:
对于宽松许可证
- 授权限制较少,使用较为灵活
- 代表协议如 MIT、Apache、BSD 等
- 使用者可以自由修改和闭源发布代码,无需公开源代码
- 适合商业产品,但衍生版本可闭源,不利于开源社区发展
对于公共许可证
- 有较多授权限制要求
- 代表协议如 GPL,LGPL 等
- 衍生代码必须开源,不能闭源商业化
- 保护开源项目源代码继续开源,有利于社区发展
- 不易商业化,且与其他协议代码难以混合
什么是传染性8
开源协议的传染性(License Inheritance)指开源软件中的一项规则,它规定软件的授权条款会 “传染” 给引用或基于该软件所产生的衍生作品,使其必须遵守相同的开源协议。
具体来说,开源协议的传染性体现在:
如果一个软件使用了 GPL 协议的代码,那么这个软件也必须使用GPL协议
如果一个项目中的某个文件使用了 BSD 协议,那么整个项目必须使用BSD协议或兼容的协议
如果在 MPL 协议的代码基础上修改出衍生代码,那么衍生代码也必须采用MPL协议
之所以有传染性,是为了保证开源代码继续开源,避免衍生项目中闭源或变相闭源。这保障了开源软件的继承和发展。
传染性还使不同开源项目代码很难混合使用,需要选择兼容的协议。这对项目选择协议时必须审慎。
兼容性协议说明9
开源协议之间的兼容性指不同协议的代码是否可以混合使用在一个项目中。常见的兼容情况有:
- 宽松许可证之间兼容
宽松许可证如 MIT、BSD、Apache 等之间是兼容的,因为它们对代码的使用和发布都有很少限制。把这些协议的代码混合使用不会有许可证冲突。
- 与宽松许可证的一方兼容
宽松许可证的代码可以和任何其他协议的代码混合使用,因为它几乎没有任何限制要求。
- 相同复制左许可证兼容
同属于强复制左的 GPL 类协议,如 GPL、LGPL、AGPL 等之间是兼容的,可以混合使用。
- 非兼容情况
不能混合使用的情况通常是 GPL 类与其他复制左许可证(如 MPL)、以及与专有软件许可证。这会造成无法满足不同的授权要求的冲突。
协议浅析
以下五个许可证的介绍参考两篇文章10 11的部分内容。
MIT - 受公司欢迎的宽松协议
MIT(The Massachusetts Institute of TechnologyLicense,麻省理工学院许可协议)是众多协议条款中,被广泛使用的其中一种。与其他常见的软件许可协议相比,MIT 是相对宽松的软件许可协议。
MIT 协议允许你任意的使用、复制、修改原 MIT 代码库,随便你卖钱还是开源,唯一的条件就是在修改后的代码或者发行包中包含原作者的信息就行了。
因而很多的公司企业在选用开源产品的时候都首选 MIT 协议,因为可以完全控制这些第三方的代码,在必要的时候可以修改或者二次开发。使用MIT的软件项目有:jquery、Node.js。
BSD - 别借我的名气做宣传
BSD 是 “Berkeley Software Distribution” 的缩写,意思是 “伯克利软件发行版”。
BSD 开源协议是一个给于使用者很大自由的协议。可以自由的使用,修改源代码,也可以将修改后的代码作为开源或者专有软件再发布。 当你发布使用了 BSD 协议的代码,或则以 BSD 协议代码为基础做二次开发自己的产品时,需要满足三个条件:
- 如果再发布的产品中包含源代码,则在源代码中必须带有原来代码中的 BSD 协议
- 如果再发布的只是二进制类库/软件,则需要在类库/软件的文档和版权声明中包含原来代码中的 BSD 协议
- (
重点)不可以用开源代码的作者/机构名字和原来产品的名字做市场推广
BSD 代码鼓励代码共享,但需要尊重代码作者的著作权。BSD 由于允许使用者修改和重新发布代码,也允许使用或在 BSD 代码上开发商业软件发布和销售,因此是对商业集成很友好的协议。
Apache License - 加强法制宣传
Apache License(Apache 许可证),是 Apache 软件基金会发布的一个自由软件许可证。相比于过分简洁的 MIT 和 BSD 协议,Apache License 在保持较为宽松的开源基础上,加上了一些避免法律冲突的限制。
同样本协议也鼓励代码共享和最终原作者的著作权,允许源代码修改和再发布。但是也需要遵循以下条件:
- 需要给代码的用户一份 Apache Licence
- 如果修改了代码,需要再被修改的文件中说明
- 在衍生的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明
- 如果再发布的产品中包含一个 Notice 文件,则在 Notice 文件中需要带有 Apache Licence。你可以再 Notice 中增加自己的许可,但是不可以表现为对 Apache Licence 构成更改
- Apache Licence 也是对商业应用友好的许可。使用者也可以再需要的时候修改代码来满足并作为开源或商业产品发布/销售
百度的深度学习框架 PaddlePaddle 使用了 Apache 协议。
GPL - 强制开源
GPL 全称 GNU General Public License ,译作 GNU 通用公共许可协议。Linux 源码就采用了 GPL 协议进行开源。GPL协议的目的就是强制代码开源和免费使用。
GPL 协议和 BSD、Apache Licence 等鼓励代码重用的许可很不一样。GPL 的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。其最大的特点就是 “开源的传染性”。也就是说,假设某公司使用了具有GPL协议的代码库,那么他理论上也必须把自己的代码库开源。这也就是为什么我们能用免费的各种 Linux,包括商业公司的 Linux 和 Linux 上各种各样的由个人、组织以及商业软件公司开发的免费软件了。
但是,GPL 并没有限制不能够商业化,也就是说你可以拿着原汁原味的开源的 Linux 系统去卖钱,即使买家可以直接在 Github 里找到 Linux kernel source 的全部代码。
LGPL - 让公司能够拿 GPL 卖钱
由于 GPL 协议的“开源传染性”,一些公司肯定无法接受将自己的代码开源出去,这还怎么赚钱呢?于是出现了 LGPL( GNU Lesser GPL),也就是限制更少(针对想闭源卖钱的公司)的 GPL。
LGPL 是 GPL 的一个为主要为类库使用设计的开源协议。和 GPL 要求任何使用/修改/衍生之 GPL 类库的的软件必须采用 GPL 协议不同。LGPL 允许商业软件通过类库引用(link)方式使用 LGPL 类库而不需要开源商业软件的代码。这使得采用 LGPL 协议的开源代码可以被商业软件作为类库引用并发布和销售。
具体来说,如果使用动态链接 LGPL 代码库,则你不需要开源。如果使用静态链接,则你可以通过封装一层的方式避免开源,可以简单理解为只需要开源直接调用 LGPL 库的那部分代码就可以了(狠狠白嫖)。
如果修改 LGPL 协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用 LGPL 协议。因此 LGPL 协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以 LGPL 协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。GPL/LGPL 都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品。
著名的 GUI 开发框架 Qt 使用了 LGPL 协议。
结语12
通过阅读本文,相信你对常见开源协议已经有了初步的了解,这是进行开源项目学习和开发的基础。要注意不同开源协议之间的区别,根据项目需求选择适合的开源协议。本文中的几个开源协议介绍,只是冰山一角,更多的协议和更详细的内容还是需要你自己去查找翻看,下面的图就算是图一乐了。
参考
- 【百度百科】开放源代码促进会
- 【OSI offical】About the Open Source Initiative
- 【OSI offical】The Open Source Definition
- 【OSI offical】OSI Approved Licenses
- 【Github】mulan-baiyulan-data-license
- 【维基百科】Copyleft
- 【Claude】什么是宽松许可证,什么是公共许可证
- 【Claude】什么是传染性
- 【Claude】兼容性协议说明
- 【知乎】GPL、MIT、Apache…一文讲清楚开源协议间的区别
- 【菜鸟教程】各种开源协议介绍
- 【Claude】以教案为使用场景给这篇文章写一个结尾