An open-source software steward under the CRA is a legal person, other than a manufacturer, that systematically provides sustained support for developing specified free and open-source products intended for commercial activities and ensures their viability.
An individual maintainer acting personally is not a steward because the definition requires a legal person. When a manufacturer places free and open-source software on the market in commercial activity, the manufacturer rules apply rather than the lighter steward role.
Start with the entity, not the repository
Identify every legal person supporting the project. Record what each entity does, how long it has done it, which products the support covers, and whether it ensures their viability. Do not infer a steward from a logo, hosting page, employment affiliation, or one-time grant.
Then identify the party, if any, placing the software on the market under its name or trademark. A project can have individual maintainers, a supporting foundation, and commercial manufacturers at the same time, each with a different role.
Test the definition element by element
Create separate findings for legal-person status, systematic activity, sustained support, specified products, intended commercial activity, viability, and manufacturer status. Link each finding to source records and a reviewer. A broad “open-source organisation” label does not resolve any element.
Preserve contrary facts. Intermittent grants, infrastructure hosting, employment of maintainers, governance rights, release authority, and security coordination may point in different directions. Record the actual activity and period rather than choosing the most familiar description.
Map support to a specific product
Describe engineering work, release management, vulnerability coordination, infrastructure, governance, and funding separately. Link each activity to the particular free and open-source product it supports. The steward analysis is not automatically organisation-wide.
Preserve charters, agreements, governance records, and support decisions that substantiate the conclusion. Review changes in sponsorship or control instead of relying on a static label.
If several entities support one project, map each separately. One may be a steward, another a manufacturer for a commercial distribution, and individuals may continue as personal maintainers. Do not force the project to have a single universal role.
Assign reporting ownership after role analysis
Only after identifying the role should the organisation map Article 24 reporting, platform representation, user communication, and coordination with manufacturers. Keep the maintainer’s technical escalation route clear even when the legal steward owns submission.
If no steward exists, do not assign the obligation to an individual by convenience. Downstream manufacturers still need their own product-specific CRA analysis. Difficult governance structures deserve counsel review rather than a broad assumption that “open source” resolves the question.
Close the analysis with an effective date, decision owner, evidence index, reporting owner for each identified legal person, and reopening events. Governance changes, new commercial distributions, sustained support arrangements, or transfer of release control should trigger review without rewriting the earlier conclusion.
Continue this workflow with the steward-reporting boundary and the role-changing manufacturer test.