开源软件英文为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。
License是软件的授权许可，里面详尽表述了你获得代码后拥有的权利，可以对别人的作品进行何种操作，何种操作又是被禁止的。软件协议可分为开源和商业。这里总结下常用的几种开源软件License的异同，包括Apache License、MPL、MIT、GPL、LGPL、BSD：
(1). 需要给代码的用户一份Apache License。
(2). 如果你修改了代码，需要在被修改的文件中说明。
(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许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。
(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相容。
(1). 确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。任何一套软件，只要其中使用了受 GPL 协议保护的第三方软件的源程序，并向非开发人员发布时，软件本身也就自动成为受 GPL 保护并且约束的实体。也就是说，此时它必须开放源代码。
(2). GPL大致就是一个左侧版权(Copyleft，或译为”反版权”、”版权属左”、”版权所无”、”版责”等)的体现。你可以去掉所有原作的版权 信息，只要你保持开源，并且随源代码、二进制版附上 GPL 的许可证就行，让后人可以很明确地得知此软件的授权信息。GPL精髓就是，只要使软件在完整开源的情况下，尽可能使使用者得到自由发挥的空间，使软件得到更快更好的发展。
(3). 无论软件以何种形式发布，都必须同时附上源代码。例如在Web上提供下载，就必须在二进制版本（如果有的话）下载的同一个页面，清楚地提供源代码下载的链接。如果以光盘形式发布，就必须同时附上源文件的光盘。
(4). 开发或维护遵循GPL协议开发的软件的公司或个人，可以对使用者收取一定的服务费用。但还是一句老话——必须无偿提供软件的完整源代码，不得将源代码与服务做捆绑或任何变相捆绑销售。
(1). 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
(2). 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
下面是六种License简图：
如果企业使用最好选择MIT、BSD、Apache License。
以上内容均整理自 络，主要参考文献包括：
1. http://www.oschina.net/news/74999/how-to-choose-a-licenset_t_t=0.1511514508165419
2. https://www.oschina.net/question/12_2828
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！