开源软件许可证总览2025版

各种软件和文档开源协议多，我统一整理出来。常见的GPL、AGPL、LGPL、Mozilla 2.0、BSD等软件协议和文档领域的CC协议都在。2025版，本次开源字体协议的相关内容。原稿文档中还附加了大量的注释信息，您可以在脑图原稿中获得，助您快速决策。

开源软件许可证总览 2025版

• 强调在前
  • 开源是对整个互联网公众开源，有的人说开源软件是把源代码给客户，给客户开源就可以了，这个理解是不对的。
• 版权的两种模式
  • 限制型协议
    • 只有明确许可你能做的，你才能做，否则侵权
      • 类似于白名单模式，约束更大
  • 开放型协议
    • 明确不让你做的，你不能做，否则随意
      • 类似于黑名称模式，约束更小
• GPL
  • GNU General Public License
    • 商业化的闭源软件不能用
  • 1989年2月25日发布
  • 如果项目中包含了GPL许可证的代码，那么整个项目都必须使用GPL许可证
    • 有人将这种“开源传染性”讽喻为“GPL病毒”
  • 你要允许别人破解你的软件
    • 在GPL第3条
  • 版权向左（copyleft）
    • 你必须开源修改前后的所有源码
    • 禁止你进行次级许可（Sub-Licensing）
      • 你不能更改原始条款中的任何条款
      • 你不能引入任何你自己的许可条款
    • 陈述自己对原始代码所做过的更改
  • 如果修改了别人的类库，必须要提供修改后的源代码
    • 在GPL第5条
  • 单独地使用GPL协议的产品没有任何问题，还能享受免费的优势
  • 遵循 GPL 协议的开源软件数量极其庞大
  • 典型应用
    • GNU、Linux、MySQL、Qt套件下的Qt Designer、Qt Creator等工具
      • 自由软件运动中，GNU和GPL关系很大，它们都是理查德·斯托曼创立自由软件基金会（FSF）并以该组织为主体发起的，GNU作为自由软件运动中比较成功（但不够成功，因为它要创立一个操作系统的目标始终未能达成，而相关的工具软件却做的非常成功）的头部案例，它的许多软件产品都使用了GPL协议。 发布GNU计划下的这些使用GPL协议的软件，他们的核心理念是：资源免费，服务收费。他们反对让客户花费巨资购买软件，他们崇尚客户免费的、很容易的获得软件并使用，然后为客户提供服务、培训和技术支持时收费。所以，这是一种完全不同的商业模式。
• GPL v2
  • 又称为LGPL
    • GPL 的一个衍生版本
  • 1991年6月发布
  • 与GPL相比
    • 修改的文本和源代码
      • 1、必须向社会公开
      • 2、不准附加作者自己作出的限制
  • 未明确是否可以使用开源软件所包含的专利，一般认为默认可以使用
    • 不禁则行
  • 软件发布才必须开源
    • 不发布就可以不开源
      • 许多人认为这是个漏洞
        • 比如我把软件放在云上提供服务，我没有发布，但是我商业化了
  • 典型应用
    • OpenJDK、GlusterFS
• GPL v3
  • 可以使用开源软件所包含的专利
  • 2007年6月29日发布
  • 与GPL及GPL v2相比
    • 除了要公开修改的文本和源代码，还要公布相关硬件
      • 触及数字版权（DRM）及产品关系
        • 与开源精神相悖
    • GPL v2和GPL v3有许多地方不一致，但一般情况下不是什么严重的问题
    • GPLv3针对Tivoization作出了禁止性条款
      • Tivoization是一些软件的统称。有一些公司开发了软件，但是他们却在这些软件中置入了用户不太喜欢的功能，例如广告，例如DRM，这时他们为了自己的利益，就会利用GPL协议的特性，将自己开发的软件以GPL协议发布，这样，他们的软件就可以操纵硬件运行而你不行（理论上你使用GPL协议的软件你是可以自由的控制和运行这些软件的，但是他们改变了软件行为却依然在使用着GPL反倒使得你不能修改软件并使得软件按照你的意愿运行并控制硬件了）。 如果一个设备可以运行任何软件，那么它是通用计算机，而该设备的所有者理所当然地应当能够控制该计算机的所有行为。如果你遇到了前述情况：有人以GPL协议发布了软件不让你控制你的计算机（或者让你对你的计算机的控制受到了限制），比如一家公司发布的产品，为了维护自己的利益，在其中置入了DRM或者广告，当你关闭了DRM或者广告时，它就会自动退出，不运行了，我们称之为tivoization。tivoization表面的意思是钛化，其实它是指“专制暴君”，是对上述这种特权公司的“暴行”的一种谴责。你可以简单地理解为：tivoization是指以自由名义发布的非自由软件的这种无耻行为。 Tivoization的来由，最早是一种名叫TiVo的数字录像设备，上世纪电视和录像还很盛行，这个设备可以帮助人们将电视节目录制下来并跳过其中的广告（这似乎侵犯了很多人的利益啊），因而广受欢迎。TiVo中使用了GPL协议的软件，按照协议，这些软件应当允许用户随意修改。但是TiVo却在此基础上做的更过份：用户可以修改，但是当软件发现自己被用户修改了之后，该软件就不能再在原来的硬件上运行了。之所以说过份，是因为对用户来说，硬件是我买的，我拥有所有权，软件也是开源的（GPL），那么我改了软件，这个软件当然应当可以继续在我的硬件上运行。后来，人们就把TiVo的这种做法，称为Tivoization。
      • 自由软件的主动权应该在使用者手上而不是乞求某人为你做点什么
      • 使用GPL v3协议的软件，虽然没有禁止DRM，但是必须允许被人破解
        • DRM是数字版权保护，它本身也饱受争议，它的核心思想是：通过数字加密和版权限制来保护数字内容，是数字产品付费这种业务模式的重要手段。 支持DRM的人觉得，我创作发布一首音乐，那么我应当享受版权保护，别人听歌得付费。 反对DRM的人觉得，DRM会损害用户的利益，例如：用户如果购买了这首音乐，通常这首音乐只能在特定的设备上播放。比如iTunes、Zune。而且DRM还存在一些用户隐私泄漏等问题。 一些人认为，用户购买了该音乐，那么他就可以随意地在自己的任何设备上播放。听上去很有道理，但是却又无法避免用户将该音乐随意传播以致于盗版泛滥。 乔布斯和比尔·盖茨就曾明确地表示反对DRM。
        • 例：用户购买的家用设备中使用的GPL协议，如果用户修改了该软件，必可以继续运行，这就使得用户通过“刷机”绕开了DRM
    • 采用了更加通用和国际化的法律词汇和专利说明
    • 更好地兼容其他许可证
      • 与Apache许可证兼容
    • 对中止条款比较温和
    • 支持BitTorrent
  • 受到Linux之父Linus的批评
    • 发布之初，受到Linux内核开发人员中的29个高级架构师（这些人都是业界真正的顶级大神呀）中的28个人的反对。 Linus抨击GPL v3，一个很重要的原因，就是他认为GPL v3的条款中有一条：不禁止DRM，但是必须允许被人破解，这就参与到了DRM的各种争议当中，在Linus看来，搞操作系统，就老老实实搞操作系统，硬件厂商搞DRM那是他们的事情，DRM好也罢，不好也罢，和操作系统没什么关系。如果要反对DRM，就去支持知识共享运动（the Creative Commons Movement）。 所以，大多数人购买电子产品，其实都不会去破解DRM（这只是一小撮黑客的需求），所以，GPL v3似乎是在保护一个并不需要那么在意的，也不是那么广泛而强烈的自由。而Linus反对GPL v3，其实也和自己做操作系统这事儿本身没什么关系（换句话说，他是在反对一个和自己没多大关系的事情）。既然如此，他们为什么还要如此激烈地在GPL v3这个问题上纠缠不清呢？ 问题的根源，其实出在最早的时候Linux刚发行的时候的一个团队后来的分裂。最早在1991年一起做Linux的那帮人，都是大佬，聚集了很多业界牛人。后来，1998年4月，前 GNU 成员 ESR （Eric Steven Raymond）、前Debian领导人Bruce Perens组织开源聚会，参与者都有谁？Linux 内核创始人 Linus Torvalds、Apache 主要开发者 Brian Behlendorf、 Sendmail 创始人 Eric Allman、Perl 语言创始人 Larry Wall、Python 语言创始人 Guido Rossum。你看看，都是业界数一数二的人物。但是，这里缺少一个七年前大家一起共事的重要人物——RMS。RMS在1991年找到Linus，让他将自己的Linux系统采用GPL v2，Linus很开心，用的很好，但是这次聚会前一久，RMS因为和Linus及其他的小伙伴们因为GPL v3的问题而分裂（出去成立了一个自由软件基金会，至此，开源软件和自由软件是两拨人了）。这也是前面说的，聚会没有请RMS的原因。那么，RMS和Linus的分歧到底在哪里呢？说来也简单，Linus的毕生追求是让全世界的所有人都能用上Linus，而RMS在开发GPL v3时，却针对市场上的一些事情做了一些规则（比如针对DRM允许破解这种狙击Tivoization的条款），这就使得如果Linus采用了GPL v3，就有可能使得这些消费电子产品的厂商不会再采用Linux，这显然与Linus的理念是相违背的。 Linus其人，其实是一个理想主义者，让全世界的所有人都用上Linux系统，有如此崇高地理想，技术还如此之强，而且50多岁了还在坚持写代码，值得尊敬，是我辈楷模。他曾经说自己只想安安静静写代码，律师有毒，不愿意因为法律问题去法庭上和别人大打出手，他认为诉讼会破坏社区，破坏信任（这个还有很有道理地，想想Java的那些官司）。他更愿意“悄悄地与公司合作，从内部说服他们”。
  • 软件发布才必须开源
    • 不发布就可以不开源
      • 许多人认为这是个漏洞
  • 典型应用
    • FastDFS
• GNU FDL
  • 专门用于软件作品的文档系统
  • 开源软件的文档，通常都是使用这个协议的
  • 有一整套规范，用于吸引商业出版商为文档作者付费
  • 软件使用手册也多适用于这种方式
• AGPL v3
  • 堵上了GPL的漏洞
    • GPL规定：软件发布时，必须开源
      • 如果不发布（如：用GPL组件编写一个Web系统，不发布而是提供在线服务），就不必开源了
  • 其他条款几乎和GPL v3一样
    • 除非获得商业授权，否则以任何方式修改和使用了源代码，就必须要开源。
      • 包含直接使用源代码
      • 包含修改使用源代码
      • 包含RPC方式引用
      • 包含类库方式引用
      • 这都属于通过API调用
      • 最严格的GPL
  • 和做云计算平台的厂商关系较大
    • 双向影响
      • 开发者发布了一套代码，使用AGPL v3，可能导致云厂商不敢再使用自己的代码
      • 自己是云厂商，不能再使用AGPL v3协议的源代码
        • 除非获得商业授权
  • 如果云服务（即SAAS）用到的代码是AGPL，那么云服务的代码也必须开源
  • 典型应用
    • minio、Apache iText v5.x+、BerkeleyDB v5.x+、Seafile Server core
      • 所以，如果你开发的软件中，自建OSS的时候，使用了minio，那么其实你得开源，是不能作为闭源软件发布出售的，很容易被对方追究法律责任，当然了，作为开源软件也是可以发布出售的，这不影响，看你如何和客户打交道了。
• LGPL v2.0
  • GPL 的一个衍生版本
    • 对应GPL v2进行“宽松化”
      • LGPL是Library GPL
  • 和GPL相比，更多的是针对类库设计的
  • 商业化应用
    • 你开发的商业软件如果以引用LGPL协议的类库，你不必开源
    • 如果你修改了LGPL协议的类库，修改的代码、涉及修改的额外代码、衍生代码都要采用LGPL协议
    • 概要
      • 你引用LGPL协议的类库，你可以发布商业闭源软件
      • 你开发LGPL协议的类库，别人的商业闭源软件可以使用
  • 1991年6月发布
  • 典型应用
    • Linux上的各种C语言程序库
• LGPL v2.1
  • GPL 的一个衍生版本
    • 对应GPL v2进行“宽松化”
      • LGPL是Lesser GPL（限制少了一点点的GPL）
• LGPL v3.0
  • 2007年6月29日发布
  • GPL的一个衍生版本
    • 对应GPL v3进行“宽松化”
      • 这些“退让”和“放松”放在额外条款中
        • 还有基于当初GNU领域的一些人的言论，足见他们并不是情愿这么做的，只是迫不得已，因为妥协，别人就不用自己开发的C库了
  • 和LGPL v2.x一样，更多的是针对类库、组件库这种应用场景设计的
  • 在LGPL v2中对应GPL v2和v3中的“软件发布才必须开源”
    • 许多人认为这是个漏洞，如做托管软件或云端软件这种未发布的
      • 所以才有了LGPL v3和AGPL
  • 动态链接库的方式（即：4d1，Linux上的.so，Windows上的.dll等），不必开源
  • 静态链接库的方式，即：4d0
    • 需要提供应用程序的目标码
      • 目标码是可以还原成软件源代码的
        • 所以这种方式不适用于商业软件
    • 有时候需要提供应用程序的源代码
      • 具体什么时候需要提供，有更详细的规则，但足以劝退商业软件
  • 无论哪种链接方式，都要说明引用了对方
  • 网上很多人误解为LGPL v3.0的库只能动态链接，不能静态链接
    • 动态链接相对于静态链接方式要承担的责任和义务更少
    • 静态链接相对于动态链接方式，要承担责任和义务的更多
  • 自己的专有软件是否允许别人逆向，没有强制要求
    • 但是如果不能限制别人逆向调试引用的库
  • 典型应用
    • Qt 5.4+、glibc、Cygwin、7-Zip
• LGPL v3
  • GNU Library or "Lesser" General Public License
    • 商业软件可以用，但不能修改LGPL协议下的代码
  • 如果项目采用动态链接的形式调用LGPL许可证的库，该项目可以不必开源
    • 商业友好
  • 如果项目采用静态链接的形式引用了LGPL许可证的库
    • 必须在文档中说明：你的程序使用了LGPL库，并且说明这个库也是基于LGPL发布的
    • 必须在应用程序发布中包含一份LGPL协议，通常就是跟随软件发布的LICENSE这个文本文件
    • 开放使用了 LGPL 库代码的所有代码，例如某些封装器。但是，其他使用这些封装器的代码就不需要开放了。
    • 包含你的应用程序的余下部分的目标文件（通常就是我们所说的 .o 等等），或者是其他等价的文件
      • 虽然使用了封装器的代码不需要开源，但是需要把编译的目标文件提供出来
  • 典型应用
    • Qt5.4+（不含Qt Designer、Qt Creator等工具）、Javaassist 2.1+
• Public Domain
  • 限制非常之少
  • 代码到手，想怎样就怎样，各种魔改都是可以的，几无限制
  • 典型应用
    • SQLite、zentaophp（禅道）
• Mozilla 1.1
  • 又称MPL，Mozilla Public License
    • 商业软件可用
    • 1995年6月发布，后来转移到了Mozilla旗下
    • 现在用的不多了
  • 只要该许可证的代码在单独的文件中，那么其他新增的文件可以不必开源
  • 以MPL许可的代码，许可方式不可变更，必须开源
  • 项目里允许多个许可证共存
  • 可以修改MPL协议的代码，但修改后的代码版权归软件的发起者
• Mozilla 2.0
  • 又称MPL，Mozilla Public License
    • 商业软件可用
  • 2012年1月3日发布
  • 兼容于GPL及Apache许可证
  • 典型应用
    • Mozilla Firefox、Mozilla Thunderbird、LiberOffice
• BSD
  • Berkeley Software Distribution License（伯克利软件授权条款）的缩写
    • 又称The 4-Clause BSD License
    • 诞生于1990年
      • 比这更早的1988年，就有了BSD协议，又被称为原始BSD，Original BSD License
        • 还被称为Old BSD License
    • 紧密相关的还有BSD 3-Clause , BSD 2-Clause
  • 可以修改源代码，可以用来开发专有软件
    • 三个前提
      • 分发软件时，必须保留原始的许可证声明
      • 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
      • 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议
      • 概要
        • 以BSD开源的，你可以随便用，甚至可以改
        • 你不能说BSD协议下的东西是你自己的
          • 你只是拥有控制权而非所有权
  • 商业友好
    • 可引用BSD协议的软件重新分发自己的闭源商业软件
      • 但是要声明这些引用，不能“瞒”
  • 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广
  • 未明确是否可以使用开源软件所包含的专利，一般认为默认可以使用
    • 一般认为不禁则行
  • 许可中包含内容
    • 广告条款Advertising Clause
      • 要在所有提及功能或软件使用方面的宣传资料中，列明所使用的 BSD 许可证下组件的原始作者
        • 会导致相当冗长的广告条款
      • 备受批评
      • 与GNU GPL许可证不兼容
    • 非认可条款Non-Endorsement Clause
      • 未经明确的事先书面许可，对BSD许可的软件的组织名称和贡献者的名称均不得用于认可从该软件派生的产品
      • 听起来似乎会让大家以为自己的软件不会被其他组织或开发人员认可
  • 典型应用
    • Redis、OpenBSD、FreeBSD、OpenCV、Python
      • 注意：Python语言的开源协议分两个阶段说： 3.8.6之前的版本，基于PSF开源协议 3.8.6及之后的版本，基于双重许可，PSF开源协议和零条款BSD许可协议 PSF开源协议其实是Python语言所在的Python基金会对BSD协议的再包装，里面加了一点自己组织的说明和免责声明。 零条款BSD协议，
• BSD-3-Clause License
  • 又称The 3-Clause BSD License
  • 修改的BSD许可证
    • 现在相对其他BSD协议，更加流行
  • 相比原始BSD，移除了很有争议的广告条款
  • 未经事先书面许可，不得使用著作权人或其贡献者的姓名或名称来宣传或推广由本软件衍生的产品
    • 相比BSD-2-Clause多出来的一条
  • 与GPL兼容
  • 典型应用
    • Quilljs、OpenHarmony核心
• BSD-2-Clause License
  • 又称The 2-Clause BSD License
  • 又称为简化的BSD，在BSD-3-Clause License的基础上，进一步移除了非认可条款
  • 与GPL兼容
  • 典型应用
    • nginx
• PSF协议
  • Python Software Foundation ("PSF")
  • 可以视为BSD协议的变种
  • 这是Python语言基金会在BSD协议的基础上发布的
    • 以BSD协议为基础
    • 增加了免责声明
      • PSF不承担任何责任
  • 典型应用
    • 当然是Python语言及其文档了
• Zero-Clause BSD License
  • 中文名：零条款BSD协议
    • 又称为Free Public License
    • 它与BSD无关，其实是MIT的变种
      • 这名字起的，也是没谁了。
  • 任何人都可以使用、复制、修改、分发Zero、Clause BSD License授权的软件
  • 该软件是按“原样”提供的，作者不承担任何责任
  • 作者不要求你保留他的许可证和版权声明
    • 你拿到代码之后，可以随便魔改，反正作者没有要求
  • 作者没有提供许可证转授说明
    • 你处理看着办吧
  • 你可以免费使用
  • 与GPL兼容
  • Python 3.8.6之后的代码、程序、文档采用的双重协议，其中一个是BSD，另外一个竟然就是此协议
• EPL-1.0
  • Eclipse Public License 1.0
    • 该许可证由Eclipse基金会设计
      • Eclipse基金会成立于2004年，其宗旨是建立一个供应商中立的、开放和透明的社区，通过培育社区和商业生态系统，为个人和组织提供一个以商业为重心的合作和创新的环境。Eclipse基金会有370多个开源项目，其中最著名的是Eclipse IDE和Jakarta EE（Oracle将Java EE捐赠给了Eclipse基金会，却没有将Java商标送出，所以后者将J2EE改了个新名字）。
  • 应用在Eclipse基金会旗下的众多项目中
  • 如果链接或者调用了EPL协议的程序，可不必受EPL约束
    • 传染生相比GPL弱很多了
    • 相对商业友好
  • 以EPL协议分发的程序，就叫EPL程序
    • 任何 都可以免费使用EPL程序
  • 基于EPL协议的软件，可以拥有第二许可证
    • 自有一套第二许可证为GPLv2的机制
      • 因此EPL程序满足某些条件后可以以GPLv2协议发布
  • 两大角色定义
    • 对贡献者的定义
      • 虽然有对EPL程序的修改和补充，但不构成修改后作品，不视为贡献者
      • 无论你改没改EPL程序，你分发了它成为修改后作品，视为贡献者
      • 概要
        • 只改没分发，不视为贡献者
        • 没改分发了，视为贡献者
        • 改了分发了，当然也视为贡献者
    • 接收者
      • 在EPL协议下或第二许可证协议下收到本程序的人
  • 一个贡献者分发本程序
    • 无论以什么形式发布，必须满足2点
      • 必须提供源代码
      • 可以使用其他许可证分发本程序
  • 如果您使用、修改或分发 EPL 软件，您会自动获得与该软件相关的专利权许可
  • 现在用的人较少了
• EPL-2.0
  • Eclipse Public License 2.0
    • 该许可证由Eclipse基金会设计
      • Eclipse基金会成立于2004年，其宗旨是建立一个供应商中立的、开放和透明的社区，通过培育社区和商业生态系统，为个人和组织提供一个以商业为重心的合作和创新的环境。Eclipse基金会有370多个开源项目，其中最著名的是Eclipse IDE和Jakarta EE（Oracle将Java EE捐赠给Eclipse基金会后变更的名字）。
  • 相对于EPL-1.0的更新
    • 在授权和许可的语言描述方面更加清晰准确
    • 对责任限制进行了澄清，以更好的保护贡献者和接收者
    • 对违反条款进行了更多的解释和指导说明
      • 强调了协议的法律性质，对解释和争端提供了更详细的规定
    • 包含了一个专门用于存放许可证文本的代码库
      • 便于开发者更好的理解和遵循
    • 对专利权相关的规定进行了一些调整，以更好的适应开源社区的需求
  • 更清晰，更现代化，更好的适应了现在开源软件社区的需求，首选EPL-2.0
• MIT
  • 又称X11
    • 商业软件可以用，甚至可以出售MIT协议的代码
  • 相比BSD协议和Apache协议，限制更少
  • 分发软件时，必须保留原始的许可证声明
  • 未明确是否可以使用开源软件所包含的专利，一般认为默认可以使用
    • 不禁则行
  • 典型应用
    • jQuery、nodejs、lua、Ruby on Rails、PuTTY、Mono、DeepSeek
• Apache 2
  • 又称为Apache License 2.0
    • 可以不开源，商业友好
  • 分发软件时，必须保留原始的许可证声明
  • 不能以任何形式暗示自己的产品是经过 Apache（官方）认可过的
    • 可以说：我的软件是基于Apache xxx
    • 不可以说：我的软件是Apache xxx
  • 修改说明
    • 如果文件被修改了，必须向用户说明该文件的修改情况
    • 没有修改的文件，必须保持许可证不变
  • 可以使用开源软件所包含的专利
    • 列出了授予和取消授予的情况
  • 典型应用
    • Hadoop、Apache HTTP Server、MongoDB、JMeter、Byte Buddy、cglib、SeaweedFS、LLVM、Alacritty、OpenHarmony周边（社区治理、开发者支持、社区交流等）
• CC协议族
  • 概述
    • 是一种公共著作权许可协议
      • 在作者保留相关版权权利的前提下，作品在满足特定条件的情况下便可以被自由复制、传播，在不违反版权保护法律的情况下获得、分享更多创作于素材
      • 很便于信息传播使用
      • 文档、博客、传媒领域用的更多一些
    • 历史演进
      • 2001年由美国一家非营利性Creative Commons基金会发起
        • Creative Commons位于美国的所谓非营利性组织的知识共享。中文名：知识共享，台湾翻译为创用CC。 作品（无论文字、图片和视频）一旦完成，创建者即自动享有著作权，默认情况下，即未授权的情况下，不得以任何形式使用。 CC协议只涉及著作权，不涉及专利、商标等其他权利。 CC协议不是独占协议，所以，你可以让自己的产品使用CC协议保障著作权的同时，采用其他协议附加到自己的产品上来。 使用CC协议的作品，虽然法律法理上没有问题，但是，2023年了，美国在没收了俄国斯的海外资产之后，也已经蓄谋禁止美国供应商向华为提供任何商品了，这种事情都做得出来，所以，大家心里要有个数啊。
        • 这不是一家独立法律资质的机构
          • 不对外提供法律服务
          • 按其现状提供协议文本和相关信息
          • 最大可能程度内不提供任何担保
            • 使用CC协议的产品造成任何问题概不负责
      • 2002年12月16日，该组织首发CC系协议
      • 2003年，CC协议进入中国
      • 2006年月29日，CC协议2.5版系列协议在北京发布
      • 2013年11月，该组织正式发布了4.0系列协议
    • 关键约束
      • 不剥夺创作者的版权或获得报酬的权利
        • 作者版权仍得到保留
      • 主动宣告他人在协议限定范围内的分享行为可以不向作者告知
      • 需要一个司法地区的CC组织进行适配本地法律的本地化后才能正式使用
      • CC许可证可以用于文字、音乐、照片和视频，不可用于软件
        • 所以，只能用来作为软件文档的许可协议，不能用于软件本身
    • 更多的被设计师、文章书籍、报刊杂志所使用的开源协议
    • 被设计为可以在全世界执行
  • CC系协议后缀用法
    • 现在见的很多，许多网站以全称：Creative Commons Attribution 4.0 International License表述此协议。
    • BY后缀
      • BY的意思是署名
        • 您可以可以复制、发行、展览、表演、放映、广播或通过信息网络向公众传播该作品
        • 必须保留作者的署名
          • 所谓著名，是TASL
            • T，Title，题目，Spirit
            • A，Author，作者，Creative Commons
            • S，Source，来源，来源URL
            • L，License，协议，许可证CC BY 4.0
            • 著名示例
              • 上述文档翻译自Creative Commons的Spirit/CC BY 4.0，并由李大伟以CC BY 4.0许可
                • 文档中的Spirit/CC BY 4.0要添加超链接，以满足四个条件中的“来源URL”。
        • 最宽松的协议版本
        • 只要在使用时署名，那么使用者可以对本创作进行转载、节选、混编、二次创作以及商业目的使用
    • SA后缀
      • SA的意思是相同方式共享
        • 你可以自由复制、散布、展示及演出本作品
        • 您的作品必须与原作品采用相同的许可协议
    • NC后缀
      • NC的意思是非商业性
        • 可以自由复制、散布、展示及演出本作品
        • 不得为商业目的而使用本作品
    • ND后缀
      • ND的意思是禁止演绎
        • 你可以原封不动地对原作品进行复制、发行、展览、表演、放映、广播或通过信息网络向公众传播
        • 不得改变、转变或更改本作品，即：不得演绎
    • 后缀可组合使用
      • CC BY
        • 可商用
      • CC BY-SA
        • 可商用
      • CC SA
        • 可商用
  • CC0
    • CC 协议以外的一种新的版权声明
      • 注意：这只是作者单方面放弃著作权的一种声明，不是许可证协议。
      • 代表作者宣布放弃该创作的一切版权，该创作进入共有领域
        • 公有领域是指任何个人或团体都不具有其所有权的知识财产
    • 该创作则可以被不加限制的引用、转载、二次改编、再发表、运用于商业用途，使用者可以不标示该创作的来源和作者
    • 中国大陆地区并不允许著作者放弃自己的版权
  • CC3
    • 概述
      • 相比CC4.0，用的人少
    • 限定
      • 只要声明来源，就可以免费用于商用
        • 想要商用又不想声明来源，付$69.95元即可
      • 你可以在任何媒介上以任何形式复制、发行作品
      • 你可以以该作品为基础，修改、转换、改编进行创作（即：演绎）
      • 必须著名
      • 只要你遵循CC3协议，许可人就无法收回你的这些权利
    • 典型应用
      • PHP官方文档
  • 典型应用
    • 维基百科
      • 创作者在youtube和flickr上发布作品时，可以选择自己的作品使用CC协议
  • 附加
    • 我国尊重版权的发展较缓，普遍做法是打水印而不是声明协议
      • 影响观感
      • 对保障著作权作用有限
    • 我国已有案例中，并未否认CC许可证的合同法律效力
      • 中国学界、商界曾发布过大陆版的CC协议
    • 我国台湾地区对Creative Commons的协议进行了本地化
      • 可以在台湾地区使用
    • 新加坡没有对Creative Commons的协议进行本地化
    • 大陆许多企业经常这么做
      • 作品中使用了采用CC BY 4.0协议的图片，并进行了编辑修改，但是却不标出处只打logo或水印
        • 这是不可以的
          • 在这里可以查阅视觉中国的反面案例。
• PDM
  • 是CC协议发布者Creative Commons发布的
  • 这不是一个协议，而是一个标志
    • 用于标记某一作品没有著作权，可以由任何人使用
    • 这么做是为了和CC0区分
      • CC0是版权声明，PDM是协议标志
• MulanPSL
  • 中国首个开源协议
    • 木兰宽松协议
    • 2019年8月发布v1
    • 2020年2月发布v2
    • 中英文具有同等法律效力，因翻译等问题出现问题时，以中文为准
  • 永久性、全球性、免费的、非独占的、不可撤销的版权和专利许可
  • 禁止“贡献者”或“关联实体”直接或间接地（通过代理、专利被许可人或受让人）进行专利诉讼或其他维权行动，否则终止专利授权
    • 可以更加放心的使用
  • 明确不提供对“贡献者”的商品名称、商标、服务标志等的商标许可
    • 保护“贡献者”的切身利益
• BSL v1.1
  • 全称Business Source License，是Mariadb公司新定义的协议
    • v1.1最目前最新版本
    • Mariadb是MySQL生态系最重要的一个分支
      • MySQL被Oracle收购，有随时闭源的风险
        • MySQL现在虽然开源，但是核心开发团队都在Oracle内部，没有外人参与。
      • MySQL的协议是双重许可
    • 尚未获得OSI认可
  • 采用BSL协议的软件，代码是开源的，你可以拿到
    • 在非生产环境，可以不受限制的使用
    • 在生产环境，后端实例不能超过3个，超过必须购买商业授权
  • 如果你的软件使用的BSL协议
    • 软件发布之日起最多4年（可在协议中声明）之后，要转为GPL v2开源协议
      • 也可以转为GPL v2之后的版本
  • Mariadb公司发布的很多产品使用的BSL协议
    • Mariadb数据库本身是GPL协议的
      • 因为它是从MySQL衍生出来的
  • 典型应用
    • Akka、CockroachDB
• SIL Open Font License 1.1
  • 一种开源字体授权许可协议
  • 你可以
    • 自由商用，无需知会作者，无需标明原作者
    • 自由传播、分享
    • 用于软件、APP中
    • 与自己的软件一起捆绑销售
    • 可修改、改造字体
  • 你不能
    • 用于违法行为
    • 单独出售字体文件
    • 修改改造字体之后以新的协议发布
• CLA
  • 开源领域的协议
    • Contributor License Agreement
    • 许多开源软件，贡献者必须签署CLA协议才能提交PR
      • 用来约束开源项目的贡献者和开源项目之间的关系
    • 中国有个本地化的CLA
  • 多少还是存在一些争议的
  • 主要内容
    • 贡献得声明对开源项目中的贡献内容（包括代码文档等）拥有所有权
      • 换句话说，你不能抄了别人的进来说这是你的然后贡献进去
    • 贡献内容要遵循开源项目的开源协议
      • 比如人家开源项目原来是MIT，不能你贡献了就改成GPL的了。
    • 贡献内容中如果包含了专利，该贡献者拥有该专利的所有权
    • 贡献者签署CLA，意味着授权开源项目及其用户可以使用这个专利
    • 对开源项目和贡献者、用户都是一种保护，可以尽可能避免各种诉讼
  • 它是对开源软件本身采用的补充协议，一般分为公司级和个人级
    • 公司级
      • 签署后代表全公司员工都认可CLA协议
      • 员工离职后企业可以通过CLA的一个管理系统取消该员工的贡献权限
    • 个人级
      • 仅代表个人认可CLA协议
  • 应用
    • 阿里巴巴只提供个人级别的CLA签署，进行了中国化
    • Google、Microsoft、华为等都使用了CLA
    • 如果开源项目没有签署CLA而又有关联诉讼，那么必须一一通知贡献者
      • ● LLVM和Firefox都曾经在这个问题上吃过亏，不可不慎。
• DCO
  • 开源领域的协议
    • Developer Certificate of Origin
    • CLA的轻量级版本
      • 为贡献者减负，避免阅读冗长难懂的法律条文
    • 目前版本是1.1
  • 主要内容
    • CLA是贡献前一次性签署
    • DCO是每次提交代码之前都要签署
      • 使用git时，提交代码添加 -s 参数自动签署
  • 应用
    • Github中可以使用DCO
    • CNCF的Sandbox
• Copyleft
  • 什么是 Copyleft
    • 与Copyright一样，保护创作者的权利
    • 促进作品自由共享
    • 衍生作品同样开源
    • 具有传染性
      • 多年以来，和Copyright有许多恩恩怨怨
        • 比如微软曾经说GPL是病毒
  • 内涵
    • 大家一起开源，鼓励共同开发，保持作品在传播过程中的开放和共享
    • 与Copyright相对应
      • Copyright注重于保护创作者的专有权利、控制作品的使用和传播
  • 协议应用
    • GPL
    • AGPL
    • LGPL
    • MPL
• 共通
  • 披露要求
    • 明确表示软件中使用了xxx开源软件的代码
      • 一般提供完整的原始许可证即可
  • 反向限制
    • 你采用了这些协议，但是你却额外附加了与这些协议中许可条款相违背的禁止性条款
      • 这是不可以的
  • 核心竞争
    • 开源厂商的产品被云厂商“白嫖”，因此才有了更新的竞争和恩恩怨怨。
  • 重点提示
    • 专业的商用软件通常不使用GPL，使用LGPL要慎重评估
  • 各类开源软件基金会
• 中国化问答
  • 虽然有众多的开源许可协议，但是一些中国的法律并不完全与它们相一致，我们要仔细评估这些差异，从而做出正确的决定。
  • 1. 我把软件开源了，你使用中出现任何问题与我无关
    • 要注意2017年颁布的《中华人民共和国网络安全法》
      • 其第二十二条规定：网络产品、服务的提供者不得提供恶意程序，网络产品、服务发现安全缺陷、漏洞时，提供者应当立即采取补救措施，按规定告知用户并向主管部门报告。 网络产品、服务提供者应当为其产品、服务提供安全维护，在规定的或者和当事人约定的期限内，不得终止提供安全维护。
    • 具有收集用户信息功能时，应当向用户明示并取得同意
  • 2. 软件发布在国外，发现安全漏洞，应当先向谁报告
    • 软件给了国外了，自己只是开发者，应当向国外报告，但向国内报告不得迟缓
      • 2021年的log4j安全漏洞，阿里云工程师发现之后，并没有第一时间向国内主管机关报告。