Donations, Sponsorship and Commercial Activity Under the CRA

Funding Does Not by Itself Decide Whether FOSS Is Commercial

Recital 18 deliberately separates how free and open-source software is developed from how it is supplied. The circumstances of development and the way development is financed should not be used by themselves to determine whether the activity is commercial. This distinction is important because open-source software can receive money from individuals, foundations, public programmes and commercial companies while still being developed and supplied through a non-commercial upstream model. A project should therefore avoid classifying itself solely from the fact that money changes hands somewhere in its ecosystem.

• Development funding is not the complete commercial-activity test.
• Receiving money does not automatically mean commercial supply.
• Product monetisation should be analysed separately.
• Responsibility for the supplied product should also be identified.

Donations Do Not Automatically Create Commercial Activity

A donation generally supports a project without necessarily purchasing the software product itself. The CRA does not create a rule stating that receipt of donations automatically turns qualifying FOSS into commercial activity. Instead, Recital 18 directs the analysis away from development financing and toward the actual supply and monetisation model. A project receiving individual or organisational donations should document those funds as project financing and separately determine whether the responsible manufacturer monetises the software.

• Donation income and product monetisation are different concepts.
• Donations should be documented as funding where appropriate.
• The project's distribution model should be analysed separately.
• Manufacturer responsibility remains a separate question.

Corporate Sponsorship Alone Does Not Make the Upstream Project Commercial

Recital 18 expressly states that the mere fact that an open-source software product receives financial support from manufacturers should not in itself determine that the activity is commercial. Corporate sponsorship can therefore fund maintainers, infrastructure, security reviews, testing or project events without automatically turning the upstream software into a commercial manufacturer product. This protection is important because commercial organisations frequently depend on community software and fund its continuity without owning or marketing the upstream project.

• Manufacturer financial support alone is insufficient.
• Corporate sponsorship does not automatically transfer product responsibility.
• Security funding can remain upstream project support.
• Actual market supply should be assessed separately.

Corporate Development Contributions Are Treated Similarly

The recital also states that manufacturer contributions to development do not by themselves determine commercial activity. A company can contribute employee time, patches, testing, documentation or technical review to an upstream project without automatically becoming the manufacturer of that project. The company can nevertheless have a completely separate manufacturer role for its own downstream products that integrate the open-source component.

• Code contributions alone do not establish commercial activity.
• Employee time alone does not establish upstream manufacturer responsibility.
• Upstream and downstream roles should remain distinct.
• Commercial products integrating the software require their own CRA analysis.

Grants Should Be Analysed as Development Financing, Not Automatically as Sales

Open-source projects may receive public grants, research funding or foundation grants tied to development milestones. The CRA's Recital 18 approach means the existence of such financing should not by itself determine that the resulting software is commercially supplied. A grant can impose project deliverables while still being different from monetising the software as a product on the market. The project should preserve enough information to explain the funding relationship and separately document any actual commercial supply model.

• Grants can fund development without being software sales.
• Milestone funding does not automatically create manufacturer status.
• Document the purpose of the grant.
• Analyse any separate monetisation arrangement independently.

Non-Monetised FOSS Receives Specific Recognition

Recital 18 states that the provision of qualifying free and open-source software that is not monetised by its manufacturer should not be considered commercial activity for the relevant CRA market analysis. This is more specific than simply asking whether a project accepts donations. A project can receive support while the actual software remains non-monetised by the responsible upstream actor. Conversely, a zero-price download can exist inside a wider monetised commercial model, so the underlying economic arrangement still needs to be understood.

• Non-monetised qualifying FOSS has specific treatment.
• Donations do not necessarily equal monetisation.
• Zero purchase price is not always proof of non-monetisation.
• Assess the complete economic relationship around the product.

Not-for-Profit Organisations Can Receive Income Without Automatically Becoming Commercial

Recital 18 specifically addresses qualifying not-for-profit organisations. Development of qualifying FOSS 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. This means the legal analysis does not depend on whether the organisation receives any income at all. Donations, grants and sponsorship can coexist with non-commercial development when the organisation satisfies the stated conditions.

• Income does not automatically eliminate non-profit treatment.
• Organisational structure matters.
• Use of earnings remaining after costs matters.
• Not-for-profit objectives should be documented.

Recurring Financial Assistance Can Matter to the Separate Steward Test

Recital 19 asks a different question when defining the ecosystem around an open-source software steward. Steward-supported products must be intended for commercial activities. The recital explains that intention for integration into monetised products includes situations where downstream manufacturers regularly contribute to development or provide regular financial assistance to ensure continuity of the software. This evidence can therefore matter to steward status even where the upstream software is not itself commercially supplied under the Recital 18 analysis.

Commercial Activity and Commercial Intention Should Not Be Collapsed Into One Test

The distinction between Recital 18 and Recital 19 prevents an important analytical error. Recital 18 addresses whether upstream FOSS is supplied in the course of commercial activity for the relevant market regime. Recital 19 helps identify software intended for commercial activities within the tailored steward regime. Regular downstream funding can be evidence for the second question without automatically deciding the first. Organisations should therefore maintain separate conclusions for commercial supply and steward commercial intention.

• Recital 18 and Recital 19 answer different questions.
• Recurring support can matter to steward status.
• Recurring support does not automatically establish upstream commercial supply.
• Document both analyses independently.

Sponsorship Benefits Do Not Automatically Decide the CRA Result

Sponsors may receive recognition, logos on project pages, access to community events or other acknowledgements. The CRA does not provide a simple rule that any sponsor benefit automatically converts the funded software into a commercially supplied product. Those arrangements can be relevant factual context, but the central questions remain how the product is supplied, whether it is monetised by the responsible manufacturer and which entity bears product responsibility. A substantial commercial service arrangement around the software can require a different conclusion from ordinary sponsorship, so the specific agreement should be understood rather than classified by label alone.

• Sponsor recognition is not automatically product monetisation.
• The actual agreement should be understood.
• Commercial services around the software can require separate analysis.
• Labels such as donation or sponsorship are not conclusive by themselves.

Keep Funding Records Separate From Product-Role Records

A practical project record should separate funding information from CRA role information. Funding records can identify donations, grants, sponsors, recurring corporate assistance and the intended use of those funds. Role records should identify who is responsible for the software product, whether it is monetised, whether a legal person qualifies as a steward and which downstream companies act as manufacturers of commercial products. Separating these records makes it easier to explain why funding exists without treating every funder as a manufacturer.

• Record donations and sponsorship.
• Record recurring corporate assistance.
• Record actual software monetisation separately.
• Identify the responsible product actor.
• Identify any qualifying steward.
• Identify downstream manufacturers separately.

Reassess When the Funding Model Becomes a Product Business Model

A funding model can evolve. A community project can later add paid product tiers, paid access, commercial distribution arrangements or another monetisation structure under the responsibility of a particular vendor. At that point the previous non-commercial conclusion should not simply be carried forward. Projects should trigger CRA role review when funding becomes directly connected to product supply, when responsibility moves to a commercial actor or when a new legal entity begins systematic sustained support that could satisfy the steward definition.

• Review new monetisation models.
• Review new commercial distribution arrangements.
• Review changes in product responsibility.
• Review new steward-like organisational support.
• Keep the conclusion current rather than historical.