常见的开源软件许可证(License)

发布时间 2023-10-06 15:57:48作者: 柯南。道尔

常见的开源软件许可证(License)

软件许可证(software license)是一种格式合同,由软件作者与用户签订,用以规定和限制软件用户使用软件或其源代码的权利,以及作者应尽的义务

License受到《合同法》的保护

开源的定义

开放源代码促进会(Open Source Initiative-OSI),提出开源需要满足的十个条款

  1. Free Redistribution(免费分发)
  2. Source Code(源代码)
  3. Derived Works(衍生作品)
  4. Integrity of The Author's Source Code(作者源代码的完整性)
  5. No Discrimination Against Persons or Groups(不歧视个人或群体)
  6. No Discrimination Against Fields of Endeavor(不歧视任何领域)
  7. Distribution of License(分发许可证)
  8. License Must Not Be Specific to a Product(许可证不得针对特定产品)
  9. License Must Not Restrict Other Software(许可证不能限制其他软件)
  10. License Must Be Technology-Neutral(许可证必须是技术中立的)

OSI官网对于开源的定义(Open Source Definition):https://opensource.org/osd/

开源许可证的种类

OSI批准的许可证是符合开源的定义的许可证。OSI认可的许可证(License)有很多,主要分为两大类

  • 宽松自由软件授权许可证(Permissive Licenses):开源项目被修改并再发布时,不要求公开源代码。

    如:MIT,BSD,Apache-2.0

  • 著作权授权许可证(Copyleft Licenses):开源项目被修改并再发布时,必须要公开源代码。

    如:MPL,GPL,LGPL

Github官网也提供了一个许可证的介绍,使用户针对自己的项目选择合适的License:https://choosealicense.com/

常见的开源许可证

MIT

MIT许可证名字源自麻省理工学院(Massachusetts Institute of Technology),又称为"X条款"

这是目前最为宽松,限制最少的开源协议。使用MIT License作为开源项目的作者,唯一诉求就是保留版权,不再有其他任何限制。在使用MIT License的开源项目时,只需要记住一点:修改后的代码或发行包,无论是以源代码还是二进制形式,必须要包含原作者许可信息

相关协议的开源项目: Vue,Node.js

BSD

BSD许可证原来时用在加州大学伯克利分校发表各个4.4BSD版本上面的,后来逐渐沿用下来了(BSD-Berkeley Software Distribution)。

这也是一个相当宽松的协议,BSD本身并不是一个协议,它是由五个协议组成:0-Clause、1-Clause、2-Clause、3-Clause、4-Clause。前面的数字代表限制条款的数目。目前4-Clause和1-Clause都已经不再使用。0-Clause也发展成了公共领域协议(Public Domain License),此协议连作者信息都不要求保留。目前最流行的BSD指的是BSD 3-Clause License(BSD-3-Clause)。以下是BSD 3-Clause在发生派生项目时,需要注意以下情况:
1.如果是开源项目派生,源代码中必须包含原项目中的BSD协议
2.如果是闭源项目派生,比如二进制类库或商业软件,在软件的文档和版权声明中要包含原项目中的BSD协议
3.不论开源或闭源项目派生,不可以用BSD项目作业、机构或项目产品名称做市场推广

BSD 2-Clause License(BSD-2-Clause)也比较常用,BSD-2-Clause与BSD-3-Clause的最大区别就是没有上面的第三条条款限制

相关协议的开源项目: Go,Nginx

Apache-2.0

Apache-2.0,是一个由Apache软件基金会发布的自由软件许可证(Apache License Version 2.0),最新版本是"Version 2"。它和BSD类似,也是比较宽松的开源协议,运行用户修改和再发布,但发生派生项目时需要注意以下情况:
1.如果修改了源代码,需要在被修改的文件中加以说明
2.派生项目中,需要带有原项目代码中的Apache-2.0协议,同时还包括商标、专利声明以及其他原作者规定需要包含的说明
3.派生项目中,如果包含Notice文件,则在Notice文件中也需要带有Apache-2.0协议

相关协议的开源项目: Android,Hadoop

MPL

MPL,由Mozilla基金会开放和维护(Mozilla Public License)。目前最新的版本为2.0,即MPL-2.0。MPL属于著作权授权许可证(CopyLeft License)类型,因此要求相对而言比较严格。包含以下特定
1.派生项目中引用MPL协议源代码的部分仍然要保持开源,如果对MPL项目源代码进行了修改,需要对修改部分做出说明
2.原项目是基于其他开源协议或者是闭源的商业项目,在引用MPL项目后,如果想保持原项目的开源协议或是继续闭源发布,那可以通过设计一个调用MPL项目代码的“接口”程序,此接口程序的源代码必须保持MPL协议,MPL项目本身也要放到一个独立的程序文件继续保持MPL协议,而原项目其他部分代码不受影响
3.MPL项目的作者,不能提供已经受专利保护的源代码,而且MPL项目本身所包含的源代码也不能用来申请相关专利

可以看到,MPL并没有要求派生项目必须完全开源,它运行通过"接口"的机制,使得派生项目中存在私有模块,并且MPL是可以兼容于GPLv3以及Apache-2.0协议的。这些特性使得MPL对商业项目具有一定的扩容度,因此MPL也被称为弱著作授权许可证

相关协议的开源项目: Firefox

GPL

GPL,GNU通用公共许可证(GNU General Public License),由自由软件基金会(Free Software Foundation ,FSF)理查德-斯托曼为GNU项目编写的,是最著名的开源License。GNU是“GNU is Not Unix”的缩写

GPL也属于家族型条款,包含了GPLv1、GPLv2、GPLv3 三个条款。任何一个项目只要用到了GPL协议的代码,那这个项目自身必须开源,并且必须遵守GPL协议(强传染性),GPL是强著作权授权许可证

当前,GPLv2、GPLv3是被经常使用的GPL协议,GPLv1已经不再被使用,GPLv3是基于GPLv2进行修订后的协议。GPLv2与GPLv3两个互相完全不兼容

相关协议的开源项目: Linux,MySQL

LGPL

LGPL,GNU宽通用公共许可证(GNU Lesser General Public License)。它是GPL的一个演进版本,目的是解决GPL的强传染性问题,也被定义为一个"类库引用"开源协议。LGPL同样有多个版本。

派生项目需要注意以下几点:
1.LGPL的派生项目也必须采用LGPL协议
2.如果派生项目引用LGPL项目的方式,不是将源代码包含其中,而是通过“库”的调用或者链接方式进行引用,那么新项目运行闭源

可以看出,LGPL协议的开源项目,可以当做第三方类库被闭源商业软件引用,但不能以其为基础,通过修改源码的形式进行派生

相关协议的开源项目: 7-Zip,FFmpeg

参考网址

https://my.oschina.net/u/5567858/blog/5535171

http://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html