规则定义开放 - 有且只有一个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 （署名-禁止演绎）

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

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

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

详见： https://creativecommons.org

开放标准的“开放”，并 不允许任何人随意修改或改造它的内容，而是指它向所有人开放使用、实现与共同建设的权利。这种开放建立在正式、透明、协作的机制之上，目的不是限制参与，而是 防止标准被割裂、滥用或私有化。唯有在保护原有结构与语义一致性的前提下，开放标准才能真正发挥作为通用基础的价值。

为什么“只有一个IFC”如此重要

IFC 采用 CC BY-ND 4.0 许可证发布。

作为一个 跨软件、跨行业、跨地区的国际开放数据标准， IFC 的核心价值在于其一致性与互操作性。

试想一下，如果没有一致性会发生什么：

如果每个人都能修改 IFC 并重新命名为“MY-IFC”、“YOUR-IFC”，在无法互相理解各说各话的情况下，不同系统之间还如何理解彼此？

如果每一个基于 IFC 的衍生版本都自称是 IFC，我们又如何能确信彼此谈论的是同一个东西？

对于软件公司或者开发者，该遵循哪个版本？你又该如何支持无数个未知的、甚至相互冲突的自定义版本？

对于数据的拥有者来说，你必须购买某款特定软件，才能打开使用某个定制版 IFC 的数据——那么你拥有的，真的还算是开放和自由吗？

这并不会带来真正的互操作性，只会有更多的混乱与割裂。

我们最终只是换了一个名字，又重新筑起了信息孤岛。

所以，只有我们保证 IFC

不出现衍生版本破坏互操作性；

不被包装为所谓“本地标准”用于私有化；

且保障所有使用者对 “IFC 是什么” 的共识不被随意篡改。

开放标准才有更大的价值和意义。

可能依旧有人会说：

“IFC 不适合我们这个地区、我们国家、我们的工作环境。”

“我们需要一个本地标准，我们需要做出适应。”

“我们得给它加个名字或标签，来证明它符合市场需求。”

但事实是：IFC 是可以兼容不同需求的。

无论是国家标准、行业扩展，还是企业的需求，都可以通过数据字典与IFC协作。 你可以通过数据字典在IFC中引用行业扩展定义、使用本地分类体系，甚至公司内部专有的定义，这些都是在真实项目中每天在发生的事情。

此外， 修改名称或者添加标签也违反了IFC的法律许可 （CC BY-ND 4.0 不可重命名再包装为新标准），还可能涉及对注册商标的侵权使用。

开放标准的本质在于共享和共建， 它属于整个社区。

当然，如果你确实遇到 IFC 的某些局限，或者你希望和整个行业一起推动标准的未来，这扇门始终是敞开的。欢迎你联系 buildingSMART，共同参与并塑造未来版本的标准。

最后：有且只有一个IFC

就像你随手抓起的一根Type-C的充电线，不用去思考是什么品牌，哪家厂商制作的，在哪儿生产的，它就可以为你的手机充电。

只有当你打开任何一个IFC文件，不需要知道它由谁创建、用什么软件制作、来自哪个国家或者地区，就能顺利和数据交互的时候。

这，才是我们所理解、所追求的开放。

顺带一提

留言板也一直开着，如果你对开放标准和IFC有任何问题，也欢迎在留言板交流提问。