开源项目中的法律风险

发布于: 2017-07-01 13:24
阅读: 1095
评论: 0
喜欢: 14

引言

写这篇博客的契机是我厂刚好开了一次这样的培训,听了以后觉得很有收获。碰巧自己最近也在写开源项目,因此觉得还是有必要写一下。

有小伙伴提到,这种问题,去网上找那个指导你如何选择 LICENSE 的图就好了。那个图能指导你选择正确的许可协议,但是并不会增进你对各个协议的了解。

本文里会通过几个例子让读者更能了解这些协议。

软件的分类

我们先来看看软件一共分为几种:

软件分类 版权保护 开放源码 再分发 修改
商业软件 不一定 × ×
开源软件
共有软件 × 不一定
微软的共享源码软件 部分提供 部分提供 部分提供

这里特别提一下公有软件,指的是著作人去世后一段时间之后,例如 50 年后,这个软件就变成了共有软件,谁都可以用,谁都可以拿去卖,但是署名不能改。

微软共享代码软件指的是,向部分用户提供了源代码,也允许部分用户进行再分发等。

开源软件

开源软件又称自由软件,提倡的是:

  • FREE TO RUN
  • FREE TO STUDY
  • FREE TO REDISTRIBUTE
  • FREE TO IMPROVE

既然把源代码共享了,如何保护自己的权利呢?可以通过著作权法和商标法。

著作权

著作权法主要要求:

  • 复制、分发、修改时,附上版权说明。
  • 修改时,对修改部分进行明示。

需要明确的是,软件的思想、功能是受专利保护,而不受著作权法保护。

商标权

是否允许使用者使用你的商标。Linux、Apple、IBM等就是商标。

许可协议

许可协议是很常见的权益声明。许可协议数量多达 82 种,主要分为三类:

  • GPL: Copyleft 原则。给你足够的自由去修改,去再分发。类似的协议:AGPL、LGPL。对商业软件来说,这是一项非常危险的许可,下文详细会讲 GPL 协议相关的内容。
  • BSDL: 绝对的自由,允许授权者修改、再分发、甚至闭源。类似的协议:Apache、MIT。
  • MPL: 集开源之力为我所用。类似的协议: Apple、Sun、Nokia、IBM。

许可协议的兼容性

一个软件中可能会集成多个开源项目。如果这几个的开源项目的许可有所冲突,或跟软件主体的许可有所冲突,表明这些项目许可不兼容,是不能在一起用的。

GPL、Apache不能集成在一起,更不能以Apache发布。

几个例子

下面的例子都是关于上文提到的一类非常危险的协议:GPL 协议的。

GPL 类许可协议是对商业最危险的许可协议。它规定你可以私自修改,使用,但是不能发布。例如 MySQL,拿过来改,只能自己用,没有问题。但绝对不能闭源发布。如果你发布了,GPL 要求你要向用户提供源码,并且一定要使用 GPL 授权

什么意思呢?如果一个库是 GPL 发布的,则任何使用这个库的程序,必须使用 GPL 授权,必须要向用户开放源代码。这是一种非常有传染性的许可协议。

下面就来看几个例子:

例0:Linux 和 Android

先来提一下这两个个例。Linux 是 GPL 协议开源的,这意味着用户可以修改,可以再分发,但必须要开源。

问题来了,许多 Linux 的驱动程序,他们使用了 Linux 系统的库,按照 GPL 许可协议,他们必须开源。但他们为什么可以闭源发布呢?

原因在于,Linux 本人在他的许可协议加上了一句话:凡是以调用内核形式访问代码的,不受 GPL 限制。

那么又说到安卓,安卓为了规避 GPL 许可的风险,做了非常大的努力:

组分 许可
Linux kernel GPL-2.0
Library MIT BSD
Runtime Apache
Framework Apache

上文提到了 Linux 使用的许可的特殊性,使安卓能把 GPL 协议限制在 kernel 层。上层全部采用了非 GPL 类许可,使厂商、用户可以闭源发布产品。只要这中间混进去了一个 GPL 库,那么这层以后的所有层,全部必须开源。包括大家开发的安卓App,也必须开源,这肯定是无法接受的。

通过 Linux 和 Android 的例子,大家一定对 GPL 的传染性有一定的概念。

例1:思科

思科开发自己的路由器时,对嵌入式 Linux 本身做了裁剪,最后安装在路由器里面发布了。

而 Linux 特殊的 GPL 许可只允许调用系统内核的情况下不受 GPL 限制,但修改源码是不行的。有一个理想主义组织,叫FSF,发现了这个情况后起诉了思科。

最终判决结果是,思科开源了代码,最终演变成了著名的openwrt

例2:Hancom office

Hancom office 是一家韩国公司开发的一套 office 软件。这个软件集成了一套开源 PDF 解释器,Ghostscript。

这个 Ghostscript 呢,拥有两种协议。一种是免费协议,是 GPL。意味着你可以免费用他的库,但是许可协议是 GPL 协议,你发布的话也必须要开放你的源代码。另一种是商业许可协议,需要花钱购买,买了以后,你就可以闭源发布你的产品了。但该公司没有购买商业许可,用了免费的 GPL 许可,但是他闭源发布了他的产品。

所以最后的结果,你懂的。

上面是两个是比较常规的例子,下面来点刺激的。

例3:GPL和逆向

A 公司购买了 V 公司软件,进行反编译用来增加自己功能。V 公司发现后,起诉 A 公司的这种行为侵犯他们著作权。

但事情发生了转折,A 公司反过来起诉 V 公司,他们在逆向时候发现 V 公司使用了一个用 GPL 许可协议的开源库,但 V 公司没有开放产品的源代码。

判决结果,A 公司修改 V 公司软件是合法的。

风险规避

说了这么多,我们在做开源时如何才能规避风险呢?可以从以下几点考虑:

  • 策略上。你为什么要开源,是为了让人随便用,到处都运行着你的代码,觉得很有成就感,还是为了其他目的。
  • 权衡利弊,选择许可。
  • 避免陷阱,对以下情况做限制:1、再分发要求。2、担保条款,免责条款。3、代码传染性。
  • 定位什么人会用我的代码。
  • 版权贡献者协议(CLA)。

最后,如果你需要更改你的开源项目的许可协议,你需要征得所有项目贡献者的同意。但如果在贡献项目以前,他们签署过版权贡献者许可协议(CLA),那么就意味着授权了版权给你,你可以不经过他们同意就修改许可协议。

结语

以上内容是依靠当场做的笔记写的,也有可能有错误,有疏漏,欢迎大家提出。

最后是一点个人建议,对于完成度比较高的工具类开源项目,GPL + 付费商业许可是比较好的选择。


Thanks for reading.

All the best wishes for you! 💕