/
2025-09-10 Standard and Open Source Meetup

2025-09-10 Standard and Open Source Meetup

Schedule: https://events.linuxfoundation.org/lfenergysummit-europe/program/schedule/

Last year we discussed many aspects of standards with regards to open source. From it came the idea to list best-practices for standards development. In preparation for this list we already collected some known issues in current standards development in 🔐Closed standards in the energy sector . Lets use this meeting to continue our effort and work towards a set of best-practices, or rather a description of the change we wish to see.

Agenda

Notes

Intro

  • Address standard setting

    • Align with other efforts in LF, like OpenChain

    • Speed of standard development might not align with Energy sector

    • IT vs OT based

    • Reference implementations for adoption

    • Engage businesses

    • To be taken seriously by standardization body

    • Process for IEC/ISO JTC1: what is the motivation? Adoption?

    • Standard of OpenADR, implemented in OpenLEADER. Could be interesting to follow how the standard will be formalized.

  • Introduction round

    • IT standards more compatible to open source then OT standards.

    • Creating product requires meeting a whole set of spread out standards.

    • Reading code as a less costly method to study the standard.

    • IEC IP policy is not written for open source software.

  • Standardization

    • Difference between newly drafted standard vs existing standards.

    • IEC: as purchaser of the standard you are allowed to sell directly or via distributor.

    • Hardly a need for the standard if there is an open source reference and a conformance suite.

    • To what extend is it mandated by the government? If required by law, it should be public, also based on lawsuit in Europe about toy safety.

    • That leaves the standards for industry internal to the industry. That could be viewed as a barrier of entry to the market.

    • Business model alternative is a membership where members pay for privileges and with their fees support development.

      • IETF explicitly has no formal structure.

      • W3C is a corporate in Switzerland, with a membership fee.

    • What is a reasonable fee for a standards document? The open source implementation makes the standards document redundant.

    • Others (e.g. Chronos Group) build implementations, not standards.

    • IEC 61850 created in '95, bridge of EU en US efforts. Conformance tests done by UCA. Some companies allowed to certify implementations based on UCA conformance tests.

    • Chronos Group: you run the tests with bug reports and have to pay for certification.

    • Idea of three income streams:

      • Contributors of the standards (membership)

      • Adopter of the standard

      • Supplier agreement

    • USB, HDMI are corporate standard, where you pay for the logo. That might be more similar to the energy sector.

    • MPEG group as another.

    • Costs in Energy: safety and security.

    • IEC does not work with membership but via national standardization bodies.

    • IEC and patents, say you’d want to create a competing standard? Contributors agree to disclose all relevant patents and participate in FRAND licensing of patents.

    • Case of HDMI (or SD-card): could you create a compatible implementation without logo? Yes in EU, probably not US. But in energy OT applications you deal with liability and conformity agreements.

    • Scenario of an open implementation from which the standard can be deduced (reverse-engineered).

    • Case of GPL licensed library for which licenses are sold.

    • IEC 61850 is one of the most sold standards.

  • What would we like to see changed in the standardization process?

    • Business model of standardization bodies.

      • Could still be fine if standards documents and conformance tests are sold.

      • If not changed, it could still be fine. Just implementing a library is not enough because a library doesn’t provide involvement, and still conformance testing needed.

      • It is the open source play: by opening up you make an bigger ocean: more users of the standards, can involve in more standards sales.

      • Code components of TC57 helps as public availability of the machine-readable files like protocol definitions.

    • Legal certainty on being allowed to publish open source implementations.

      • Now in contact IEC there is confusion about legal status. That needs to be solved.

      • LF Energy could be the host for open source reference implementations.

      • The standard can be implemented in test code, eventually becoming a conformance test suite. Then still a certification body should do the certification (transfer of liability).

    • For new standards that are adopted (via JTC1) mandate that the standards are available as open standards.

  • How to address it