Skip to content

Choose and add a LICENSE for the cdcf-website repo #52

@JohnRDOrazio

Description

@JohnRDOrazio

Problem

The repo has no LICENSE file and no "license" field in
package.json. By default, this means no license is granted:
the code is technically all-rights-reserved, which conflicts with
the foundation's stated open / commons mission and prevents anyone
else from using or contributing to the codebase with confidence.

Surfaced by the README badge work in #51 — the README couldn't get
a license badge because there's nothing to point at.

Why this needs board + technical council input

License choice is a governance decision, not a developer decision:

  • It commits the foundation to a specific stance on permissive vs
    copyleft, on patent grants, and on what downstream users can do
  • It interacts with the foundation's own governance docs and the
    vetting criteria (Unify deploy.yml and deploy-staging.yml into a single environment-parameterized workflow #46-style decisions about what we accept from
    community projects)
  • It needs to be consistent across the foundation's repos so
    community contributors aren't navigating mismatched terms

Precedent in the foundation

CatholicOS/foundation-docs is licensed under Apache 2.0.
Adopting the same here would be the obvious-default for
consistency, but the technical reality is more nuanced (see below).

Technical complication: this repo has two licensing zones

This repo contains both Next.js application code and WordPress
theme/plugin code. WordPress is GPLv2-licensed, and themes/plugins
that link against WordPress are typically considered derivative
works (the WordPress Foundation's stance), so they're effectively
required to be GPLv2-compatible:

Path What it is License constraint
app/, components/, lib/, src/, proxy.ts, next.config.ts, package.json, etc. Next.js standalone app (talks to WP over HTTP) NOT a WP derivative work — free to choose
wordpress/themes/cdcf-headless/ WordPress theme Inherits GPLv2 from WordPress
wordpress/plugins/cdcf-redis-translations/ WordPress plugin Inherits GPLv2 from WordPress
wordpress/translate-all.php WP-CLI script Inherits GPLv2

So the practical license options are roughly:

  1. Apache 2.0 root + GPLv2 wordpress/ — matches foundation-docs
    precedent on the Next.js side; honors WP's GPL on the WordPress
    side. Two LICENSE files (or per-directory headers). Most
    common pattern in mixed Next.js + WP codebases.
  2. GPLv2-or-later everything — single license, conceptually
    simpler. More restrictive on the Next.js side than Apache 2.0;
    diverges from foundation-docs.
  3. Apache 2.0 everything — clean and consistent with
    foundation-docs, but legally questionable for the WordPress
    theme/plugin since Apache 2.0 has explicit patent termination
    that GPLv2 doesn't, raising compatibility questions for the WP
    parts.
  4. Dual-license on the WordPress side (Apache 2.0 + GPLv2)
    more legally elaborate; gives downstream the choice. Less
    common; needs careful drafting.

Suggested decision points for the board / technical council

  • Confirm whether the foundation's general stance is permissive
    (MIT/Apache) or copyleft (GPL/AGPL/MPL)
  • Confirm comfort with patent grants (Apache 2.0 has one;
    MIT does not)
  • Decide whether mixed licensing in one repo (option 1) is
    acceptable operationally, or whether we should split the
    WordPress theme/plugin into separate repos to keep this one
    under a single license
  • Add "license": "<SPDX-id>" to package.json and add a
    LICENSE file (or files) at the chosen scope(s)
  • Backfill license headers in source files per project
    convention (Apache 2.0 typically requires a NOTICE file +
    header in each source file; GPL is less strict about per-file
    headers but encourages them)

Related

Out of scope

  • Choosing on the developer's own authority — this is intentionally
    a governance decision
  • Writing the LICENSE text(s) before that decision is made

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions