CRA Responsibilities for Individual Open Source Maintainers

Maintainer Is Not a Defined CRA Economic-Operator Role

The CRA contains defined roles such as manufacturer, importer, distributor and open-source software steward, but it does not assign a separate set of obligations simply to someone called a maintainer. Open-source communities use maintainer to describe many different relationships, ranging from a volunteer who merges patches to a project founder with substantial control or an employee maintaining software for a company. The CRA analysis therefore needs to look beyond the community title and determine who is legally responsible for the product and in what context it is supplied.

• Maintainer is not itself a CRA economic-operator category.
• Community titles do not decide legal responsibility.
• The factual role must be analysed.
• Product responsibility and commercial supply are central.

Source-Code Contribution Alone Does Not Create Manufacturer Responsibility

Recital 18 provides an important protection for collaborative development. The Regulation does not apply merely because a natural or legal person contributes source code to qualifying free and open-source software that is not under that person's responsibility. A maintainer who reviews, merges or contributes code therefore should not automatically be treated as the manufacturer. Responsibility for the product has to be identified separately. This helps protect ordinary open-source collaboration from becoming a chain of individual manufacturer obligations.

• Contribution alone is insufficient.
• The product must be under the person's responsibility before that factor changes.
• Natural persons are expressly relevant to the recital.
• Collaborative development does not automatically create manufacturer status.

Technical Control and Legal Product Responsibility Are Different

A maintainer can have significant technical control without necessarily assuming legal responsibility for a product placed on the market. For example, a maintainer might control merges and releases for a project governed by a foundation, or might maintain an upstream component used by many unrelated companies. Conversely, an individual developer can operate a product under their own name and take responsibility for its commercial supply. The CRA analysis should therefore document who controls technical development and who actually assumes responsibility for the product as supplied.

• Merge authority does not automatically equal manufacturer responsibility.
• Release authority does not automatically decide commercial status.
• Foundation governance can affect role allocation.
• An individual can separately assume responsibility for a product.

An Individual Natural Person Is Not an Open-Source Software Steward

Article 3(14) defines an open-source software steward as a legal person other than a manufacturer. An individual natural person acting in their personal capacity therefore does not fit that specific definition. This remains true even where the individual performs extensive maintenance, coordinates releases or has longstanding influence over the project. A foundation, association, company or other qualifying legal person around the project can instead require steward analysis where the complete statutory test is met.

• Steward status requires a legal person.
• An individual natural person does not fit Article 3(14).
• Technical influence does not change the legal-person requirement.
• A surrounding organisation can require separate steward analysis.

A Natural Person Can Still Potentially Be a Manufacturer

The manufacturer definition is different from the steward definition and can include a natural person. An individual therefore cannot assume that personal or independent status automatically excludes manufacturer obligations. Where a natural person develops or has developed a product, assumes responsibility for it and markets it under their own name or trademark within the relevant CRA market context, manufacturer analysis is required. For qualifying FOSS, the commercial-activity treatment in Recital 18 remains important. The correct conclusion depends on product responsibility and market activity, not simply whether the developer operates through a company.

• Natural persons can fall within the manufacturer definition.
• Personal status is not an automatic exemption.
• Product responsibility matters.
• Commercial activity remains important for qualifying FOSS.

Volunteer Status Does Not Replace the Role Analysis

Many maintainers describe themselves as volunteers because they receive no payment directly from the project. That fact can be relevant to understanding the project context, but payment status is not itself the CRA legal test. An unpaid contributor whose project is not under their responsibility is strongly distinguishable from a person who commercially markets a product even if some development work is unpaid. The role assessment should therefore focus on responsibility, market activity, governance and monetisation rather than using volunteer as a legal category.

Employment by a Company Can Create a Separate Organisational Relationship

A maintainer may contribute upstream as part of paid employment. That does not automatically make the employee personally the manufacturer of the upstream project. The employing company may be a downstream manufacturer, sponsor, contributor or potentially another regulated actor depending on the facts. The project can also have a separate steward organisation. Documentation should therefore identify whether the maintainer acts personally, on behalf of a company or under foundation governance when performing specific activities.

• Paid employment does not automatically make the employee the manufacturer.
• The employer's role should be analysed separately.
• The upstream project's role structure can remain independent.
• Document whose authority the maintainer is exercising.

Maintainers Should Know Who Owns Vulnerability Decisions

Even where an individual has no direct CRA economic-operator role, maintainers are often central to practical vulnerability handling. Projects should identify who receives vulnerability reports, who determines embargo or disclosure handling, who coordinates fixes and which organisation carries any formal Article 24 or manufacturer duties. This avoids placing legal obligations informally on an individual simply because that person is technically knowledgeable or responsive.

• Define vulnerability intake ownership.
• Define remediation decision ownership.
• Separate project processes from legal responsibility.
• Avoid making one maintainer the accidental compliance bottleneck.

Maintainers Can Work Within a Steward's Article 24 Policy

Where a qualifying open-source software steward supports the project, Article 24 requires the steward to maintain a documented cybersecurity policy that fosters secure development and effective vulnerability handling by developers. Individual maintainers can participate in those processes without personally becoming the steward. The policy should reflect how maintainers report, document, address and remediate vulnerabilities and how the steward supports those activities through governance and infrastructure.

• Maintainers can participate in steward security processes.
• Participation does not make the individual the steward.
• The steward owns its Article 24 policy obligation.
• Project workflows should support maintainers rather than shift legal roles onto them.

Document Individual Roles Without Over-Classifying Contributors

Projects should keep a simple role map for important maintainers. It can identify whether each person acts independently, for a foundation, for a sponsor or for a downstream manufacturer, and who owns the product, release process, infrastructure and security policy. The purpose is not to create regulatory files on ordinary volunteers. It is to ensure that legal responsibility is assigned to the correct organisation or responsible product actor and that individual contributors are not mistakenly classified as manufacturers or stewards merely because they are visible project leaders.

• Identify the responsible legal entity where one exists.
• Separate personal and organisational activities.
• Record who owns the product role.
• Avoid classifying maintainers from job titles alone.
• Review when project governance changes.