Legal roles

This page gives the parties of Fediversity, the role of each party under the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847), the Product Liability Directive (PLD, Directive (EU) 2024/2853) and NIS2 (Directive (EU) 2022/2555), and the events that change a role. It also gives the duties for the content of an instance under the Digital Services Act (DSA, Regulation (EU) 2022/2065) and the regulation on terrorist content online (TCO, Regulation (EU) 2021/784). The roles under the GDPR are in Data protection.

Pending review by a lawyer. This page is not legal advice. The maintainers publish the scenarios now, so that the parties can prepare. A lawyer has not checked the conclusions yet. The board of Stichting Edsger Institute engages the lawyer. Until a lawyer confirms a conclusion, do not use it as the basis of a contract or of a decision about compliance.

Summary

Probably no party is a manufacturer of Fediversity under the CRA now:

• Edsger develops the code as a not-for-profit organization. It is an open-source software steward (CRA Art. 3(14), Art. 24, recital 19). See What a steward must do.
• The hosting providers run Fediversity as a service for operators. This is the base case (scenario 1). The CRA does not apply to a cloud service that a manufacturer did not design and develop as a part of a product (CRA recitals 11 and 12). NIS2 can apply to these services.

Some events make a party a manufacturer. Then all the obligations of a manufacturer apply from the first day, and the reporting obligation of CRA Art. 14 applies since 2026-09-11. The PLD is a separate risk. It applies to products that are put on the market or into service after 2026-12-09, and it treats software as a product also when it is supplied as a service (PLD recital 13).

Parties and roles

Scenarios

Scenario 1: a hosting provider runs Fediversity as a service

This is the base case. A hosting provider gets the software from this repository, deploys it on its own infrastructure, and offers it to operators. The operators use their deployments through the panel. The hosting provider does not supply the software to the operators. A hosting provider can also be its own operator, for example if it runs Fediversity only for its own organization. That case is less common, and the result under the CRA is the same.

• The CRA does not apply, while scenario 3 does not apply.
• The PLD can apply. The software is a product also when it is supplied as a service (recital 13), but the PLD does not apply to services as such (recital 17). The PLD makes the manufacturer of a defective product liable (Art. 8(1)). A hosting provider is the manufacturer of the product if one of these conditions is true:
  • It develops the product, or it puts its name or its trademark on the product (Art. 4(10)).
  • It integrates Fediversity as a component into its own product in the course of a commercial activity (recital 15).
  • It substantially modifies the product and then puts it into service (Art. 8(2)). A modification is substantial if it changes the intended functions or the risk profile of the product (Art. 4(11), recital 39), for example if the hosting provider adds applications. Repairs and other operations that are not a substantial modification do not make it liable (recital 39).
• Fediversity is open source, so each hosting provider can make these changes. Then it is liable for the product that it changed. It is not clear who is liable for a defect in the software if a hosting provider runs it without changes and without its own name.
• The damage that the PLD covers includes the destruction or corruption of data that are not used for professional purposes (Art. 6(1)(c)). Data of a business customer are usually professional data. The posts and the media of the private users of an instance are probably not professional data. So a loss of the data of an instance with private users is in the scope of the PLD.
• A defect can come from a cybersecurity weakness or a missing software update (Art. 7(2)). The manufacturer is not exempt for a defect that comes from an update, or the lack of an update, that it controls (Art. 11(2)).
• A contract cannot limit or exclude this liability (Art. 15). Claims expire 10 years after the product was put on the market or into service (Art. 17).
• A manufacturer that integrates open-source software, which was supplied outside a commercial activity, is liable for that component. The developer of the open-source software is not (recitals 14 and 15). So Edsger stays out of scope while scenario 2 does not make its supply commercial.

Scenario 2: a consulting subsidiary of Edsger

Edsger plans a subsidiary that advises hosting providers about the software. The hosting providers keep the role of hosting provider. The software stays open source, and the subsidiary does not limit its distribution. The proceeds of the subsidiary go to Edsger for its not-for-profit objectives.

• Consulting is a service. It does not put a product on the market, so it does not make the subsidiary a manufacturer.
• The risk is the line between consulting and paid support for the software. The CRA counts these as supply in the course of a commercial activity (recital 15):
  • a price for technical support that is more than the recovery of the actual costs;
  • an intention to monetize the software;
  • donations that are more than the costs of the design, development and supply.
• If the paid work of the group becomes support for the software, the supply of the releases can become commercial. Then Edsger or the subsidiary is the manufacturer, and Edsger can lose the status of steward. Recital 18 keeps the development by a not-for-profit organization non-commercial only if all earnings after costs go to not-for-profit objectives.
• Under the PLD, open-source software that someone develops or supplies outside the course of a commercial activity is out of scope (Art. 2(2)). The same line applies.
• If the subsidiary does more than advise, for example if it operates or maintains the systems of a hosting provider, it can be a managed service provider under NIS2 (Art. 6(39), Annex I). If it gets access to personal data, it is a sub-processor under the GDPR (Art. 28(4)).

To keep the scope of the subsidiary clear:

• Sell consulting on the operations of the hosting provider: architecture, deployment, operations, audits and training.
• Do not sell releases, builds, long-term support branches or service levels for security fixes. Every fix goes upstream to all users free of charge.
• Write this scope in the statutes of the subsidiary and in its contracts with clients.
• Keep the flow of money from the subsidiary to Edsger apart from payment for the software, for example as a dividend for the not-for-profit objectives. A lawyer must check the structure.

Scenario 3: someone supplies Fediversity as a product

A party gives the software, or a product that contains it, to a customer that runs it itself. Examples: a distribution with its own name, an appliance, or a paid build. This is less common than scenario 1. The CRA calls this placing on the market, so that party is the manufacturer of its product (Art. 3(13)). See What a manufacturer must do.

A hosting provider that only runs Fediversity for operators is in scenario 1, not in this scenario.

Funding of the development

Grants, and development work by commercial project partners, do not by themselves change the role of Edsger:

• CRA: the circumstances of the development, and how the development is financed, do not decide if the supply is commercial. Financial support from manufacturers, contributions of manufacturers to the development, and regular releases do not by themselves make it commercial (recital 18). A party that contributes source code to a product that is not under its responsibility is not in scope (recital 18). Regular contributions or regular financial support from manufacturers show that the software is intended for commercial activities. That is a condition for a steward (Art. 3(14), recital 19).
• PLD: the supply of open-source software by a not-for-profit organization is in principle not commercial. It becomes commercial if the software is supplied in exchange for a price, or for personal data that are used for other purposes than the security, compatibility or interoperability of the software (recital 14).

What a steward must do

Edsger is an open-source software steward. Art. 24 applies from 2027-12-11, and Art. 14 applies from 2026-09-11 (Art. 71(2)). The steward must:

• Put in place a cybersecurity policy, and document it so that others can verify it (Art. 24(1)). The policy fosters the secure development of the product, the handling of vulnerabilities by its developers, and the voluntary reporting of vulnerabilities (Art. 15). It includes how the developers document, address and remediate vulnerabilities, and it promotes the sharing of information about vulnerabilities in the open-source community. SECURITY.md and the threat model are parts of this policy.
• Cooperate with the market surveillance authorities when they ask. On a reasoned request, give them the documentation of the policy (Art. 24(2)).
• Report actively exploited vulnerabilities, to the extent that it is involved in the development of the product (Art. 24(3), Art. 14(1)).
• Report severe incidents and inform the users, to the extent that the incidents affect the network and information systems that the steward supplies for the development of the product (Art. 24(3), Art. 14(3) and (8)).
• Not put the CE marking on the product (recital 19).

No administrative fines apply to a steward (Art. 64(10)(b)).

What a manufacturer must do

If scenario 2 or 3 occurs, the manufacturer must:

• Decide the class of the product (Art. 7, Annexes III and IV). The core functionality decides the class. A component in an important class does not by itself make the product important. Fediversity contains an operating system and identity management (Annex III, class I) and a hypervisor and container runtime (Incus, Annex III, class II). The core functionality of Fediversity is the hosting of fediverse applications, so it is probably a product of the default class. Write down this decision and the reasons.
• Do the conformity assessment (Art. 32). For the default class, internal control (module A) is sufficient. For open-source software in Annex III, module A is also sufficient if the technical documentation is public when the product goes on the market (Art. 32(5)).
• Write the technical documentation (Art. 31, Annex VII) and keep it for 10 years (Art. 13(13)). Technical documentation maps each item of Annex VII to the documents in this repository.
• Sign the EU declaration of conformity (Art. 28, Annex V) and put the CE marking on the product (Art. 30).
• Give the information and instructions for the user (Annex II), including the end of the support period.
• Set a support period of at least 5 years, unless the product is in use for a shorter time (Art. 13(8)).
• Report actively exploited vulnerabilities and severe incidents through the single reporting platform of ENISA, with an early warning within 24 hours (Art. 14).
• Meet the essential requirements of Annex I. Threat model gives the controls and the open gaps.

What the PLD needs

• Keep the security updates in time (#2178, #611, #2082) and the backups (#2186). These decrease the risk of a defect and of data loss.
• Keep the records that show the state of the software at a given time: the commits and the release tags (#2178), the SBOMs and the advisories (SECURITY.md). A court can order the disclosure of evidence (PLD Art. 9).
• The hosting providers, and the subsidiary if scenario 2 occurs, must check their liability insurance.

Duties for the content of an instance

The DSA and the TCO apply to a party that stores content for others. Probably two parties have these duties:

• The operator is the hosting service for the content of its instance.
• The hosting provider is a hosting service for its customers, the operators.

Fediversity does not do these duties for a party. It gives the settings that are below. Each party must tell who does the work, and must give a contact address that a person reads.

The duties

There is no exemption from the duties in this table for a small organization. DSA Art. 15(2) and Art. 19(1) remove only the transparency reports and the duties of online platforms from micro and small enterprises. In the TCO, the size of the party is a factor for the penalty (Art. 18(2)(f)). A systematic or persistent failure of Art. 3(3) can cost up to 4% of the global turnover of the preceding business year (Art. 18(3)).

Plan for the period of one hour

The period starts when the party gets the order. An authority that has not sent an order to the party before gives a warning at least 12 hours before its first order (TCO Art. 3(2)). There is no warning in a justified emergency, and none for a later order. Thus do these steps before you offer an instance to the public:

1. Choose who reads the contact address for removal orders, also outside office hours.
2. Choose who can remove the content in each application. This person needs a moderator account.
3. Agree what the hosting provider does if the operator does not answer in time, and what the operator does if an order goes to the hosting provider.

Set the contact data of an application

The panel has no setting for one legal entity or one contact address for all the applications of a deployment. Thus set the data in each application. The hosting provider publishes its own contact data on its own website.

Which application settings are operator-facing tells how the settings work. The privacy policy is in Data protection and in privacyPolicyUrl of the operator configuration.

Give a person a moderator role

A person gets an account in the directory of the deployment, and not in each application. Manage the users of your deployment tells how to add a person, and which group the person needs. The same account then logs in to all the applications through SSO. Do not make separate accounts in the applications, because you must then manage the users in more than one place.

The directory also gives the roles of the applications. To make a person a moderator or an administrator of all the applications of the deployment, add the account of the person to a shared role group. To give a role in one application only, use the role group of that application. A group is there only when an application in the deployment uses it:

The applications do not have the same roles, thus a shared group does not give the same rights in each application:

• Pixelfed has no moderator role. application-moderators gives no role in Pixelfed. A person who must remove content in Pixelfed needs application-admins or pixelfed-admins, and thus gets all the rights of an administrator of Pixelfed.
• Mastodon also has the role Owner, which bypasses all the permission checks. Only mastodon-owners gives this role.
• Mastodon also has custom roles, which you give in its web administration. No group gives a custom role, and the sync does not remove a custom role from an account that is in no role group.

fediversity-admins is not one of these groups. It gives access to the administration tools of the deployment, and no role in an application.

Each application syncs the roles of its accounts from these groups some minutes after a change. When a person is in more than one group that gives a role in an application, the highest role applies. When a person is in no group, the application gives the base role. Thus remove the person from the group to remove the role. Then:

• The directory is the only place for these roles. A role from the table that you give in the web administration of the application changes back at the next sync.
• The sync changes only the accounts that log in through SSO, and not the local accounts of an application.
• The account must exist in the application, thus the person logs in one time before the role applies.
• PeerTube logs the person out when the role changes.
• The sync needs the OpenBao secrets backend of the hosting provider. Without it, the roles stay in the web administration of each application.

A deploy creates no moderator. It seeds one administrator in the directory, and only if the operator sets email (Operator configuration). Each deploy puts this administrator in application-admins and, if Mastodon is in the deployment, in mastodon-owners.

Text for the contracts of hosting providers

A hosting provider can add this text to its contracts with operators. Let a lawyer check it before you use it. Replace the parts in italics with the names of the parties and the period that they agree.

1. The Hosting Provider runs the Fediversity software as a service for the Operator. The Hosting Provider does not supply the software, or a product that contains it, to the Operator to run itself.
2. The Fediversity software is free and open-source software under the European Union Public Licence, version 1.2. Stichting Edsger Institute develops it. The Hosting Provider does not get the software from Stichting Edsger Institute under a contract.
3. If the Hosting Provider supplies the software, or a product that contains it, to the Operator as a product, for example a distribution, an appliance or a build that the Operator runs itself, the Hosting Provider is the manufacturer of that product under Regulation (EU) 2024/2847. A separate agreement then applies to that product.
4. This clause does not limit a liability under Directive (EU) 2024/2853.
5. For the duration of this contract, the Hosting Provider updates the Fediversity software to each release that has a fix for a vulnerability, within the agreed period after that release. The security policy of the Fediversity software (SECURITY.md) gives the support period of a release.

The data processing agreement is in Contract templates.

Questions for a lawyer

• Scenario 2: does the planned scope of the subsidiary keep the supply of the software by Edsger non-commercial (CRA recitals 15 and 18, PLD Art. 2(2))? The proceeds of the subsidiary go to Edsger for its not-for-profit objectives. Which structure of this flow of money is permitted?
• Scenario 1: is a hosting provider that runs Fediversity without changes, and without its own name on it, liable under the PLD? Which changes make it a manufacturer, for example its own configuration, added applications, or its own name on the panel?
• Is the text for the contracts of hosting providers correct and sufficient?
• Is an instance with no payment an information society service, and thus a hosting service under the DSA and the TCO? An operator can run an instance for a small group. Does it make the content available to the public?
• Who gets a removal order: the operator, the hosting provider, or both? Which party must act if the order goes to the party that does not moderate the content? Should the text for the contracts of hosting providers state this?
• Which duties apply to a copy of content from another instance, which federation stores on the instance of the operator?
• Does a contact address on a page of the application meet DSA Art. 11, Art. 12 and TCO Art. 15, or must the operator publish it in another place?
• Does Article 17(3) of the GDPR permit an audit store with Object Lock, which stops the erasure of a record before the end of the lock? Is the retention period of 365 days in the hosting provider guide sufficient and proportionate?