/
2024-09-06 Open source standards meetup

2024-09-06 Open source standards meetup

Open source standards meetup held at LF Energy Summit Europe 2024. Notes based off the flip-overs filled during the meeting.

Flipover 1

Definition

What do we define as 'open source standard'? Taking IETF as an example:

  • Patent free

  • Free of cost

  • No restrictions on use

Patents

'Patent free' might be achievable for new standards, but will be hard for existing standards and similarly existing areas of industry. There are ways of dealing with existing patents, like A) having a patent pool and B) having relevant patents be available under FRAND licensing terms. Especially in the energy sector patents might already exist. Some open source licenses have ways of addressing patents. For example CERN hardware license has a way of dealing with patents in a way quite similar to patent pooling. It is worth noting that EU is investigating into license pooling practices with regards to competition law.

Open source standards

Open standards should be be open from the beginning There has to be a community, collaboration and governance. Open source standards puts implications on both process and outcome.

How to deal with cost (effort) of creating and maintaining standards?

Standards can be created for new topics or for topics where already a standard exists. The latter brings the risk of license proliferation. Vendors would have to do more work to support more standards. Furthermore a government mandate could require certain standards, making it less likely the new standard would be adopted.

Flipover 2

Open source standards should bring the same freedoms/rights as open source software. Four freedoms of free and open source software: use, study, share, improve (modify).

What if an open source standard is modified, as that would be permitted? In that case it would no longer be the same standard, so allowing this is fine. As it is a different standard, it would have to use a different name. This could be enforced using trademark.

Standards should provide long-term guarantees. This requires 'perpetual development'. A paper 'perpetual development' has recommendations on perpetual development.

Collaborative standards development

Traceability would benefit standards development, as we are accustomed to in open source software development. Being able to see all individual changes and the discussion around them. Open source standards development could really benefit from distributed version control like git, although it should ideally be more usable as many people involved in the standards process are not accustomed to using git.

Do standards need to be documents, like pdf documents? Or could they be something else, like in a more code-like form? As standards are descriptions of best practices a document makes sense. Taking inspiration from API documentation, a strict protocol definition could be equal to a standard. Most standards already contain recommendations or a reference implementation that can help adoption. Such a reference implementation could be published as open source. It could be updated when the standard updates. Typically a reference will be used when available, so this can help adoption and bring uniformity in the working. Reference implementations do bring the risks of the reference implementation defining the standard in place where the standard is unclear. An alternative approach could be the way the IETF operates, by not sharing a reference implementation, but rather having interoperability meetings to discuss issues of compatibility and refine the standard where needed.

Where do we want to access standards? Ideally in an open space.

Flipover 3

Reach of a standard

What are goals of a standard? The main value of a standard differs among the people in the room:

  • Interoperability

  • Resilience (a reference document to fall back on when implementations disappear)

Standards should exist on the boundaries of use.

The field of application matters for the type of standard. ICT / communication standards as open source standards make sense for IT and OT applications, but could equally be open hardware references for hardware applications.

Reference implementations bring the risk of becoming the de-facto standard by making a decision on points where the standard is unclear.

Standards should only define the minimal required, leaving room for implementation decisions. Having standards describe requirements with Must, Should and Could can help to allow more space for implementation.

It would be good to have provenance of standards, so it is clear where parts of the standard originate from. We've come to expect this provenance from collaborative tools (e.g. Git/GitHub), which could be beneficial to standards as well. In the common principles of open source development could be implemented into standards

We need a 'standard of standards': a common way of developing standards according to open source principles.

Reference implementations and validations

LF Energy could provide reference implementations for standards. This is besides certification to verify correct implementation. Perhaps the reference implementations could be certified.

Suggestion of the book 'Networks of Power' about early electrification history.

Flipover 4

In practice there is a lack of interoperability and compliance in standards in the energy sector. LF Energy could 'lead the change' to improve the situation.

Reference validations are helpful too, besides reference implementations, as validations enable automatic validation of implementations.

There need to be guarantees on the software supply chain, including updates, to enable adoption. A support commitment by the community will help. What about the funding needed for these reference projects to guarantee development?

Inspiration can be drawn from the Open-o-meter, as a measure for how open hardware is https://doi.org/10.1016/j.procir.2018.08.306

Reproducibility is a key part of open source. This results in independence of vendor, tool, etc., which circles back around to resilience.

Moving forward

Dream outcome: A LF Energy whitepaper/one-paper with best practices It is not a new idea, but it would add the LF Energy stamp on it and it would be something to refer too. It could be complemented by marketing with numbers to highlight the value of this mode of operation.

Flipover 5

To summarize the plan of action:

  • Create a set of best practices for open source standards

  • Create a one-page whitepaper to highlight the best practices. This can help get buy-in and thus funding for reference software.

  • References implementations and validations can be created according ot these standards

A list of known issues and bugs in the current standardisation process to address in the best-practices will be helpful too. (see: 🔐Closed standards in the energy sector )

How to organize ourselves?

  • Slack channel: #standards

  • A repository somewhere to work on the best practices and one-pager

Nico will check with the SIG data standards and tooling to make sure there is no overlap, or otherwise there is a collaboration.

Once we have something substantial we can promote it on #general channel too, with a specific call to action: to list known problems that should be addressed in the open source standards best-practices.

Summary on open source standards: There is no clear definition or commonly agreed definition of open source standards yet. In general the idea would be to have open standards be developed to be more aligned with the way in which open source software and hardware is developed. This has implications for the process of developing standards (public, collaboratively, transparent) and the rights granted in the final standards, determining how they can be used in open source standards (think of the four freedoms of free software, open-o-meter for hardware). Patents are a special concern when it comes to permissions of using the standard.