[知识产权] 开源协议

0 引言

引言

  • 这几年明显可以感受Github、Gitee上优秀的开源项目越来越多，这些开源软件给众多开发者提供了便利，小到个人兴趣爱好的小工具，大到国之重器突破卡脖子，以至于有的开发者调侃自己是面向Github编程。

当然，绝大多数开源项目都会附带开源协议，大多数人可能对开源协议不太了解————客观来讲，一般情况下如果是个人非商业化使用，或者作为企业内部工具，问题都不大。

  • 时至今日软件开源社区已引领开放创新和数字创新实践前沿超过二十载，并正以其独特的方式重塑着数字经济时代、人工智能时代下人类社会的组织生产模式与价值逻辑。

  • 据报告显示，当前已经有超过90%的IT领导者都在使用企业级开源，国内超过八成的软件开发中使用到了开源技术。

  • 《国民经济和社会发展第十四个五年规划和二〇三五年远景目标纲要》首次将“开源”纳入顶层设计，开源经济俨然成为各界关注的焦点。

  • 开源理念创造巨大经济效益的同时，也对传统的知识产权保护制度提出了挑战。

本文将介绍开源软件的发展历史、价值追求、开源许可协议文本，并结合国内的司法裁判观点探讨有关开源的法律问题。

核心引文 : [A1]、[A2]

本文我们通俗易懂讲一下常见几种开源协议，如果有理解错误的地方，欢迎交流指正。

什么才叫“开源软件”？

  • 不是可免费商用就叫开源，更不是公开了源代码就叫开源。
  • 例如，在Llama 1发布时，很多评论认为它开源了，又没有完全开，这就是典型的对开源的误解。

  • 开源的标志是开源许可证，即Open Source License。

  • 只有当一个软件的许可证条款符合开源定义时，才可以称作一个开源软件。

例如，为什么Llama2的许可协议不符合开源定义呢？

  • 开源的定义，在国际上是有明确的规定的: 开源促进会（开源定义 – 开源促进会 (https://opensource.org/)）发布的著名的十条定义，来源于debian社区对自由软件的定义，是目前国际通用的开源定义。

例如，在这十条中，Llama的许可协议与以下两条有冲突：

    1. 不歧视个人或群体（Llama License 第2条规定月活7亿以上的企业用户，无法通过本License直接获取授权）
    1. 不歧视领域：许可证不得限制任何人在特定领域使用该程序。例如，它可能不会限制该程序用于企业或用于基因研究。
      （Llama License 第1条b4款中引入的《可接受使用政策》，限制了任何违法行为、欺骗行为和未披露风险的使用；b5款禁止使用Llama2的输出结果去改善其他Ai大模型。这就属于对使用领域的限制）

可见，Meta一方面不希望巨无霸公司【白嫖】，另一方面也不希望被其他AI模型白嫖。可以理解。但是，这就导致它不是真正的开源软件。

自由软件运动 => GPL开源协议的诞生

自由软件运动 & GPL开源协议

  • 目前，计算机程序被纳入著作权法的保护范畴并被世界范围普遍接受。

  • 20世纪80年代，美国电话电报公司（AT&T）推出的操作系统UNIX被世界各地的学者与开发人员广泛使用。

  • 彼时的AT&T通过著作权保护对UNIX实行专有，其源代码也逐渐走向封闭。

  • 为了应对软件闭源的垄断效应，理查德.斯托曼（Richard Stallman）发起了自由软件运动

  • 其核心理念是，软件的用户应该拥有运行、复制、分发、研究、修改和改进软件的自由。
  • 他还倡导了GNU计划(GNU General Public License Plan, GNU通用公共许可证，简称 GPL)，旨在创建一个完全自由的操作系统。GNU计划产生了大量的开源软件，并最终形成了GNU通用公共许可证（GPL），这对开源软件的发展产生了深远影响。
  • 并在次年1985年10月，创办了对开源产业、计算机科学与产业影响深远的自由软件基金会（Free Software Foundation, FSF）。
  • 其组织的主要工作：执行GNU计划，开发更多的自由软件，完善自由软件理念。
  • 其是一个致力于推广自由软件、促进计算机用户自由的美国民间非盈利性组织。

自由软件运动的重大成果

  • 开源操作系统：Linux

Linus Torvalds于1991年10月5日首次发布基于UNIX的开源操作系统Linux。
一个性能稳定的多用户网络操作系统，迅速发展并成为世界上最广泛使用的开源操作系统之一。
Linux有上百种不同的发行版，如基于社区开发的debian、archlinux，和基于商业开发的Red Hat Enterprise Linux、SUSE、Oracle Linux等。

  • 开源社区：Github

GitHub于2008年4月10日正式上线，除了Git代码仓库托管及基本的Web管理界面以外，还提供了订阅、讨论组、文本渲染、在线文件编辑器、协作图谱（报表）、代码片段分享（Gist）等功能。
GitHub是现在最受欢迎的托管平台，过亿的开发者，400多万的组织，420多万的代码仓库。

GPL 协议

  • GNU计划(GNU General Public License Plan, GNU通用公共许可证，简称 GPL)
  • 是由自由软件基金会发行的用于计算机软件的协议证书。
  • GPL协议是GNU项目使用的协议，要求用户公开源代码，并且在修改后必须继续以GPL协议发布。
  • 这意味着如果你使用了GPL协议的代码，你的项目也必须遵循GPL协议，这被称为“传染性”许可。这使得GPL协议成为最严格的开源协议之一。
  • 最佳实践: (from 较为中肯的网友观点)

商业软件不能直接使用受GPL保护的代码，因为这会导致整个项目必须遵守GPL的所有条款。
一般不建议使用，主要还是太麻烦了。
如果一定要使用，也有看到一些人的规避的办法，那就是隔离。
需要明确哪些部分是基于GPL开源代码的衍生作品，哪些部分是独立开发的。
根据GPL协议的规定，只有基于GPL开源代码的衍生作品才受到GPL协议的约束。

可以通过将基于GPL开源代码的部分与独立开发的部分分开部署，并对每个部分分别进行著作权登记，以此来有效隔离GPL协议的传染性。

GPL 1.0

许可模式

  • 每次分发 GPL 程序时，接收者会自动依据相关 GPL 条款从每个上游许可人处获得一个许可证。

  • 只要分发的作品中包含其他版权所有人的素材，这些版权所有人就都是上游许可人。

  • 这相当于是一个三维（而非线性）许可权利。

  • 该作品的每个接收者都默认或直接从每位许可人处获得许可。

  • 这一自动向下游授予许可的机制是 Copyleft(英译：非盈利版权、公共版权) 得以运行的核心。

  • 每个许可人独立授予许可，而且每个许可人都有权在遭到侵权后独立终止该许可。

GPL 2.0

许可模式

  • 在 GPL2.0协议下，受到侵犯的许可会自动终止。

GPL 3.0

GPL 3.0是由自由软件基金会发布的一种自由软件许可证，其旨在确保软件保持自由发布；同时，提供对开发者和最终用户的保护。
GPL 3.0 是 GPL 许可证的第三个版本，旨在解决前两个版本中出现的一些法律和技术问题。

许可模式

  • 而在 GPL 3.0 协议下，违反许可证协议的一方可能在许可终止前进行补救。
  • 侵权方的下游用户只要未侵权，其获得的许可就仍然有效。

因为他们是从所有的上游权利人处直接获得许可，而不依赖于分发软件的侵权方所授予的许可。

  • 基于相同原因，任何侵权人即使再获得一份该程序副本，也无法获得任何新许可权利。

也就是说，一旦该程序的任何上游许可人终止了授予侵权人的许可，该侵权人就无法再自动获得新许可，即使再获得一份该软件也不允许。

著佐权“触发器

  • 大多数开源义务都是通过分发（distribution）触发的。
  • 依据GPL3.0，如果发布软件的副本，无论以免费还是以收费的模式，须确保副本的接收者也能收到或者得到源代码。
  • “传播（propagate）”作品指使用该程序做任何如果没有许可就会在适用的版权法下直接或间接侵权的行为，包括复制，分发（无论修改与否），向公众提供等；但不包括在电脑上运行或者私下的修改。

也就是说“传播”的边界大于“分发（distribution）”。
“发布”作品指任何让其他方制作或者接收副本的传播行为；
仅仅通过电脑网络与一个用户交流，且没有发送程序副本的行为不是发布。

  • GPL3.0的基本许可部分将被许可人分为了两种：
  • 不发布受保护作品的被许可人，可以无条件地制作、运行和传播作品；
  • 发布受保护作品（无论修改与否）的被许可人，则需要满足GPL3.0规定的条件（提供修改声明、随程序附带源代码等）。

性质

  • 早期我国就有学者提出：开源许可证属于合同。
  • 首先，认为 GPL在内容和形式上都具备合同的法律特征，适用 GPL 进行许可的行为首先是一种民事法律行为
  • 其次，源代码的接收者通过使用源代码的行为做出了承诺并与发布者达成合意；
  • 最后，GPL 在形式上具备合同的法律特征，属于书面合同。
  • 也有学者认为，缔结履行 GPL 的行为属于负担债务的行为。
  • 在具体当事人中产生约束力，符合合同成立的一般要件，权利人发行源代码、并附加 GPL 协议可以被视为邀约;
  • 源代码接收者下载使用、修改或传播著作权人所公开源代码的行为则为承诺，且承诺作出即产生法律效力，合同即告成立。
  • 我国互联网行业在2000年后迅速进入高速发展期，几与欧美同步，GPL 协议的效力很快进入我国司法审查的视野，贡献出“不乱买公司诉闪亮公司案”“数字天堂诉柚子移动案”以及“罗盒”系列案等经典案例。
在二审中，原告上诉称被告的前端代码和后端代码存在交互、且没有进行有效隔离，不是相互独立的。

最高院在二审判决中认为，根据GPL3.0协议开源传染性的例外条款对“聚合体”的规定：
    闪亮时尚公司所称GPL协议的“传染性”应当是指GPL协议的许可客体不仅限于受保护程序本身，还包括受保护程序的衍生程序或修订版本，但不包括与其联合的【其他独立程序】。
	本案中，虽然不乱买公司认可其前端代码中使用了GPL协议下的开源代码，但其主张权利的是后端代码，其后端代码是独立于前端代码的其他程序，并不受GPL协议的约束，无需强制开源。

最高院的在该案中的二审判决引用了GPL.v3开源协议中对开源传染性的例外条款。
突出体现了基于对程序之间关系的深入分析、综合判断涉案程序是属于“衍生产品”还是“独立程序”的总体思路。
这体现了我国法院对于涉开源协议相关案件审理理论和方法的进步，也更符合开源社区和其他国家司法实践中的主流思路和方案。
  • 2019年11月初，数字天堂公司诉柚子公司等侵犯计算机软件著作权纠纷案，由北京高院二审作出终审判决，被称为中国 GPL 诉讼第一案。

深圳知识产权法庭 祝建军法官 认为软件著作权人将其享有权利的软件按照平台的规定进行上传，即意味着该软件著作权人愿意按照平台规定的许可证将其软件进行开源许可，此为合同要约行为。
而用户对平台上的开源软件进行使用、修改、发布，则意味着其以行为的方式承诺愿意，按照开源许可证使用该开源软件，此为合同承诺行为。
如此一来，双方通过行为的方式成立开源软件许可证合同关系。

  • 在后续涉及 GPL 协议的判例中，法院进行了更多的探索。

在罗盒公司诉风灵公司案中，法院指出开源许可证具有合同性质，可认定为授权人与使用者订立的著作权协议，属于我国合同法调整的范围。
入选2021年中国法院十大知识产权案件的罗盒公司诉玩友公司案中，法院直接对开源协议的效力做出了认定，认为协议内容具备合同特征，属于广义的合同范畴，是授权方和用户订立的格式化著作权协议。

GPL 3.0传染性约束范围的司法审查

  • 在我国最早涉及GPL的案件－柚子公司等与数字天堂公司著作权纠纷案中：
  • 法院在认定涉案插件是否开源软件时，以涉案插件所在文件夹中不含有开源许可证文本为由，否定了涉案插件为开源软件的衍生软件。
  • 案件上诉后，二审法院同意了一审法院有关开源软件和开源许可证的认定。
  • 该判决仅根据开源协议所在的文件夹位置否定了GPL传染性的适用，引起了诸多争议。

  • 在不乱买公司案件中，法院认为原告主张权利的后端代码独立于开源的前端代码，无需强制开源。

  • 在罗盒案中，就开源协议的传染性问题，法院作出了如下的分析：

  • 如果程序的一部分是独立的、非衍生的，那么这部分软件独立发布时可以不受GPL3.0协议约束。
  • 要避免开源代码传染其他代码，国际上已有行业先例。

比如，谷歌公司将其发布的安卓系统分为多个独立的不同层级框架，对每个层级适用不同的开源协议。
若无法回避许可协议之间的冲突，也至少应当采取简单的编程接口连接，降低软件源代码运行时的融合程度。
而案涉软件既没有采取类似的隔离措施，也没有证明案涉的源代码是独立的，所以案涉软件受GPL的传染性约束，应当承担开源义务。

  • 在2023年判决的网经公司诉亿邦公司等侵害计算机软件著作权案中（该案涉软件适用GPL2.0），被告抗辩原告在案涉软件中使用第三方开源代码而并未履行开源义务。

最高人民法院基于“合同相对性”原则，认为不宜审查原告是否违反其与第三方之间的GPL协议；
即便原告违反该等GPL协议导致涉案软件存在权利瑕疵，也不影响原告寻求被侵权的权利救济。
被诉侵权人根据开源协议提出不侵权抗辩的情况下，软件开发者自身是否违反GPL2.0协议和是否享有软件著作权，是相对独立的两个法律问题，二者不宜混为一谈，以免不合理地剥夺或限制软件开发者基于其独创性贡献依法享有的著作权。

  • 可以看出，我国司法界倾向于认可开源协议的效力，在审查开源协议使用者的义务时更加注重实质，提出了审查“展示方式、所用技术、分工”以及“修改软件在逻辑上与开源代码的关联性”等关键标准来判断开源协议传染性的约束范围。

著名开源项目

  • MaxKB ：基于 LLM 大模型的知识库问答系统

LGPL 协议

  • LGPL (Lesser General Public License)
  • 最新版本是LGPLv3 ，2007年6月29日发布，较早的版本有2.0和2.1版。
  • 此种授权之出现，是为了在GPL与许可试授权(如MIT及柏克莱大学的BSD)间取得折中。
  • 采用LGPL之计划本身虽然仍有"著作权脱离"("Copyleft")之限制条件，但这些限制不感染仅仅只联结到本计划的软件。

不过此等软件仍会受到其他限制。

  • LGPL是相对宽松的传染型许可证，允许商业软件使用，是GPL协议的一个变种。

  • 如果修改、分发LGPL协议的代码，那跟GPL是一样的。

  • 任何修改或衍生自LGPL许可证的软件都必须继承LGPL许可证，不允许封闭源代码。

  • LGPL许可证的初衷在于扩大开源组织库函数的影响力，使GNU库函数的广泛应用，成为事实的软件开发标准。

因此，LGPL允许商业软件在一定条件下使用GNU库函数，而不受开源的影响。
LGPL许可证，适用于特殊设计的函数库。
准许非自由的程序可以与这些函数库连结。

Apache 2.0 协议

  • Apache 2.0 是Apache软件基金会使用的开源协议，允许用户自由使用、修改和分发软件，但要求必须保留版权和许可声明。
  • 如果在使用受保护的代码时进行了修改，那么根据Apache License 2.0的规定，修改后的代码必须以源代码的形式提供。
  • 这是为了方便其他开发者理解和维护代码，同时也符合开源的精神。
  • 在使用受Apache License 2.0保护的代码时，应遵守相关的商标和专利规定。

这意味着，未经授权，不得使用受保护的商标或专利技术。
这也是一种商业模式，源码可以使用，但需要付专利费。

  • 同时，这种协议的友好开放性，也经常跟其他补充协议一起用。

比如： FastGPT

著名开源项目

  • QWen2-VL 大语言模型
  • 零一万物 大语言模型
  • FastGPT
  • Milvus 向量数据库

https://github.com/milvus-io/milvus?tab=Apache-2.0-1-ov-file#readme

MPL 协议

  • MPL (Mozilla Public License)
  • MPL是一种弱著作权许可证，1998年初由Netscape的 Mozilla 小组为其开源软件项目设计。
  • Netscape公司认为GPL没有很好地平衡开发者对源代码的需求和他们利用源代码获得的利益。
  • MPL虽然要求对于经MPL许可证发布的源代码的修改，也要以MPL许可证的方式再许可出来，以保证其他人可以在MPL的条款下共享源代码。 但是，在MPL许可证中对“发布”的定义是“以源代码方式发布的文件”。

这就意味着MPL允许一个企业在自己已有的源代码库上加一个接口，除了接口程序的源代码以MPL许可证的形式对外许可外，源代码库中的源代码就可以不用MPL许可证的方式强制对外许可。
这也是一种隔离的策略。

  • MPL许可证允许在其授权下的源代码与开发者个人文件进行混合，闭源商用，但在MPL授权下的代码文件必须遵守MPL许可证，并且保持开源。
  • MPL许可证不像GPL许可证那样明确表示反对软件专利，但是却明确要求源代码的提供者不能提供已经受专利保护的源代码（除非他本人是专利权人，并书面向公众免费许可这些源代码），也不能在将这些源代码以开放源代码许可证形式许可后再去申请与这些源代码有关的专利。

MIT 协议 := X 条款 := X11条款

  • MIT (Massachusetts Institute of Technology) License
  • MIT许可证之名源自麻省理工学院（Massachusetts Institute of Technology, MIT），又称“X条款”（X License）或“X11条款”（X11 License）。
  • MIT协议是最宽松的协议之一，允许用户自由使用、修改和分发软件，只要保留MIT版权声明。
  • 商业软件可以无限制地使用受MIT协议保护的代码。
  • MIT许可证要求在所有副本中包含原始版权和许可证信息，但相对简单，只需保留原始许可证和版权声明即可。

著名开源项目

  • Fasis : 向量数据库
  • Ollama : LLM部署工具 & 运行环境

BSD 协议

  • BSD (Berkeley Software Distribution) License
  • BSD许可证原先是用在加州大学伯克利分校发表的各个4.4BSD/4.4BSD-Lite版本上面（BSD是Berkeley Software Distribution的简写）的，后来也就逐渐沿用下来。

1979年加州大学伯克利分校发布了BSD Unix，被称为开放源代码的先驱，BSD许可证就是随着BSD Unix发展起来的。

  • 与MIT协议类似，允许用户自由使用、修改和分发软件，但保留了原作者的版权声明。
  • 然而，如果其他人对代码进行了修改并发布，他们可以选择不公开源代码。
  • 这使得BSD协议成为许多大型项目的选择，如FreeBSD和NetBSD。

其他协议

CC 协议 := 共创协议

https://creativecommons.org/
https://www.ruanyifeng.com/blog/2008/04/creative_commons_licenses.html

CC协议中作者可保留的权利

  • 作者使用CC协议，可以且只能选择保留以下四种权利：
  • 署名（Attribution，简写为by）：必须提到原作者。
  • 非商业用途（Noncommercial，简写为nc）：不得用于盈利性目的。
  • 禁止演绎（No Derivative Works，简写为nd）：不得修改原作品。
  • 相同方式共享（Share Alike，简写为sa）：如果允许修改原作品，那么必须使用相同的许可证发布。

以上4中权利排列组合，就有16种，但是要注意几点：
1） 不能同时选择 禁止演绎 与 相同方式共享
2)　不能同时放弃４种权利

Llama2 协议 ≠ 严格的开源协议

  • 核心内容
    1、Llama2的协议不满足开源定义，不属于真正的“开源”软件；
    2、可以二次开发、可以免费商用；
    3、提供SaaS服务无需履行任何义务；但分发时需要提供许可证副本和归属通知；
    4、不要假装和用户对话的是真人，不是AI。

  • 授予的权利

Llama License 第1条第a款：
根据Meta的知识产权或 "Llama材料 "中体现的Meta拥有的其他权利，您被授予非排他性的、全球性的、不可转让的和免版税的有限许可，以使用、复制、分发、拷贝、创作衍生作品和修改 "Llama材料"。
“免版税的”，即说明了其非商业属性；
“创作衍生作品和修改"，即说明了可以二次开发。

注意，按照协议的定义部分，”Llama材料“不仅包括软件本身，还包括了相关文档。

  • 推荐文献

详情参考

其他协议

除了常见的协议外还有很多其他的，也有一些奇奇怪怪的协议，比如WTFPL，估计没有什么比这个更天马行空、更自由洒脱了，有意思

总结

协议 修改源码后可以选择闭源 修改后的文档必须放置版权说明 新增代码必须使用此许可证 对修改的源码文档进行说明 可以用于商业软件
BSD 是 否 否 否 是
MIT 是 否 否 否 是
Apache License 2.0 是 是 否 是 是
GPL 否 否 是 否 是
LGPL 否 否 否 否 是
  • GPL和LGPL ： 对商业使用有较严格的限制，如果是企业使用，尽量避免使用这GPL协议的开源项目。
  • LGPL不修改源码只是引用可以。
  • MIT、BSD、Apache：提供了较为宽松的条件，允许商业软件无限制地使用其代码。
  • MPL也允许商业使用，但衍生作品必须以MPL或更宽松的协议发布。
  • 尽可能在商业使用之前把开源协议搞清楚，有可能会因为使用不当而存在争议的问题，虽然不多，但还是有一些因为开源协议的知识产权诉讼案例。

  • 在选择开源协议时，开发者需根据项目的具体需求和条件选择最合适的协议。同时，开源社区也鼓励开发者在使用开源代码的同时，尊重和注明原作者的著作权。

也就是说，GPL(包括GPL v2、GPL v3)/LGPL协议的开源代码，我们虽然可以在商业软件中使用它，但只能原封不动的使用而不能对它做任何改动，如若改动则必须开源。
而BSD/Apache2.0/MIT则相对比较协议友好，是我们的首选。
特别需要注意的是，LIBIEC61850这个常见的开源IEC61850协议栈采用的协议即为GPL v3协议，我们不能在不二次开源的情况下对其进行任何修改。

X 参考文献

  • [1] 马治国,朱建：开放源代码软件通用公共许可证的法律性质[J].科技进步与对策
  • [2] 北京高级人民法院 (2018) 京民终 471 号民事判决书
  • [3] 祝建军.开源软件的著作权保护问题研究
  • [4] 广东省深圳市中级人民法院（2019）粤 03 民初 3928 号民事判决书
  • [5] 广州知识产权法院（2019）粤 73 知民初 207 号民事判决书
  • [6] 最高人民法院（2019）最高法知民终 663 号二审民事判决书
  • [7] 同注释5
  • [8] 最高人民法院（2021）最高法知民终51号民事判决书
posted @ 2024-09-12 22:27  千千寰宇  阅读(58)  评论(0)  编辑  收藏  举报