赞
踩
上一期我们介绍了关于开源License的一些基本知识。虽然开源License的总体数量很多,但是常用的License还是很有限的。今天我们就更直接地了解下常用License具体的含义和区别。通过这篇文章,首先大家可以对常用License有一个基本的认识,同时可以让我们更加“安全”的引用其他的开源项目,最后如果我们自己需要主导开发开源项目,也可以更有针对性的选择适合自己的开源License。
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,伯克利软件发行版(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在发生派生项目时,需要注意的情况:
如果是开源项目派生,源代码中必须包含原项目中的BSD协议。
如果是闭源项目派生,比如二进制类库或者商业软件,在软件的文档和版权声明中要包含原项目中的BSD协议。
不论开源或闭源项目派生,不可以用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软件基金会发布的自由软件许可证(Apache License Vesion 2.0),最新版本为 “Version 2”。它和BSD类似,也是比较宽松的开源协议,允许用户修改和再发布。但是,发布派生项目时需要注意:
如果修改了源代码,需要在被修改的文件中加以说明。
派生项目中,需要带有原项目代码中的Apache-2.0协议,同时还包括商标,专利声明以及其他原作者规定需要包含的说明。
派生项目中,如果包含Notice文件,则在Notice文件中也需要带有Apache-2.0协议。
*代表开源项目:Android, Apache HTTP Server, Hadoop, Spark, Babylon.js, LLVM, Log4j等
适用商业软件
资料来源于网络
MPL,由Mozilla基金会开发和维护(Mozilla Public License)。MPL在经历了1.0和1.1两个版本后,目前最新版本为2.0,即MPL-2.0。上篇文章中我们提到过著作权授权条款(Copyleft Licenses)类型的License,MPL就是其中之一,所以它的要求相对来说比较严格。MPL开源项目的主要特点包括:
派生项目中引用MPL协议源代码的部分仍然要保持开源。如果,对MPL项目的源代码进行了修改,需要对修改部分作出说明。
原项目是基于其他开源协议甚至是闭源的商业项目,引用MPL项目后,如果仍然想保持原项目的开源协议或者是继续闭源发布,那可以通过设计一个调用MPL项目代码的“接口”程序。此接口程序的源代码必须保持MPL协议,MPL项目本身也要放到一个独立的程序文件继续保持MPL协议,而原项目其他的代码部分不受影响。
MPL项目的作者,不能提供已经受专利保护的源代码(除非他本人是专利权人,并书面向公众免费许可这些源代码),而且MPL项目本身所包含的源代码也不能再被用来申请相关专利。
我们可以看到,MPL并没有要求派生项目必须完全开源或者必须遵循MPL协议,它允许通过“接口”的机制,使得派生项目中存在私有模块,而且MPL是可以兼容于GPLv3(非GPLv2)及Apache-2.0协议的。这些特性使得MPL对商业项目具有一定的扩容度。因此,我们也称MPL为弱著作权授权条款。
*代表开源项目:Firefox, Thunderbird, Letsencrypt/boulder等
适用商业软件,但要额外注意上面提到的一些事项。
资料来源于网络
GPL,GNU通用公共许可证(GNU General Public License),由自由软件基金会(Free Software Foundation,FSF)理查德·斯托曼为GNU项目所撰,是最著名的开源 License。GNU的缩写是“GNU is Not Unix”,关于GNU项目的细节可以参考一下链接:
GPL也属于家族型条款,包含了GPLv1、GPLv2和GPLv3三个条款。GPL还有一个比喻性的称呼,叫做“传染性”协议,这也是GPL协议最大的特点:任何一个项目只要用到了GPL协议的代码,那这个项目自身必须开源,而且也必须遵守GPL协议。这就是GPL的传染性,我们也称GPL为强著作权授权条款。
当下,GPLv2和GPLv3是经常被用到的GPL协议,而GPLv1已经不再被广泛使用了。GPLv3是基于GPLv2进行修订后的协议。修订后的v3协议内容篇幅是v2的两倍,主要是在改进和更清晰的描述一些主题条款,包括专利赔偿,内部化和许可侵权的补救措施等等。详情可以参考如下链接:
对于我们只需要知道,GPLv2和GPLv3最大的不同点是:它们两个互相完全不兼容。GPLv3与其他开源协议的兼容性会更高,比如前面提到的MPL完全可以兼容于GPLv3,但是不兼容GPLv2。
*代表开源项目:Linux, MySQL, Blender, VLC等
允许商用,但不适用于闭源要求的商业软件。
资料来源于网络
LGPL,GNU 宽通用公共许可证(GNU Lesser General Public License)。它是GPL的一个演进版本协议,目的是为了解决GPL的强传染性问题,也被定义为一个 "类库引用" 开源协议。针对于不同版本的GPL协议,LGPL也有相对应的不同版本。详情可以参考如下链接:
https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License
LGPL的具体要求是:
跟GPL一样,LGPL的派生项目也必须采用LGPL协议。
如果派生项目引用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 标准的一种轻量级渲染引擎,目标是在浏览器中实现桌面级的渲染效果,支持超大复杂场景的 3D 呈现。易上手,易分享,易迭代,易协作、成本低,跨平台是我们的核心优势,我们将为 3D 场景爆发时代提供引擎基础工具。
未来我们将会持续把最干货最前沿的 WebGPU 技术分享给每一位社区成员,也欢迎大家为 Orillusion 开源社区做出自己的贡献。我们一直坚信,开源社区的技术留痕是每一位技术人员最崇高的追求!因此,我们尊重,我们认可,我们更期待,加入 Orillusion,让我们共同进步!
——Link uncharted, 链接未来世界
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。