skip to content

Does the EU CRA's open-source steward regime shield a foundation whose library ships in paid products?

level: seniorimportance: nice to knowfreq 30%

answer

  1. three tiers, not an exemption
  2. outside commercial activity is out of scope
  3. steward is not a manufacturer
  4. policy, cooperation, reporting - no CE mark
  5. the integrator owes the product duties

basics

~20 s

Partly. A steward is not a manufacturer: no CE marking, no conformity assessment, no essential-requirement liability. It does owe a documented cybersecurity policy and reporting of exploited flaws. The vendor embedding the library carries the product duties.

solid answer

~50 s

It shields the foundation from the manufacturer machinery, not from work. The CRA puts three positions on a scale. Free and open-source software supplied outside a commercial activity - the unpaid contributor, the hobby project - is out of scope entirely. An open-source software steward, a legal entity that systematically provides sustained support for open-source products used in commercial activity, gets a lighter tailored regime: document and apply a cybersecurity policy covering secure development and vulnerability handling, cooperate with market surveillance authorities, and report actively exploited vulnerabilities and severe incidents it becomes aware of. No CE marking, no conformity assessment, no essential-requirement compliance. The vendor that embeds the library in a product it sells is the manufacturer of that product and owes the full set, including due diligence on components it integrates. Duties do not transfer upstream - but that diligence lands on the foundation as demand: inventory data, a disclosure contact, fix timelines.

go deeper

for a junior

Know that the CRA excludes open-source software supplied outside a commercial activity, and that a foundation is not automatically treated the same as a company selling a product.

for a middle

Distinguish the three tiers and list what a steward actually owes - a documented cybersecurity policy, cooperation with authorities, reporting of exploited flaws - and what it does not, such as CE marking or conformity assessment.

for a senior

Show how the duties land in practice: the integrating vendor is the manufacturer, its due-diligence obligation arrives at your door as demands, and you need a published policy, a disclosure contact and stated supported branches to absorb it.

for a principal

Own the strategy - whether to accept steward status, how to convert downstream compliance demand into funding or membership, and how to protect a small maintainer team from becoming an unpaid compliance function.

## Three positions, not two The question that dominated the CRA's drafting was whether it would make maintainers liable for software they give away. The answer the regulation reached is a three-tier scale, and being precise about which tier you are in is the whole answer. **Tier 1 - out of scope.** Free and open-source software supplied outside the course of a commercial activity is not covered. An individual publishing a library, a volunteer project, a contributor working on something in their own time: no duties. The regulation is explicit that this exclusion should not evaporate because a project accepts donations or because contributors are employed elsewhere. **Tier 2 - the open-source software steward.** A legal person, other than a manufacturer, whose purpose or objective is to systematically provide sustained support for the development of specific free and open-source products with digital elements intended for commercial activity, and which ensures the viability of those products. A foundation employing maintainers for a widely repackaged library fits this squarely. The steward gets a deliberately light, tailored set of duties: - put in place and document, in a verifiable manner, a cybersecurity policy fostering secure development and effective vulnerability handling for the products it stewards - cooperate with market surveillance authorities on request - report actively exploited vulnerabilities and severe incidents it becomes aware of, to the extent it is involved in the development of the product What a steward does **not** owe: CE marking, conformity assessment, compliance with the essential product requirements, technical documentation, or a declared support period. Those belong to the manufacturer tier. **Tier 3 - the manufacturer.** The vendor that integrates the library into a product it places on the EU market under its own name. That vendor owes everything: essential requirements for the whole product including the embedded library, vulnerability handling, the reporting clock, the support period, and explicit **due diligence on the third-party components it integrates**. ## What actually happens to the foundation Duties do not flow upstream, but consequences do. The moment a commercial vendor's own compliance depends on your library, that vendor needs things only you can supply, and it will ask for them contractually or publicly: - component inventory data good enough to feed its SBOM - a monitored security contact and a stated coordinated disclosure practice, because its 24-hour reporting clock starts from evidence that may reach you first - some visibility of fix timelines and supported branches, because its declared support period assumes yours - evidence of the cybersecurity policy it can put in front of its own auditor This is the real strategic content of the question. The steward regime protects the foundation from the CE machinery it could never afford; it does not protect it from becoming the unpaid compliance department of every vendor downstream. The sensible responses are the ones the maintenance community has been arguing for anyway: publish the security policy and the disclosure contact so the demand arrives in one channel rather than fifty; state supported versions and support horizons explicitly so vendors cannot assume forever; and convert diligence demands into funding, membership or seconded engineers rather than absorbing them. The regulation also creates a **voluntary security attestation** route for free and open-source software, letting a steward or another party attest to a project's conformance with some requirements so downstream manufacturers have something to point at. It is voluntary and it is not a CE marking, but it is the mechanism the regulation offers for exactly this friction. ## The line to draw carefully in an interview Two mistakes are equally bad. Saying *open source is exempt, so nothing changes for us* ignores the steward tier and the downstream demand. Saying *the CRA makes maintainers liable for the products their code ends up in* is the scare version and is simply wrong - the manufacturer of a product is liable for the product it sells, including the parts it chose to embed, and cannot push that onto an upstream it does not pay. The interesting judgment sits in between: how a foundation decides whether it wants steward status and its duties, or would rather restructure so it is plainly a tier-1 project; how it prices vendor demands; and how it stops a well-meaning compliance obligation from crushing three maintainers.

  • A vendor demands that your foundation guarantee a 30-day fix service level. Is that a CRA obligation?
    No. The vendor's obligation to remediate without delay attaches to its product, not to your project, and the CRA gives it no power to conscript your maintainers. Its remedies are to fix the flaw itself in its own build, fund the work upstream, or choose a different component. Treat the request as a commercial conversation - membership, sponsorship or a seconded engineer - rather than a legal one.
  • Does taking donations or selling paid support turn a project into a commercial activity?
    Not automatically. The regulation is deliberately careful that accepting donations without profit-making intent does not pull a project into scope. Charging for support or hosting can, depending on the arrangement, and monetising the software itself certainly can. The safer read is that the more your entity systematically sustains a project used commercially, the more likely the steward tier applies - which is a light regime, not the manufacturer one.
  • What is the single most useful thing a steward can do before the obligations bite?
    Publish the cybersecurity policy and a monitored security contact, and state which branches are supported for how long. That satisfies the documented-policy duty, gives downstream manufacturers one channel instead of ad-hoc mail to individual maintainers, and prevents vendors from silently assuming an indefinite support horizon that no one agreed to.

The steward regime is closer to a food-hygiene policy for a community kitchen than to a factory licence: you must show how you work and speak up when something is wrong, but nobody makes you certify a production line.

saying these in an interview costs you the question

  • Says open source is simply exempt and nothing changes
  • Claims maintainers become liable for products embedding their code
  • Thinks a steward must CE-mark releases
  • Assumes accepting donations alone creates commercial activity
  • Confuses the steward's light duties with manufacturer duties
  • Believes a vendor can transfer its remediation duty upstream

context

resolving links…