The CRA does not give each open-source steward all the duties of a maker. The duty depends on the steward’s role in a given project.

The flaw-report rule applies only as far as the steward helps develop the product. A different test applies to a severe event. That event must affect a network or system that the steward provides for the work. The same limit applies to user facts about that event.

Map these facts for each project. A group can have a different role in each one.

Record development involvement

Name the legal entity for each project. Then record what it does. Cover these points:

  • long-term support;
  • rights to make choices;
  • work on the code and releases;
  • security work; and
  • systems that it provides.

Name the proof and owner for each point.

Do not rely on claims such as “we host the project.” A claim that “we fund its team” is also too broad. List the actual work so it can be tested under Article 24. Update the record when support or control changes.

Build a project-by-project role matrix

Give each project its own row. Name the entity and product. Add its role in the work, its long-term support, and what it does to keep the project viable. Add its power over releases and security. Note the systems it provides, the business setting, and the proof.

The same group may have a different result for two projects.

Keep a person’s own work apart from work done for the legal entity. A job, board seat, or access to the source code may be proof. No single fact proves the role by itself.

Separate the two occurrence routes

For a flaw under active attack, ask if the steward helps develop the product. For a severe event, ask if it affects a work system that the steward provides. Run both tests if the attack crosses code and systems.

Give each project a safe way to send in alerts. Name the person who can decide if the steward must report. Link the people who maintain the code to the legal entity that can file on the EU platform.

For a system event, name the network or system. State which project work it aids and which projects it affects. Record its product security effect and the steward’s control. An attack on an unrelated office system does not make every project a severe event.

For a flaw, link the steward’s work to the affected product. Keep proof of active attack in its own record. Leave both routes open until each set of facts is clear.

Coordinate without erasing roles

Makers that use the project may have their own Article 14 duties. A steward’s report does not finish a maker’s product review. A maker’s report also does not prove that the steward’s systems were affected.

Share the flaw facts when that helps. Keep separate times of awareness, scope choices, user groups, and filing proof. The record should link each steward task to a route and project.

Review the matrix after a change in control, funding, systems, or release rights. Keep the dates for each role choice. A later case must use the facts that were true at the time, not just the current project site.

Continue this workflow with the maintainer-or-steward analysis and the component-maintainer handoff.