开放源代码是促进软件业态繁荣的重要助力，也是开发组织团队建立生态标准的重要发布途径。
无论是组织，或是个人，你都需要通过开放源代码许可（Open Source License）来申明明确发布者与引用者间的使用协议。

本文将简要说明：

开源发展
类型及典型许可证说明
开源引用者须知
开源发布者须知
常见曲解陷阱说明
本文参考引用

开源发展

开放分享早在计算机诞生以前，就广泛的流传应用于人们的生产生活，比如厨师分享公开的食谱、医师公开讲解病理护理、老师传授不同层面的知识经验……
在软件领域，除了开放源代码（Open Source）这一概念，还有自由软件（Free Software）、免费软件（Software which is free of charge）。在一段时间里，它们常在不同的软件领域社区、组织机构中被混乱地称谓，今天我们应该知道他们的区别：

免费软件即是强调个人、团体可以无需付费自由使用的软件；自由软件是由1985年成立的自由软件基金会倡议推进的基础公共源代码开发事业，多数含义上以GPL（copyleft）为模式促进维护基础公共软件不受垄断限制地发展；开源软件则是1998年召开开放源代码会议上，由克里斯蒂娜·彼得森提出通过决议采纳的通用公开源代码项目的称谓
免费软件通常在使用上不加以限制，但在修改、商用、二次贩售上是严格禁止的，并且相当一部分是不开放源代码的；在这一点上与开源软件在发行发布上明显有差异，后者在开放源代码基础上在修改商用上限制也比较宽松
自由软件的特殊性在公共性不容侵犯，即所发行软件为公共事业，仍和收纳、涵盖的软件项目都应保持沿用公共开放协议（GPL、LGPL），也即是软件授权的“传染性”，其主要约束在于禁止封闭、限制商用、协议沿用；很多自由软件也是特殊形式的免费软件，并且都满足开放源代码的基本性质

开放源代码活动 得到认同、推广以来，软件开发领域发生了深刻的变化，软件研发不再是局限于小部分圈子的“极客行为”，而演变为了全球性的事业路径。其早期萌发来源的 自由软件活动 也作为一种更严格的开源形式，以不同的解读维护着软件公共事业的发展，就其根源来看都是极大地促进了软件开发的全球化开放性与次代升级。
在商业领域免费软件早已经成为一种常规业态，以“免费开源”为核心的软件领域生态、产业生态愈发强大，传统的软件许可贩售市场正在被不断侵蚀。如果你的软件倾向于系统工程、核心生态、应用灵活、需求多变，那么开源开放将是极为重要的发布分发形式与最强大的竞争来源。

开源是一种方法，自由是一种精神。

@李克用, 知乎www.zhihu.com/question/42117033/answer/93654955

开源许可概览

这里探讨的开放源代码定义来自1998年确认的定义，开源许可证来自开源基金会认可通过的协议。通过这里可以查阅访问最新的已通过许可协议，截至撰稿时间（2019-03-19）有81份开源许可证书被认可通过。

官方分类

开源基金会也对这些开源许可证进行了归类：

流行并广泛使用于强大社区的（9）
国际通行的（3）
特殊用途的（7）
其他混杂的（7）
其他未归类（14）
弃用部分（52）：与更流行许可证冗余的、不可重复使用的、被替代废弃的、自愿申请退出的

常见许可证详述

开源许可的审批均由开源社区、开发者社区、组织机构提出申请，因为许可项目的运营方式不同也分为通行社区许可、语言/产品许可、组织开源许可、特殊开源许可。这里仅对通行社区许可中较常见的几种许可证进行说明，其他许可证或是接触不多，或是具备相通性不过多赘述。

Apache-2.0

版权许可
专利许可
商标许可
再分发免责

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

需要给代码的用户一份Apache Licence，如果你修改了代码，需要在被修改的文件中说明。
在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议，商标，专利声明和其他
原来作者规定需要包含的说明。

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

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

GPL与LGPL

我们很熟悉的Linux就是采用了GPL。GPL协议和BSD，Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。
GPL协议的主要内容是只要在一个软件中使用(”使用”指类库引用，修改后的代码或者衍生代码)GPL协议的产品，则该软件产品必须也采用GPL协议，既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。
由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。

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

MIT

MIT是和BSD一样宽范的许可协议，作者只想保留版权，而无任何其他了限制.也就是说，你必须在你的发行版里包含原许可协议的声明，无论你是以二进制发布的还是以源代码发布的。

MPL

Mozila Public License是又一个自由软件倡导者，它要求授权者必须保持项目代码开源，但不要求一定继承该许可证。与LGPL许可证不同，MPL要求你开放源代码的基础上必须对所修改部分进行附注说明。

BSD

BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”，可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
但”为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

开源引用与权益甄别

在我们的项目中总会依赖引用这样，或那样的开源项目，了解并遵从开源项目的许可协议是很重要的。不仅仅是对于开源社区、软件作者的尊重，另一方面也能保障后续项目的合法合规发行。
乌克兰程序员Paul Bagwell对开源项目选型制作了简单的图示，阮一峰进行了中文翻译，图示简明指出开源协议的解读选取，你应该考虑如下问题：

开源发布与产品规划

参照开源项目选型中，对开源许可证的解读取舍，在发布开源项目时在主流社区开源许可证上所需判别问题类同如下：

本项目开源授权者是否强制开源？
对强制开源项目，是否强制沿用当前许可证？
对非强制开源项目，是否修改的每个文件都需放置版权说明？
对不要求沿用许可证，是否要对修改内容附详细说明？
对允许闭源且不必放置所有修改版权说明的，是否可以使用本项目名字促销？

经典问题

开源 VS 免费

显然可以确认的，绝大多数开源软件都可以免费使用，绝大多数免费软件并不开源，但二者并不存在包并关系。

开源是一种软件发行方式，但不一定是唯一发行方式，也就出现很多开源版本与商用版本的软件销售方案
免费是一种商业策略，当然存在简单的免费使用，但通常这类软件与开源基本没有关系，并且你必须接受他的附加条款和绑定业务；但更多的免费软件都是一种产品策略，可以用于体现软件商业取舍

启动开源生态

结语

关于开源生态

http://www.sohu.com/a/278743817_115128

引用内容：
1 五种开源协议的比较(BSD，Apache，GPL，LGPL，MIT). 2010-06-09. http://www.ha97.com/833.html