Challenges in Using IEC Standards in Open Source – Nico Rikken, Alliander
Event Recap: LF Energy Summit Europe 2025
TL;DR
At LF Energy Summit Europe 2025, Nico Rikken (Alliander) examined the challenges open source projects can face when working with IEC standards. Drawing from his experience supporting open source projects at Alliander, Rikken discussed access barriers, licensing uncertainty around published IEC code components, incomplete code components and version inconsistencies, and the difficulty of explaining open source software conventions within standardization processes.
Watch the full presentation:
https://youtu.be/HsB0jnAl8QQ?si=WT2D1xVpUdu6Ijov
Presentation Overview
Rikken opened by describing his work in Alliander’s open source program office and his background in electrical engineering, development platforms, home energy management systems, smart meter data, and microgrids. Through this work, he has interacted with several IEC standards used in the energy sector, including IEC 61850 and CGMES.
He emphasized that standardization is crucial for interoperability in energy systems, particularly as the energy transition requires many different actors to participate. Standards can support independence, collaboration, and testability, which is why open source projects often need to implement them.
The first challenge Rikken highlighted is that IEC standards documents are not publicly available. Using IEC 61850 as an example, he stated that access to the full set of standards costs approximately €26,000. While large organizations may be able to provide access to employees, this creates barriers for open source contributors such as hobbyist engineers, retired professionals, or users who want to investigate an issue but no longer have access to the standard.
He also noted that even within organizations that do have access, retrieving standards can be cumbersome. As a result, some developers may rely on online libraries or existing source code instead, which can risk copying mistakes from prior implementations.
Protocol Licensing and Open Source Compatibility
Rikken then focused on published IEC code components, such as XSD files used to implement IEC 61850. He explained that these files are often needed verbatim when implementing a protocol, because fields, abbreviations, and structures must match the standard.
He credited IEC TC57 for publishing code components publicly, but stated that the associated license creates uncertainty for open source implementation. In his reading, the license resembles a BSD-style license in some respects, but restricts modification to what the standard or IEC clarifications permit. Rikken compared this with the Open Source Definition, which requires the ability to modify and create derivative works without such restrictions.
He also described uncertainty around redistribution. According to Rikken, responses he received through IEC and national standardization channels suggested that redistribution of light code components requires a commercial license. At the same time, open source lawyers he referenced questioned whether protocol definitions themselves are copyrightable in the same way as creative works.
Rikken framed this ambiguity as a practical problem for open source projects. Organizations with legal support may be able to assess and accept risk, but individual contributors or smaller projects may receive unclear or discouraging guidance.
Incomplete and Inconsistent Code Components
Another challenge described during the session was that publicly available code components are not always complete. Rikken gave an example involving an NSD file containing abbreviations needed for IEC 61850. In his example, the abbreviations are important because software can use them to present users with full text definitions from the standard.
He then described a workaround used in the OpenSCD project: a “bring your own files” approach, where users supply the required standard files themselves. However, this introduced another issue. Depending on where users obtained the files, they received different versions.
Rikken described a case in which software developers had one version of a file, while a user obtained a later version through IEC. Differences between those files caused validation issues in the user interface, leading to a GitHub discussion about why the software did not work. He said attempts to retrieve older versions through the national standardization body were unsuccessful, leaving developers unable to reproduce the exact file set.
Explaining Open Source Requirements
Rikken also addressed the challenge of communicating these issues to standardization bodies. He said discussions often pass through marketing, sales, legal, and committee structures, while many assumptions still appear to be shaped by proprietary software conventions.
In his view, open source software has different practices around access, redistribution, modification, reproducibility, and collaborative development. Explaining those requirements in the context of standards can be difficult when decision-making authority is distributed across multiple groups.
What Openness Can Enable
To show what more open access can make possible, Rikken pointed to what he described as the CGMES model published under an Apache 2.0 license. He said that although the model was still available in a proprietary format, Netbeheer Nederland, the Dutch association of grid operators, used it to create a linked data model with LinkML.
According to Rikken, this made the model easier to extend, generate validation tooling from, publish as web documentation, and experiment with. He presented this as an example of how open source can help make standards easier to understand, implement, and adopt.
Rikken also cited policy discussions in the United States and European Union that recognize the growing relationship between standards, open data, and open source software. He encouraged organizations to participate in public consultations and make clear that open source implementation matters for modern standards development.
Recommendations and Call to Action
Rikken closed by summarizing several areas where progress would help open source projects work more effectively with standards.
These included clearer legal guarantees for open source implementations, support for open source reference implementations, and maintaining openness when existing open standards are submitted into formal standardization processes. He also argued that reference implementations and sandboxes can make standards easier to test, adopt, and improve.
His final call to action was to speak up: document cases where standards create barriers for open source implementation, contact standardization bodies directly, and participate in consultations when possible.
Watch the full presentation:
https://youtu.be/HsB0jnAl8QQ?si=WT2D1xVpUdu6Ijov
FAQ
What was the session about?
The session examined challenges that open source projects encounter when using IEC standards, including access barriers, licensing uncertainty around published IEC code components, incomplete or missing code components, version inconsistencies, and communication challenges with standardization bodies.
Why are standards important for open source energy projects?
Rikken emphasized that standards are crucial for interoperability, independence, collaboration, and testability in energy systems.
What access challenge did the speaker describe?
Rikken stated that IEC standards documents are not publicly available and used IEC 61850 as an example, noting that access to the full set costs approximately €26,000.
What licensing issue was discussed?
The session discussed uncertainty around whether published IEC code components can be redistributed or modified in ways that are compatible with open source software licenses.
What example did the speaker give of version inconsistency?
Rikken described a case where software developers and users obtained different versions of a required standard file, causing validation problems in an open source project.
What did the speaker recommend?
He encouraged clearer legal guarantees for open source implementations, more open source reference implementations, preservation of openness in standards processes, and broader participation in standards consultations.
About LF Energy
LF Energy is an open source foundation within the Linux Foundation focused on advancing collaboration in digital energy infrastructure.
Learn more: https://lfenergy.org
Last updated: May 1, 2026
AI Disclosure
This post used artificial intelligence tools for research, structural assistance, or grammatical refinement. The final content was reviewed, edited, and validated by human contributors to LF Energy to ensure accuracy and alignment with our community standards. We remain committed to transparency in the use of generative technologies within the open source ecosystem.
