从Web服务器到信息站,再到挖掘Facebook信息的大数据算法,几乎所有与您交互的计算机系统都至少有一部分在开源软件上运行。在科技行业,开源软件催生了一大批初创公司,促成了世界历史上最大的软件收购。

免费的软件似乎是一件礼物,它使我们所熟知的世界成为可能,并且在商业世界里引起了轰动,最初的企业不习惯这种慷慨大方的状况。这些公司并不愿意使用免费软件,免费听起来过于激进,还似乎有某种政治化的意味,所以人们给它重命名为“开源”。

所以,开源软件便渗透到了整个世界。

但是,最近开源世界出现了一些问题。在过去的一年中,Redis Labs、MongoDB和Confluent等公司都更改了软件许可,从开放源代码许可改为更严格的条款,限制了软件的操作范围,从而使其不再是开源软件。

Redis Labs、MongoDB和其他公司认为,这是一种更现代的技术趋势:托管软件服务,也称为“云”。

为了应对Elastic(Elastic Search的公司)的许可变更,AWS在今年春季发布了自家版本的开源 Elasticsearch:Open Distro for Elasticsearch。除了就AWS新版本的命名引起新的商标争议外,Elastic的回应与MongoDB和Redis的回应也大相径庭,没有发表任何抗议。

云计算的爆发

MongoDB围绕着与该公司同名的开源NoSQL数据库创建。MongoDB对于存储非结构化数据(例如图像)非常有用,它可以处理更多传统数据类型。数据存储在类似JSON的文档中,而不是关系数据库的列和行中。由于没有结构化表,因此没有用于处理数据的“结构化查询语言”,因此被称作“ NoSQL”。

MongoDB并不是唯一的NoSQL数据库,但是它是使用最广泛的数据库之一。DB Engines的数据显示,MongoDB是第五大受欢迎的数据库,Google、Code Academy、Foursquare等都在使用MongoDB。

MongoDB也在牵头创建一种新型的开源许可证,其 CTO Eliot Horowitz认为,随着云计算的到来,这对于保护开源软件是必要的。

Horowitz等人认为,云计算要求开源社区重新考虑并更新开源许可证,以“应对新环境中的新挑战”。实际上,所谓的挑战其实是AWS、谷歌云和微软,它们都能够采用开源软件,并将其包装为服务并进行转售。AWS或Azure打包MongoDB并将其作为SaaS的一部分提供的问题在于,它被用来与MongoDB自己的SaaS产品(MongoDB Atlas)竞争。那么,受到威胁的不是MongoDB的源代码,而是MongoDB自己的SaaS。

为了应对其面临的潜在威胁,MongoDB已从Gnu通用公共许可证(GPL)转移到服务器端公共许可证(SSPL)。SSPL意味着你可以用这个软件做任何你想做的事情,除了用它来构建与MongoDB Atlas竞争的东西。

最初,MongoDB将SSPL提交给开源审计组织(OSI),该组织负责监督和批准新的开源许可证。但是根据OSI邮件列表上进行讨论的结果以及许可证的措辞后,SSPL不太可能会得到OSI的批准。MongoDB在今年早些时候取消了转为SSPL的考虑。SSPL不是开源许可证,并且永远不会是。

要理解原因,就要知道MongoDB并不是第一个遇到这种情况的开源企业。事实上,一部分原因是公司随意使用软件,但对开源社区毫无贡献。

开源许可证各不相同,但自1998年OSI成立以来,其主要内容如下:您可以使用此代码并对其进行所需的操作,但不能使该代码专有,并且如果在其他代码中使用它,那么该项目也不可以是专有的。 这些许可证通过这种方式编写,以防止公司在自己的代码中使用开源代码,却不将工作中的任何成果共享给原始项目。

但是SaaS的概念在二十年前还不存在。如今,在SaaS产品中包装一段代码在现代意义上等同于在应用程序中使用它。

这个说法很新,但它可以解决另一个老问题,而不仅仅是许可。 这个问题早在OSI出现之前就存在了:如果免费提供软件,那该如何从软件中赚钱?

一个传统的答案是围绕开源软件出售服务。 但是对于Horowitz来说,这明显还不够。 他表示,通过支持合同使开源货币化从来都不是一种伟大的商业模式。 Red Hat可能会反驳这一观点,但是Horowitz认为,更多保护性许可证将带来更多风险投资,并在MongoDB使用的开放模式的基础上催生更多的软件企业。他说:“我们是独一无二的,但我希望我们并不那么独特。”

他可能是对的。保护性更强的许可证可能会吸引更多的风险资本投资,因为他们的投资有更大的回报可能性。但是,如果这些资金真的来了,那它就不会投资于开源,因为这种对软件的限制意味着它不再符合开源的定义。

相反的论点

很多开源厂商对MongoDB的Horowitz的观点提出了反驳。其他人认为,目前的这一套许可证还是没问题的,需要改进的是业务模式。

原开源定义的合著者Bruce Perens说,SSPL与OSI的开源定义第九条是不兼容的,“许可证不能限制其他软件”。由于SSPL强制任何与所覆盖的软件聚合(并不是派生)的SaaS软件成为开源软件,因此它无法通过这个测试。 Perens把第九条写进了OSD,以禁止这种行为。

MongoDB并不是唯一一个抱怨云计算正在侵蚀其利润的公司。Redis Labs是第一个对云提供商威胁其业务发出警告的公司,而Redis Labs最终可能会有更好的解决方案。Redis Labs最初改变了它的许可证,加入了“通用条款子许可证”(Common Clause sub-license),它禁止任何人出售它所涵盖的任何软件。带有通用条款许可的软件都不是开源的,而Redis实验室承认这一点,它从未将其软件的这些部分描述为开源。

但今年春天,Redis实验室做出了另一项许可变更,对其部分模块采用了自主开发的专有许可。需要说明的是,大多数Redis是由三个子句BSD许可管理的,但有些模块如RedisJSON、RedisSearch、RedisGraph、RedisML和RedisBloom则不是。

Redis Labs表示,虽然用户可以查看和修改代码,或在其应用程序中使用代码,但它限制了用户可以构建的应用程序类型。在Redis实验室的新许可证下,就不能自由地构建任何你想要的东西。比如不能构建数据库产品、缓存引擎、处理引擎、搜索引擎、索引引擎或任何ML或AI派生的服务引擎。换句话说,你不能使用Redis实验室的代码来与Redis实验室竞争。这违反了开源许可的核心原则之一:对衍生软件没有限制。

但对于Redis Labs和MongoDB而言,说您是开源的同时,只有您应该从自己的开源软件中受益是没有道理的。但在商业模式中的专属软件中,这是有一定道理的。

这是Elastic曾走过的路。虽然有些问题最终还未定格,但有部分公司已经设法通过开源和专有代码获得成功。Elastic就是一个例子,并且它在已经面临来自AWS的竞争时,还准备一直坚持下去。

AWS不仅提供多年的Elasticsearch服务(表面上与Elastic自己的产品竞争),而且AWS最近打包了自己的Elasticsearch代码库版本,将其扩展为免费提供Elastic尚未作为开源发布的一些服务。

历史的教训

为什么MongoDB不想开源?毕竟成功的专属软件很少。为什么不继续开源呢?

Horowitz表示,开源会带来更好的系统软件,尤其是在数据库领域,他会继续将安全性和社区性作为保留开源的优势。对软件的更多关注意味着更少的错误和更高的安全性。

但是再看一看开源的定义,很明显,Horowitz忽略了构建在每个开源许可中的一个关键组件——慷慨。

开源永远不会限制你对软件的使用。这可能也是这一概念成功的主要原因,也让它成为大企业的首选。

这种慷慨的态度是您创建社区的基础,社区是构建成功的开源项目的基石。通过允许最大范围内的用户使用您的软件,您可以获得最大的社区、更多地关注错误、更多的人修复它们。那个社区变成了动力,这种势头会成为市场份额。而有时,市场份额会变成利润,但这最终不是开源的目的。

正如Perens所说,我们必须在“开放源代码”和“使用开源代码赚钱的权利”之间划清界限。开源代码定义允许但不支持您的赚钱权利,但我们不会更改规则。

Horowitz和MongoDB似乎已经接受了这一观点,或者至少在他们递交SSPL许可批准时接受了这一不可避免的事实。你构建了开源软件,但这并不意味着丰厚的利润。

Redis Labs摆脱了开源的束缚,但因为它获得了开源的所有好处:社区支持、广泛采用以及受益者提供的广泛的代码贡献。Redis Labs这一举动激怒了社区。

而事实上,Redis的分支是好的。GoodFORM采用重新授权的Redis模块,就像在许可证更改之前一样,这个项目将为Debian、Fedora和其他不能发布专属软件的Linux发行版维护这些模块。

Redis Labs新许可证的意外结果是,任何想要使用Redis的完整和开源版本的人都必须使用GoodFORM,而不是Redis。

单个开发人员可能不太在意,但是想要使用开源软件的大公司则没有那么大胆。对于他们来说,要么使用带有OSI许可的开源软件,要么打电话给律师。但是,似乎没有人会仅仅为了安装一个软件而打电话给律师,开源就是在最小化法律负担。

Redis Labs的新许可证使公司处于比较尴尬的位置,GoodFORM成为更合理的选择,这也可能暗示了为什么MongoDB最终希望保持开源的原因。

从以往来看,其他已更改为闭源代码许可证的开源代码项目进展得并不好。Xfree86项目曾是上世纪90年代至本世纪初运行X Windows的标准。2004年,Xfree86开始发布自由软件基金会认为与GPL相悖的代码。使用Xfree86的下游操作系统对此持反对态度,于是诞生了分支X.org,逐渐取代了Xfree86的位置,而Xfree86则被抛弃。

还有其他例子:LibreOffice是OpenOffice的分支,MariaDB是由于MySQL许可证更改而产生的,Wireshark同样因Ethereal而产生,这样的例子不胜枚举。在这些情况下,需要注意的不只是出现了分支,还需要注意新项目带来的开发人员、社区和长期支持开源软件的动力等现象。开源社区的力量是强大的,同样,它的反噬力量也是如此。Xfree86实际上在X.org启动六个月后就生机不再,OpenOffice也同样很快就面临相同的境遇。

开源项目的历史性教训就是,一旦您选择开源,就很难再改变路线,就算路线改变成功,也很难保持原有地位甚至很难生存。

开源之所以叫开源,原因是什么?

开源的历史告诉我们开源没有回头路,那么为什么还要这么做呢?

Beanbooks是一个由Linux计算机制造商System76派生出来的小项目,它是Perens所认为的理想开源软件的一个完美例子。在新兴的开源经济范式中,Perens认为公司的非差异化软件是开源软件的最佳方案。也就是说,开源提供了业务的基础架构,而不是核心。

换句话说,Beanbooks不是System76的利润中心,而是System76利润中心的使能技术,该技术仍在构建基于Linux的计算机。

但是,尽管Beanbooks是开源的理想选择,但它不是开源的。为什么?

System76出售Beanbooks的托管版本即SaaS,当时该公司担心更大的公司会出现,采用GPL代码克隆Beanbooks,并从System76的投资中获得利润。所以System76的创始人Carl Richell说,他可以理解像MongoDB和Redis Labs这样的公司,但是他有关有人为了竞争而窃取代码的担心也发生了,为此他感到非常遗憾。

Richell表示,担心有人会打包软件而导致投资损失。System76几年来一直希望获得诸如专利保护之类的服务,但是那在损害我们的同时也损害了平台,我们不应该担心那些问题。

尽管Beanbooks的SaaS版本看起来还不错,但是可用代码无法获得更新,从开源软件的角度来看,它是完全没有用的。Github页面没有发展,没有社区。Beanbooks的服务还在继续,但它并不像其他开源项目一样有社区贡献思想、代码。Richell认为,如果Beanbooks从一开始就拥有GPL或类似的许可证,它可能会避免自己的命运。

Ritchell认为,成功的关键不是开源软件,而是创新。差异化不是目前要做的,要做的是前进的速度,唯一成功的方法就是保持领先。

相比于MongoDB和Redis来说,Chef项目(软件自动化和部署工具的制造商)就很符合这个理念。今年春天,Chef宣布将把它的许可改为完全开源(在Apache 2.0许可下)。Chef首席执行官Barry Crist写道:“我们欢迎任何人使用我们的软件,并根据自由软件的四项基本自由对其进行扩展。”虽然Crist没有提到任何其他公司,但不难看出“四项基本自由”是对Redis和MongoDB做法的回应。

每个人都倾向于同情处于劣势的人,Redis Labs和MongoDB想要把自己描绘成在开源中处于劣势的人,与邪恶势力进行英勇的战斗,那他们是吗?

Redis Labs和MongoDB看起来仍然很健康。今年早些时候,Redis实验室筹集了6000万美元的资金,根据提供资金的公司来看,Redis准备进行一次成功的IPO。所有人都认为,MongoDB在2017年的IPO是一个巨大的成功。该公司股票首次公开发行(ipo)价格为24美元,此后一直稳步攀升。如今,它的股价在每股100美元以上。在2019年早些时候,MongoDB最大的用户之一Lyft确实投奔了AWS,但在股价小幅下跌之后,MongoDB的股价又回到了Lyft离开前的水平。

两家公司许可证变更的后果还有待观察,但是考虑到MongoDB的大部分开发都来自员工,因此无论它是否是开源的,它都可能保持正常。

开源模式从来就不是适合每个人的。正如Perens所说,“你可以使用任何你想要的许可,只要你不称之为开源,那就是你的自由。”但我们有开源的某些权利,为了保护商业模式而放弃这些权利是没有意义的。”

在这种情况下,开源的慷慨表现在出于任何目的使用该软件的权利。

这一直是判断软件开源与否的基本标准:许可是否限制了软件的慷慨程度?开源之所以能发展到今天,是因为它可以在任何地方、任何东西上使用。您可以将开源软件和私有软件结合起来;可以重新编写开放源代码库,以便它可以与您的专有代码接口;可以获得开源库,把它包装成一种服务,然后卖掉它等等。

因为这就是开源的意义:通过慷慨而获得自由。

原文作者:SCOTT GILBERTSON

Comments are closed.