License是软件的授权许可，里面详尽表述了你获得代码后拥有的权利，可以对别人的作品进行何种操作，何种操作又是被禁止的。软件协议可分为开源和商业两类，对于商业协议，或者叫法律声明、许可协议，每个软件会有自己的一套行文，由软件作者或专门律师撰写，对于大多数人来说不必自己花时间和精力去写繁长的许可协议，选择一份广为流传的开源协议就是个不错的决策。
世界上开源软件协议OPEN SOURCE LICENSE的种类非常之多，并且同一款协议有很多变种，协议太宽松会导致作者丧失对作品的很多权利，太严格又不便于使用者使用及作品的传播，所以开源作者要考虑自己对作品想保留哪些权利，放开哪些限制。
开源协议有哪些：
1.GPL
GPL，是GNU General Public License的缩写。我们很熟悉的Linux就是采用了GPL，GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。
GPL1即最初的版本，发布于1989年一月，其目的是防止那些阻碍自由软件的行为，而这些阻碍软件开源的行为主要有两种(一种是软件发布者只发布可执行的二进制代码而不发布具体源代码，一种是软件发布者在软件许可加入限制性条款)。因此按照GPLv1，如果发布了可执行的二进制代码，就必须同时发布可读的源代码，并且在发布任何基于GPL许可的软件时，不能添加任何限制性的条款。
GPL2在1991年6月发布，与此同时第二个许可证程序库GNU通用公共许可证(LGPL,the Lesser General Public License)也被发布出来并且一开始就将其版本定为第2版本以表示其和GPLv2的互补性。这个版本一直延续到1999年，并分支出一个派生的LGPL版本号为2.1，并将其重命名为轻量级通用公共许可证(又称宽通用公共许可证)(Lesser General Public License)。
GPL3正由斯托曼起草，由伊本·莫格林和软件自由法律中心(Software Freedom Law Center) 提供法律咨询。斯托曼在2006年2月25日自由及开源软件开发者欧洲会议的演讲上说在所有的改动中，最重要的四个是：解决软件专利问题;与其他许可证的兼容性;源代码分区和组成的定义;解决数位版权管理(DRM)问题。
GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用，修改后的代码或者衍生代码)GPL 协议的产品，则该软件产品必须也采用GPL协议，即必须也是开源和免费，这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势，由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。
2.BSD
BSD开源协议是一个给于使用者很大自由的协议，可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。但”为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
BSD 代码鼓励代码共享，但需要尊重代码作者的著作权。
3.MIT
MIT许可证之名源自麻省理工学院(Massachusetts Institute of Technology, MIT)，又称“X条款”(X License)或“X11条款”(X11 License)，是一份简短而宽松的协议，只提供了版权保护和声明，它授予他人复制，修改，合并，发布，分发，授权和/或销售本软件的副本的权力，被授权人可根据程序的需要修改授权条款为适当的内容。作者只想保留版权，而无任何其他了限制，也就是说必须在发行版里包含原许可协议的声明，无论以二进制发布的还是以源代码发布。
4.MPL
MPL是The Mozilla Public License的简写，同著名的GPL许可证和BSD许可证相比，MPL在许多权利与义务的约定方面与它们相同(因为都是符合OSIA认定的开源软件许可证)，但是相比而言MPL还有以下几个显著的不同之处:
MPL虽然要求对于经MPL许可证发布的源代码的修改也要以MPL许可证的方式再许可出来，以保证其他人可以在MPL的条款下共享源代码。但是，在MPL许可证中对“发布”的定义是“以源代码方式发布的文件”，这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。这些就为借鉴别人的源代码用做自己商业软件开发的行为留了一个豁口。
MPL许可证第三条第7款中允许被许可人将经过MPL许可证获得的源代码同自己其他类型的代码混合得到自己的软件程序。
对软件专利的态度，MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码(除非他本人是专利权人，并书面向公众免费许可这些源代码)，也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。
对源代码的定义。在MPL(1.1版本)许可证中，对源代码的定义是:“源代码指的是对作品进行修改最优先择取的形式，它包括:所有模块的所有源程序，加上有关的接口的定义，加上控制可执行作品的安装和编译的‘原本’(原文为‘Script’)，或者不是与初始源代码显著不同的源代码就是被源代码贡献者选择的从公共领域可以得到的程序代码。”
MPL许可证第3条有专门的一款是关于对源代码修改进行描述的规定，就是要求所有再发布者都得有一个专门的文件就对源代码程序修改的时间和修改的方式有描述。
5.Apache License 2.0
Apache License是著名的非盈利开源组织Apache采用的协议，该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布(作为开源或商业软件)。需要满足的条件也和BSD类似：
需要给代码的用户一份Apache License。
如果你修改了代码，需要再被修改的文件中说明。
在延伸的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache License。你可以在Notice中增加自己的许可，但不可以表现为对Apache License构成更改。
Apache License也是对商业应用友好的许可，使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。
6.LGPL
LGPL(亦称GPL V2)是GPL的一个为主要为类库使用设计的开源协议，和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL 允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。
但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。
如何选择开源协议:
为了简单清楚的理解，这里我们直接看3张图：
1.协议有哪些限制：
2.协议授权详情：
3.开发如何选择协议：
关于Arm的授权模式:
Arm共有三种不同的授权模式。
(1)架构/指令集层级授权：
指可以对Arm架构进行大幅度改造，甚至可以对Arm指令集进行扩展或缩减，苹果就是一个很好的例子，在使用Armv7-A架构基础上，扩展出了自己的苹果swift架构。
(2)内核层级授权(IP授权)：
指可以以一个内核为基础然后在加上自己的外设，比如USART、GPIO、SPI 、ADC 等等，最后形成了自己的MCU。
(3)使用层级授权：
要想使用一款处理器，得到使用层级的授权是最基本的，这就意味着你只能拿别人提供的定义好的IP来嵌入在你的设计中，不能更改人家的IP，也不能借助人家的IP创造自己的基于该IP的封装产品;
