feat(site): show each feed's data licence, and widen the adopters lead - #45
Merged
Conversation
"Can I consume this feed" has two halves: which spec version it speaks, and what the licence lets me do with it. The second one was nowhere on the site. The health check now resolves the licences a consumer actually ends up with — per event, with feed-level inheritance applied — instead of reporting feed.license. That distinction is the whole point: an event may override the feed's licence, and an aggregator feed may omit feed.license entirely as long as every event carries its own, so a badge built from feed.license alone would be wrong exactly for the mixed feeds where the question matters most. A feed with one effective licence shows it; a feed with several says "3 licences" and the tooltip lists them and points out that aggregating means checking each event. A licence given as a URL has no honest short label, so it reads "custom licence" with the URL in the tooltip. Also: the adopters lead said "communities and events", which undersold who the registry is for — conferences and directories publish here too, and what they expose is their event data. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #44. Two changes.
Licence badge
Deciding whether to consume a feed has two halves: which spec version it speaks (#44) and what its licence permits. The second was nowhere on the site.
The catch is that
feed.licenseis not the answer. Per the spec, an event may override the feed's licence, and an aggregator may omitfeed.licenseentirely as long as every event declares its own — so a badge built fromfeed.licensewould be wrong precisely for the mixed feeds where a consumer most needs to know.check-feeds.mjstherefore resolves the effective licences (per event, inheritance applied) andfeed-health.jsonreports the distinct set:CC0-1.03 licences, with a tooltip listing them and noting that aggregating the whole feed means checking each event's, not only the feed'sCustom licence, URL in the tooltip; no short label can honestly summarise arbitrary termsFailure state is still not shown publicly — health is for maintainers (issues) and for consumers via JSON.
Adopters lead
"Communities and events already exposing their data in this format" → "Communities, conferences and directories exposing their event data in this format" (and the Spanish equivalent). Conferences and directories publish here too, and what they expose is their event data.
Verification
Checked in the browser against the local site, including synthetic health data for the mixed-licence and URL-licence cases: badges, labels and tooltips render correctly in both languages.
npm run validatepasses.🤖 Generated with Claude Code