开源合规及其风险管理

前言

1、开源合规及其风险管理的目的与意义

目的与意义：

• 了解开源与许可协议、专利
• 了解不同场景下开源的合法合规要求，避免开源代码因不符合相关要求在对外提供后而引发的法务和知识产权方面的影响
• 了解合法合规工具，掌握合法合规提升效率的方法

2、开源合法合规的必要性

1）外部压力

• 开源软件维权人的积极维权
• 开源社区规范的倒逼
• 开源爱好者的自媒体监督

2）内部压力

• 内部流程规范的要求和追责机制

一、开源软件合规风险

1、开源软件三大组成要素

1）开源软件定义

开源软件是一种源代码免费向公众开放的软件，任何团体或个人都可以在其 License 的规定下对其进行使用、复制、传播及修改，并可以将该修改形成的软件的衍生版本再发布。

—— 来源于 OSI 开源软件定义

2）运作机制

开源软件三大组成要素：License + 社区模式 + 商业模式；

• License 是游戏规则，不遵守将承担法律后果
• 社区是组织方式，其发展的核心学问所在，主要特征：子项目充分竞争、充分的对等评审、用户充分参与、源代码发布等
• 商业模式是本质，主要包括：捐赠、技术服务、广告、增值产品、双重授权、软硬件结合等

比如 Open-Core 这类的商业模式，将企业版中的部分功能开源，从而吸引用户进来社区，当用户数量足够多，能够为它的其他收费功能进行付费时，企业也因此获得收益。也有些企业主要是提供技术服务，比如基础设施维护；另外有些开源软件中会植入广告，收取一定费用等。

2、开源软件主要合规风险

当你听到“开源软件”一词时，你是否认为它与共享软件、免费软件或共有领域软件之类一样，是免费使用的？以及使用开源软件不会具备对应的法律风险？

使用开源软件就是有可能触犯会到它对应的一个法律风险！总体来说，开源软件的合规风险主要分为三大类：开源知识产权风险、数据安全和隐私风险和出口管制风险。其中开源知识产权风险又分为三类：版权、专利和商标风险。

1）版权侵权风险

不遵守开源许可证导致的版权侵权，比如未按 License 要求保留版权声明、许可证文本等。

软件版权其实具备很多对应的一个权利，包括署名权、发表权、保护作品完整权、修改权、复制权和发行权等这些权利。总体来说，不管是开源软件还是闭源（专有）软件，软件的程序及相应的文档都受版权法保护，且版权保护不需要履行注册手续，自产生之时就自动获得版权。

对比闭源软件和开源软件的一些特性，就闭源软件来说，它的版权所有者，通过 ”软件许可协议“，将自己的代码许可给对应的用户，而开源软件的版权所有者，通过 ”开源许可证“ 将自己的代码许可给用户。除此之外，两者在具备版权保护这一方面，不论是闭源还是开源软件，都是具备对应的版权法，即具备版权保护，但在是否提供源代码方面，开源软件代码就是公开提供所有的源代码，闭源软件就需要具体去看对应的所有者和用户之前的合同协议是否需要提供相应源代码。在 “可复制、可修改和可自由发布” 这三大特性方面，闭源软件保留改权利，不允许用户自由复制、修改和分发，然而开源软件是可以自由复制、使用、修改和分发。

开源软件的版权风险分为两大类：

① 违反开源许可证

违反开源许可证主要是指开源软件的使用者，没有按照对应开源许可证的规定去使用开源软件，从而导致版权侵权，之前有一个案例：在 2007 年，Linux 社区成员指责华硕公司没有用遵守 GPL 许可证的规定，华硕公司公布其云顶 Linux 操作系统的 Eee PC 的完整源代码，包括 asus_acpi 组件和所有核心数据，对于希望完全掌控软件的企业而言，将全部源代码开源显然是不可接受的，因此，使用开源软件的企业有必要了解开源软件的法律风险。

② 开源软件存在版权瑕疵

开源软件存在版权瑕疵是指贡献者将不具备版权的代码贡献到开源社区，使得开源软件本身存在版权瑕疵，例如：某一个开源软件贡献者在贡献代码时，把某个公司的 Java 代码，或者说不具有版权的代码贡献到开源软件 a 中，在该情况下开源软件 a 就存在版权瑕疵，用户在使用开源软件a时，可能会触犯到版权，这一点值得注意。

2）专利侵权风险

开源软件侵犯第三方专利导致的专利侵权风险（如 GPL2.0 序言所述：“自由软件还持续受到软件专利的威胁”）

大多数情况下，开源软件中的贡献者协议或者 CLA 里一般不会有太多的定义来描述专利条例，因此在 GitHub / Gitee 上使用开源软件时存在一定的专利侵权风险。

专利风险分为：

① 外部战略风险

外部风险是指不受开源软件许可证约束的乙方针对开源软件的使用者发起的专利请求，相关案例如下：微软公司在 2009 年 2 月起诉导航设备制造公司 TomTom 侵犯其多项专利，该多项专利中有两项涉及 FAT 文件系统，包括 TomTom 产品在内的 Linux 内核都在使用该文件系统，该案也是微软公司第一次针对 Linux 发起专利诉讼，同年 3 月，TomTom 同意向微软支付一笔专利许可费，从而迅速与微软达成和解。

② 内部专利风险

内部风险是开源软件的贡献者针对开源软件使用者发起的专利请求。

3）商标侵权风险

大部分开源许可证不包括商标授权，因此随意使用未经授权的商标会产生侵权风险。

商标和项目有些情况下是分离的，比如我们将某个项目捐赠给某个基金会，但商标我们不一定捐赠给这个基金会，也就是说我们的源代码和商标是分离的，如果在公开场合对商标进行传播，则需要对商标进行授权。如果想要主导一个开源社区，需要注册几类跟IT相关的商标，比如第 9 类、第 38 类、第 41 类、第 42 类等类别的商标。

商标法不同于旨在激励独创性作品和创造性发明的版权法和专利法，商标法的目的是通过保护产品或服务的来源，从而保护生产经营商。开源软件的用户有权在原来的代码基础上开发新的产品，所以开源项目的衍生产品是无法使用与原来项目同样的商标。对于大部分开源许可证的授权，都有对应的版权授权，部分有专利授权，但是很少有开源许可证有对应的商标授权，因此企业在使用开源软件的时候，一定不要随意使用开源软件的商标。

例举 Apache 软件基金会对 Apache 软件商标使用的一个详细规定：

• 可以使用的情况有：描述作品来源、复制 NOTICE 文件时保留的商业性标识、书籍或杂志上等学术用途；
• 不可以使用的情况有：软件产品的品牌中、域名中、会议或活动的名称中。

4）商业秘密风险

商业秘密被公开的风险，比如使用 GPL 的一些开源软件，可能会导致传染，让部门/公司内一些产品的核心软件也必须依照该许可证进行开源，从而导致商业秘密被泄露。

• 因不当使用开源软件而导致产品核心软件代码开源
• 未经授权，将第三方非公开代码开源

3、开源不等于免费，开源软件随意使用存在法律风险

1）履行开源义务

开源软件使用者除了享有使用的权利，还必须按照 License 规定履行相应的开源义务，否则即违反了开源 License。

开源义务包括：

① 使用声明义务

在对外分发产品时，附上声明文档，注明产品所使用的开源软件名称、版权、License 内容等信息。

② 代码开源义务

将一定范围内的代码对公众开放，开源范围视具体 License 的要求和产品具体使用方式而定。

2）案例

某公司内研发员工发现内部某款产品是基于源项目 xx 开发，该项目以 MIT License 发布，但该产品在使用时删除了部分代码文件中 License 声明信息，且在发布时也未另外声明，此行为已经违反了该软件的 License 的使用声明要求。

解析： MIT、BSD 这类开源软件 License 要求较为宽松，使用者可以任意使用，修改代码（甚至软件名称），分发等，但其同时要求使用者履行使用声明义务，即保留原软件的版权与 License 声明信息（或者在单独文件中声明），该产品的行为直接违反了履行使用声明义务的要求。

启示： 由于该产品仅在公司内部使用，不会对外暴露，因此其行为引发外界开源诉讼风险较小，但对于对外商用发布的产品，必须严格按照 License 要求履行开源义务，否则可能引发开源诉讼导致赔款甚至禁售风险。

二、开源许可证及其风险管理

1、开源许可证本质

1）在中国大陆法系国家，开源软件许可证毫无争议的是许可人与被许可人之间的合作，开源许可证是个格式合同，不允许更改；在美国法下，它可能是合同，也有可能是版权；

2）开源许可证规定了许可人（软件开发者）和被许可人（用户）的权利和义务，可能涉及版权、专利、商标、担保等一系列权利义务的设置，正是这些权利和义务，决定了权利人是否将源代码真正地向社会公众开放，从而可以实现是否是开源软件的判断，即初始作者有权选择某个许可证（比如许可证 a）将初始软件发布，对应的中间分发者如果想要再次修改，然后再分发这个软件，那中间分发者需要按照许可证a的要求，梳理需要遵循的义务，再去发布软件，且选择的许可证必须满足许可证a的条件；

3）被许可人在违反许可证设定的义务时构成合同违约，同时，根究具体情况还可能构成著作权侵权，我国合同法第 122 条规定，在违约与侵权构成责任竞合时，当事人需择一地主张权利，涉及采取补救措施、赔偿损失、定金违约金等法律救济形式。

2、许可证规定内容

每个许可证具备的特性都可能不一样，其中 1~5 项为通用属性：

1）编写者：许可证的作者有修改许可证，发布许可证新版本的权利。

2）版本号：开源许可证都应具备版本号，版本号不同，内容有可能不同。

3）术语定义：定义关键概念，比如 "modified"、"derived"、"source code"。

4）版权规定：版权许可条款-明确用户在版权方面的权利；重新发布的规定-规定用户使用、复制和发布的要求。

5）免责条款：免除许可证颁发者和贡献者的责任。

6）专利规定：明确用户在专利方面的权利；专利报复条款。

7）商标规定：明确声明不能使用商标。

8）其他条款：附加责任、新版本选择、地区限制、违约责任规定等

3、开源软件分发场景判断

首先，我们要先判断我们的开源软件的应用场景属于自用还是分发，如果应用场景属于自用，那么就可以忽略开源许可证的规定与要求。

比如，一个公司并没有将开源代码分发给不同主题下的第三方，而是在公司内部同一个主体下进行开源代码的分发，或者仅仅是一个人在自己使用开源软件的这种请款，那该应用场景就属于自用，则可以忽略对应开源许可证的一些要求。

再比如说，一个甲公司把代码分发给第三方，构成了分发条件，在这种情况下就需要遵循对应许可证的规定。

还有一种情况，SaaS 服务就是云服务方面，除了 AGPL、SSPL 这类许可证针对云服务有一个明确的规定外，大部分许可证对其分发没有一个明确的规定。

针对金融和分发，举一个实例，也是前段时间发生的一个状况：某个银行，用 Itext（AGPL 许可证）创建转账发票（PDF），Itext 公司给其发了一封律师函，认为该银行的使用场景存在违规情况，在这种情况下，需要去判断使用场景属于自用还是分发，如果属于自用，那么可以忽略对应许可证的规定，如果是分化，则需深层次判断是否需要遵循对应许可证的规定，那以下哪种场景涉及分发呢？

1）银行使用内部系统创建所有发票，并将它们储存在服务器上，想要查看、打印发票的人可以上网从该服务器获取打印发票；

2）每当用户在系统中查看、打印发票时，都会触发即时创建 PDF 的流程。

答案是第一种情况下属于自用，第二种场景属于分发。首先说说第二种场景，用户在系统中每当想要查看打印发票时，都会即时触发对应代码，这种情况下就涉及到触发对应分发场景，那第一种情况为何不属于分发？其中一个关键词是银行使用内部系统，创建所有发票，所以银行是使用内部系统去运行 Itext，创建转账发票，在整个创建过程中，并没有第三方的一个用户接触到流程，因此第一种情况下属于内部使用，可以忽略AGPL 修正的规定。

4、自由开源软件组件

1）常见的使用情境

① 合并（Incorporation）

开发人员可能会复制部分的自由开源软件，到你的软件产品之中。相关的字词包括：

• 整合 (Integrating)
• 融合 (Merging)
• 贴上 (Pasting)
• 改用 (Adapting)
• 嵌入 (Inserting)

② 链结（Linking）

开发人员可能会链结或加入自由开源软件许可组件，与你的软件产品一起运作。相关的字词包括：

• 静态/动态键结 (Static/Dynamic Linking)
• 配对 (Pairing)
• 贴上结合 (Combining)
• 利用 (Utilizing)
• 打包 (Packaging)
• 建立相依关系 (Creating interdependency)

③ 修改（Modification）

开发人员可能会对自由开源软件组件进行变动，包括：

• 增加/注入新的程序代码到自由开源软件组件里
• 对自由开源软件组件进行修正、优化，或更改
• 删除或移除程序代码

④ 转变 (Translation)

开发者可能会转化程序代码的状态，包括：

• 将中文翻译成英文
• 将 C++ 转变为Java
• 编译成二进位代码

⑤ 开发工具

开发工具可能会在幕後执行某些操作行为。例如，开发工具可能会将其自身的部分程序代码注入至输出成果。

2）自由开源软件组件如何被发行？

① 谁会收受到这些软件？

• 顾客/合作伙伴
• 社区项目
• 在商业团体范围内的另一个法人(这可能会被视为发行)

② 传递的形式是什么？

• 以程序源代码传递
• 以二进位代码传递
• 预载到硬体里

5、开源许可证大家庭

目前开源许可证超过 2,700 多种，根据其互惠性，即常听到的传染性（为何会用到互惠性这个词？传染性相对会有些污名化，是开源的特性，传染性对于大家来说会更好理解，但开源许可证本质上是希望自由公开使用开源软件，因此选择更积极的褒义词去形容开源许可证的特性）。许可证的互惠性，主要是关于许可证对于分发衍生软件的限制，比如许可证 a 和其他模块以某种方式组合在一起，构成衍生作品，该衍生作品也必须遵守对应许可证 a，那么就可以理解为许可证 a 是具有互惠性的。根据互惠性的强弱，可进行如下分类：

开源许可证可按 “源代码再发布时的要求” 分类，按照软件再发布时对提供源代码的要求，互惠性越强，商业友好性越差，版权侵权风险越大。

1）宽松型许可证

宽松型许可证（Permissive License）是最基本的类型，用户可以修改代码后闭源。它有三个基本特点：

• 用户使用代码没有限制；
• 不保证代码质量，用户自担风险；
• 用户必须披露原始作者。

Apache 许可证是注明的非营利开源组织 Apache 软件基金会采用的许可证。该许可证鼓励代码共享和尊重原作者的著作权，允许代码修改和再发布（作为开源或商业软件），同时该许可证还为用户提供专利许可。

如果去分发 Apache 2.0 的一个开源软件，则需要满足以下 4 个条件：

• 没有修改过的文件，必须保持许可证不变。
• 凡是修改过的文件，必须向用户说明该文件修改过。
• 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议、商标、专利声明和其他原来作者规定需要包含的说明。
• 如果再发布的产品中包含一个 Notice 文件，则在 Notice 文件中需要带有Apache 2.0 许可证，你可以在 Notice 中增加自己的许可，但不可以表现为对Apache 2.0 许可证构成更改。

2）弱互惠型许可证

如果一个软件包含弱互惠型开源许可证下的部分代码，完全发布时某些部分必须使用该许可证，其他部分可在其他协议下发布，典型的弱互惠型许可证主要有 LGPL、MPL 和 EPL。

下面主要介绍 LGPL（GNU Lesser General Public License，2.1、3.0，以下分别称“LGPL 2.1" 与 "LGPL 3.0”）

• LGPL 许可证是 GPL 的一个为主要为类库使用设计的开源协议，和 GPL 许可证要求任何使用/修改/衍生之 GPL 的软件必须采用 GPL 许可证不同，LGPL 许可证允许商业软件通过类库引用的方式使用 LGPL 类库而不需要公开商业软件的源代码，这使得采用 LGPL 许可证的开源代码可以被商业软件作为类库引用并发布和销售。
• LGPL 2.1 再发布需要满足的条件：如果修改 LGPL2.1 的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须使用 LGPL 2.1。
• 相比于 LGPL 2.1，LGPL 3.0 不仅要求用户公布修改的源代码，还要求公布相关硬件，如安装环境代码等；同时，LGPL 3.0 明确了专利许可。

3）互惠型许可证

互惠型开源许可证明确要求，如果一个软件包含该协议下部分代码，完全发布时必须作为整体适用该协议。GPL（GNU General Public License，2.0、3.0，以下分别称“GPL 2.0" 与 "GPL 3.0”）最初由自由软件基金会（Free Software Foundation）Richard Stallman 为 GNU 项目所填写，GPL 2.0 给予任何人自由复制、修改和发布 GPL 2.0 代码的权利。

GPL 2.0 再发布需要满足的条件：

• 所有以 GPL 2.0 发布的源代码的衍生，也必须按照GPL 2.0发布；
• 不论以何种形式发布，都必须同时附上源代码。
• 确保软件自始至终都以开放源代码形式发布，保护开发成果不被窃取用作商业发售。

GPL 3.0 与 GPL 2.0 类似，区别在于：GPL 3.0 不仅要求用户根据许可证要求公布修改的源代码，还要求公布相关硬件，如安装环境代码等；GPL 3.0 明确了专利许可。

AGPL 3.0 基于 GPL 增加了规定在使用开源软件提供云服务时也必须提供源代码。所以如果使用 AGPL 许可证的一个开源软件的时候，需要关注到使用场景。

4）不同 License 约束内容的区别

以下 10 种 License 覆盖了开源软件中 90% 以上的代码，采用这些 License 的开源软件在业界应用也最为广泛；其中 GPL V2 对于开发者和二次开发者的义务要求最多，使用时应加以关注。（建议使用相对宽松型的 License）

6、互惠性与聚合体

谈到了互惠性，大家可能也会怀疑，互惠性是完全不能隔离掉的吗？其实也是有一些隔离措施，其中比较关键的一个定义就是聚合体，那聚合体是由多个独立的程序组合而成的共同体。GPL 允许你制作和发布一个聚合体，即使其他软件的许可证，不是自由开源许可证，不是 GPL 兼容的许可证或闭源分发也可以。唯一的条件是你不能禁止用户行使每个独立程序许可证所允许的权利。

如何去区分，到底是两个独立的程序组成的聚合体，还是一个程序的一个两部分呢？这本质上是个法律问题，会根据不同国家、不同地域的法律规定产生变化，但又无法脱离技术。从技术方面来看，独立程序的标准，既依赖于通信机制，也依赖于通信语义（交换了什么样的信息）。

进程间通信的方式有很多，比如：消息传递、同步、共享内存、远程过程调用、Socket 通信等。如果两个模块都包含在一个可执行文件中，或者两个模块运行时共享内存，那它们一定是同一个程序。反过来，管道、socket 通信和命令行参数通常都是两个独立程序的一个通信机制。但是如果两方的通信语义非常密切，共享内部数据结构，那它们也会被认为是一个大程序的两个组合部分。

应用程序一般由三个部分组成：私有代码；开源代码；第三方组件。

针对开源代码的引用方式，一般包括以下九种，其中前 4 种是比较常见的引用方式：

1）动态链接（Dynamically linked） 一种是 Lib 包含了函数所在的 DLL 文件和文件中函数位置的信息 (入口)，代码由运行时加载在进程空间中的 DLL 提供，称为动态链接库（dynamic link library)。

2）静态链接（Statically linked） 一种是 Lib 包含函数代码本身，在编译时直接将代码加入程序当中，称为静态链接库 static link library。(所以无论是动态链接库还是静态链接库，都会有 lib 文件)。

3）源码引用（Source Code）： 源代码，例如 .java 或 .cpp文件。与构建，二进制文件或发行版一起打包组件的源代码。

4）单独(聚合体)（Separate Work）： 适用于松散集成的组件，应用程序具有其自己的可执行文件，而组件与应用程序之间没有链接。

5）汇总（Merely Aggregated）： 适用于您的项目不使用或以任何方式依赖的组件。

6）标准实现（Implementation of Standard）： 适用于根据标准实施的情况，例如，项目随附的 Java 规范请求。

7）前提条件（Prerequisite）： 适用于您的发行版中未提供但必需的组件。例如预先准备好 JDK 的支撑。

8）开发工具/排除（Dev. Tool / Excluded）： 组件将不包含在已发布的项目中，例加，内部用于构建，开发或测试的组件。例处单元测试，IDE 文件或编译器。

9）未指明的/不确定（Unspecified）： 尚未确定此组件用法，您可以使用 "未指定" 来表示您需要调查此组件的使用情况。

针对以上九种引用方式，对应每一个许可证的风险都是不同的，其中风险限定的范围为，开源软件许可证侵犯版权的风险与企业核心代码被污染的风险。就互惠型许可证举例：针对这九种引用方式，分了两种使用场景：

• 第一种场景是商业分发项目，主要指的是把整个代码打包，然后整个通过实体分发给用户；
• 第二种场景是 SaaS 项目，即云服务；

整体来说，针对互惠型的许可证，商业分发项目包括动态链接、静态链接、源码引用，使用这些引用方式都是具备很高的风险，但是对于 SaaS 项目来说，这三种引用方式的风险相对来说低很多，因为互惠型的许可证，比如说 GPL 它没有针对云服务做对应的规定，但是值得注意的是，互惠型许可证的一个引用方式：前提条件，对于商业分发项目这种场景，具备一定风险。

7、开源许可证的兼容性

兼容性定义：适用不同许可证的两个开源程序合并成一个较大的程序，或者把其中之一的代码合并入另一个时，如果各个许可证的限制或条件没有冲突，允许该种合并，我们就可以说这些许可证是兼容的。

如果是许可证 a 的代码和许可证b的代码，他们组合成一个作品，如果组合作品是以许可证 a 发布，那就可以说许可证 a 兼容 b；如果组合作品是以许可证 b 发布，那就可以说许可证 b 是兼容 a；如果组合作品可以许可证 c 发布的话，我们就可以说许可证 c 是兼容 a 和 b 的，那这个相对来说比较抽象。

以喝饮料来举个形象的例子：A 许可证要求你喝碳酸饮料，B 许可证要求你喝可乐，C 要求你喝 2L 可乐， ABC 这三种许可证它的要求逐渐严格，当你履行了喝可乐的这个动作时，同时也满足 A 许可证要求喝碳酸饮料这个要求，所以可以说 B 是兼容 A 的，C 的要求会更为严格，必须喝 2L 可乐，那这种情况下就可以说 C 是兼容 A 和 B 的；如果 D 许可证要求你吃汉堡，那这种情况下， D 和 A、B、C 都是不兼容的。

因此需要查看双方的许可证协议中是否包含一个条款，允许你将协议升级到稍后的版本，例如，LGPL v2.1 和 GPL v3 是不兼容的，但如果两方的许可证协议中都包含“可以升级到更高版本”的条款，那么 LGPL v2.1 就可以升级到 LGPL v3，LGPL v3 和 GPLv3、AGPL v3 是兼容的。

许可证的兼容性列表可以分为以下两种情况：

1）合并/修改代码：从要组合的代码中取出整体/部分代码，修改或不修改都可以，然后把它添加到你的代码中构成一个作品。

2）使用库：没有直接复制代码，在编译或运行时通过链接、导入或其他典型的机制（例如静态与动态链接）把要组合的开源代码绑定在一起。

三、开源许可证与知识产权风险示例

1、开源软件许可证与知识产权风险

1）场景一：若企业作为使用人使用开源软件（Apache 和 BSD 等许可证无风险）

2）场景二：若企业作为贡献人贡献开源代码（MPL/EPL/Apache的专利许可仅限于贡献部分）

2、许可证遵从义务引发的诉讼

许可证遵从义务引发的诉讼主要指以违反许可证义务的版权诉讼为主，由维权个人/组织发起，原告胜诉率极高，后果含开源、赔款、禁令（和解：开源/赔偿），主要集中在欧美，以美国和德国为主，但近些年来国内的诉讼也越来越多。

1）美国发起诉讼的部分案例

• 2007 年，SFLC 代理 busybox 分别起诉 Xterasys Corporation，High-Gain Antennas，verizon，Monsoon Multimedia，每诉均要求禁令，后均和解
• 2008 年, SFLC 代理 FSF 起诉思科，后和解
• 2009 年, SFC 代理 busybox 起诉三星、百思买等 14 家公司，法院首次下达开源软件禁令
• 2013 年, XimpleWare 起诉 Versata 等 12 家公司，后赔偿和解
• 2009-2014 年，多家公司收到来 SFLC/SFC 的警告函，包括三星（三星 2013 年再次对 SFC 捐款和解），均私下和解。
• 2016年，Artifex Software vs. Hancom，后赔偿和解。

2）欧盟发起诉讼的部分案例：除了 2007 年的 Iliad 案在法国，其他均发生在德国。

• 2004年，Welte 起诉 SiteCom，被告败诉，法院首次颁发开源软件禁令
• 2006年，Welte 起诉 Versatel，被告败诉
• 2006年，Welte 起诉 D-Link，被告败诉。赔偿 2000 余欧及诉讼费用，并披露销量以及上下游名单
• 2007年，Welte 起诉 Skype， 被告败诉
• 2007年，Welte 起诉 lliad, 被告败诉
• 2013年，Welte 起诉 Fantec，被告败诉，赔偿 8000 余欧及诉讼费用，并披露销量及上下游名单
• 2015年，Mchardy 起诉某厂商，法院发临时禁令 期间，上百家公司收到来自 Welte 和 Mchardy 的违反开源许可证义务的警告函，绝大部分和解。
• 2016，Mchardy 起诉德国某运营商，申请禁令，后原告撤诉
• 2016，Linux 权利人起诉 Vmware，后原告败诉
• 2016，某软件商 vs. 德国某大学，申请禁令，原告胜诉
• 2017，Mchardy 起诉 Gerniatech，申请禁令，后原告撤诉

3、许可证遵从义务引发的非诉问题示例

1）ONAP 发布代码前会例行扫描检视，发现因许可证冲突导致无法使用的代码多次要求运营商贡献方重写或删除。

2）企业某对外开源项目中使用并修改了 Apache License 代码，但在该文件包中无修改标记且遗漏许可证文本，被权利人发现在社媒公开投诉。

3）企业某对外开源项目中误将开源无修改软件的版权声明误替换为企业版权声明，代码开放 3 分钟后即被开源爱好者发现并在网络公开。

4、开源软件专利侵权风险——业界部分诉讼

1）相比商业软件：诉讼较少——本身的特性（免费许可与不诉义务）、社区环境

2）版权权人起诉少：以下诉讼除了最后一起均为第三方起诉开源软件用户

3）OIN，FSF 等：常协助被告搜集无效证据、号召联合抵制、促成低成本和解或无效原告专利

5、软件本身版权风险

1）版权风险：代码开发时因未经授权使用开源代码引发

2）诉讼/纠纷示例：

• Oracle vs. Google ， Android API 接口 + 9 行代码 （争议金额：90亿）

• Elasticsearch Inc. vs. Floragunn GmbH and certain GitHub users，X-Pack source code in content hosted on GitHub

  专利涉及知识产权本身的风险，不仅要看最后官司的结果，更要看这中间带来的对企业品牌声誉的影响，而且中间所付出的各种诉讼的费用以及相应的人力成本都是非常巨大的。所以说我们的建议就是使用开源参与开源之前就能够有专业的团队和专家开发者，大家能够懂开源合规是什么，尽可能地在自身的能力范围内做到开源合规，这是非常重要的，可以给公司将来的风险能够降低到最低。

四、企业开源合规风险防控

1、企业使用开源合规流程

企业使用开源合规流程主要包含三大环节：

1）开源组件引入代码仓

识别和审计主要指的是去扫描并审计源码，这个源码就包括自由软件、第三方专业软件和开源软件，确认代码来源和许可证。处理问题主要指的是需要根据公司的开源政策和合规的红线，去处理审计中出现的问题，比如可能发现某些开源软件具备互惠性比较高的许可证，在这种情况下就需要去注意其使用场景。

① 识别（辨识）

辨识自由开源软件组件；

步骤：

• 来自工程师的输入要求
• 扫描软件
• 对开源软件的发现执行尽职调查 (Due Diligence)
• 将人工辨识之新组件信息加到知识库

成果：

• 对该自由开源软件的合规纪录被建立或更新、
• 依自由开源软件政策所订，穷尽或限定范围内，对源代码审核之稽核将被要求。

② 审计（稽核）

辨识自由开源软件许可证；

步骤：

• 供稽核之程序源代码被辨识
• 源代码或已使用软件工具进行扫描
• 稽核或扫描的「成果 (Hits)」被审核及验证，而得作为该程序代码适宜的来源信息
• 稽核或扫描依该软件的开发与释出周期而被反覆操作

成果：

• 稽核报告能用以辨识、程序源代码的原始出处及其许可证
• 有待处理的疑虑

③ 处理问题

处理审计过程辨识出的所有疑虑；

步骤：

• 提供反馈予相应的工程师，以处理在稽核报告里，与你的自由开源软件政策冲突的疑虑
• 该工程师继续就相关的程序源代码实施自由开源软件审核

成果：

• 对报告里每一个被标记的文档作处理，及对任何标记许可冲突的状况作处理

2）从代码仓引入产品

审核、审批主要指的是审核并批准的合规记录，也包括流程记录环节，保存公司内部每个产品每次发版时经过批准的开源组件清单。准备声明，因为开源许可证会有需要声明的义务，包括对您开发软件的版权所属、通知说明之类的。

① 审核

审核已处理之疑虑以确认其与你的自由开源软件政策相合；

步骤：

• 於审核工作人员里，应包含适切对应的管理阶层
• 依你的自由开源软件政策为参据来实施审核

成果：

• 确保在稽核报告里的软件与自由开源软件政策相合
• 准备往下一个步骤前(例如：核可前)，保存稽核报告的发现，并标注已处理的疑虑

② 批准（核可）

自由开源软件组件经批准认同合规纪录：

• 根据上一个步骤的软件稽核及审核结果，软件可能被核可或可能不被核可使用；
• 核可时，必须注明被核可的自由开源软件版本、被核可组件的使用模式，以及其他依自由开源软件许可证应施行的义务性要求；
• 核可须对应到适宜的行政管理阶层来进行。

③ 留存记录

保存每个产品每个版本经过批准的开源软件清单：

• 当一个自由开源软件组件被核可在产品中使用时，其应被加入该产品的软件清单；
• 该项核可及核可的条件，必须被登记纪录在可追踪系统里；
• 若新版本的自由开源软件组件或新的使用模式被提出时，该追踪系统必须清楚显示这需要一个新的核可。

④ 声明

为发行产品中任一自由开源软件备妥适宜的声明：

• 藉由完整著作权及署名声明之提供，来承认自由开源软件的使用；
• 通知产品的终端使用者，如何获得自由开源软件程序源代码的复制件（当此要求适用时，例如 GPL 及 LGPL 即为此种状况）；
• 应需求复制产品里自由开源软件程序代码之全部许可证协议文件。

3）产品发布

发布声明及源码、发布后的验证、准备待发布的开源声明。

在发行环节，需要发行源码和声明，并且需要把索取源代码的说明文件也分发出去，如果后续用户想要索取源码，我们也需要把对应的索取渠道告知给用户。

① 发行前的验证

验证发行的软件已经过审核及核可

步骤：

• 验证预计发行的自由开源软件套件已经过辨识及核可
• 验证已经过审核的程序源代码与贩售产品里相对应的二进位代码是符合的
• 确保已被审核的源代码符合相对应的产品执行文档
• 验证所有相应的声明已被列入，以告知终端使用者其索取已被辨识之自由开源软件程序源代码的权利
• 确保所有相应的声明已被纳入好让终端用户知道他们能获取相关自由开源软件的权益
• 验证合规于其他已被辨识的义务性要求

成果：

• 使发行的套件仅会包含已经过审核及核可的软件
• 「供发行的合规稽证 (Artifacts)」(依 OpenChain 规范书所定义)，包括被列入发行套件或其他投递模式所相应的声明文档

② 相应程序源代码的发行

依据要求提供相应的程序源代码

步骤：

• 提供伴随任何相关联建置工具以及文件的对应程序源代码（例如，上传到发行网站上或列入发行套件里）
• 此相应程序源代码应被辨识与标记，以和其产品及版本别对应

成果：

• 提供相对应程序源代码的义务性规则被满足

③ 最后验证

确认合规於许可证的义务性规定

步骤：

• 验证相对应的程序源代码（若有的话）已经被正确地上传或发行
• 确保其他许可证有被遵守
• 验证上传或发行的程序源代码与经核可的版本是相对应的
• 所需声明已被适当地发布与提供验证
• 验证其他被辨识出的义务性要求已达到；

成果：

• 验证供发行的合规稽证 (Artifacts) 已被适切地提供

2、企业贡献开源项目的合法合规要求

企业参与外部已存在的开源项目，向其贡献代码，在代码开源前，我们需要考虑哪些合法合规要求？

1） 了解并签署贡献者协议或开发者原创声明（视社区要求而定）：了解贡献者协议/原创声明中对企业（贡献者）的约束。

2） 明确开源文件来源，确保可开源：明确贡献内容中所有代码、文档等文件的来源及版权，确保拥有将贡献内容提交至社区的合法授权。

3） 识别清理 License 冲突：识别贡献内容中所包含的所有开源 License，整改确保与项目 License 不冲突。

4） 履行开源义务：根据贡献内容中包含的开源 License，履行相应开源义务。

3、企业自发（发布）开源合规流程

如果企业想要自发或者说发布一个开源项目，它的合规流程应该是怎么样的？那企业在对外发布开源项目时，应调查清楚开源项目包含哪些第三方组件，确定开源项目组件信息，包括组件的来源、出处等。

企业自发（发布）开源合规流程也分为三个环节：

1）确认：披露和发现。

确认企业在这个开源项目中使用了哪些第三方开源软件组件和片段。在这个环节，需要输入项目的源码，输出软件物料清单（SBOM），突出显示开源软件的组件和片段，其来源和许可证。

2）批准：审查和批准。

批准开源软件的预期用途。在这个环节需要去输入第一个环节输出的SBOM和架构，输出产品或者服务发布时应遵守的义务汇编，探寻开源许可证的风险及声明义务，梳理清晰。

3）通知：遵循 OSS 许可证。

通知部署的开源软件所有许可义务，当在第二环节准备好的需要遵守的义务和责任之后，那在第三个环节需要准备材料，把材料发布出去，包含所有通知的源代码（书面通知、版权、许可文本和归属）。

4、业界开源项目的法务合规保障机制

当前开源社区对于合规保障较弱，而公众对于一般开源社区也较为宽容，发现问题及时整改解决即可，但由单个企业主导发布的开源项目，则容易被公众或竞争对手针对，因此要有更严格的保障：

1）项目发布前培训

项目发布前，对项目负责人进行培训，告知相关法务注意事项，如代码成份分析、合法性检查、License 兼容性整改、贡献者协议要求等，但没有强制审查检验机制。

2）项目负责人组织合规整改

项目负责人组织清理与项目 License 不兼容的代码，通过人工审查 + Maven 插件工具 + 其他扫描工具（项目负责人自行决定） 进行识别清理，但没有强制在项目发布前要求完全清理，可能会在发布后持续进行。对于删除原有 Copyright、存在不兼容 License 等行为可能难以被发现，主要靠发布后用户/贡献者持续发现推动解决。

3）签署贡献者协议

项目发布后，要求每个贡献者签署贡献者协议，约定贡献代码版权归属（一般归贡献者），若含有专利，则贡献者必须确保该专利是被授权给所有用户使用，但即使存在问题，也可能难以第一时间发现，主要靠自觉。

4）Committer 持续审视

Committer 负责审视贡献代码，识别和解决合规问题，依赖个人能力，主要还是靠贡献者自觉。

5）问题发现解决

社区中的合规问题一般通过 “用户/贡献者反馈 —— Committer 组织整改” 方式解决，若发现抄袭、修改版权等行为，Committer 会组织进行整改，而相应贡献者也会遭到社区谴责，可能影响其后续的贡献。

5、开源前需要考虑的合法合规事项

企业原创或主导、由企业主动对外开放、以开源社区形式运作的开源项目，在项目开源前，我们需要考虑哪些合法合规要求？

怎么做？具体步骤如下：

• 项目成员岗前合规培训
• 基于商业诉求，明确项目License，贡献者协议等法务文档
• 持续扫描识别License风险，及时清零
• 发布前合规检查，确保风险清零
• 社区运营过程中持续扫描识别并解决合规问题

1）制定并配置项目法务文档

明确项目 License，贡献者协议、企业权利声明等文档；

① 选择 License

License：规定了该项目所有用户所享有的权利及必须履行的义务，开源项目的业务团队根据自身业务目的，与企业的法务部共同明确项目 License。

如果限制少，更多地选择宽松的许可证，比如 BSD 和 Apache 许可证，如果需要代码对外开源，或者履行更多地开源义务，可以选择比较严格一点的许可证，比如 GPL 或者 MPL许可证。

② 案例-选择 License

业务诉求：

• 代码开放，提供版权和专利免费许可，无强迫用户回馈诉求
• 鼓励使用，无限制分裂诉求
• 优先使用中文许可证

代码扫描结果： 除了 BSD 代码外，无其他第三方许可证的代码，故所选许可证与BSD兼容即可

推荐： 国产木兰宽松许可证

③ 示例：license 惹争议事件

Facebook Patents License 惹争议

• Facebook React（ FB+PL 许可）
• BSD-3 Clause：商业友好，无强制开源义务，仅需履行声明义务即可
• Facebook Patents License：“Facebook 保护主义” 条款，若使用者对 Facebook 发起专利诉讼，即使该专利与 React 无关，React 对该使用者的授权也会被终止

2017 年 7 月，Apache 基金会主管兼法律事务副主席 Chris Mattmann 正式发表声明称：Facebook BSD+Patents License （FB+PL）已经正式被列入 “Category X” 列表，因此 Apache 项目中将不能够包含或依赖于 Facebook Patents License 的代码；而已经发布的代码，涉及 FB+PL 许可证的，需要在 8 月 31 号前完成替换。

Facebook BSD+Patents License 持续被众多开发者诟病声讨，2017 年 9 月，Facebook 表示后续将 React 等采用 FB+PL 许可的项目，改为 MIT 许可。

解析： Facebook BSD+Patents 许可证增加了对 Facebook 的专利保护条款，即如果用户使用了该软件，那么就不得针对 Facebook 或其任何附属公司的任何产品或服务发起专利诉讼，否则 Facebook 针对该软件授予的专利许可将自动终止，导致用户承担的专利不诉范围远远超出了其使用的 React 本身。

启示： 某些开源项目表面声明的 License 看似宽松，但可能潜藏风险，产品在引入开源软件时应获取其完整的 License 。若无法确定 License 风险， 可先向法务部咨询，评估风险后再决定引入。

④ 代码原创声明 & 贡献者协议

代码原创声明：面向企业内部，所有参与开源代码编写的员工需签署。主要内容包括：

• 承诺个人开发的代码都为个人原创，若包含第三方知识产权的内容，或是公司专利，须如实向公司反馈，在获得批准后才能合入开源代码。
• 若由于个人原因（如提供虚假信息，隐瞒信息等）导致项目开源后公司遭受侵权诉讼等损失，个人须承担相应责任，代码开发者对自己的代码负责。

贡献者协议：面向公司外部，所有参与社区代码贡献的贡献者必须签署。主要内容包括不限于：

a、贡献者所享有的权力

• 如是否享有贡献代码的版权，社区内部的发言权等

b、贡献者所需承担的责任和义务：

• 贡献者必须确保贡献内容有充分地授权，能够以项目 License 开源，或贡献内容 License 与项目 License 相兼容。
• 若贡献内容包含第三方知识产权内容，须获取相应的授权，并在贡献时明确声明。
• 贡献者承诺其贡献的内容属于原创，或者拥有其贡献内容的合法授权。

⑤ 版权声明及免责声明

企业权利声明及免责声明：针对企业享有版权的内容，须附上企业的权利声明与免责声明，以保护企业权利。

声明包括企业原创文件和非企业原创文件两类：

a、企业原创文件：在文件头附上企业的版权信息与免责声明

• 企业版权信息，年份为代码新增年份，邮箱可以是项目运营统一邮箱，或该文件开发者邮箱，以便其他开发者或用户通过该邮箱进行提问或沟通；
• License 及免责声明。

b、非企业原创文件：企业在其基础上进行了修改，则在文件头附上企业的版权信息，免责声明一般在原文件 License 中会有声明，无需额外添加；

• 保留原文件中的声明，不得更改或删除；
• 企业修改年份，可只写年份，也可写具体日期；
• 简要说明修改内容；
• 企业版权信息，邮箱同上文（可以是项目运营统一邮箱，或该文件 owner 邮箱）。

⑥ 案例-某编译器误改版权事件

• 某编译器版权声明修改遭热议：某编译器开源前，使用版权信息生成脚本对自研代码文件生成企业版权信息；
• 脚本运行范围误将 third_party 目录也覆盖在内，导致其中的文件版权也被修改；
• 上网当天即被网友发现，在网络上引发热议，该项目于当天紧急整改后再次上线。

2）识别项目所有文件来源

识别项目中其他开源软件及其 License：明确项目所有代码来源，区分企业代码，开源代码，确保持续可追溯；

① 开源代码可能产生的风险

涉及第三方知识产权的开源代码可能产生以下三种风险：

• 开源代码包含第三方非公开信息，引发商业秘密纠纷；
• 开源代码本身侵权第三方知识产权，可能被潜在的权利人起诉和要求赔偿，甚至禁止该代码的使用；
• 未经授权使用开源软件相关的商标、标志，且不属于合理使用。

② 使用扫描工具确保可开源

通过某工具扫描项目全量文件（代码文件及二进制文件），明确所有文件来源，确保：

• 开源代码包中的代码原则上必须由企业原创代码构成，不得包含来源不明的代码或二进制包，也不得包含未获得相应授权的第三方代码以及版权标识、包括但不限于免费代码、开源代码或商业代码，若需要随项目一起发布，则须获得相应版权方许可。
• 开源代码包中不得包含未经授权批准的第三方商标和非公开信息等，尤其避免包含第三方特有特性代码，未经授权批准的第三方公司商标、标识、公司名、人名等敏感信息。
• 若开源内容中包含企业专利，必须经过业务团队与法务部审核批准后方可开源。
• 禁止在企业原创代码文件中嵌入其他开源软件代码片段。

3）识别清理 License 冲突

清理与项目 License 冲突/不兼容的开源软件：

• 清理与项目 License 冲突的开源软件；
• 在项目代码中标识项目License与企业版权信息；

① 检查与项目许可证是否兼容

不同开源 License 所规定的权利与义务不同，相互之间可能不能兼容，项目在发布前必须检查项目引入的所有开源软件 License，确保其与项目许可证相兼容

常见 License 兼容关系，具体兼容关系可咨询对应法务；不兼容的 License 不可以出现代码混同，比如将部分代码加入到另一部分代码中。

• 通过 FOSSID 等工具扫描识别项目中所包含的所有开源软件 License。
• 判断这些 License 与项目 License 是否冲突，涉及具体冲突判断可向开源律师求助。
• 对 License 冲突进行整改清理。

② 对于冲突 License整改

对于冲突 License 整改的两种方式：

• 采用其他不冲突的开源软件替代；
• 自研重写替代：重写时应采取 clean room 方式，重写人员不得直接接触参考开源代码，更不得直接在参考代码基础上进行修改，只可以在了解参考代码的功能后独立写出实现代码，否则重写可能失败，无法规避非兼容许可证。

4）遵从开源License，履行相应义务

• 基于已识别到的开源软软件清单，分析各 License 风险，剔除权利不明或义务难以履行的开源软件；
• 履行开源软件义务（主要为声明义务）；

① 声明义务

若项目中集成了其他开源软件，项目在发布时也须遵从相应开源 License，履行开源义务，否则也会导致侵权风险。由于开源项目代码天然开放，因此开源项目主要涉及的是声明义务：

• 明确项目中所包含的所有非企业原创的开源软件（第三方开源软件）。
• 在项目根目录下添加“第三方开源软件使用声明” 文档，记录所使用的所有第三方开源软件的版权和许可证文本。
• 保留所有第三方开源软件文件中的版权及 License 声明，若企业在其基础上进行了修改，可在原文件声明内容的基础上增加企业的版权声明（针对修改部分），但不可删除原有第三方声明。

5）管控后续合入代码，符合 License 要求

• 与贡献者签署贡献者协议，明确贡献代码版权归属，约束贡献者代码符合项目License 要求；
• 贡献代码审核，定期识别合规问题，及时整改。

① 持续风险识别

对于社区后续合入的代码，包括企业或其他贡献者贡献的代码，需要持续进行风险识别，避免引入与项目 License 冲突的代码：

a、从法务角度：

• 在社区运作规则中明确代码贡献合规要求，贡献者必须签署或同意《贡献者协议》，方能提交代码。

b、从运作机制角度：

• 设立代码合入门禁，合入前必须通过门禁扫描，识别并确认无风险后方可合入。
• 定期对项目进行整体扫描，识别并及时处理发现的风险。