出品| CSDN（ID：CSDNnews）

很多初创公司都在担心如何设计开源项目的商业模式。 以下内容是笔者目前对这个问题的探索，应该以此为出发点。

开源许可证

既然我们已经决定将“Milvus 矢量搜索引擎”（作者公司在 GitHub 上的开源项目）开源，那么第一步就是选择合适的开源许可证。 虽然自由软件创始人RMS曾倡导copyleft的概念，但copyleft也是一种特殊的Copyright。

那么，什么是开源许可证？ 简单来说，只要是经过OSI（Open Source Initiative）认证的许可证，就可以称为开源许可证。 OSI 有专门的流程来审查许可证是否符合开源定义。

例如，MongoDB新设计的SSPL（Sever Side Public License）在完成OSI认证之前，MongoDB只能说它的许可证是source available（源可用），但不能说它是开源的（当然这个限制是行业的）实践），非强制）。

目前主流的开源许可证可以在OSI网站上找到。 网上也有很多文章比较各种License之间的差异（请参考阮一峰老师的博客），就不一一赘述了。

这里我们主要根据自己的情况谈谈开源License的选择。 简单来说，开源许可证可以分为三个级别：

•严格，以GPL 2.0许可证为代表软件设计文档数据库部分，典型软件为MySQL

•中等，以Apache 2.0许可证为代表，目前使用最广泛

•失去，以BSD、MIT、PostgreSQL为代表的许可证，典型软件是PostgreSQL

熟悉数据库的朋友一定都知道MySQL和PostgreSQL。 MySQL是最流行的开源数据库，而PostgreSQL是衍生项目最多的开源数据库。 如今的新项目很少使用GPL 2.0许可证，它的传染应该是大家最关心的问题。

对于推广基础技术，MIT/BSD类型的许可证是一个不错的选择。 也许现在很少有人使用FreeBSD了。 但它仍在发展。 由于非常宽松的 2-Clause-BSD 许可证，FreeBSD 被许多制造商用来开发自己的闭源系统。

例如，索尼的 Play Station 3 和 4 系统基于 FreeBSD，任天堂的 Switch 游戏机也是如此。

Redis 还使用宽松的 3-Clause-BSD 许可证（与 2-Clause 相比，它对商标的使用有更多限制）。 然而软件设计文档数据库部分，整个Redis工具链的许可情况非常复杂。

以至于Redis在切换部分组件的许可证时，引起了业界极大的误解。 所以中途把license严格起来有点敏感。

看似复杂的 Redis 许可矩阵

如果最好的政策太紧急，那么下一个政策就太慢了。 然后中间选择Apache 2.0。 Apache 2.0 目前是 Apache 基金会和 CNCF 基金会推荐的默认开源许可证。

来自 GitHub 网站的 Apache 2.0 许可证的简要说明

Apache 2.0与其他开源许可证一样，不限制商业用途，并且默认包含专利许可证。 不过，Apache 2.0也明确规定了该开源许可下软件制造商的免责条款。 这是开源软件公司提供订阅增值服务的法律依据。

但即使有了像 Apache 2.0 这样成熟的开源许可证，每个人仍然有一个担忧：公共云。

是否需要防范公有云厂商？

开源软件和公有云的关系这两年有点紧张。 一种流行的观点是，公有云吸干了开源软件的血液，却没有为开源社区做出太多贡献。

许多开源项目开始寻找面对公共云时保护自己的方法。 毕竟，公有云的出现在一定程度上扰乱了原有的开源商业模式。 最终用户通过购买云服务获得公有云服务提供商的保护，绕过开源厂商。

于是，共同条款应运而生。 Common Clause是一个附加条款，开源厂商仍然需要选择一个基本的主许可证。 最终的形式类似于：Apache 2.0 + Common Clause 1.0。

普通从句比较简洁，全文只有3句。

通用条款主要禁止他人利用开源软件获取利润而不增加开源软件的价值。 其局限性主要体现在以下三点：

假设第三方基于开源软件构建了一套面向用户的应用程序，并且这套新的应用程序增加了原始开源软件的价值，那么这套新的应用程序将不会受到任何限制。 这保证了开源厂商和合作伙伴之间的合作关系不会受到影响。

不过Common Clause还没有经过OSI认证，所以添加Common Clause后，建议只说是源代码可用（source available）。 虽然会引起一些争议，但初创开源项目选择添加 Common Clause 似乎被越来越多的人所理解。

但是，我们的开源项目并不打算添加 Common Clause。 有两个重要原因。

来自 MongoDB 的灵感

MongoDB 是一个成功的开源项目的例子。 MongoDB 从一开始就获得了 AGPL 3.0 许可证的许可。 如果公有云使用MongoDB来提供服务，那么公有云厂商需要公开相关底层服务的源码。 因此AWS、Azure、Google Cloud等美国公有云都选择开发自己的文档数据库。

在美国之外，MongoDB很难用法律武器来保护自己。 MongoDB在2018年10月修改新版本许可证时，再次抱怨公有云厂商侵犯MongoDB的利益，主要指的是美国以外的公有云厂商。

因此，对于具有全球野心的开源基础软件厂商来说，仅凭一张许可证就很难充分保护自己。

另一方面，当AWS有DynamoDB时； Azure 有 Cosmos DB； 而且Google Cloud拥有Cloud Firestore，MongoDB不再是唯一的文档数据库。 在随后的移动互联网浪潮中，MongoDB Mobile在移动端并没有达到预期的影响力。

毕竟像Realm这样的移动文档数据库可以直接与多个公有云文档数据库同步，这极大地方便了移动开发者。 2019年4月，MongoDB以3900万美元收购了Realm。

既防备别人又部分影响自己的发展空间，值得吗？ 答案因人而异，开源项目需要根据自身情况做出选择。

四爷的新攻略

据咨询公司Gartner统计，2018年谷歌云占据公有云IaaS市场4.0%的份额，排名全球第四。 它仍然不及领先者AWS（47.8%）的市场份额的一小部分。 谷歌云想要迎头赶上，他该怎么办？

在今年的 Google Cloud Next 大会上，新上任的 Google Cloud CEO 邀请了 Redis Lab CEO 和 MongoDB CEO 来帮助该平台。

会上，谷歌云推出了Redis托管服务，MongoDB在谷歌云市场上架。 随后，MongoDB的Atlas云服务也与谷歌云展开了一系列合作。

Redis和MongoDB在开源社区和互联网行业具有很大的技术影响力。 而且他们是开源行业中向公有云厂商开火比较频繁的两家公司。

最近，他们修改了公共云供应商的许可证。 因此，Google Cloud Next 的消息很有趣。

与成熟的开源厂商合作似乎是谷歌云的新策略。 这条路值得尝试。 毕竟，老四想要用老大的手段打败老大，恐怕很难。

齐白石曾说过：“学我者生，似我者死”。 谷歌云是第一个解决这个问题的。 相信越来越多的公有云厂商会想了解这个问题，并选择与成熟的开源厂商合作。 因此，对于开源基础软件来说，当务之急是提高自身的成熟度，预防措施可以暂时放在一边。

商业设计

中，我们提到“Apache基金会有1.9亿行代码，根据COCOMO II模型估算，这些代码的开发成本超过200亿美元（2019年年报）”。 这样一来，每行代码的开发成本就超过100美元。 所以不要认为开源软件就应该免费使用。

典型的开源商业模式

目前，比较成熟的开源软件商业模式包括以下几种：

• 订阅服务：开源许可证使制造商免于承担软件质量和软件缺陷修复的责任。 这些对于企业级应用程序来说是必需的。 因此，最自然的商业模式就是提供软件订阅服务，为用户提供生产级的服务支持响应和热修复。

•高级功能：例如Redis。 核心组件是开源的。 但工具软件和高级功能（如多租户、无共享分布式架构等）都是收费的。

•云服务：例如Databricks。 Spark 是开源的，但付费版本仅作为 Azure 和 AWS 上的云服务提供。

•生态效益（仅针对非常大的开源厂商）：例如，华尔街分析师估计，谷歌每年仅为了iPhone上的默认搜索引擎入口就向苹果支付近100亿美元。 想想Android为Google节省了多少钱？

软件世界存在两大问题：一是大型软件系统的项目管理（人月神话），二是软件定价。

关于项目管理，已经有很多研究和实践，大家都有参考点。 软件定价尚无成熟的公式或模型。

但至少对于开源软件的定价，我们必须避免以下两个陷阱：

•定价高，可享受10%折扣