开源生态|超实用开源License基础知识扫盲帖（下）

上一期我们介绍了关于开源License的一些基本知识。虽然开源License的总体数量很多，但是常用的License还是很有限的。今天我们就更直接地了解下常用License具体的含义和区别。通过这篇文章，首先大家可以对常用License有一个基本的认识，同时可以让我们更加“安全”的引用其他的开源项目，最后如果我们自己需要主导开发开源项目，也可以更有针对性的选择适合自己的开源License。

 

MIT

MIT,源自麻省理工学院(Massachusetts Institute of Technology, MIT),又称X11协议。这是目前最为宽松，限制最少的开源协议。使用MIT License作为开源项目的作者，唯一诉求就是保留版权，而不在有其他任何限制。 在使用MIT License的开源项目时，只需要记住一点：修改后的代码或者发行包，无论是以源代码形式还是二进制形式，必须要包含原作者的许可信息。

 

*代表开源项目：React, Vue, Angular, JQuery, Node.js, Three.js, Lua, .Net Core, Ruby on Rails等

适用商业软件

                       

资料来源于网络

 

BSD

BSD，伯克利软件发行版（Berkeley Software Distribution）。也是相当宽松的开源协议，可以自由地使用，修改源代码，也可以将修改后的代码选择继续开源或者闭源。但是我们要知道的是BSD本身并不是一个协议，它是由五个协议组成：0-Clause、1-Clause、2-Clause、 3-Clause, and 4-Clause。前面的数字代表限制条款的数目，比如4-Clause就是BSD四条款版。第一个版本的BSD指的就是4-Clause，目前4-Clause和1-Clause都已经不怎么再使用了。而0-Clause也发展成为了公共领域协议（Public Domain License），连作者信息都不要求保留。目前最流行的BSD指的是BSD 3-Clause License（BSD-3-Clause），也叫做BSD 3-Clause New/Revised License。所以我们这里主要介绍下BSD-3-Clause在发生派生项目时，需要注意的情况：

1. 如果是开源项目派生，源代码中必须包含原项目中的BSD协议。

2. 如果是闭源项目派生，比如二进制类库或者商业软件，在软件的文档和版权声明中要包含原项目中的BSD协议。

3. 不论开源或闭源项目派生，不可以用BSD项目作者、机构或项目产品的名称做市场推广。

    

与此同时，BSD 2-Clause License（BSD-2-Clause）也比较常用，它也被称为BSD 2-Clause Simplified/FreeBSD License。我们需要知道的是BSD-2-Clause和BSD-3-Clause的最大区别就是，它忽略了上面的第三条“不许炒作打广告”的条款限制。

 

*代表开源项目：Dart, Django, FreeBSD, Flask, Go, Nginx等

适用商业软件

                             

资料来源于网络

 

Apache-2.0

Apache-2.0，是一个由Apache软件基金会发布的自由软件许可证（Apache License Vesion 2.0），最新版本为 “Version 2”。它和BSD类似，也是比较宽松的开源协议，允许用户修改和再发布。但是，发布派生项目时需要注意：

1. 如果修改了源代码，需要在被修改的文件中加以说明。

2. 派生项目中，需要带有原项目代码中的Apache-2.0协议，同时还包括商标，专利声明以及其他原作者规定需要包含的说明。

3. 派生项目中，如果包含Notice文件，则在Notice文件中也需要带有Apache-2.0协议。

    

*代表开源项目：Android, Apache HTTP Server, Hadoop, Spark, Babylon.js, LLVM, Log4j等

适用商业软件

                     

资料来源于网络

 

MPL

MPL，由Mozilla基金会开发和维护（Mozilla Public License）。MPL在经历了1.0和1.1两个版本后，目前最新版本为2.0，即MPL-2.0。上篇文章中我们提到过著作权授权条款（Copyleft Licenses）类型的License，MPL就是其中之一，所以它的要求相对来说比较严格。MPL开源项目的主要特点包括：

1. 派生项目中引用MPL协议源代码的部分仍然要保持开源。如果，对MPL项目的源代码进行了修改，需要对修改部分作出说明。

2. 原项目是基于其他开源协议甚至是闭源的商业项目，引用MPL项目后，如果仍然想保持原项目的开源协议或者是继续闭源发布，那可以通过设计一个调用MPL项目代码的“接口”程序。此接口程序的源代码必须保持MPL协议，MPL项目本身也要放到一个独立的程序文件继续保持MPL协议，而原项目其他的代码部分不受影响。

3. MPL项目的作者，不能提供已经受专利保护的源代码（除非他本人是专利权人，并书面向公众免费许可这些源代码），而且MPL项目本身所包含的源代码也不能再被用来申请相关专利。

    

   我们可以看到，MPL并没有要求派生项目必须完全开源或者必须遵循MPL协议，它允许通过“接口”的机制，使得派生项目中存在私有模块，而且MPL是可以兼容于GPLv3（非GPLv2）及Apache-2.0协议的。这些特性使得MPL对商业项目具有一定的扩容度。因此，我们也称MPL为弱著作权授权条款。

 

*代表开源项目：Firefox, Thunderbird, Letsencrypt/boulder等

适用商业软件，但要额外注意上面提到的一些事项。

                    

资料来源于网络

 

GPL

GPL，GNU通用公共许可证（GNU General Public License），由自由软件基金会（Free Software Foundation，FSF）理查德·斯托曼为GNU项目所撰，是最著名的开源 License。GNU的缩写是“GNU is Not Unix”，关于GNU项目的细节可以参考一下链接：

https://en.wikipedia.org/wiki/GNU_Project

GPL也属于家族型条款，包含了GPLv1、GPLv2和GPLv3三个条款。GPL还有一个比喻性的称呼，叫做“传染性”协议，这也是GPL协议最大的特点：任何一个项目只要用到了GPL协议的代码，那这个项目自身必须开源，而且也必须遵守GPL协议。这就是GPL的传染性，我们也称GPL为强著作权授权条款。

 

当下，GPLv2和GPLv3是经常被用到的GPL协议，而GPLv1已经不再被广泛使用了。GPLv3是基于GPLv2进行修订后的协议。修订后的v3协议内容篇幅是v2的两倍，主要是在改进和更清晰的描述一些主题条款，包括专利赔偿，内部化和许可侵权的补救措施等等。详情可以参考如下链接：

http://www.groklaw.net/article.php?story=20060118155841115

 

对于我们只需要知道，GPLv2和GPLv3最大的不同点是：它们两个互相完全不兼容。GPLv3与其他开源协议的兼容性会更高，比如前面提到的MPL完全可以兼容于GPLv3，但是不兼容GPLv2。

 

*代表开源项目：Linux, MySQL, Blender, VLC等

允许商用，但不适用于闭源要求的商业软件。

                    

资料来源于网络

 

LGPL

LGPL，GNU 宽通用公共许可证（GNU Lesser General Public License）。它是GPL的一个演进版本协议，目的是为了解决GPL的强传染性问题，也被定义为一个 "类库引用" 开源协议。针对于不同版本的GPL协议，LGPL也有相对应的不同版本。详情可以参考如下链接：

https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License

 

LGPL的具体要求是：

1. 跟GPL一样，LGPL的派生项目也必须采用LGPL协议。

2. 如果派生项目引用LGPL项目的方式，不是将源代码包含其中，而是通过“库”的调用或者链接方式进行引用，那这个新的派生项目则允许闭源。

    

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

 

*代表开源项目：7-Zip, FFmpeg, FreeCAD, VLC, Qt等

允许商用，闭源要求的商业软件需要注意引用方式。

                                

资料来源于网络

 

介绍完这些常用的开源License之后，我们可以看出，如果不考虑细节条款，总体按照“宽松度”属性的排序应该是：

MIT>BSD>Apache-2.0>MPL>LGPL>GPL。

 

最后，我们要说的是Orillusion WebGPU引擎也即将要跟大家见面啦！经过内部的讨论，最终我们决定选择最为宽松的MIT协议作为我们的开源License。目的就是让大家在没有任何顾虑的情况下，放心使用我们的引擎核心，更自由的发挥创造力，服务更多的应用场景，丰富开源社区，为WebGPU和Web3D领域的发展做出自己的贡献！也希望中国能有更多优秀的底层引擎技术开发者，通过开源的形式打造出世界级的引擎产品，为未来的3D场景爆发时代提供底层的基础生产力工具！我们一起努力！

---

欢迎大家加入 Orillusion 开发者社群，陪我们一起见证 WebGPU 的发展，快来成为 Orillusion 社区第一批 “源” 住民吧！让一起打造有价值、有活力、有温度的共创社区！长按或扫描下方二维码添加小鸥微信吧！

                                   

---

Orillusion 致力于打造全世界第一款完全开源基于 WebGPU 标准的一种轻量级渲染引擎，目标是在浏览器中实现桌面级的渲染效果，支持超大复杂场景的 3D 呈现。易上手，易分享，易迭代，易协作、成本低，跨平台是我们的核心优势，我们将为 3D 场景爆发时代提供引擎基础工具。

未来我们将会持续把最干货最前沿的 WebGPU 技术分享给每一位社区成员，也欢迎大家为 Orillusion 开源社区做出自己的贡献。我们一直坚信，开源社区的技术留痕是每一位技术人员最崇高的追求！因此，我们尊重，我们认可，我们更期待，加入 Orillusion，让我们共同进步！

                                                                                                                                      ——Link uncharted, 链接未来世界

---

长按关注 Orillusion 官方微信，第一时间了解 WebGPU 引擎动向，学习开发技巧，一起打造 Web 3D 世界！