我们看到太多流行的开源数据库例如 mongodb、redis、elasticsearch，它们被控制的厂商重新许可为更严格的开源许可或核心模型或非 OSS 许可。这是因为这些厂商不知道如何围绕开源构建可持续的商业模式，并回到传统的厂家锁定策略。这就是为什么真正的开源，在其横向扩展阶段，不应由厂商所有，而应由社区支持治理，最好是在开源基础下。
Grafana Labs宣布重新授权其流行的开源监控工具Grafana、Loki 和 Tempo，从 Apache2.0 到更严格的 GNU AGPLv3 许可证。
SSPL 本身是由MongoDB于 2018 年发明的，用于从 AGPLv3 重新授权其流行的数据库。尽管 MongoDB（以及现在的 Elastic）试图将 SSPL 描绘成一种开源许可，但负责开源许可的机构开源计划(OSI)拒绝了这些尝试。
除了 MongoDB 之外，近年来还有一些其他供应商发明自己的非 OSS 许可证来限制开源项目的例子，通常是在一个开放核心模型中，其中没有将功能引入开源项目，而是单独打包在非 OSS 许可证。例子包括：
- Redis Labs，它在 BSD 许可的核心Redis之上引入了根据Redis 源可用许可(RSAL)许可的附加“模块” 。
- Timescale，它在 Apache 2.0 许可的核心TimescaleDB之上引入了Timescale 许可（“TSL”）下的功能。
- Cockroach 实验室，其中引入了在功能业务来源执照（BSL）和Cockroach 社区许可的Apache 2.0许可内核的顶部（“CCL”）CockroachDB。
有些人声称这些公司并不是真正的开源玩家。我倾向于不同意。了解这些公司的工作和他们的投资后，我相信他们一开始就致力于开源，并且投入了大量的工程时间来构建和维护。
然而，这些公司所没有的是支持它的商业模式。他们忘记了简单的规则：
开源不是一种商业模式。
商业供应商旨在最大限度地提高其投资利润 (RoI)。另一方面，开源旨在共享知识并造福社区，无论是个人、初创公司还是大型公司。
开源不是商业模式
一些公司想出了一种商业模式。Red Hat、SUSE 和 Canonical 就是最好的例子。有些公司还没有，就撞墙了。然后他们的开源开始破解。这就是 MongoDB、Elastic、Grafana 和上述其他公司的情况。用他们自己的话说，他们见证了亚马逊等巨头的竞争。
尽管原理相同，但它需要与传统方法略有不同的思维方式。
使用服务模型，公司可以围绕专业服务构建其业务，以实现成功的开源。
有了产品模型，公司需要清楚地了解其独特的价值主张（UVP），将这个秘密武器构建到其 IP 中，其他一切都可以全心全意考虑开源。
由于开源项目往往有一个非常集中的目标，因此其他生产级的问题经常被忽略或没有完全涵盖，无论是运营、管理、安全、合规性还是其他。这些无人关注的问题都是厂商的商机。
这当然不是一成不变的，而是一个不断发展的东西。随着项目的成熟及其在生产环境中的使用量的增长，社区自然会推动更多地关注这些问题。这要求供应商不断创新和完善其 UVP。不幸的是，供应商常常错过这一点，而是采取防御性的反应，阻止社区围绕这些问题贡献开源代码。这是一个早期的危险信号，可能预示着以后的重新许可行动。