Decision guide

Commercial IEC 61850 SDK vs open source: what you are actually buying

2026-10-29 · 9 min read

Every team building a 61850 device reaches the same fork: take an open-source stack and own it, or license a commercial one and own the product instead. Both get a report published in a lab. The differences that decide the project appear later — at type approval, on a non-Linux target, and the first time a third-party master sends something the standard allows but your implementation never saw.

The two options, stated fairly

The best-known open-source option is libiec61850, published under GPLv3 with commercial licences available from its maintainer. It is well written, widely used in research and teaching, and it has genuinely lowered the barrier to building a 61850 device. If your product ships as a service, runs on Linux, and never faces a formal conformance test, it may be all you need.

Commercial stacks — ours included — cost money up front and are usually delivered with source under a per-project licence. The honest question is not which one is better in general, but which risks you are equipped to carry.

Where open source is the right answer

Be clear about this, because pretending otherwise wastes your time:

• The device runs Linux on x86 or ARM, and will for its whole life.
• Your customer accepts a self-declared test report rather than an independent one.
• You have an engineer who can read the stack and will still be there in three years.
• GPLv3 obligations are compatible with how you distribute the product — or you buy the commercial licence from the maintainer, which is a perfectly reasonable path.

Where the open-source route stops paying

These are the four places we see teams arrive, usually nine to eighteen months into a project.

• Targets that are not Linux. VxWorks, bare metal and older RTOS ports are where a stack written for POSIX starts costing weeks. A relay platform chosen in 2019 may not be negotiable.
• Edition 2 depth. Basic MMS read/write/reporting is one thing; reservation, report ownership, and configured-versus-creatable dataset limits are another. If the master station exercises them, you find out during acceptance.
• Evidence. When the buyer is a utility or a tier-one vendor, "we ran the open-source tests" is not an artefact they can file. A clause-level report with the raw byte stream is.
• The bad day. A third-party master behaves in a way the standard permits but your stack never handled. With source you can patch it — and now you are maintaining a fork of a project you did not write, on a schedule set by a customer, with nobody to escalate to.

A comparison on the dimensions that matter

What the licence fee actually covers

It is rarely the code. You are paying for the years of field deviations already absorbed into the implementation, for ports that exist rather than ports you have to write, for the tooling around the stack (ICD configuration, model-to-device data mapping, point tables), and for the fact that when a customer escalates at 2 a.m., there is a named engineer who has seen it before.

Our own model is per-project source licensing with royalty-free redistribution inside your product line. We say that plainly because the alternative — per-unit royalties — changes the economics of a device that ships in thousands.

How to decide in one meeting

Ask three questions and write the answers down:

• Which targets must this run on for the next ten years? If the list contains anything other than Linux, price the port before you pick a stack.
• What artefact does the customer accept as proof? If it is a clause-level report, the stack must be able to produce one — and someone must be able to defend it.
• Who maintains it after the integration engineer leaves? A fork with one maintainer is a single point of failure that does not appear in any risk register.

Ten questions to ask any 61850 vendor

These apply equally to us. If a vendor cannot answer them with specifics rather than adjectives, that is the answer.

• Which editions are supported, and which services are not?
• Source or binary, and what does the licence allow in our own product line?
• Which CPU and OS combinations are actually tested, not merely "supported"?
• How are GOOSE and SV timing handled — kernel bypass, dedicated thread, or best effort?
• What happens when a third-party device deviates from the standard?
• Can you give us a clause-level conformance report for our device after integration?
• Is the SCL tooling included, or is it a separate product?
• What is the support channel, in which language, in which time zone?
• What is the escalation path when a customer site is down?
• What does the licence cost at 1×, 10× and 100× our current volume?

Questions that come up

Is an open-source stack legally usable in a commercial device?

That depends on the licence and on how you distribute the product. libiec61850 is GPLv3, which imposes obligations on distribution; its maintainer also offers commercial licences. Read the licence, and involve whoever signs off on legal risk — this article is about engineering trade-offs, not legal advice.

Can we start with open source and switch later?

Yes, and many teams do. The cost of switching is concentrated in the SCL model handling and the API surface, not in your application logic, provided you kept the model files and the data-mapping layer separate from the protocol calls.

How long does integration actually take?

For a conventional protection or measurement device whose data model is already defined, our published figure is one to two weeks using the ICD tooling and the mapping table. Devices with unusual models or multiple downstream protocols take longer, and anyone quoting you a fixed number without seeing the ICD is guessing.

Keep reading