开源许可证

最新推荐文章于 2024-07-08 19:37:05 发布

机器视觉001

最新推荐文章于 2024-07-08 19:37:05 发布

阅读量694

点赞数

分类专栏：软件开发文章标签：开源许可证

原文链接：https://baike.so.com/doc/2302044-2435184.html https://github.com/Kimi-Gao/Program-Blog/issues/65 http://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html https://www.runoob.com/w3cnote/open-source-license.html https://www.ilanl

版权

软件开发专栏收录该内容

412 篇文章 14 订阅

订阅专栏

开源许可证

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

开源许可证是一种具有法律性质的合同，目的在于规范受著作权保护的软件的使用或者分发行为。

开源定义

开放源代码(英语:Open Source)描述了一种在产品的出品和开发中提供最终源材料的做法。一些人将开放源代码认为是一种哲学思想，另一些人则把它当成一种实用主义。

开源软件的详细定义比较复杂，简单点说，就是一种源代码可以任意获取的计算机软件，这种软件的版权持有人在软件协议的规定之下保留一部分权利并允许用户学习、修改、增进提高这款软件的质量。

并非公开了源代码就算是开源，公开源代码和开放源代码是两回事。

许可证定义

许可证即授权条款。开源软件并非完全没有限制。最基本的限制，就是开源软件强迫任何使用和修改该软件的人承认发起人的著作权和所有参与人的贡献。

任何人拥有可以自由复制、修改、使用这些源代码的权利，不得设置针对任何人或团体领域的限制。不得限制开源软件的商业使用等。而许可证就是这样一个保证这些限制的法律文件。

如何选择许可证

开源软件的许可证比较繁多和复杂，对于我们来说，经常遇到的开源许可证大多是GPL和BSD两种，此外还有Adobe经常使用的MPL许可证。

简单来说，GPL许可证具有相当强的传染性，如果你想要把一份采用GPL许可证的代码经过修改后再次发布二进制版本，那么你同时也必须再次开放其源代码。

而BSD许可证则相对宽松许多，它允许对源代码的修改后再次发布时仅包含许可证而不必再次开放源代码，且可以将修改后的版本转为商业用途(如微软的产品中引入了BSD网络部分的源码，修改后则作为专有软件出售)。

1. 从开源软件开发的角度来看，若只是利用开源程序包作为工具来生产与其分离的作品，那么绝大多数开源许可证都是可以的；

2. 如果将软件用于商业性发行且不愿意发行自己所修改的源码，那么可以选择BSD许可证，它能使修改保持专有；

3. 若希望源码总是自由的，GPL许可证及LGPL许可证是最佳选择(不推荐采用LGPL许可证，LGPL许可证有很大漏洞，divX从开源突然转为专有就是一例，如果希望在开源版本之外能够有一个你自己开发的更强大的商用版本出售，建议采用BSD，这样你自行对其的修改就不必再次公开了)；

4. 若想在与其它人共享代码时提供相应的保护，可以选择MPL许可证，该许可证可通过将软件(和任何对它的修改)分为受保护部分和贡献部分，在完全开放的 GPL许可证和封闭的BSD许可证之间架起一座巧妙的桥梁。

许可证版本

Apache License

Apache License（Apache许可证），是Apache软件基金会发布的一个自由软件许可证。

Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和最终原作者的著作权，同样允许源代码修改和再发布。

Apache 协议 2.0 和别的开源协议相比，除了为用户提供版权许可之外，还有专利许可，对于那些涉及专利内容的开发者而言，该协议最适合。

但是也需要遵循以下条件：

需要给代码的用户一份Apache Licence。
如果修改了代码，需要再被修改的文件中说明。
在衍生的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以再Notice中增加自己的许可，但是不可以表现为对Apache Licence构成更改。
Apache Licence也是对商业应用友好的许可。使用者也可以再需要的时候修改代码来满足并作为开源或商业产品发布/销售。

使用这个协议的好处是:

永久权利：一旦被授权，永久拥有。
全球范围的权利：在一个国家获得授权，适用于所有国家。假如你在美国，许可是从印度授权的，也没有问题。
授权免费：无版税，前期、后期均无任何费用。
授权无排他性：任何人都可以获得授权。
授权不可撤消：一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码。

分发代码方面包含一些要求，主要是，要在声明中对参与开发的人给予认可并包含一份许可协议原文。

BSD

BSD是"Berkeley Software Distribution"的缩写，意思是"伯克利软件发行版"。

BSD 在软件分发方面的限制比别的开源协议（如 GNU GPL）要少。

该协议有多种版本，最主要的版本有两个，新 BSD 协议与简单 BSD 协议，这两种协议经过修正，都和 GPL 兼容，并为开源组织所认可。

新 BSD 协议在软件分发方面，除需要包含一份版权提示和免责声明之外，没有任何限制。另外，该协议还禁止拿开发者的名义为衍生产品背书，但简单 BSD 协议删除了这一条款。

BSD开源协议是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。

当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：

1．如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
2．如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
3．不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。

而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

BSD 2-Clause license

BSD允许使用者修改和重新发布代码(以其他协议形式)，允许闭源商业发布和销售。

BSD鼓励代码共享的同时，要求尊重代码作者的著作权。

使用BSD协议，需要遵守以下规则：

再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议；
如果再发布的只是二进制类库/软件，则需要在类库/软件的文档那个和版权声明中包含原来代码中的BSD协议。

BSD (3-Clause) License

BSD允许使用者修改和重新发布代码(以其他协议形式)，允许闭源商业发布和销售。

BSD鼓励代码共享的同时，要求尊重代码作者的著作权。

使用BSD协议，需要遵守以下规则：

再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议；
如果再发布的只是二进制类库/软件，则需要在类库/软件的文档那个和版权声明中包含原来代码中的BSD协议;
不可以用开源代码的“作者/机构的名字”或“原来产品的名字”做市场推广。

GPL

GPL （GNU General Public License）：GNU通用公共许可协议。

Linux 采用了 GPL。

GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。

GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。

这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。

GPL v2

GPL 是GNU通用公共许可协议(GNU General Public License)的简称，我们很熟悉的 Linux 和 Git 就是采用了 GPL，该协议力图保障你分享和修改某程序全部版本的权利——确保自由软件对其用户来说是自由的。

所谓自由软件，强调自由，而非免费。

GNU通用公共许可协议设计用于确保你享有分发自由软件的自由（你可以为此服务收费），确保你可以在需要的时候获得这些软件的源码，确保你可以修改这些软件或者在新的自由软件中复用其中某些片段，并且确保你在这方面享有知情权。

自由权利包括复制、分发和修改。源码是指所有修改作品及生成、安装、运行（对可执行作品而言）目标码所需的源码，包括控制上述行为的脚本，但其中不包括系统库、通用工具。

GPL v3

GPL v3与GPL v2类似。

区别在于，不仅要求用户公布修改的源代码，还阻止了其他一些私有化的方式，例如：不得将产品内的软件“tivo化”或“锁定”，或者（用行业内的话来说）“安全启动”。

也就是说，不得以任何形式阻止用户修改产品内的以 GPL 许可协议发布的软件。

LGPL

LGPL是GPL的一个主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。

LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。

因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。

GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。

LGPL v2.1

LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。

但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。

GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品

LGPL v3

相对于LGPL v2，不仅要求用户公布修改的源代码，还阻止了其他一些私有化的方式，例如：不得将产品内的软件“tivo化”或“锁定”，或者（用行业内的话来说）“安全启动”。

也就是说，不得以任何形式阻止用户修改产品内的以 GPL 许可协议发布的软件。

MIT

MIT是和BSD一样宽范的许可协议，源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称X11协议。

作者只想保留版权，而无任何其他了限制。MIT与BSD类似，但是比BSD协议更加宽松，是目前最少限制的协议。

这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有：jquery、Node.js。

MPL (Mozilla Public License 1.1)

MPL协议允许免费重发布、免费修改，但要求修改后的代码版权归软件的发起者。

这种授权维护了商业软件的利益，它要求基于这种软件的修改无偿贡献版权给该软件。

这样，围绕该软件的所有代码的版权都集中在发起开发人的手中。但MPL是允许修改，无偿使用得。MPL软件对链接没有要求。

EPL (Eclipse Public License 1.0)

EPL允许Recipients任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。

使用EPL协议，需要遵守以下规则：

当一个Contributors将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布，而不能改用其他协议发布。除非你得到了原"源码"Owner 的授权；
EPL协议下,你可以将源码不做任何修改来商业发布。但如果你要发布修改后的源码，或者当你再发布的是Object Code的时候，你必须声明它的Source Code是可以获取的，而且要告知获取方法；
当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时候，你可以将整个Project/Product以私人的协议发布，但要声明哪一部分代码是EPL下的，而且声明那部分代码继续遵循EPL；
独立的模块(Separate Module)，不需要开源。

Creative Commons 知识共享协议

Creative Commons (CC) 许可协议并不能说是真正的开源协议，它们大多是被使用于设计类的工程上。

CC 协议种类繁多，每一种都授权特定的权利。一个 CC 许可协议具有四个基本部分，这几个部分可以单独起作用，也可以组合起来。

下面是这几部分的简介：

署名作品上必须附有作品的归属。如此之后，作品可以被修改，分发，复制和其它用途。
相同方式共享作品可以被修改、分发或其它操作，但所有的衍生品都要置于CC许可协议下。
非商业用途作品可以被修改、分发等等，但不能用于商业目的。但语言上对什么是"商业"的说明十分含糊不清 (没有提供精确的定义)，所以你可以在你的工程里对其进行说明。例如，有些人简单的解释"非商业"为不能出售这个作品。而另外一些人认为你甚至不能在有广告的网站上使用它们。还有些人认为"商业"仅仅指你用它获取利益。
禁止衍生作品

CC 许可协议的这些条款可以自由组合使用。大多数的比较严格的CC协议会声明 "署名权，非商业用途，禁止衍生"条款，这意味着你可以自由的分享这个作品，但你不能改变它和对其收费，而且必须声明作品的归属。

这个许可协议非常的有用，它可以让你的作品传播出去，但又可以对作品的使用保留部分或完全的控制。最少限制的CC协议类型当属 "署名"协议，这意味着只要人们能维护你的名誉，他们对你的作品怎么使用都行。

CC 许可协议更多的是在设计类工程中使用，而不是开发类，但没有人或妨碍你将之使用与后者。只是你必须要清楚各部分条款能覆盖到的和不能覆盖到的权利。