Barry O’Donovan: the CRA role changes by product

Summary

The CRA’s open-source rules turn on how a specific product is supplied and supported. Barry O’Donovan says one organization can be a steward for a free product and a manufacturer for a paid edition.
A nonprofit label does not settle that question. Operators still need a product-level inventory, a vulnerability contact and a clear patch path.

A nonprofit can publish open code and sell a richer edition. The CRA may treat those products differently. That is Barry O’Donovan’s practical reading of the law: the role follows the product, not the organization’s nameplate.

O’Donovan, INEX’s lead developer of IXP Manager, made the case at RIPE 93 in a talk about software supply chains. He put the operator’s question plainly: when an exchange or network relies on open-source software, what security work can it expect from the project that supplies it?

The European Commission’s current guidance draws two separate lines. A manufacturer that places an open-source product on the market carries the manufacturer obligations. A legal person that does not place the product on the market but gives sustained, systematic support to a specific open-source product intended for commercial activity may qualify as an open-source software steward. That steward role brings a cybersecurity policy, vulnerability handling and cooperation with market-surveillance authorities.

O’Donovan used a familiar split: a project gives away its open version, then sells a version with extra features. In his account, the organization can be a steward for the open version and a manufacturer for the paid one. The Commission’s wording also points to specific products and their supply. This is a more useful unit of analysis than stamping one permanent CRA label on a foundation, company or development team.

The law puts limits on sweeping assumptions. The mere fact that a project receives company funding, accepts contributions or publishes regular releases does not by itself make its software commercial. The regulation also says that open-source development by a nonprofit is not a commercial activity when the organization uses all earnings after costs for its nonprofit purposes. Price, responsibility for the product, sustained support and the intended use all matter together.

O’Donovan offered IXP Manager as a working example. He said INEX considers the project to fit the steward category and had published secure-development and vulnerability-disclosure policies after other exchanges asked for supply-chain evidence. He also described INEX as nonprofit while charging for exchange ports. That is his operational interpretation, not a regulator’s classification of IXP Manager. The public rule still turns on the product and the organization’s actual role.

For operators already covered by NIS2, upstream labels do not replace their own supply-chain work. Article 21 calls for supply-chain security and security in acquisition, development and maintenance, including vulnerability handling and disclosure. O’Donovan’s advice was concrete: keep a software inventory, track vulnerabilities and maintain a timely patch policy.

At the question line, he expected the easy cases to be clear and the grey area to reach courts. That leaves a practical test for every product an operator depends on: who controls releases, who receives vulnerability reports, who can issue a fix, and which edition is being supplied? A project’s legal role can change when its product or business model changes. An inventory that records only the organization’s name will miss the switch.