前言 本文旨在介绍开源软件许可证，这些许可证规定了使用、修改和分发开源软件的条件。通过了解不同类型的开源许可证及其特点，读者将能够更好地理解在开发和使用开源软件时的法律和道德责任。

对于很多刚踏入软件这个行业的小伙伴来说，「开源软件许可证」是个比较陌生的概念。但是随着经手项目逐渐增多，会发现很多项目，尤其是一些大型项目，经常会引用到别人一些优秀的开源代码，而这些优秀的开源代码通常都会在最开始简单地附上一段关于授权的声明或在项目根目录下提供完整的授权声明文件，比如：「The project is licensed under the Apache 2 license.」，诸如此类便是「开源许可证」。

声明开源许可证，可以让广大开发者看到并获取我们作品的同时又保留了我们作为作者的一些权利。在提高自身业界知名度的同时又能防止有人将作者名字改成自己，拿去谋取利益。

开源不等于免费，开源也不等于没有约束。

开源许可证是开源软件的授权许可，里面详尽表述了个人或组织获得开源代码后拥有的权力，包括可以进行哪些操作以及禁止哪些操作。对于绝大部分人来说，与其自己花大把时间去编写一份开源许可证，倒不如直接选择一个广为流传且合适的已有开源许可证，这样做既省心又省力。而且，靠个人完成一份开源许可证的编写也不是一件容易的事情。

在全球范围内，开源软件社区的活跃程度日益增长，吸引了来自不同领域的开发者和用户。然而，开源协议的法律实际应用在各国略有不同。

中国开源第一案：https://linux.cn/article-11683-1.html

开源软件

开源软件，顾名思义是指能够免费且不受限制地使用、再开发、再发布的软件。但在狭义上，只有符合开放源代码促进会（Open Source Initiative）定义的软件才能被称为开源软件。这个定义提出了十个特征，必须全部符合才能认定为开源软件。

这些特征包括：

可自由再分发。

提供源代码。

允许衍生作品。

不得过度限制原始代码的修改。

不得歧视特定人、群体或用途。

必须「技术中立」等。

根据这些标准，一些看似自由使用的软件可能不符合开源软件的定义。例如，Elasticsearch原本使用Apache 2.0授权，是真正的开源软件。但面对云服务提供商如AWS等将其用于营利目的却不回馈改进的情况，Elasticsearch在2021年1月选择了SSPL（Server Side Public License，服务器端公共许可证）和Elastic License两种许可证并行；SSPL要求如果将程序的功能或修改后的版本作为服务提供给第三方，则必须免费公开提供服务源代码，这违背了开源软件的定义。另一方面，Elastic License要求不能向第三方提供主机或托管服务，也违反了开源软件的定义，因此也不算严格意义上的「开源」。

开源许可证

开源许可证是软件许可证的一种特殊形式，用于规定开源软件的使用、修改、分享等相关事宜。它是一种格式合同，涉及版权、专利、商标等权利义务，自动生效。

在美国，一些法院认为软件许可证是合同（contract），一些法院则认为是许可（license）。两者的区别在于，许可在传统上是由地产或物主作出的，目的在于允许他人使用自己的地块或物品。因此，它是单方向的，不构成完整的合同，而是作为合同的一个要素，用来和他人交换的条件。由于合同和许可之分在法律上有着重要的意义，它们的违约救济和版权侵权救济等方面有着不同的规定。

与美国不同，大陆法系国家如中国普遍认为开源软件许可证构成合同，但这种合同是事先规定好的标准化格式合同，并且自动生效。

开源许可证的种类繁多，据不完全统计，广义上的开源许可证超过200种，其中OSI批准的许可证有96个。这些许可证的内容各不相同，有些条款非常有意思，例如，啤酒软件许可证（Beerware License）规定，用户与作者聚会时可以请作者喝一杯啤酒；Jason Hunter 许可证规定，如果将该许可证下的代码用于商业目的，那么项目开发团队的所有成员都必须拥有 Jason Hunter 撰写的《Java Servlet编程》最新版。

尽管开源许可证种类繁多，但绝大多数开源软件使用的都是几种常见的许可证之一。根据Whitesource的调查报告，90%左右的开源软件使用的是10个常见许可证之一。

常见开源许可证

世界上的开源许可证（Open Source License）大概有上百种，而常见的开源协议大致有GPL、BSD、MIT、Mozilla、Apache和LGPL等。 alt text

Apache License

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

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

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

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

使用这个协议的好处是:

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

BSD

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

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

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

  • 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。

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

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

GPL

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

Linux 采用了 GPL。

GPL 协议和 BSD, Apache Licence 等鼓励代码重用的许可很不一样。GPL 的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种 linux，包括商业公司的 linux 和 linux 上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。

LGPL

LGPL是GPL的一个为主要为类库使用设计的开源协议。和 GPL 要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用 LGPL 协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改 LGPL 协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用 LGPL 协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以 LGPL 协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。

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

MIT

MIT是和BSD一样宽范的许可协议,源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称X11协议。作者只想保留版权,而无任何其他了限制。MIT与BSD 类似，但是比 BSD 协议更加宽松，是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有：jquery、Node.js。

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；

4.独立的模块(Separate Module),不需要开源。

Creative Commons 知识共享协议

Creative Commons (CC) 许可协议并不能说是真正的开源协议，它们大多是被使用于设计类的工程上。 CC 协议种类繁多，每一种都授权特定的权利。 一个 CC 许可协议具有四个基本部分，这几个部分可以单独起作用，也可以组合起来。下面是这几部分的简介：

  • 署名 作品上必须附有作品的归属。如此之后，作品可以被修改，分发，复制和其它用途。

  • 相同方式共享 作品可以被修改、分发或其它操作，但所有的衍生品都要置于CC许可协议下。

  • 非商业用途 作品可以被修改、分发等等，但不能用于商业目的。但语言上对什么是"商业"的说明十分含糊不清 (没有提供精确的定义)，所以你可以在你的工程里对其进行说明。例如，有些人简单的解释"非商业"为不能出售这个作品。而另外一些人认为你甚至不能在有广告的网站上使用它们。 还有些人认为"商业"仅仅指你用它获取利益。

  • 禁止衍生作品

CC 许可协议的这些条款可以自由组合使用。大多数的比较严格的CC协议会声明 "署名权，非商业用途，禁止衍生"条款，这意味着你可以自由的分享这个作品，但你不能改变它和对其收费，而且必须声明作品的归属。这个许可协议非常的有用，它可以让你的作品传播出去，但又可以对作品的使用保留部分或完全的控制。最少限制的CC协议类型当属 "署名"协议，这意味着只要人们能维护你的名誉，他们对你的作品怎么使用都行。

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

后记

在过去几年，我们可以清晰地观察到商业公司对开源的日益重视，传统企业对开源软件和技术态度的开也在不断提升。IBM 以340亿美元收购了开源软件制造商 Red Hat，而Salesforce 也以65亿美元收购了 Mulesoft；微软加入了开放发明网络（OIN）并贡献了6万项专利，随后又以75亿美元收购了 GitHub ；这些都是显著的例子。

大型科技公司不仅依赖于开放源码项目，还积极向这些项目贡献代码，或者在开源许可证下提供自家的内部工具，并将这些举措作为企业责任的体现。这表明整个开源生态系统的扩大使得开源许可证的作用变得更加重要。

随着技术和社会环境的不断变化，可能会出现新的许可证或者对现有许可证的修订，比如 Elastic 放弃了 Apache 许可证。作为开发者和用户，我们应该时刻关注这些变化，确保我们的项目和行为符合当前的法律和道德标准。

最后，我们希望读者能够在使用和贡献开源软件时，牢记开源精神，尊重他人的劳动成果，并积极参与到开源社区的建设中去。只有通过共同的努力和合作，我们才能够推动开源软件的进步，为全球科技发展贡献自己的一份力量。

参考