The problem
The registry currently assumes listing content (names, descriptions, screenshots from .camp/listing.yml) carries the plugin's own license. That holds well enough for community GPL plugins, but it is not strictly true and it breaks down for commercial vendors: product names and logos are trademark, not copyright, and marketing copy committed beside a GPL plugin is not automatically GPL. LICENSE-DATA now states the trademark reservation (no data license here grants mark rights or implies endorsement), but a reservation is not control. A vendor deciding whether to participate needs a way to say what applies to their content, in a form machines can honor.
Proposed mechanism
An optional content-license: block in .camp/listing.yml, where authors already control their listing:
content-license:
default: plugin # the current assumption, now explicit
screenshots: display-only
description: display-only
- Absent means current behavior (content under the plugin's license), so nothing changes for existing listings and the zero-config promise holds.
- A floor built into every allowed value: at minimum, the registry may re-encode, host, and display the content. This is non-negotiable because of the privacy model (RFC §4.6): every asset serves from the registry, never from a vendor origin, so visitors are never exposed to third-party tracking. For the same reason, reference-not-embed (storing URLs to vendor-hosted assets instead of the bytes) is deliberately not adopted, despite being the conventional answer to vendor asset control.
- Withdrawal is prospective and already in the author's hands: listing.yml is theirs; removing content removes it at the next release, and the pinned history keeps only what was published.
- Mirrors honor declarations machine-readably: the factual record always replicates (it is CC0/ODbL data); rich content travels only where its declared license permits, and is omitted otherwise. A listing with withheld content still appears everywhere as facts plus links.
- Vocabulary starts small:
plugin (follows the plugin license), free (CC BY style, replicate with attribution), display-only (registry display only; mirrors omit). Extensible later; enumerated in the schema so values are validated.
What "enforcement" means here
Three layers, worth keeping separate:
- Technical prevention: none, by design. The index and its assets are public and mirrorable; metadata cannot stop a clone or a scrape, and the registry will not DRM public data. Nothing in any registry is enforceable in this sense.
- Legal force: real, and it belongs to the content owner. Content declared
display-only remains the owner's copyright; the registry never acquired the right to sublicense it and therefore never did. A mirror that redistributes it anyway infringes against the owner, who holds the ordinary remedies. The declaration sharpens those rights rather than creating them: an explicit machine-readable notice on the record removes the implied-license defense a mirror could otherwise build from "it was published inside an openly licensed index."
- Normative compliance: the default path. Official mirror tooling reads the declarations and omits withheld content automatically, so complying takes zero effort and infringing takes deliberate effort. Good-faith mirrors are covered by tooling; bad-faith copying is covered by the owner's legal rights; there is no third category.
The docs should state this plainly: the registry cannot technically prevent copying and has no standing to enforce content rights it does not own; the metadata's job is to make the owner's terms explicit so that compliance is automatic and infringement is indefensible.
Scope when built
listing.schema.json + ingest validation, site rendering (a rights line on the plugin page), MIRRORING.md replication semantics, LICENSE-DATA and AUTHORS.md updates, and a DESIGN.md entry recording the decision, including the reference-not-embed rejection and its reason.
Filed as a design candidate; not scheduled.
The problem
The registry currently assumes listing content (names, descriptions, screenshots from
.camp/listing.yml) carries the plugin's own license. That holds well enough for community GPL plugins, but it is not strictly true and it breaks down for commercial vendors: product names and logos are trademark, not copyright, and marketing copy committed beside a GPL plugin is not automatically GPL. LICENSE-DATA now states the trademark reservation (no data license here grants mark rights or implies endorsement), but a reservation is not control. A vendor deciding whether to participate needs a way to say what applies to their content, in a form machines can honor.Proposed mechanism
An optional
content-license:block in.camp/listing.yml, where authors already control their listing:plugin(follows the plugin license),free(CC BY style, replicate with attribution),display-only(registry display only; mirrors omit). Extensible later; enumerated in the schema so values are validated.What "enforcement" means here
Three layers, worth keeping separate:
display-onlyremains the owner's copyright; the registry never acquired the right to sublicense it and therefore never did. A mirror that redistributes it anyway infringes against the owner, who holds the ordinary remedies. The declaration sharpens those rights rather than creating them: an explicit machine-readable notice on the record removes the implied-license defense a mirror could otherwise build from "it was published inside an openly licensed index."The docs should state this plainly: the registry cannot technically prevent copying and has no standing to enforce content rights it does not own; the metadata's job is to make the owner's terms explicit so that compliance is automatic and infringement is indefensible.
Scope when built
listing.schema.json + ingest validation, site rendering (a rights line on the plugin page), MIRRORING.md replication semantics, LICENSE-DATA and AUTHORS.md updates, and a DESIGN.md entry recording the decision, including the reference-not-embed rejection and its reason.
Filed as a design candidate; not scheduled.