The CRA gives “open-source software steward” a set meaning. It must be a legal person, but not the maker. It must give steady, long-term aid to the work on named free and open-source products. Those products must be meant for business use. The aid must also keep them viable.

A person who acts alone as a maintainer is not a steward. The term requires a legal person. If a maker puts such software on the market as part of its business, the maker rules apply. It cannot use the lighter steward role.

Start with the entity, not the repository

Name every legal person that aids the project. Record what each entity does and for how long. Name the products that it aids. State how its work keeps them viable.

A logo or hosting page does not prove the role. Nor does a person’s job link or one grant.

Next, ask if a party puts the software on the market under its name or mark. One project may have people who maintain it, a group that aids it, and firms that sell it. Each may have a different role.

Test the definition element by element

Test each part of the legal term on its own. Make a finding for:

  • status as a legal person;
  • regular and long-term work;
  • the named products;
  • planned business use;
  • work that keeps them viable; and
  • status as a maker.

Link each finding to its proof and reviewer. A broad label such as “open-source group” settles none of these tests.

Keep facts that point the other way. Grants, hosting, staff jobs, board rights, release power, and security work may not point to one result. Record what took place and when. Do not choose a role just because its name seems familiar.

Map support to a specific product

List code work, release work, flaw response, systems, control, and funding as separate acts. Link each act to the product that it aids. A role for one product does not give the entity that role for all projects.

Keep charters, deals, control records, and support choices that prove the result. Review a change in funding or control. Do not rely on a fixed label.

If several entities aid one project, map each one. One may be a steward. Another may be the maker of a paid form of the software. People may still maintain it in their own name. Do not force one role on the whole project.

Assign reporting ownership after role analysis

Map the Article 24 duties only after the role is clear. Then name who reports, who acts for the entity on the platform, and who tells users. Also plan how the steward and makers will work together. Keep a clear route for a maintainer to raise a technical alert.

If there is no steward, do not give the duty to a person for ease. Makers that use the project still need their own CRA review. Ask counsel to review a hard control structure. The words “open source” do not settle the test.

Close with the date, owner, proof index, and report owner for each legal person. List the events that will reopen the review. These include a change in control, a new paid form, new long-term aid, or a shift in release power. Keep the old result as a record of the earlier facts.

Continue this workflow with the steward-reporting boundary and the role-changing manufacturer test.