xiboplayerxiboplayer
EN

RFC-0001 — xiboplayer OSS AS-IS redistribution posture

FieldValue
StatusPublished (pending external legal review)
AuthorPau Aliagas pau@xiboplayer.org
Created2026-04-14
Published on site2026-04-16
Affected reposxiboplayer, all 11 player platforms, xiboplayer-www
Supersedes—
RelatedRFC-0002 CRA-readiness, Security page, Code-signing policy

1. Summary

The public xiboplayer project is distributed AS-IS under AGPL-3.0-or-later, in the same posture as any other open-source project (Linux, PostgreSQL, React). The xiboplayer project does not make CRA manufacturer claims, does not register as a CRA open-source steward, and does not offer warranties, SLAs, or compliance commitments of any kind on the public OSS binaries.

2. Motivation

EU Regulation 2024/2847 (Cyber Resilience Act, "CRA") places obligations on parties that "place products with digital elements on the market" in the EU. The regulation explicitly excludes free and open-source software that is not itself placed on the market in the course of a commercial activity (Recital 18, Article 2(5)).

xiboplayer is developed and published as free and open-source software under AGPL-3.0-or-later. Maintainers do not sell the binaries, do not offer paid support for the OSS binaries, and do not promote them as a commercial product. This places the project in the same legal category as the overwhelming majority of well-known OSS projects — which ship AS-IS, with license-provided disclaimers, and leave CRA compliance to downstream commercial integrators.

The natural, lowest-friction posture is therefore:

  • Public xiboplayer: AS-IS OSS, no compliance claim, standard OSS disclaimer.

3. Posture

3.1 Legal posture of public xiboplayer

  • All public artefacts (source, RPM, DEB, APK, WGT, IPK, zip, container images) are distributed AS-IS under AGPL-3.0-or-later
  • The standard AGPL disclaimer applies in full:

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

  • No CRA manufacturer claim, no steward registration, no Annex I compliance statement, no CE marking, no Declaration of Conformity
  • No support commitment, no SLA, no security-patch timeline promise
  • Maintainers act as OSS contributors, not as any regulated party

3.2 OSS hygiene we keep (not a CRA commitment)

These are standard OSS project practices unrelated to CRA, kept because they're cheap and downstream consumers expect them:

  • SECURITY.md in each repo — GitHub convention; invites bug reports
  • /.well-known/security.txt on xiboplayer.org — RFC 9116 industry norm
  • GitHub Security Advisories — free GitHub feature
  • CycloneDX SBOM on every release — so downstream redistributors don't have to duplicate the work
  • GPG-signed releases

None of these are presented as legal commitments. They are what good OSS projects do.

3.3 What we explicitly DO NOT do

To prevent any ambiguity that could be read as an implicit commitment:

  • No security response SLA published anywhere public
  • No support window or "supported versions" policy
  • No commitment to fix any specific class of vulnerability within any timeframe
  • No Annex I essential-requirements statement of compliance
  • No CE marking of any artefact
  • No EU Declaration of Conformity signed
  • No registration as a CRA steward with ENISA
  • No 5-year support commitment (AGPL says "as is, forever" — legally: no guarantee we'll patch anything)

This restraint is intentional. Every one of the above, once made, creates potential legal obligation. AS-IS OSS means no such obligations.

4. Alternatives considered and rejected

4.1 Open-source steward (Art. 24) registration

Rejected. The steward regime still requires:

  • Documented cybersecurity policy (public)
  • Cooperation with EU market surveillance (ongoing obligation)
  • ENISA actively-exploited-vuln notification (24 h — a legal commitment)
  • Coordinated disclosure facilitation (process obligation)

These are small individually but collectively create a named-entity obligation that has to be staffed and maintained. For a small team without dedicated compliance capacity, AS-IS OSS is materially simpler and safer.

4.2 Full manufacturer compliance on OSS

Rejected. Heavy cost, material product-liability exposure, and no proportionate benefit for a non-commercial OSS project.

4.3 Silent / no statement at all

Rejected. Without an explicit AS-IS statement a court might interpret commercial-looking channels (e.g. a paid-infrastructure-hosted release domain) as implicit placing on the market. An explicit AS-IS disclaimer forecloses that argument.

5. Risks and open questions

5.1 Classification: is distribution of the OSS binaries itself a "commercial activity"?

CRA Article 2(5) excludes OSS not placed on the market commercially. Recital 18 clarifies that "in the context of free and open-source software that is made available on the market in the course of a commercial activity, and only in that context, this Regulation should apply".

Whether our distribution counts as "commercial activity" depends on facts, not on what we say. Factors likely to weigh in our favour:

  • Binaries are free
  • Source is fully open under AGPL
  • Distribution domain (xiboplayer.org) is project-focused, not commercial
  • No paid features, tiers, or upsells on the OSS side

The explicit AS-IS language in §3.1 is the legal shield. AGPL's disclaimer plus the explicit non-commercial positioning are the mechanisms by which we intend to remain outside CRA's "commercial activity" test.

5.2 Competitor-triggered complaint

A competitor could file a complaint with an EU market surveillance authority asserting we are placing OSS on the market commercially. Mitigation: the AS-IS posture documented here is the defence; having it written, signed, and consistently applied is what makes it credible.

5.3 Downstream commercial redistributors

Anyone who redistributes xiboplayer in a commercial context becomes their own manufacturer for CRA purposes. That is their obligation, not the OSS project's — and nothing in this RFC is intended to transfer compliance from the redistributor to upstream.

6. Artefacts

This posture is backed by the following concrete files and URLs, each of which is the ground truth for a specific claim above:

7. References

RFC-0001 is authored by Pau Aliagas pau@xiboplayer.org on behalf of the xiboplayer open-source project, in Catalonia, European Union. It is not legal advice. This RFC is published pending external counsel review.