“Open” is one of the most admired words in the tech world. It evokes freedom, inclusiveness, and innovation. By contrast, words like “Rules” sound like limits or restrictions.
But here’s the twist: when we celebrate openness, we often talk about freedom—but rarely about the rules that make that freedom sustainable. We celebrate the possibilities openness brings, but we don’t always ask:
How are these possibilities maintained? How do we keep openness from collapsing into chaos?
Take “open source” and “open standards” as examples, do they really mean unrestricted freedom? How do they remain collaborative and sustainable? How do we keep openness working at scale?
Let’s dig in.
Open Source: Freedom Lives in the License
In software development, “open source” doesn't mean “no rules.” It means the project is published under a specific open source license—a legal agreement that defines how the software can be used, modified, and shared.
These licenses typically clarify three things:
- Permissions – What you're allowed to do
- Conditions – What you must do to comply
- Limitations – What you’re not allowed to do
Here are a few common examples:
MIT License
- ✅ Permissions: Commercial use, modification, redistribution—even closed-source reuse
- 📌 Conditions: Must keep the original license and copyright notice
- ❌ Limitations: No warranties, no patent protection
Apache License 2.0
- ✅ Permissions: Commercial use, private use, modification, and patent use
- 📌 Conditions: Retain copyright notice and state modifications
- ❌ Limitations: No warranty; can’t use Apache trademarks
GNU GPL v3
- ✅ Permissions: Commercial use, redistribution, modification, private use, and patent use
- 📌 Conditions: Must publish source code, use the same license (copyleft), credit original authors, and declare modifications
- ❌ Limitations: No warranty; redistribution must remain open
These licenses don’t limit collaboration—they make it possible. They create trust, protect contributors, and provide a stable foundation for long-term development. That's what keeps open source projects structured, sustainable, and scalable.
Open Standards Depend on Consistency
Standards are not code. They’re data models, structures, classifications, or definitions. That’s why software licenses like MIT or GPL aren’t always suitable. Instead, most open standards use licenses like Creative Commons BY-ND 4.0.
Here’s what that means:
CC BY-ND 4.0 (Attribution-NoDerivatives)
- ✅ Permissions: Free to use and redistribute—including for commercial, educational, and implementation purposes
- 📌 Conditions: Must credit the original author and keep the content unchanged
- ❌ Limitations: No modifications, adaptations, or derivative works allowed; cannot repackage it as a new standard
In other words, open in open standards doesn’t mean anyone can freely rewrite or remix the content. It means everyone can use, implement, and participate in building around it, within a clear, transparent, and collaborative framework.
These restrictions aren’t about gatekeeping. They prevent fragmentation, misuse, or privatization of the standard. Only by protecting the consistency of shared structure and semantics, we could see the ture value of open standards as a reliable, transparent, universal foundations.
Why “Only One IFC” Matters
IFC is licensed under Creative Commons BY-ND 4.0.
As an open data standard, the true value of IFC lies in consistency and interoperability. It’s not just about being open—it’s about being usable, reliably, by everyone.
Now imagine what happens without that consistency:
- If anyone could modify IFC and rebrand it as “MY-IFC” or “YOUR-IFC”, how would systems still understand each other?
- If every work derived from IFC claimed to be IFC, how could we even agree on what we’re talking the same thing?
- As a developer or vendor, how would you support unknown, countless custom even conflicting versions?
- As a data owner, what happens if your data only work in one specific software tool that understands a particular tailored custom variation of IFC? Is that really open?
The result isn’t interoperability—it’s confusion and fragmentation.
We end up rebuilding silos, just with a different label.
Someone may argue:
- "It not fit in my region, my country, my working environment."
- "We need a local standard, we need to make adaptation."
- "We need put a name or a tag on it to prove it's suitable for the market."
But here’s the truth: adaptation is always possible—without breaking IFC’s core consistency and interoperability.
Whether it's national standards or industry extensions, all of these can work in collaboration with IFC through data dictionaries. You can reference industry-specific definitions, adopt local classification systems, or even use proprietary internal definitions within IFC via data dictionaries—these are things that happen every day on real-world projects.
Moreover, modifying the name or adding a new label violates the legal license of IFC (CC BY-ND 4.0 prohibits renaming or rebranding it as a new standard), and may also involve unauthorized use of registered trademarks.
The essence of an open standard lies in shared ownership and collaborative development—it belongs to the entire community.
So yes, IFC is open.
But it’s open within one clear rule—only one IFC.
Only when you can open any IFC file, access the data smoothly, without needing to know who made it, what software was used, or where it came from, that’s when open truly values.