开源软件License汇总

开源软件英文为Open Source Software，简称OSS，又称开放源代码软件，是一种源代码可以任意获取的计算机软件，这种软件的著作权持有人在软件协议的规定之下保留一部分权利并允许用户学习、修改以及以任何目的向任何人分发该软件。

某些软件的源代码只有创建它的个人、团队或组织(并保持对它的独占控制)才能修改。人们称这种软件为”专有”或”闭源”软件。只有专有软件的原始作者才能合法地复制、检查和更改该软件。并且为了使用专有软件，计算机用户必须同意(通常通过签署他们第一次运行该软件时显示的许可证)他们不会对软件作者未明确许可的软件进行操作。

与专有软件一样，用户在使用开源软件时必须接受许可条款即开源软件License，但开源许可的法律条款与专有许可的法律条款大不相同。

出于多种原因，人们更喜欢开源软件而不是专有软件：

(1).他们对这种软件有更多的控制权。

(2).它一般有开源社区，可以帮助他们成为更好的程序员。

(3).他们认为它比专有软件更安全和稳定，因为任何人都可以查看和修改开源软件。

开源基金会对于开源软件和开源社区的组织、发展、协同创新提供了主导作用。开源基金会遵循公开、透明、开放等理念，为开源软件的孵化提供技术、运营、法律等全方位支持，为开源的社区建设和运营提供指导，发挥了孵化器和加速器的作用，开源基金会已成为开源生态最重要的组织者，如：

(1).1985年成立的自由软件基金会(Free Software Foundation, FSF)，编写并维护一些GNU软件包。

(2).1999年成立的Apache软件基金会(Apache Software Foundation, ASF)，托管于ASF的项目均遵循Apache License。

(3).2000年成立的Linux基金会(Linux Foundation, LF)。

如果你发现开源软件中的bug，你可以提交请求来修复它，如开源代码存放在GitHub上，则操作步骤为：

(1).fork这个项目。

(2).修改fork的项目。

(3).commit并推送到GitHub。

(4).发pull request，等待代码审核。

License是软件的授权许可，里面详尽表述了你获得代码后拥有的权利，可以对别人的作品进行何种操作，何种操作又是被禁止的。软件协议可分为开源和商业。这里总结下常用的几种开源软件License的异同，包括Apache License、MPL、MIT、GPL、LGPL、BSD：

1. Apache License：是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布(作为开源或商业软件)。需要满足的条件也和BSD类似：

(1). 需要给代码的用户一份Apache License。

(2). 如果你修改了代码，需要在被修改的文件中说明。

(3). 在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。

(4). 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache License。你可以在Notice中增加自己的许可，但不可以表现为对Apache License构成更改。

(5). Apache License也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。

2. MPL (Mozilla Public License)：1998年初,Netscape的Mozilla小组为其开源软件项目设计的软件许可证。MPL许可证出现的最重要原因就是，Netscape公司认为GPL许可证没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。同著名的GPL许可证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同(因为都是符合OSIA 认定的开源软件许可证)。但是，相比而言MPL还有以下几个显著的不同之处：

(1). MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来，以保证其他人可以在MPL的条款下共享源代码。但是，在MPL 许可证中对”发布”的定义是”以源代码方式发布的文件”，这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些，就为借鉴别人的源代码用做自己商业软件开发的行为留了一个豁口。

(2). MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。

(3). 对软件专利的态度，MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码(除非他本人是专利权人，并书面向公众免费许可这些源代码)，也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。

(4). 对源代码的定义而在MPL(1.1版本)许可证中，对源代码的定义是:”源代码指的是对作品进行修改最优先择取的形式，它包括:所有模块的所有源程序，加上有关的接口的定义，加上控制可执行作品的安装和编译的’原本’(原文为’Script’)，或者不是与初始源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。”

(5). MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定，就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。

3. MIT(Massachusetts Institute of Technology)：源自麻省理工学院(Massachusetts Institute of Technology, MIT)，又称"X条款"(XLicense)或"X11条款"(X11 License)。MIT内容与三条款BSD许可证(3-clause BSD license)内容颇为近似，但是赋予软体被授权人更大的权利与更少的限制。被授权人有权利使用、复制、修改、合并、出版发行、散布、再授权及贩售软体及软体的副本。被授权人可根据程式的需要修改授权条款为适当的内容。在软件和软件的所有副本中都必须包含版权声明和许可声明。此授权条款并非属copyleft的自由软体授权条款，允许在自由/开放源码软体或非自由软体(proprietary software)所使用。此亦为MIT与BSD(The BSD license, 3-clause BSD license)本质上不同处。MIT条款可与其他授权条款并存。另外，MIT条款也是自由软体基金会(FSF)所认可的自由软体授权条款，与GPL相容。

4. GPL(General Public License)：GPL同其它的自由软件许可证一样，许可社会公众享有：运行、复制软件的自由，发行传播软件的自由，获得软件源码的自由，改进软件并将自己作出的改进版本向社会发行传播的自由。Linux就是采用了GPL。GPL还规定：只要这种修改文本在整体上或者其某个部分来源于遵循GPL的程序，该修改文本的整体就必须按照GPL流通，不仅该修改文本的源码必须向社会公开，而且对于这种修改文本的流通不准许附加修改者自己作出的限制。因此，一项遵循GPL流通的程序不能同非自由的软件合并。GPL所表达的这种流通规则称为copyleft，表示与copyright(版权)的概念”相左”。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。GPL 带有很强的传染性，那么如果一个库使用GPL发布，那么使用这个库的所有软件也必须使用GPL发布。GPL协议最主要的几个原则：

(1). 确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。任何一套软件，只要其中使用了受 GPL 协议保护的第三方软件的源程序，并向非开发人员发布时，软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说，此时它必须开放源代码。

(2). GPL大致就是一个左侧版权(Copyleft，或译为”反版权”、”版权属左”、”版权所无”、”版责”等)的体现。你可以去掉所有原作的版权信息，只要你保持开源，并且随源代码、二进制版附上 GPL 的许可证就行，让后人可以很明确地得知此软件的授权信息。GPL精髓就是，只要使软件在完整开源的情况下，尽可能使使用者得到自由发挥的空间，使软件得到更快更好的发展。

(3). 无论软件以何种形式发布，都必须同时附上源代码。例如在Web上提供下载，就必须在二进制版本（如果有的话）下载的同一个页面，清楚地提供源代码下载的链接。如果以光盘形式发布，就必须同时附上源文件的光盘。

(4). 开发或维护遵循GPL协议开发的软件的公司或个人，可以对使用者收取一定的服务费用。但还是一句老话——必须无偿提供软件的完整源代码，不得将源代码与服务做捆绑或任何变相捆绑销售。

5. LGPL(Lesser General Public License)：是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。

6. BSD：BSD开源协议是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。当你发布使用了BSD协议的代码，或者以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：

(1). 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。

(3). 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

下面是六种License简图：

如果企业使用最好选择MIT、BSD、Apache License。

以上内容均整理自网络，主要参考文献包括：

1. http://www.oschina.net/news/74999/how-to-choose-a-license?_t_t_t=0.1511514508165419

2. https://www.oschina.net/question/12_2828

开源软件License汇总相关推荐

Java培训学习之Java开源软件的汇总
Java开源软件的汇总: EcSplorer [Java开源 Eclipse插件] EcSplorer(Eclipse Simplified Explorer)是一个类似于 Windows Explo ...
关于开源软件License的说明
Soa 竞赛中对于开源软件有如下要求: 关于开源软件(Open Source Software)的使用系统开发过程中可以使用开源软件,系统运行安装包中也可以使用开源软件.但是,对所使用的开源软件有如 ...
推荐系统开源软件列表汇总和点评
我收集和整理的目前互联网上所能找到的知名开源推荐系统(open source project for recommendation system),并附上了个人的一些简单点评(未必全面准确), 这方面 ...
[开源]C#中开源软件大汇总(外国的)
一.博客类项目 1.SubText 项目介绍:Subtext 是一个个人博客发布平台,详细的介绍请进SubText 项目分类:博客项目license:BSD License 项目主页:http:// ...
2006“IBM杯”中国高校SOA应用大赛禁止使用任何版本的GPL/LGPL license的开源软件
看着手头的这个 Word 文档,心情沉重. 这个世界怎么了? What's wrong with Free Software? IBM didn't support GPL. Should the c ...
开源软件使用的风险和应对方法
目录一.开源软件的漏洞 1.1 发现漏洞并评估影响范围 1.1.1 开源软件清单和SBOM 1.1.2 如何得到软件产品完整的SBOM 1.1.3 通过SBOM识别漏洞影响范围 1.1.4 漏洞感知 ...
推荐系统的常用算法,选择,漫谈,推荐系统开源软件汇总
推荐系统的常用算法概述前一阵子准备毕业论文的开题,一直在看推荐系统相关的论文.对推荐系统有了一个更加清晰和理性的认识,也对推荐算法有了深入了解.借此机会总结分享一下,大家多多拍砖. 推荐系统的出现 ...
open source license主流的开源软件协议介绍
open source license主流的开源软件协议介绍(20190222) 文章目录: 一.开源软件的直观介绍二.常用开源协议介绍三.常用开源协议之间的对比当Adobe.Microsoft ...
License分类 + 引入开源软件时License的注意事项
License分类 + 引入开源软件时License的注意事项 License分类 GPL: linux.openJDK,openJFX,mysql 融合感染,单独子模块不感染(自己的模块与引入模块的 ...

开源软件License汇总

开源软件License汇总相关推荐

最新文章

热门文章