The CRA uses a role-based and activity-based approach to open source. The most important questions are who is responsible for the product, whether it is supplied commercially, whether a legal person provides sustained stewardship support, and whether another manufacturer incorporates the software into its own commercial product.
Start With the CRA Definition of Free and Open-Source Software
Article 3 defines free and open-source software as software whose source code is openly shared and that is made available under a free and open-source licence granting rights to make the software freely accessible, usable, modifiable and redistributable. The definition matters because source visibility alone is not sufficient. A product that permits source inspection but restricts modification or redistribution may not qualify for the CRA's specific free and open-source treatment. Projects should therefore record the applicable licence and distribution terms before moving to the commercial-activity or organisational-role analysis.
- Source code must be openly shared.
- The software must use a qualifying free and open-source licence.
- Access and use rights are required.
- Modification and redistribution rights are required.
Open-Source Licensing Does Not Automatically Remove CRA Obligations
The CRA distinguishes how open-source software is developed and supplied rather than giving every product under an open-source licence the same regulatory treatment. A company can develop a product in public, accept community contributions and distribute the source under an open-source licence while still marketing the product under its own responsibility in a commercial context. In that situation the open-source development model does not necessarily displace the manufacturer role. Conversely, a community project supplied outside a commercial manufacturer relationship can occupy a different position. The regulatory analysis therefore needs to look beyond the licence label.
- Open source can coexist with commercial manufacture.
- Public development does not determine manufacturer status.
- Community development and commercial supply should be separated.
- Product responsibility is central.
Commercial Activity Is Assessed From the Actual Supply Context
Recital 18 explains that the way open-source development is financed should not by itself determine whether activity is commercial. The recital specifically indicates that financial support from manufacturers or manufacturer contributions to project development do not by themselves make the activity commercial. Regular software releases do not by themselves establish commercial activity either. This prevents ordinary open-source project practices from being converted automatically into commercial manufacturer status. At the same time, a manufacturer that actually monetises and markets a product cannot avoid its role merely because the product is distributed using an open-source licence.
- Funding alone does not decide commercial status.
- Corporate code contributions alone do not decide commercial status.
- Regular releases alone do not decide commercial status.
- Actual monetisation and market supply remain important.
Non-Profit Development Receives Specific Recognition
Recital 18 also addresses not-for-profit organisations. It explains that development of qualifying free and open-source products by not-for-profit organisations should not be considered commercial activity where the organisation is structured so that earnings remaining after costs are used to achieve not-for-profit objectives. This does not mean every organisation using the word foundation or non-profit automatically falls outside every CRA obligation. A legal person can still meet the separate open-source software steward definition, and a different entity can still act as manufacturer of a commercial downstream product. Organisational structure and actual role should therefore be analysed separately.
- The CRA recognises non-profit open-source development.
- Use of earnings for not-for-profit objectives is relevant.
- Non-profit status does not prevent possible steward status.
- Downstream commercial actors remain separate.
Individual Contributors Are Not Automatically Responsible for the Product
Recital 18 expressly recognises that natural or legal persons can contribute source code without having responsibility for the open-source product. The Regulation should not be read as making every person who submits a patch, pull request or source-code contribution into the manufacturer. Responsibility for the product needs to be established separately. A contributor might work for a manufacturer or steward in some situations, but contribution itself is not the legal test. Open-source projects should therefore distinguish ordinary contribution from governance authority, project ownership, sustained organisational support and commercial product responsibility.
- Source-code contribution alone does not create manufacturer status.
- Responsibility for the product is a separate question.
- Project governance can matter more than contribution volume.
- Employment or organisational relationships may require separate analysis.
A Manufacturer Can Commercialise Open-Source Software
The CRA manufacturer definition includes entities that develop or manufacture products with digital elements, or have them developed or manufactured, and market those products under their own name or trademark. Open-source software can fit that model when a company assumes responsibility for a product and supplies it commercially. The manufacturer then needs to consider the normal CRA obligations applying to that product, including cybersecurity risk assessment, product security requirements, vulnerability handling, technical documentation and conformity assessment. The fact that users are allowed to modify and redistribute the source does not transfer the manufacturer's responsibilities to upstream community contributors.
A Steward Is Different From a Commercial Manufacturer
The CRA created open-source software stewards precisely because some legal persons play a sustained and important role in project viability without acting as the manufacturer that markets the product. A qualifying steward supports specific free and open-source products intended for commercial activities and does so systematically and on a sustained basis. Article 24 gives that role a tailored set of cybersecurity-policy, vulnerability-handling, authority-cooperation and reporting obligations. A steward should not simply be treated as a manufacturer with fewer resources. The Regulation deliberately gives the two roles different legal definitions and different duties.
- Steward and manufacturer are separate roles.
- The steward regime is tailored to sustained upstream support.
- Article 24 contains steward-specific obligations.
- A legal person should determine which role actually fits its activities.
Open Repository Hosting Does Not Automatically Create Market Supply
Recital 20 explains that merely hosting products with digital elements on open repositories, including through package managers or collaboration platforms, does not by itself constitute making those products available on the market. This matters for public code-hosting services and open-source distribution infrastructure. Hosting can still be relevant to the separate steward analysis when it forms part of systematic sustained support for specific projects, but the act of repository hosting alone should not be treated as commercial distribution of every hosted project.
- Repository hosting alone is not automatic market supply.
- Package-manager hosting alone is not enough.
- Distribution in commercial activity requires a separate analysis.
- Hosting can still contribute to a wider stewardship role.
Downstream Commercial Use Creates a Separate Manufacturer Analysis
Open-source components are routinely incorporated into commercial products. The upstream component's regulatory position does not automatically determine the downstream product's position. A manufacturer that integrates third-party open-source software into its own product remains responsible for evaluating the cybersecurity effects of that dependency. Article 13 includes due diligence regarding components sourced from third parties. The manufacturer should therefore know which open-source components it uses, monitor relevant vulnerabilities and maintain evidence showing how those dependencies were assessed and maintained.
- Upstream and downstream roles are separate.
- Commercial integrators remain responsible for their products.
- Third-party component due diligence applies.
- Open-source dependencies should be tracked throughout support.
Use a Five-Step Open-Source CRA Test
A practical analysis can be performed in five stages. First, confirm that the software meets the CRA definition of free and open-source software. Second, identify the person or organisation responsible for the product. Third, examine whether the relevant development or supply is connected to commercial activity. Fourth, determine whether the entity acts as a manufacturer, an open-source software steward, an ordinary contributor or another actor. Fifth, identify any downstream commercial manufacturer integrating the component. This sequence prevents both over-regulation of ordinary contributors and under-classification of commercial open-source products.
- Confirm FOSS status.
- Identify product responsibility.
- Analyse commercial activity.
- Determine the legal role.
- Identify downstream commercial integration.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.