When Is Free and Open Source Software Outside CRA Manufacturer Obligations?

There Is No Blanket Open-Source Exemption

The CRA does not contain a rule saying that every product distributed under an open-source licence is exempt. Instead, the Regulation distinguishes non-commercial upstream development from commercial manufacturer activity and creates the separate open-source software steward role. The correct analysis therefore begins with the specific software and actor. A project can be outside the manufacturer-facing market regime while another organisation around the same codebase has Article 24 steward obligations and a downstream company has full manufacturer obligations for its own commercial product.

• Open-source licensing alone is not an exemption.
• Manufacturer status depends on responsibility and market activity.
• Steward obligations can exist separately.
• Downstream manufacturer obligations can also exist separately.

Non-Monetised FOSS Can Sit Outside Commercial Manufacturer Activity

Recital 18 provides one of the clearest protections for upstream FOSS. Qualifying free and open-source software that is not monetised by its manufacturer should not be considered to be supplied in the course of commercial activity for the relevant CRA market regime. This means an entity should not assume that publishing a maintained open-source project automatically activates the full manufacturer framework. The factual record should still identify the entity responsible for the software and confirm how the product is distributed and whether any monetisation occurs.

• Non-monetised qualifying FOSS receives specific treatment.
• Publication alone does not establish commercial supply.
• Product responsibility should still be identified.
• Monetisation arrangements should be documented.

Free of Charge and Non-Monetised Are Not Always the Same Thing

The CRA manufacturer definition can include products marketed free of charge, so the analysis should not simply ask whether users pay a download fee. Monetisation can exist through business models that are not a direct software purchase. For open-source software, Recital 18 focuses specifically on whether qualifying FOSS is monetised by its manufacturer. Projects should therefore examine the actual economic relationship around the product rather than using zero price as the only evidence. A company can offer software without a purchase price while still operating a commercial product model around it.

• Zero purchase price is not the complete test.
• The manufacturer definition can include free-of-charge products.
• FOSS monetisation should be assessed factually.
• Business models around the product can matter.

Ordinary Source-Code Contributors Can Be Outside the Regulation

Recital 18 expressly states that the Regulation does not apply to natural or legal persons who contribute source code to qualifying free and open-source products that are not under their responsibility. This protects ordinary collaborative contribution. A developer does not become the CRA manufacturer merely by submitting code, reviewing patches or participating in project development. The key qualification is responsibility for the product. Where a contributor also controls and markets a product under its own responsibility, a different analysis can apply.

• Source contribution alone does not create manufacturer status.
• The product must not be under the contributor's responsibility for this protection.
• Natural and legal persons can both be contributors.
• Other factual roles still need separate analysis.

Qualifying Non-Profit Development Can Be Non-Commercial

Recital 18 states 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 all earnings after costs are used to achieve not-for-profit objectives. This allows non-profit organisations to receive and manage money without automatically converting their upstream development into commercial manufacturer activity. The organisation should nevertheless document its structure, objectives and treatment of earnings if it relies on this distinction.

• Not-for-profit development has specific protection.
• Receiving income does not automatically defeat the protection.
• Earnings after costs must support not-for-profit objectives.
• Organisational evidence should be maintained.

Upstream FOSS Components Have Their Own Rule

For qualifying FOSS components intended for integration by other manufacturers into their own products with digital elements, Recital 18 provides that the component should be considered made available on the market only if monetised by its original manufacturer. A downstream company's commercial use therefore does not automatically impose the downstream company's manufacturer role on the upstream component project. This separation is essential to the CRA's treatment of open-source supply chains.

Downstream Manufacturers Are Not Exempt

The upstream protection does not remove obligations from a manufacturer that integrates FOSS into its own commercial product. The downstream manufacturer remains responsible for the product it places on the market and must exercise the required due diligence for third-party components. This prevents the open-source carve-out from becoming a loophole through which a commercial manufacturer could avoid responsibility merely because important parts of its product originated in community software.

• Upstream status does not control downstream manufacturer status.
• Commercial manufacturers retain responsibility for their own products.
• Third-party component due diligence remains relevant.
• Open-source dependencies should be tracked.

A Steward Can Be Outside Manufacturer Obligations but Still Inside the CRA

One of the most important distinctions is between being outside manufacturer obligations and being outside the CRA altogether. Article 3 defines an open-source software steward as a legal person other than a manufacturer that provides systematic sustained support for specific qualifying FOSS intended for commercial activities and ensures product viability. Article 24 then places tailored obligations on that steward. A qualifying foundation or other organisation can therefore avoid manufacturer classification while still having cybersecurity-policy, vulnerability-handling, cooperation and limited reporting responsibilities under the CRA.

• A steward is not a manufacturer.
• A steward is still a CRA-regulated role.
• Article 24 contains the tailored steward obligations.
• Outside manufacturer duties does not necessarily mean outside the CRA.

Repository Hosting Alone Does Not Create Manufacturer Obligations

Recital 20 provides another useful boundary. The sole act of hosting products with digital elements on open repositories, including package managers and collaboration platforms, does not itself constitute making the product available on the market. This prevents infrastructure providers from becoming manufacturers or distributors of every project they host merely because they provide repository services. Hosting can still be relevant to a broader steward role when combined with systematic sustained support for specific products.

• Repository hosting alone is not market supply.
• Package-manager hosting alone is not market supply.
• Collaboration-platform hosting alone is not enough.
• Broader sustained support can still require steward analysis.

Do Not Use 'Outside the CRA' as a Shortcut

Open-source projects should document their position using the narrowest accurate conclusion. If the entity is not acting as a manufacturer because the relevant FOSS activity is non-commercial, the record should say that the manufacturer obligations do not apply on that basis. It should then separately assess whether the organisation is an open-source software steward, whether it provides repository or distribution services with another economic-operator role and whether downstream manufacturers use the software. This avoids an overly broad statement that could become inaccurate as the project, funding or governance model changes.

• State which role or obligation is outside scope.
• Do not rely on a blanket exemption statement.
• Assess steward status separately.
• Assess downstream commercial use separately.
• Review the conclusion when the project changes.

Reassess When Monetisation or Responsibility Changes

A project that is non-commercial today can later adopt a monetisation model, move under a company trademark, acquire a responsible commercial vendor or become supported by an organisation meeting the steward definition. The CRA analysis should therefore be revisited when distribution, responsibility, funding structures or product governance materially change. The objective is not to classify the project's history once, but to determine the legal role that fits the current supply and governance model.

• New monetisation can change the analysis.
• A new responsible vendor can change the analysis.
• Governance changes can affect steward status.
• Role classification should be maintained over time.