开放但封闭
在如今代码量庞大到单个头脑无法掌握的时代，当实际上社区无法访问源代码时，很难看到软件自由如何存在。
在自由软件的早期，一个安全的假设是，任何使用计算机的人都具备某种编程技能——即使只是编写 shell 脚本。因此，许多自由软件的倡导者，尽管非常关注用户自由，但对于根据自由条款提供源代码但不提供二进制文件的软件，仍然具有很高的容忍度。
这被认为是不受欢迎的，但只要源代码可以使用，就不会被取消资格。即使在表面上符合自由软件规则的情况下，也演变出许多其他方式来确保软件在没有与特定供应商建立商业关系的情况下，实际上无法部署。
对于“开放但封闭”模式的这种容忍度延续到了新的开源运动中。只要代码根据开源许可证被解放出来，许多人就认为更大的利益得到了服务，尽管为了商业模式而设置了障碍。
但时代已经变了。随机的代码解放仍然是可取的，但对最大数量的人来说，最大价值的来源是开源所解锁的协作和集体创新。虽然抽象的“开放”在 20 世纪被容忍，但只有“为协作而开放”才能满足 21 世纪的开源社区。无论是“开放核心”、“恐吓软件”、“延迟开放”、“仅向客户提供源代码”、“需要专利许可费”还是企业家们玩的许多其他游戏之一，在不实际允许协作的情况下，仅满足 OSD 或 FSD 的字面要求现在已经过时了。
因此，OSI 收到的社区成员关于“开放但封闭”的投诉比任何其他主题都多。所有规模的公司都大声宣扬他们对开源的热爱，但却对非客户保留源代码，这类咨询最多。当被联系时，OSI 代表社区联系这些公司，但回应始终是他们“在其权利范围内”，根据相关的开源许可证，可以随心所欲。
一个应该被彻底驳斥的说法是，向非客户保留开源代码是可以接受的。所有开源许可证都应被解释为要求向公众提供源代码。OSD 第 2 条非常明确：
2. 程序必须包含源代码，并且必须允许以源代码和编译形式分发。如果产品的某种形式没有与源代码一起分发，则必须有公开的方式以不超过合理的复制成本获取源代码，最好是通过互联网免费下载。源代码必须是程序员修改程序的首选形式。不允许故意混淆的源代码。不允许使用预处理器或翻译器的输出等中间形式。
有趣的是，相关公司通常根据开源许可证获得了他们正在商业化的源代码，而他们自己只拥有代码的很小一部分的版权。他们可以被认为已经圈占了公共资源，自己享受着开源的全部好处——并为此庆祝——但却阻止其他人以相同的条款进行协作。
如果不是因为公司声称是开源的坚定支持者，许多社区成员可能会容忍这种情况。即使这种行为，如果能向上游贡献代码，也可能会对某些人有所缓解。但在没有公共代码的情况下，大多数社区成员都质疑某些东西是否是开源的，无论使用何种许可证。“开放但封闭”在二十年前可能被容忍，但今天的规则是要么开放，要么闭嘴。
图片来源
“OpenClosedPost.png” ©开源倡议，2018年，知识共享署名-相同方式共享 3.0 未本地化版本，是“Paris – A Bicycle against an old wall – 4292.jpg”的衍生作品（添加了图形元素），©Jorge Royan（自己的作品），2008年，通过 维基共享资源 并根据 知识共享署名-相同方式共享 3.0 未本地化版本 许可获得许可使用。