What Does Commercial Activity Mean for Open Source Software Under the CRA?

The CRA Separates Development From Commercial Supply

Recital 18 draws an important distinction between development of free and open-source software and the supply of that software in the course of commercial activity. Open-source projects are often developed publicly with contributions from individuals, companies, foundations and other organisations. Those development circumstances do not themselves determine whether the resulting product is being commercially supplied. The commercial analysis should focus on the actual market relationship around the product rather than assuming that professional development, corporate participation or organised project governance automatically makes the software commercial.

• Development activity is not automatically commercial supply.
• Professional development alone is not decisive.
• Corporate participation alone is not decisive.
• The actual supply and monetisation context should be examined.

How Development Is Financed Does Not Decide Commercial Status

The CRA expressly states that the circumstances under which a product was developed or the way development was financed should not determine whether the activity is commercial or non-commercial. This matters because many major open-source projects receive grants, donations, sponsorship, employee time or infrastructure from commercial organisations. A project should not classify itself as commercial merely because money supports its development. At the same time, financing cannot be used to obscure an actual commercial supply arrangement. Funding and supply therefore need to be documented separately.

• Development financing is not the commercial-activity test.
• Grants do not automatically establish commercial activity.
• Sponsorship does not automatically establish commercial activity.
• Commercial supply should be analysed separately from project financing.

Manufacturer Financial Support Does Not by Itself Make the Project Commercial

Recital 18 specifically addresses financial support from manufacturers. The mere fact that manufacturers financially support an open-source product does not by itself determine that the upstream activity is commercial. This protects common open-source funding models where companies contribute money because they depend on a project but do not become the original manufacturer of that project merely through funding. The project should still record the relationship, because regular financial assistance can become relevant to the separate steward analysis in Recital 19 when evaluating whether supported software is ultimately intended for integration into monetised products.

• Manufacturer funding alone does not establish commercial activity.
• Funding does not automatically transfer product responsibility.
• The funding relationship should still be documented.
• Regular downstream support can be relevant to steward analysis.

Corporate Code Contributions Do Not by Themselves Make the Project Commercial

The CRA applies the same principle to development contributions. Manufacturers can contribute code, engineering effort or other development resources to an open-source project without making the upstream project commercial solely because of those contributions. A project with many corporate contributors can therefore remain outside the manufacturer-facing commercial supply analysis if the other conditions point away from commercial activity. The relevant question remains whether the product itself is monetised and supplied on the market by the responsible manufacturer, not simply who contributed to its codebase.

• Corporate contributors do not automatically commercialise the upstream project.
• Contribution volume alone is not the legal test.
• Product responsibility remains separate.
• Actual monetisation remains important.

Regular Releases Do Not Create Commercial Activity by Themselves

Open-source projects often publish predictable releases, security updates and maintenance versions. Recital 18 expressly states that the mere presence of regular releases should not by itself lead to the conclusion that a product is supplied in the course of commercial activity. Release discipline therefore should not be treated as evidence that a volunteer or community project has become a commercial vendor. This is important for cybersecurity because the CRA should not create an incentive for open-source projects to release less frequently merely to avoid appearing commercial.

• Regular releases alone are not commercial activity.
• Security releases do not create manufacturer status by themselves.
• Maintenance cadence is not the same as market supply.
• Projects should continue responsible release practices.

Non-Monetised FOSS Is Treated Differently

Recital 18 states that, for economic operators within the relevant CRA market framework, the provision of qualifying free and open-source products that are not monetised by their manufacturers should not be considered commercial activity. This is a more specific rule than simply asking whether the software is available free of charge. Manufacturer status and monetisation still require factual analysis, but the recital makes clear that the CRA does not intend ordinary non-monetised FOSS distribution to be treated in the same way as commercial product supply.

Open-Source Components Have a Specific Monetisation Rule

Recital 18 also addresses qualifying FOSS components supplied for integration by other manufacturers into their own products with digital elements. Such a component should be considered made available on the market only if it is monetised by its original manufacturer. This protects upstream component development from becoming commercial market supply merely because downstream companies use the component commercially. The downstream manufacturer remains responsible for its own product and must perform the CRA due diligence required for third-party components.

• The rule specifically addresses FOSS components.
• Downstream commercial integration does not automatically commercialise the upstream component.
• Original-manufacturer monetisation is important.
• The downstream manufacturer still has its own CRA obligations.

Not-for-Profit Development Receives Specific Protection

Recital 18 provides 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 remaining after costs are used to achieve not-for-profit objectives. The rule focuses on organisational structure and use of earnings rather than merely the presence of income. A non-profit organisation can therefore receive funds and still conduct non-commercial FOSS development under this recital when the relevant conditions are met.

• Non-profit organisations can receive income.
• Use of earnings after costs is relevant.
• The organisation's structure matters.
• Non-profit development is distinct from commercial manufacturer activity.

Commercial Activity and Steward Commercial Intention Are Different Questions

A subtle but important distinction exists between Recital 18 and the open-source software steward regime. An upstream project can be published without being made available on the market as commercial supply, while a legal person supporting that project can still qualify as a steward because the supported software is ultimately intended for commercial activities. Recital 19 gives integration into commercial services or monetised products as examples. Regular contributions or regular financial assistance from downstream manufacturers can also help establish that intended commercial ecosystem for the steward analysis. The commercial-activity test for manufacturer-facing market supply should therefore not be collapsed into the separate steward test.

• Manufacturer commercial activity and steward commercial intention are different tests.
• A non-commercial upstream project can still have a steward.
• Commercial downstream integration can be relevant to stewardship.
• Document the two analyses separately.

Use Evidence Rather Than a Single Funding Label

A practical commercial-activity assessment should record the software product, licence, responsible entity, distribution model, monetisation arrangements, downstream integrations, funding sources and use of project income. It should separately identify sponsorship, grants, corporate engineering contributions and recurring releases so that those factors are not mistakenly treated as proof of commercial activity. Where a manufacturer monetises the software or component, the record should describe how. Where the activity is treated as non-commercial under Recital 18, the reasons should be recorded in a reproducible way.

• Record actual monetisation.
• Record funding separately.
• Record downstream commercial relationships.
• Record organisational structure where non-profit treatment is relevant.
• Document why the activity is commercial or non-commercial.