Skip to content

Decide how the CC BY-SA licence footer survives the cutover: a theme default or a per-repo footer.md #203

Description

@mmcky

Part of #147 (parity study 2026-09-11 — decisions).

Problem

Every lecture page built with quantecon-book-theme ends with the same footer: a CC BY-SA 4.0 badge, the sentence "Creative Commons License – This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International." and "A theme by QuantEcon". The footer is written straight into the page template with no condition around it, so every Sphinx lecture site shows it without configuring anything (layout.html L353-L361).

This theme renders a footer only when a site sets site.parts.footer (PageContent.tsx L105). The part is declared with no default in template.yml L20-L22, and SiteFooter.tsx L6-L22 renders whatever Markdown the site supplies. With the part unset, the page has no footer at all: no licence notice and no theme credit. Nothing under app/ reads MyST's license field. docs/layout.md L39-L48 says the part matches "the Sphinx sites' footer block", but it gives no standard content and no warning that leaving the part out removes the licence notice. Neither docs/ nor README.md mentions a licence.

The content-driven footer was a deliberate choice. PLAN.md L59 lists "content-driven footer" as already at parity, and the comparison table in #33 recorded the footer as "Parity (improved: configurable)". Neither says that the licence notice is no longer shown by default.

Where the consumers stand:

Site site.parts.footer What a reader sees
lecture-wasm (live on this theme) not set; its site: block holds only template (myst.yml L119-L122) no licence or Creative Commons text (verified on the live site 2026-09-11)
lecture-python-programming jb2 branch (open PR QuantEcon/lecture-python-programming#363) footer.md (myst.yml L90-L92) the badge and licence sentence, without "A theme by QuantEcon" (footer.md L1-L6)
this repo's visual-test fixture footer.md (myst.yml.in L44-L45) the badge, the licence sentence and "A theme by QuantEcon" (footer.md L1-L5)

#147 records the cutover as all-or-nothing, with every lecture series moving at once. Any series that moves without its own footer.md loses the licence notice, as lecture-wasm already has.

Decision needed

When a site sets no site.parts.footer, should the theme supply the licence notice and theme credit itself, or should adding footer.md be a documented migration step for each lecture repo?

Option 1: default footer when the part is unset Option 2: footer.md as a documented migration step
What changes The theme renders built-in licence and credit content when site.parts.footer is absent. A site that sets the part keeps its own content. docs/layout.md gives the standard footer.md content and warns that omitting the part removes the licence notice. footer.md becomes a per-repo step in the cutover migration.
For Same behaviour as the Sphinx theme. With a hard-coded default there is no per-repo step to forget, and lecture-wasm gets the notice on its next theme bump. No licence terms in theme code, so each site states its own. The theme's behaviour stays as PLAN.md and #33 recorded it, and only docs change in this repo.
Against The theme states a licence for content it does not own, so a site under other terms has to know to replace it with its own footer.md. SiteFooter takes a Markdown tree, so a default needs either a built-in tree or a separate fallback, plus a badge. The theme bundles no CC badge, and the Sphinx theme hot-links licensebuttons.net (layout.html L355). Every repo has to remember the step, and lecture-wasm has already missed it. Each repo decides about the credit, and the jb2 footer.md already leaves it out.

Points that bear on the options:

  • Where option 1 gets its text. The default could be hard-coded, as the Sphinx theme does, or built from MyST's project.license. That field does reach the theme: the fork lists license among the project frontmatter keys (project/types.ts L16-L21) and copies project frontmatter into the site manifest (manifest.ts L143-L167). But neither lecture-wasm's myst.yml nor the jb2 one sets it, so building from it would trade a footer.md for a license: entry in each repo. The per-repo step would remain.
  • Option 2 cannot be enforced through template.yml. Marking the part required would not catch a missing footer. The site build validates the template's options and frontmatter but not its parts (manifest.ts L370-L385), and validateParts runs only inside MystTemplate.prepare (template.ts L201-L218), which the site build does not call.
  • The theme credit. Whether "A theme by QuantEcon" stays is part of this decision. Under option 1 the theme decides. Under option 2 each repo's footer.md does.

Report's lean: the study recommends adding this to the #147 gate as a decision to settle before the cutover. It names both options and does not choose between them.

Acceptance criteria

  • The decision is recorded on this issue: option 1 (saying whether the default is hard-coded or built from project.license) or option 2.
  • The decision says whether "A theme by QuantEcon" stays, and where it is set.
  • If option 1: a site without site.parts.footer renders the licence notice (and the credit, if kept), a site with the part renders only its own content, and a test covers the unset case.
  • If option 2: docs/layout.md shows the standard footer.md content and warns that leaving the part unset removes the licence notice. footer.md is also listed as a per-repo step in the cutover migration plan (Lecture repos moving off the Sphinx theme have no checklist of what myst.yml and CI must now set #209), or in PLAN.md's "Consumer migration" checklist until that plan exists.
  • PLAN.md:59 is no longer edited: PLAN.md gets a closing note instead of row edits (Close out PLAN.md now that the parity plan is complete #218).
  • An issue or PR in QuantEcon/lecture-wasm is linked here to restore the notice on that site, either through a footer.md or through a theme bump that carries the default.

Context

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussOpen-ended team deliberation or a decision to be made

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions