一、问题

说到GPL,恐怕大家都不陌生了。但你知道LGPL、GPL、AGPL的区别吗?甚至后面的众多知名软件如MongoDB、ElasticSearch等都相继修改的SSPL又是什么?

GPL是如何让企业用户为之“闻风丧胆”的呢?GPL其实是一个家族license,包括LGPL/GPL/AGPL等,有不少公司都被这个license告了,支付了巨额的罚款!

看这么多名字,让人记不住。有什么办法能让人深刻记住这几个license的区别?

以我个人的经验,研究某个事务的产生历史,是一个不错的办法,因为这样可以产生一条完整的故事主线,将这些东西联系起来。让我来尝试一下,看看能不能梳理出一条这样的主线出来!

二、GPL的诞生

我们大家都知道,出版图书,需要取得该图书的版权(著作权)。但这个版权是什么呢?

从英文字面意思来看,Copyright = Copy+Right,其实也就是拷贝权

对于图书而言,拷贝其实就是印刷书籍,也就是出版+印刷图书的权利。所以对于图书而言,历史上的Copyright其实就是印刷权。

这个权利其实一般人不容易获得,你想要印刷图书你起码得有一台印刷设备吧,对于我们这种一般人来说,要大规模复印一本书,至少得来一台高级复印机吧 →_→

复印机

(看我像买得起一台复印机的人吗🐶)

But, 时移世易,一个全新的美丽的开源世界到了我们的面前!

开源软件,跟图书有啥关系?

真要说关系,其实没啥关系!只不过,他们有一点共同点和一点不同点。

共同点就是,他们都是创作者写的【废话!】,因而他们都有版权。

而不同点就是,时代进步啦,软件是运行在计算机上的,所谓Copyright的复制权,Ctrl+C + Ctrl+V, 几秒钟内就复制完成,复制成本几乎为零。

这咋办呢,咋保障开源软件的顺利发展呢?

这个时候我们的大神出场了,Richard Stallman,光看这个名字很多人可能不知道他是谁。

李茶

这个胡子拉渣的大叔,创建了自由软件基金会(FSF),一个人撑起了开源世界的一片天!理查大叔有一个伟大的梦想,他发起自由软件运动,他想把UNIX用开源一肩挑!他是想要改变世界的男人!

这个梦想就是GNU计划!GNU的口号就是“GNU’s Not Unix",

1
...[[[[GNU's Not Unix]'s Not Unix]'s Not Unix]'s Not Unix]'s Not Unix...

看吧,首递归了都!【禁止套娃啊喂,首递归会导致堆栈溢出的!】

GNU logo

【gnu的英文含义是角马,只看词典翻译,看起来有点不知所云。但看这个GNU的logo,帮我们生动解答了GNU的含义: 一头长了角的马!不但学到了一个单词,还看懂了GNU的图标,简直双赢!这大概就是互文吧?】

唯一可惜的是,GNU的系统内核Hurd没开发完成,就被Linux捷足先登,窃取了劳动成果,导致现在知道Linux的多,知道GNU的少!【李茶大叔心理一万个草泥马奔过!】

李茶大叔开发了GNU计划中的大名鼎鼎的GCC、GDB、EMACS等。以及发明了我们现在要讨论的GPL。

GPL英文全称 GNU General Public License,通用公共许可证。这个东西出来的目的就是为了推广开源软件和保障开源软件的顺利发展。【存在即合理 —— 事物存在都有其背后利益的原因🐶】

GPL其实就是新型的Copyright,李茶大叔称它为Copyleft。这里英文好的同学应该就秒懂了,Right既有权利的意思,又有右边的意思。李茶大叔在这里反其道而行之,称之为著佐权不过分吧!

妙啊

说道这里,我们先来看看GPL的主要条款:

    1. 作者不对使用方使用该软件造成的任何损失负责。
    1. 基于该软件衍生的新软件,必须遵守GPL。
    1. 提供方分发含有GPL的软件,必须同时提供该软件的源码。

咱们来尝试解读一下这几个条款是怎么起作用和为自由软件服务的。

    1. 第一条其实就是软件作者的免责声明。鼓励程序员们放心贡献自己的代码吧,不用担心别人找你麻烦。
    1. 第二条就是“传染性”,这个很好理解。而也正是这个传染性,奠定了在自由软件发起之初,其能够广泛传播的基础。
    1. 第三条是GPL最本质的条款,要求GPL的软件都要开源,这样大家用的时候能看到源码才放心嘛,也方便用户能够自由修改做定制。

所以,说到底,这三条条款是真真正正为开源发展服务的。

只是,商业和免费几乎是两个对立的世界。企业以盈利为目的,其活动构成了商业活动。如果一个企业赖以生存的软件都被开源了,那岂不是没啥门槛了,别人随随便便就复制一个了?(这个在软件发展的早期是成立的,到了现在软件生态已经很成熟了,也有不少公司靠完全开源盈利,如红帽)

所以,商业公司对于GPL的软件,那是It can’t be too careful.

三、怎么规避

作为有正义感的开源世界的一员🐶,我本不应该写这一段。但又作为企业的一员,想想为了自己的这口饭碗,还是含泪写下了本段!

我爱我的工作

要怎么规避呢,当然得从本质上,也就是条款上下手,对吧!

第一条怎么规避? 有两种方法:

  • 一种很明显的方法是,不用该软件了呗!

    保证不捶你

  • 另一种方法就是,谨慎选择没啥毛病的软件。比如开发者不明,来源不明,漏洞多多等软件。保证一个质量高的来源,那咱们用户受到伤害的可能性就小很多了。

第二条怎么规避? 就是怎么避免被传染呗?放心,凭借咱们防疫3年的经验,对于这种传染渠道清晰、传播路径明确的传染性远小于新冠病毒的GPL来说,还不是小Case?

这里也有两种方法:

  • 第一种方法是,不从GPL软件衍生。我们做软件开发的都知道,一个软件包括编译和链接两个步骤。在编译阶段,我们不直接编译GPL的软件源代码进入我们的目标软件,在链接阶段,我们不动态链接和静态链接GPL软件的动态库和静态库。这样我们的软件就没有衍生GPL软件。

  • 另一种方法间接衍生。在我们必须使用该软件的功能,又不想被它传染的时候的一个办法。何谓间接衍生?计算机界有一个银弹:

    计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决.

说到这里不知道你想到了什么没有?我们新建一个API服务软件的中间层,该中间层被传染GPL,OK,没关系,咱按照条例,开源就是了。而你真正需要原GPL软件的功能通过API服务提供。通过这样的一个隔离层,就成功规避了衍生的问题。谷歌为安卓就这样干过!

妙啊

第三条怎么规避?

这个没有太多办法,只能抠字眼了。字面上强调了分发,那我们能规避的唯一方法就是不分发。所以,咱们在服务器上使用任何GPL软件,都无需担忧GPL软件的开源义务履行问题。

四、LGPL、GPL、AGPL

既然已经有了GPL,为什么又要有LGPL、AGPL等等一系列的License呢?

  • 主要是因为用得越多,就会发现场景越多,一些不同的场景会有不同的需求嘛。

有些场合GPL可能确实严厉了一点,就出了一个宽松一点的LGPL(GNU Lesser General Public License),允许你动态链接使用咱们的库,毕竟动态链接库是不会修改原始软件的功能的嘛!

比如像glibc这种基础库。如果大家动态链接这种基础库的时候也被迫开源,那就很难有商业公司会去用glibc了。所以glibc是LGPL的。

  • 另一方面是因为,噢,从上面规避的那一段,原来我的GPL有个巨大的漏洞啊!居然有人可以通过完全服务化方式避免分发,“恶意规避”,是可忍,李茶大叔不可忍!【此处为作者杜撰】

岂有此理

真实情况其实是一个叫做Affero的公司为了自己Web服务的代码开源而想要一个即使不分发也要遵守license的license,开始叫做Affero License。后来发现,原来Affero License完全包括了GPL,这样不就片段引用了嘛,还造成了起草的包含了GPL内容的Affero License不遵守GPL(没有在里面声明GPL)【又是一个套娃!】

因此,跟FSF讨论一下,还是并入GPL家族吧,改名为AGPL(GNU Affero General Public License)。

而这个AGPL又增加了什么内容呢?

从上面可以看出,他是为了解决服务端的源码衍生规避开源的问题。因此增加了条款:

    1. 服务端衍生的不分发的软件,也要开源!

至于怎么规避,看下一章节。

五、SSPL

随着开源世界的发展,世界真是越来越美好了。服务化软件也雨后春笋般萌芽成长。 MySQL、Redis、MongoDB、ElasticSearch…

简直是各种大公司的福音呀,拿来即用,Amazon成为第一个最会薅羊毛的公司,毕竟它是世界上最大的云服务公司嘛。当然,其他云服务厂商也是在暗爽。

一些开源开发者,特别是企业主导的开源开发者发现自己的软件,自己没赚到钱,反而被其他云厂商白嫖

AGPL还能白嫖的原因是,它要求开源的是使用的这个软件本体。比如我使用MySQL【这里假设MySQL是AGPL的,实际上是GPL的】,我完全服务端部署,不修改,我压根都不用履行开源义务,因为MySQL本来就是开源的。

我要反击!

为首的就是MongoDB公司。在AGPL的基础上改进了条款。

1
只要你在服务端用了我的MongoDB,你服务端所有相关的软件(包括服务、API、账户系统、第三件等等)都要开源!

如果这样描述大家还不明白,用更白话来说,就是你要把你服务端完整的整套部署代码全部开源。这样的一个License叫做SSPL(Server Side Public License),名字也是直白的告诉你,就是针对服务化场景的。

这样就基本不可能会有企业会使用SSPL的软件了,除非购买MongoDB的服务。

这样也算是填补了AGPL的漏洞了。经过这么长时间和多方的共同参与制定,SSPL已经很完善了,目前看已经不存在什么漏洞了。【如果你发现了什么漏洞,请告诉我,我请你喝咖啡。】

Elasticsearch也在考虑使用SSPL。我相信会有越来越多服务化的软件会考虑使用SSPL,除非为首的这些云化厂商愿意给开源社区付费!拒绝白嫖,从Amazon做起!

白嫖

六、参考链接