开源与自由 | 商业自由:从边缘到核心贡献

原创
2021/11/23 10:05
阅读数 6.1K

作者:肖滢;策划:h4cd

当我们谈论开源时,很少谈论自由,尽管开源与自由同行。从 1998 年开源兴起时,我们就无法把开源和自由分割开来。因为它孕育于自由软件运动,自由使用、复制、修改、分发源码,其精神内核一直延续至今。“自由”,为何对开源如此重要?我们将依次用《开源,是背叛自由还是以退为进?》《开放协作:赋予开发者的自由》、《商业自由:从边缘到核心贡献》三篇文章来回答这个问题,本文为第三篇。

不得不承认的是,个人英雄式的独立开发者时代已经落幕,随之而来的是,互联网科技企业成为开源社区的主要力量。

当企业成为开源的主体,开源一定需要商业自由。那么,开源与商业是怎样的关系?商业自由能为开源带来什么?为了保证商业自由,企业做了什么样的选择?无限制地放开商业自由,对开源会有什么影响?

不是二选一

我们提到过,1998 年 Mozilla 的开源,具有划时代意义。由它开始,掀开了企业大规模开源的序幕。在 20 世纪七八十年代,还没有开源的说法,只有“自由软件”,自由软件主要由个人或者大学等机构主导,GNU 工程就是其中典型的代表。而发布自由软件的企业屈指可数,它们处于自由软件世界的边缘位置。

自由软件在商业企业中并不受欢迎。它赋予用户分发软件源代码的自由,在很大程度上损害了企业的利益。 

微软 CEO 比尔·盖茨于1976年发布的一封公开信,可以反映出企业对分享软件这一行为的普遍态度。他在信中抱怨,未经授权使用 Altair BASIC 的情况太普遍,导致新成立的微软公司回报甚微,并指出那些分享拷贝软件的人是剽窃者。“谁能负担得起白做专业工作?哪个业余爱好者可以花 3 年时间进行编程、查找所有错误、记录他的产品并免费分发?事实是,除了我们之外,没有人在业余爱好软件上投入大量资金。你所做的就是盗窃。” 

不过,自由软件本身并不抵制商业化。自由软件基金会(FSF)就明确表示,自由软件无关价格。很多人以为,GNU 计划的精神是不应该为分发软件副本收费,或者应该尽可能少收费——刚好足以支付成本。这是一种误解。实际上,他们鼓励重新分发自由软件的人尽可能多地收费,以此来支持开发。“分发自由软件是为开发筹集资金的机会。不要浪费它!”当然,这一切都建立在保证用户有自由运行、学习、修改以及再发行原版或是修订版软件的前提下。 

“开源”的出现,更是为商业自由而来。1998 年,正是因为 ESR 等一批自由软件运动的倡导者考虑到“free software”中的“free”有免费的意思,对商业不友好,才出现了用“开源”一词替代“自由软件”,以方便对外宣传,吸引更多的企业加入到自由软件运动中来。随后,开源促进会(OSI)批准了第一批许可证,其中就包括 BSD 许可、MIT 许可两个商业友好型的许可证。OSI 维护着开源定义(OSD),判定一份许可证是否属于开源许可证,以 OSI 认证为准。 

从一开始,开源与商业不是二选一的关系,而是共生的关系。 

早在上世纪 90 年代后期,RedHat、MySQL AB 等公司就证明了,利用开源软件来赚钱是可行的。尤其是 RedHat 在1999 年以创纪录的 IPO 公开上市,更是令不少企业艳羡不已。 

而今,开源已经是一种成熟的商业模式,一头扎进去,人才、市场、名声,全都可以握在手里,足够顺利的话,甚至还能建立一个以开源项目为核心的产业生态,坐收渔翁之利。 

2007 年,为避免苹果公司的移动操作系统 iOS 垄断市场,谷歌主动开源 Android 操作系统( 该开源项目简称:AOSP)。由此,Android 系统在移动端的市场份额一路飙升,2020 年超过 70%。这也为谷歌移动服务(GMS)带来广阔的市场。要知道,GMS 每年为谷歌带来数百亿美元收入。 

用开源的手段扩张市场,在软件行业已经屡见不鲜,除了谷歌这样的科技巨头,不少初创企业也加入进来。MongoDB 公司的 CEO Dev Ittycheria 就明确表示,开源就是为了获得市场。公司成立的第三年,MongoDB 已经初步开发完成,却没有足够的资源面向整个庞大的市场进行营销,因此想利用开源的病毒性传播属性,让软件得到广泛使用。这一策略确实奏效,几年之后,MongoDB 成为了最受欢迎的 NoSQL 数据库之一。 

微软收购全球最大的软件开发平台 GitHub 进一步表明,大公司正在寻求成为开源的主要供应商,并准备在其中投入大量资金。  

商业反哺开源 

企业是商业自由的最大受益者,同时也在反哺开源。它已经从最初的开源软件使用者,转变成集创建者、使用者以及贡献者多重身份于一体的角色。开源已经离不开企业,离不开商业自由。 

最直接的证据是,企业贡献了一大批顶级的开源项目,成为开源技术的引领者,尤其是在近几年尤为活跃的人工智能、大数据、云计算等新兴技术领域。微软创建了源码编辑器 VSCode,谷歌创建了机器学习平台 TensorFlow、容器编排平台 Kubernetes,Facebook 创建了移动应用开发框架 React Native。众所周知,这些技术领域的创新都源于开源生态,企业功不可没。 

它们同样也为其他开源项目贡献代码。尤其是软件巨头,成为了最大、最活跃的贡献者。根据 Open Source Contributor Index 公布的 2020 全球开源厂商 GitHub 开源贡献排名,谷歌和微软两大互联网巨头排在榜单前二位,二者参与开源贡献的活跃贡献者人数都超过了 5000 人,参与的开源社区超过 10000 个。微软、谷歌、IBM、Oracle、Facebook 五家科技巨头企业参与的开源项目数超过 20000 个。 

在一些大型的、复杂的、生命周期长的开源项目上,企业所具有的软件工程调度能力,会比零散的个人开发者更具有优势。红帽博客编辑总监 Joe Brockmeier 认为,理想情况下,企业开源结合了两个世界的优点——开源的优势与企业软件提供的稳定性、性能、支持和生态系统。 

也正是因为开源允许商业自由,才有更多商业模式诞生,吸引更多企业加入。从最早期的“RedHat”模式,发展到 SaaS 模式、Open Core 模式、限制性许可模式、混合许可模式等,越来越多的企业在尝试构建新的开源商业模式。在过去的十年中,Open Core 模式成为了最成功和最常用的方法。Elasticsearch 和 MongoDB 就是该模式下商业化的开源项目,二者也都成为了商业开源软件公司(COSS)。对于其他跃跃欲试的企业来说,一套成功的商业模式无疑是具有鼓动性的。 

此外,企业结合开源软件实现商业转化,获得收入之后也能够更好地回馈开源社区,让项目可持续。一个现实问题是,很少有人有足够的空闲时间将其用于真正的开源贡献。因此,不少通过开源获益的企业会付钱给开发人员或运营人员,让他们为开源软件做出贡献。 

难以想象,在企业取代个人成为开源领域绝对主流的时代,没有了商业自由,开源会变成什么。 

许可证的选择 

在开源世界,什么会限制企业的商业自由?那自然是规则,也就是开源许可证。选择什么样的许可证,关系到企业的开源商业模式。 

开源许可证大体可以分为两大类:一类是 Copyleft 许可,另一类是宽松型许可。宽松型许可证对他人如何使用开源组件的限制最小,几近于无。它们允许用户在不同程度下自由使用、修改和重新分发开源代码,并允许在专有衍生作品中使用宽松型许可的开源组件,几乎不需要任何回报。 

简而言之,宽松型意味着不强制开源,条条框框少了,对商业友好,企业利用开源软件发展业务更加便利。 

一个越来越明显的趋势是,宽松型开源许可证使用量明显增长,而 Copyleft 许可证,尤其是GPL 许可证的使用量继续减少。根据 WhiteSource 发布的数据显示,2020年,76% 的开源组件拥有宽松型许可,比上一年提高了 9 个百分点。24% 的开源组件是 Copyleft 许可,比上一年减少了 9 个百分点。在 2012 年,Copyleft 许可证还牢牢占据上风,有 59% 的使用率,而宽松型许可证的使用率仅为 41%。 

宽松型许可证大行其道,开源项目创建者的意志起了决定性的作用。近年来,互联网科技企业成为了开源项目的主要创建者,而不再是个人。使用 Copyleft 许可证,就意味着失去自己的私有软件的控制权,从商业角度出发,限制较少的宽松型许可证是企业的最佳选项。对用户限制越少,对自己也就越有利,企业本身就是最大的用户。 

MIT 许可证及 Apache 2.0 许可证 ,就是典型的宽松型许可证。2020 年,使用 MIT 许可证或 Apache 2.0 许可证的开源项目超过一半,其中不乏一些备受瞩目的开源项目。例如,Ruby on Rails、jQuery 和 Angular.js 使用 MIT 许可证,Kubernetes、TensorFlow 和 Swift 首选 Apache 2.0 许可证。事实上,所有 ASF 项目——其中一些被广泛使用——都在 Apache 2.0 许可下。 

用户也选择以宽松型许可证授权的开源组件,这样可以最大限度地减少法律部门对开源许可证合规性的挑战。而针对许可证不符合企业要求的开源项目,已经有不少企业制定了黑名单,禁止开发人员引用相关代码,从而避免风险。比如,Google 就禁用了以 AGPL 授权的软件。AGPL 是 Copyleft 许可,其中一条特别规定是,即使软件被运行在向公众提供服务的服务器上,那么该软件的任何修改也必须开源。 

总之,为了保证商业自由,企业做出了使用宽松型许可的选择,无论是作为创建者的角色——将软件开源,还是作为使用者的角色——引入开源软件,更遑论作为贡献者的角色提交代码了。 

商业自由的“度” 

站在自由软件之父 RMS 的角度,将自由软件代码用于专有软件,就是在剥夺了用户使用、学习、修改软件的自由;站在 OSI 的角度,将开源软件代码用于专有软件是符合开源精神的,这是在保护用户基于任何目的使用软件的自由,哪怕是将代码用于专有软件。OSD 规定,开源许可不得歧视个人或团体,不得歧视任何领域。企业用户也是用户,商业自由也是自由。 

当开源许可证成为商业自由的保护伞,一视同仁对待所有用户时,就有人开始不满。尤其是不少开源软件创建者,从选择许可证开始,尽可能地让自己拥有更多权利,尽可能地限制他人的自由,从而保护自己的利益。 

历史上不是没有发生过这种事。网景最初开源 Mozilla 项目,就是采用了自己制定的 Netscape 公共许可证,其最显著的特点是它给予了 Mozilla 的原始开发者,也就是网景它自己,有权分发后续及衍生软件,其他贡献者却不可以,最后结果证明了这条路根本行不通。 

随着 SaaS 交付模式日益流行,使用与贡献不对等的情况变得严峻。云服务供应商依托开源软件大举盈利,却不需要贡献任何代码,在这种情况下,无限制地放开商业自由,就是对开源厂商的伤害。贝恩资本的 Salil Deshpande 曾表示:“需要明确的是,这并不违法。但我们认为这是错误的,不利于可持续的开源社区。” 

为解决这一问题而诞生的开源许可证—— AGPL 曾被寄予厚望,但由于它的限制条件有些模糊,比如“用户通过网络进行交互”可以延伸到什么程度没有具体说明,且它是强 Copyleft 许可证,最终被部分开源厂商抛弃 

不能没有商业自由,但又不能无限制地放开商业自由,商业自由的“度”在哪里? 

面对云服务供应商的“吃白食”行为,有厂商在发布开源项目时,在许可证之外,还会添加限制条款。Nebula Graph 是一款开源的分布式图数据库,基于 Apache 2.0 许可证分发。不久前,开源厂商 Nebula Graph 为了防止云服务供应商从项目中获利而不作出回报,在项目中加入了  Common Clause 1.0 条款。不过在 ASF 的要求下,Nebula 团队最终移除了该条款。 

也有很多开源厂商直接变更许可证,以防止云服务供应商从他们的代码中构建服务。今年 1 月,Elastic 公司宣布,把根据 Apache 2.0 许可授权的 Elasticsearch 和 Kibana 源代码变更为双重授权许可模式,即 SSPL+Elastic 许可。 

SSPL 是 MongoDB 在基于 GPL v3 的基础上,面向服务器端制定的许可证。该许可证虽然允许用户使用及修改产品源代码,但有一个基本要求,就是在该协议下,如果企业将产品作为服务对外提供,则必须同时提供“服务源代码”。所谓“服务源代码”,是指程序或修改版本的相应源代码,以及用于提供此服务的软件源码,包括但不限于管理软件、用户界面、应用程序接口、自动化软件、监控软件、备份软件、存储软件和托管软件,所有这些让用户可以使用可用源码运行服务实例。而 Elastic 许可则更加严格,直接禁止将软件作为托管或托管服务提供给第三方。 

除此之外,Confluent、MongoDB、Cockroach Labs、Redis Labs、Timescale 和 Graylog 等,也都从 OSI 批准的开源许可转向非“开源”的许可。 

如果一个软件限制云厂商使用,那还能算是开源软件吗?当然不算。根据 OSD 第六条,不得歧视任何领域,这就表示,不让商用,不让云服务用,这些行为都是禁止的。把云厂商排除在外的许可证,不是 OSI 所认可的开源许可证。没有采用开源许可的软件自然也算不上开源软件。 对于 SSPL,OSI 就明确表示,它不是开源许可证,因为它实际上剥夺了用户权利。 

面对开源厂商的相继出逃,开源还应该坚持无限制地放任商业自由吗?如果不限制,那么谁来为贡献者的劳动成果买单?企业的角色注定了,开源对它而言,不会是一项只求付出,不求回报的活动。 

如果能够找出让贡献者和使用者之间平衡的点在哪里,或许就会知道,开源能够允许的商业自由的“度”在哪里。从云计算上升的发展势头来看,这个问题将会成为长期争议的焦点。


参考资料: 

1、https://sourcecodecontrol.co/sspl/ 

2、Producing Open Source Software:How to Run a Successful Free Software Project 

3、https://www.whitesourcesoftware.com/resources/blog/open-source-licenses-trends-and-predictions/ 

4、https://www.peterchen.vc/kai-yuan-xiang-mu-shang-ye-hua-de-li-nian-he-lu-jing-light-view/ 

5、https://blog.timescale.com/blog/how-open-source-software-makes-money-time-series-database-f3e4be409467/ 

6、https://firstmonday.org/ojs/index.php/fm/article/view/1211/1131 

7、https://www.mongodb.com/licensing/server-side-public-license 

8、https://www.elastic.co/cn/licensing/elastic-license

展开阅读全文
打赏
1
6 收藏
分享
加载中
写的真不错,虽然我们一直在用开源技术,但是大多数人一直没有对开源软件做过什么贡献,但是如果变相的不让大家用,我想这也不符合开源精神吧 ,所以这可能就是es 不再继续被apache使用的原因了吧,打着开源旗号, 坐收渔翁之利,还是挺可耻的
2021/11/29 11:38
回复
举报
更多评论
打赏
1 评论
6 收藏
1
分享
返回顶部
顶部