03/10 edition: an open-source steward is not a manufacturer

The licence does not populate the organisation chart

This edition addresses open-source project owners, manufacturers incorporating their code and legal teams. It asks who receives security information when the same code crosses a project, development infrastructure and a commercial product. It reports neither an actual dispute nor a 3 October event.

The Commission's open-source page distinguishes manufacturers placing products on the market from legal persons providing sustained support for the development and viability of specific open-source products intended for commercial activities, as stewards. An open licence alone does not decide which relationship exists. Applying this to a particular entity requires examining its activity.

A tailored regime, not a smaller manufacturer

Article24 provides for a documented cybersecurity policy and cooperation framework for stewards. It should not be summarised as 'every manufacturer obligation, but with fewer resources'. Responsibility relates to the specific role defined by the regulation.

In paragraph3, the reference to Article14(1) applies insofar as the steward is involved in development; references to Article14(3) and (8) relate to severe incidents affecting networks and systems provided for that development. These qualifications prevent treating every incident in every derived product as a universal, identical steward duty.

Do not align different calendars

Article71 distinguishes general application on 11 December 2027 from Article14 application on 11 September 2026. The Commission's reporting page clarifies that steward obligations under Article24(3) apply from 11 December 2027. Do not convert the manufacturer date into an early start for the entire steward regime.

Velqory's proposed preparation can begin earlier: map contacts, infrastructure and information handover. That is voluntary organisation within this proposal, not proof that a foundation already has every Article24 duty in October. Keep the date and cross-reference beside the conclusion.

Hand over information without transferring the role

This original, untested matrix aims to prevent 'we notified the project' from meaning 'we addressed the sold release'. The commercial product owner should understand its distribution; the project's contact should know what information can be received safely.

The upstream patch did not update the product

Hypothetical scenario: a project publishes a fix, but a manufacturer still distributes a product incorporating the previous revision. Information handover needs two recipients: whoever maintains the project and whoever can change the commercial release. Do not invent that either is automatically a steward.

The proposed exercise asks both sides to identify the revision used, secure contact channel and owner of the next decision. It fails if the manufacturer closes the matter solely because a project commit exists. It passes if the dependency is linked to a release and an assigned task, without asserting effectiveness of an unverified update.

An open relationship needs clear boundaries

Velqory recommends a small operational agreement on contact, sensitive information and follow-up, without turning cooperation into a fictitious transfer of responsibility. Avoid requiring volunteers to make statements about third-party products they cannot know.

Retain role classification and review changes in marketing, entity or support provided. A single ecosystem may include different activities; one repository label cannot replace that analysis. The useful outcome is knowing who can answer each question, which duty is not yet applicable and which preparation was voluntarily undertaken.