CRA Responsibilities for Corporate-Sponsored Open Source Projects

Corporate Sponsorship Does Not Automatically Make FOSS Commercial

Open-source projects often depend on companies for money, employee time, infrastructure and engineering expertise. Recital 18 deliberately prevents those facts from becoming an automatic commercial-activity test. The mere fact that a manufacturer financially supports a qualifying free and open-source product does not by itself determine that the upstream activity is commercial. The same is true when manufacturers contribute to development. A project should therefore analyse how the software itself is supplied and monetised rather than treating the identity of its sponsors as sufficient evidence of commercial market supply.

• Corporate funding alone does not establish commercial activity.
• Corporate development contributions alone do not establish commercial activity.
• Sponsor identity is not the complete CRA test.
• Actual product responsibility and monetisation remain important.

Employee Contributions Do Not Automatically Transfer Manufacturer Status Upstream

A company may allow or encourage employees to contribute code to an independent upstream project. Those contributions do not automatically make the company the manufacturer of that upstream product. The project can continue to have its own governance and responsibility structure. The company can simultaneously be the manufacturer of a separate downstream product that incorporates the software. The CRA analysis should therefore distinguish contributions made to the upstream project from responsibility for the commercial product that the company itself places on the market.

• Employee contributions can remain upstream contributions.
• Upstream governance can remain independent.
• The sponsoring company can separately be a downstream manufacturer.
• The same code can appear in different CRA relationships.

Regular Releases Still Do Not Make the Project Commercial by Themselves

Corporate sponsorship often improves release discipline by funding maintainers, testing and release engineering. Recital 18 nevertheless states that regular releases should not by themselves lead to the conclusion that software is supplied in the course of commercial activity. A well-funded project can therefore publish frequent releases without becoming a commercial manufacturer merely because of that cadence. Release frequency should be documented as a project characteristic rather than used as a substitute for analysing monetisation and product responsibility.

• Regular releases are not commercial activity by themselves.
• Corporate release engineering does not automatically alter the rule.
• Security updates should not be discouraged.
• Monetisation should be analysed separately.

Regular Corporate Support Can Matter to the Steward Test

Recital 19 introduces a different question for the open-source software steward regime. Steward status covers specific qualifying FOSS products intended for commercial activities. The recital explains that intention for integration into monetised products includes cases where downstream manufacturers regularly contribute to development or provide regular financial assistance to ensure software continuity. This does not contradict Recital 18. The first rule prevents sponsorship from automatically becoming commercial upstream market supply. The second helps establish the intended commercial ecosystem around software for purposes of the steward definition.

• Commercial activity and steward commercial intention are separate tests.
• Regular downstream contributions can be relevant to stewardship.
• Regular financial assistance can also be relevant.
• The supported software may remain upstream while serving a commercial ecosystem.

The Sponsoring Company May Have Its Own Manufacturer Obligations

A company that integrates sponsored open-source software into a product it markets under its own responsibility must assess that downstream product separately. Open-source sponsorship does not replace or reduce the manufacturer obligations applying to the company's own product. Article 13 requires manufacturers to exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the finished product. Corporate sponsors should therefore distinguish upstream support activities from their internal product-security and conformity responsibilities.

• Downstream product responsibility remains with the manufacturer.
• Third-party component due diligence remains relevant.
• Sponsorship does not transfer responsibility upstream.
• Internal product compliance should be documented separately.

The Sponsoring Company Is Not Automatically the Steward

Financial or engineering support alone does not automatically make a sponsoring company an open-source software steward. Article 3(14) requires a legal person other than the manufacturer in the relevant steward relationship whose purpose or objective is to provide systematic sustained support for development of specific qualifying FOSS intended for commercial activities and that ensures the viability of those products. The complete test must be satisfied. A foundation can be the steward while several companies sponsor or contribute to the project downstream.

Governance Can Remain Independent From Corporate Funding

A project can receive substantial commercial support while maintaining independent technical governance. The CRA role assessment should therefore identify who decides releases, security policy, project direction and product responsibility rather than inferring control from the size of a donation or contribution. Where a foundation or other legal person manages governance and ensures project viability, that entity may require steward analysis. Where the sponsor controls and markets a product as its own, manufacturer analysis can instead become relevant.

• Funding level does not necessarily equal governance control.
• Identify who controls project direction.
• Identify who assumes product responsibility.
• Document the legal person providing sustained support.

Corporate Infrastructure Support Can Be Relevant Without Deciding the Role

Companies often supply build infrastructure, continuous integration, hosting, signing systems, test environments or security services to open-source projects. These activities can improve project viability and security, but no single infrastructure contribution automatically determines manufacturer or steward status. Recital 19 recognises development-platform management and source hosting as examples of sustained support, yet the full Article 3(14) test still controls. Project documentation should record infrastructure ownership and dependency because those systems can also become relevant to severe-incident reporting where a qualifying steward provides them for product development.

• Infrastructure support can form part of sustained support.
• One infrastructure service does not decide steward status.
• Ownership and operational responsibility should be documented.
• Development systems can later become relevant to Article 24(3).

Security Funding Should Strengthen Rather Than Replace Project Processes

A sponsor may fund audits, vulnerability remediation, maintainer time or secure-development improvements. Those contributions can support the project's security without changing the underlying CRA role allocation. Where a steward exists, its Article 24 cybersecurity policy should explain how supported projects document, address and remediate vulnerabilities. Where the sponsor is a downstream manufacturer, the sponsor should separately maintain the evidence needed for its own third-party component due diligence and product risk assessment.

• Security funding can benefit upstream development.
• Steward policies remain distinct from manufacturer evidence.
• Downstream due diligence remains the manufacturer's responsibility.
• Roles should be documented instead of merged.

Maintain a Corporate Sponsorship Role Map

For significant corporate-sponsored projects, maintain a role map identifying the upstream project, governing organisation, sponsors, regular contributors, infrastructure providers, downstream manufacturers and any qualifying steward. Record whether sponsorship is occasional or regular, whether financial assistance is intended to ensure software continuity, how the software is commercialised downstream and which entity is responsible for each product. This prevents corporate participation from being mistaken either for automatic manufacturer responsibility or for automatic exemption.

• Identify sponsors and regular contributors.
• Identify the steward, if one exists.
• Identify downstream manufacturers.
• Separate funding from product responsibility.
• Record infrastructure ownership.
• Review when governance or commercial relationships change.