为了保留开源的优势，请考虑细致入微的许可方法，在开放性、可持续性和安全性之间取得平衡。
译自 Beyond the Walled Garden of Open Source，作者 Jonathan Marsh。
开源为创作者（发布者）和消费者（用户）提供了优势。然而，当开源的原则与现实情况（如资助开发活动和投资适当的安全级别）发生冲突时，有时会出现摩擦和争议。当开源倡导者和监管者试图从开源的清晰界限出发时，就会出现一些骚动。更多人接受和支持许可和监管方面的细微差别将为更多用户带来开放的益处。相反，缺乏细微差别可能会缩小开源公域的边界，因为开源许可在更多情况下变得不切实际。
广泛的研发资金成本高昂，大多数开源依赖企业提供资金。但“免费”（如免费啤酒或自由）往往与产生自我维持资金的需求相冲突。公司找到了各种方法来混合或限制他们对开源的承诺，以保留足以维持其企业的收入潜力。
例如，MongoDB 在向用户提供开源产品时发现，用户在开源中获得的自由也赋予了竞争对手恶意行为的自由。以 Mongo 为例，亚马逊开始提供基于 Mongo 并与其兼容的 SaaS 版本，基本上免费利用了 Mongo 所有历史研发和思维共享开发投资，并利用这些投资反过来对 Mongo 施加巨大的商业压力。Mongo 用开源许可证赠予了亚马逊一根棒球棒，然后亚马逊反过来用它打了他们。为了回应一些纯粹主义者的强烈抗议，Mongo 从纯粹的开源许可证退回到了一种仍然为用户提供开源优势的许可证，但限制了潜在竞争对手以前享有的完全自由。他们的许可证不再被认为是纯粹的开源，即使大多数用户没有看到许可证变更带来的实际影响。通过这种机制，Mongo 已将其许可证持有者细分为用户（开源）和竞争对手（商业）。
许多其他提供开源产品的公司已经转向开源核心模式，该模式提供基本产品作为开源，但在商业许可下添加其他功能。这些公司将其许可证持有者细分为基本功能用户（开源）和高级或企业功能用户（商业）。
WSO2 提供功能齐全的开源产品，但提供商业化支持和维护。免费用户可以获得全部功能，但只有商业用户才能获得具有企业级 SLA 的支持帐户，接收大量产品生命周期的更新和错误修复、私人安全公告、专家建议、云托管和其他服务。通过这种模式，我们将许可证持有者细分为“原样”用户（开源）和完全支持的用户（商业）。
这些例子说明了公司如何利用开源来实现其特定目标并为成功的商业模式奠定基础，这一点存在很大差异。但这并不是发布者将其作为开源发布的唯一原因。个人爱好者社区或组织联盟走到一起，分享对开发共享问题的标准解决方案的投资。公司发布开源可能不是为了直接盈利，而是为了围绕其品牌或观点建立行业思想共享，通过对竞争技术施加压力来撼动市场，或者孵化生态系统以改进创新或保持开发和维护成本下降。个人或组织可能会将开源发布，仅仅是为了分享感兴趣的东西或为人类知识领域做出贡献——这可能是一个研究项目、测试或已经结束其商业生命周期但仍被特定用户使用的产品。
它将服务于那些以更广泛的术语推广开源的人，而不是将开源视为一个围墙花园，其中内部的一切都被认为是“开放的”，而外部的一切都不是。相反，应该在更广泛的背景下考虑开放性，并尽可能鼓励在官方认可的开源许可环境之外开放。要做到这一点，需要欣赏和适应发布者的价值观和动机的多样性。有了这种观点，新的可能性就会出现：
- 针对开源“邻近”场景的标准化许可证。 许可证标准化是开源社区的一项杰出成就。通过定义和标准化那些展现出开放特性的许可证，同时将它们与当今的纯开源许可证区分开来，可以扩大这些益处。例如，一个标准化的开源邻近许可证，它可以保证用户享有开放性带来的好处，但又能限制来自竞争对手的威胁，这将改善目前为此目的而存在的各种许可证的混乱局面。就像知识共享为各种内容许可证（包括“保留所有权利”）提供了一系列标准化许可证一样，也可以开发出具有不同开放程度的标准化许可证，直至“保留所有权利”。这样一套许可证所暗示的普遍接受将鼓励更多公司在其许可证策略中追求更显著的开放程度。
- 用于表明发布者意图的标准。 随着有关开源的法规的出现（例如，《欧洲网络弹性法案》），消费者没有一种普遍接受的方式来了解开源产品是否打算在面临安全挑战的环境中进行关键用途。《网络弹性法案》规定，所有产品（包括开源产品）都必须执行风险评估、提供安全更新，并在合理期限内积极维护项目。其结果是，所有在欧盟开展业务的公司发布的开源软件都必须得到最高级别的关注。如果这些要求不利于发布目标，发布者很可能会完全放弃发布。相反，通过提供发布者接受的意图和责任的明确声明，用户可以选择具有适当安全特性的软件。这将防止开源软件从公共领域消失，这在其他情况下可能非常有帮助。