当前位置:   article > 正文

开源与自由第三篇 :商业自由:从边缘到核心贡献。当企业作为开源主体后,二次开发闭源做自己的收费产品,却并不进行反馈开源主体,如何解决?云服务商的处理是典型代表,但还有其他_agplv3是商业自由的吗

agplv3是商业自由的吗

文 | 肖滢

策划 | h4cd

出品 | OSC开源社区(ID:oschina2013)

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

270367c65b55a39acee3ee348fb57928.png

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

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

不是二选一

我们提到过,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 许可则更加严格,直接禁止将软件作为托管或托管服务提供给第三方。 (在这不懂这句话是支持二次修改开源还是闭源2022.5.25

插入内容,到复制连接处结束:

拒绝云服务商白嫖,Elasticsearch 和 Kibana 变更开源许可协议

每个开源项目都会有自己的一个开源协议,例如 Apache、MIT、BSD、GPL 等等,可以说是对于该项目开发者、使用者甚至是商业化受益者的一种约束。

不过,开源项目的开源协议也不是一条路走到黑的,不少著名的项目都曾经更换过开源协议。很大程度上是因为一个原因——云服务商白嫖,拿来别人辛苦开发的东西去做自己的收费产品,却并不进行反馈,这种『拿来主义』令很多开源项目团队表示不满

Elatic 这次更换协议的发声,不是第一个,也肯定不是最后一个。随着开源的普及和发展,未来此类事件会越来越多,也希望更多人能够从使用者、支持者,成为开源的贡献者。当然,尤其是云服务公司,总不能当貔貅吧~

日前 Elastic 公司宣布,将对旗下 Elasticsearch 和 Kibana 进行开源许可修改,从 Apache 2.0 许可的源代码移到服务器端公共许可(SSPL)和 Elastic许可的双重许可下,使用户可以选择要应用的许可。该公司市值 140 多亿美元。根据官方信息,从 7.11 版本开始,两个产品的所有维护分支,默认发行版将继续使用 Elastic 协议。

目前,两个项目的协议分别更新于 2018 年和 2019 年

为什开源项目要改协议?

官方表示,为了保证社区和用户能够自由开放地访问、使用、修改和分发这两个产品和源码。重点来了:它还通过限制云服务提供商在不共享其修改内容和服务管理层的源代码的情况下限制其将我们的产品作为服务提供,从而保护了我们在开发免费和公开分发的产品方面的持续投资。

毕竟谁的钱也不是天上掉下来的,云服务商直接白嫖,云服务直接装上作为自己的产品打包赚钱,没有支持和回馈,这显然不合情理了。

Elastic 表示,同阿里巴巴和腾讯建立了合作伙伴关系,两个产品不受影响,微软、谷歌、阿里和腾讯甚至是 AWS 的 Elastic Cloud 也可以正常使用。

不过,Elastic 我们与 Amazon Elasticsearch Service 上的 AWS 没有商业关系。不积极支持该服务,也不再希望我们对软件的投资直接受益于该服务。为了透明起见,我们还在与 AWS 进行持续诉讼。

都闹到对簿公堂了,可见积怨已久。

此次更换协议对于使用者有什么影响?

官方表示:没有影响,您还可以像之前一样使用。

改开源协议,还有谁?

当然有,而且不少。

3.1 Redis2018 年 8 月,Redis Lab 表示,Redis 开源许可依然是 BSD,但是模块许可协议修改为 Apache 2.0 并附带 Commons Clause。

2019 年,Redis Labs 决定删除 Commons Clause,更换成新的许可 RSAL,Redis 表示该协议不针对开发人员,仅仅是为了自己对于产品的维护,防止云服务商打包产品进行垄断牟利。

3.2 MongDB

2018 年 10 月,MongoDB 宣布更改开源协议,将从 GNU AGPLv3 更改为 SSPL。此举遭到了红帽等组织的弃用,因为他们认为 SSPL 不是真的开源,当然,MongoDB 也不否认,毕竟自己的产品一直被云服务商白嫖甚至是公然售卖,搁谁都受不了了。

3.3 OpenCV

2020 年 7 月,OpenCV OpenCV 官方宣布,将开源协议从 BSD 变更为 Apache 2.0。目的是针对其中的“专利”相关进行说明。尽管代码本身免费,如果使用 BSD 许可的代码,当中包含的专利可能涉及到一系列的复杂问题。目前,OpenCV 4.5.0 及更高版本使用 Apache2.0 协议,而 4.4.0 以下版本采用了 BSD 协议。

3.4 Google

这里也是针对云服务商,不过不是协议。

2019 年,Google 表示将不会将旗下的开源项目 Knative 捐给 CNCF,毕竟自己造出了 K8S,眼睁睁看着云服务商吃肉而自己连口汤都不喝不到,所以就决定利用自己的发明者的优势和云服务商竞争一下到底谁该吃这块肉。

当然,Google 此举也遭到了一些开源项目创建者的反对。

那些神奇的协议

开源协议,规定开发者和使用者对于项目的修改和使用、分发等一系列行为。了解开源项目的朋友们可能对 Apahce、MIT、GPL 之类的开源协议再熟悉不过了,这里搁置不表,有兴趣的朋友可以直接去访问开源协议的官网去了解。

GitHub 当中默认能够直接选择的是哪些协议呢?

ApacheLicense 2.0GNUGeneral Public License v3.0MITLicenseBSD2-Clause "Simplified" LicenseBSD3-Clause "New" or "Revised" LicenseBoostSoftware License 1.0CreativeCommons Zero v1.0 UniversalEclipsePublic License 2.0GNUAffero General Public License v3.0GNUGeneral Public License v2.0GNULesser General Public License v2.1MozillaPublic License 2.0TheUnlicense

如果使用其他协议,只要自己建立一个 License.txt 声明即可。

除了这些之外,通常我们使用的开源协议是通过开源促进会(OSI,Open Source Initiative)批准的开源协议。去年 2 月,OSI 首次通过了来自中国的木兰开源许可证 v2 版本(MulanPSL-2.0),使其正式成为一个国际化开源许可证。

SSPL 是由 MongoDB 最初创建的可提供源代码的许可证,旨在体现开放源码理想的许可证,允许自由和不受限制地使用,修改和重新分发。其简单要求是:如果您以服务给他人,您还必须根据 SSPL 公开发布任何修改以及管理层的源代码。SSPL 是基于 GPLv3 的 copyleft 许可证。并没有经过 OSI 批准,因此官方还特意声明:『为了避免混淆,我们暂时不将两个产品称为开源,而使用“免费和开放” 进行描述』

这里还有两个奇奇怪怪的协议。WTFPL 和 DBAD 协议,我知道一说这个你们就来精神了。

WTFPL,全称 Do What The F*ck You Want To Public License 就是你 ** 想用它做点啥就做点啥吧。目前也是通过了 FSF 和 GPL 许可的,当然了这个存在一定的争议,有些人表示这个权限给的太散漫了。不过,既然作者同意了,那就随他去吧。

另外一个神奇的协议叫做 DBAD,全称 Don’t be a dick。该协议的最神奇之处是,他是要求开发者的,协议里面还对 dick 进行了定义,意思是可别整幺蛾子了。

百度安全验证https://baijiahao.baidu.com/s?id=1689384334788988208&wfr=spider&for=pc

除此之外,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

 一、参照物理的基础理论(牛顿定理)和技术发明专利,区分自由开源软件和闭源专业。但是实际中发现无法参照物理那样定义。因为软件无论基础的操作系统(windows,Linux)还是某一专业处理某一问题的软件(word)都是思想创造的,不是外部已经存在,由专家只是发现的定理,或者是专业人士利用物理特性发明的创造。现在感觉linux是基础的操作系统软件了,广大的厂商开始赞助,可是在一开始的时候,linux刚发展,可是广大的商业企业没人赞助的,政府也不赞助。任何新事物都经历萌芽,发展,壮大,成熟,消亡阶段,软件出现也是。所以没有固定的模式,需要随时视情况而定,例如后来微软,IBM开始拥抱开源,闭源开源混合模式发展企业

二、自由开源成为共识,如果二次开发后转为闭源进行商业垄断,而不回馈一次开发主体包括企业,个人等组织,会导致收回使用权许可。或者同类企业竞争,或者一次开发主体(企业个人组织)联合二次开发企业的同行业企业做出同样产品开源迫使最早的利用二次开发开源软件转闭源牟利的企业改变

三、自始至终闭源的专业软件如苹果,微软的windows系统,谷歌的GMS,人们无权要求开源或者让之转自由软件。需要大量的精力专业付出形成的强大公司力量,不可能不要报酬。形成的垄断需要政府层面处理反垄断。不能从道德要求。还有广大的PLC以及各个行业比如电力,环保中的众多的企业都有自己的产品,包含专门的软件,能让人家开源吗?

四、单片机产品比如消谐仪,数采仪,厂家还提供程序源码吗?那是技术转让了。源码技术核心企业核心竞争力

五、许多开源代码要求不能用于商业。或者用于商业需要分享收入提成

六、如果都想白捡现成,谁还去开发新软件,完美功能需要全力以赴开发,如果基本生活保障不了,还如何追求完美产品。

七、用户:普通用户和专业程序员用户。普通用户不关心源代码,例如电子商务人员不关心程序源代码只要能用就行,给了源码也不会操作。而专业的程序员用户可能考虑源代码。但是各行业的也不一定关心非自己行业的源代码。环保行业人不会关心快递行业的软件源代码

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小丑西瓜9/article/detail/448121
推荐阅读
相关标签
  

闽ICP备14008679号