规则定义开放 - 有且只有一个IFC

作者：buildingSMART 中国

“开放”总让人联想到自由、包容、创新，是技术世界里最令人向往的词汇之一。

相较之下，“规矩”“限制”听起来似乎总带点保守和压抑的意味。

但有趣的是，我们谈论“开放”时，常常只讲自由，却很少提规则。我们推崇开放带来的各种可能性，却很少追问：

这种可能性是怎样被维护的？怎么防止开放演变成混乱？

像是“开源软件”和“开放标准”，它们真的意味着无限自由吗？它们之所以能开放协作、持续发展，又靠的是什么？

开放还是开源？

在中文语境中，“开放标准”和“开源软件”经常被混用，但它们实际上是两个不同的概念：

开放标准（Open Standard）

指任何人都可以免费获取、实现和参与的标准，强调互操作性和共识。如 HTTP、HTML、USB、IFC。

开源软件（Open Source Software）

指源代码公开、可自由使用、修改和分发的软件项目，如 Linux、Blender、FreeCAD。

⚠️ 需要注意的是：“ 开源标准 ” 这个说法是误用，没有明确的英文对等表达，通常来自于把“开放标准”或“开源软件”混为一谈， 不推荐使用。

开源的自由写在协议里

在软件开发领域，提到“开源”，人们通常指的是使用了某种开源许可协议的软件项目。这不代表无条件的开放，而是建立在明确许可协议上的法律定义。通常都围绕着三个基本要素进行定义：

Permissions （权限）：允许做什么

Conditions （条件）：需要遵守什么

Limitations （限制）：禁止做什么

例如最常见的几种：

MIT License

✅权限：允许商用、修改、分发，甚至闭源再利用

📌条件：只需保留原作者的版权声明和许可条款

❌限制：项目默认不附带任何担保，且无专利保障

Apache License 2.0

✅权限：允许商业使用、分发、修改、私用、且允许专利使用

📌条件：要求保留版权声明，并注明修改内容

❌限制：无担保责任，不得使用 Apache 商标

GNU GPL v3

✅权限：允许商业使用、分发、修改、私用、且允许专利使用

📌条件：开源源代码、相同协议下分发、保留版权声明、声明修改内容

❌限制：无担保责任，不可闭源再分发

详见： https://opensource.org/licenses

可以看到，这些协议并不是在设限，而是在为开源生态设定边界和协作规则。不同项目会根据自己的社区目标和使用场景，选择合适的协议来发布代码。协议越清晰，社区参与者就越能信任项目、贡献力量，也更容易在法律上保护自己的劳动成果。

而这些规则，恰恰是让开源变得 可持续、可协作、可共建 的基石。

开放标准靠的则是一致性

标准不是代码。它们是数据模型、结构、分类或定义。这就是为什么软件用的 MIT 或 GPL 许可证并不总适用于标准。大多数开放标准采用的是像 Creative Commons BY-ND 4.0 这样的许可证。

开放不仅仅是“公开”，更强调 结构的可访问性、语义的一致性、生态的可参与性。这对于标准来说尤其重要。

CC BY-ND 4.0 （署名-禁止演绎）

✅权限：允许自由传播、可再分发（包括商业用途），可用于教学、文档、标准实现

📌条件：必须署名原作者、保留原始出处

❌限制：不允许任何形式的修改、演绎或衍生版本，不可重命名再包装为新标准