开源与自由 | 商业自由：从边缘到核心贡献
作者：肖滢；策划：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/
6、https://firstmonday.org/ojs/index.php/fm/article/view/1211/1131
7、https://www.mongodb.com/licensing/server-side-public-license
热门推荐
相关文章
近期评论
-
来自： 留言板
-
来自： 留言板
-
来自： 留言板
-
来自： 留言板
-
来自： 留言板
-
来自： 移动APP安全测试用例指南
-
来自： Android多设备自动化测试实践
-
来自： 留言板
-
来自： 留言板
-
来自： 留言板
