RFC86: Relicense cBioPortal from AGPL to Apache 2.0 [Epic]

[jjgao]

Overview

This epic tracks the full relicensing of cBioPortal from AGPL to Apache 2.0 as proposed in RFC86.

Why

• NCI ITCR and CZI funder requirements mandate permissive licenses
• AGPL's perceived "viral" nature has blocked adoption by pharma, biotech, and tech companies
• Apache 2.0 provides explicit patent grants required by many corporate legal teams

Why Apache 2.0 over MIT

Apache 2.0 is chosen over MIT because it includes an explicit patent grant + retaliation clause — critical for corporate/industry adoption (same choice made by Kubernetes, etc.). MIT is silent on patents.

---

Deadline: 2026-09-30

This is aggressive relative to precedent — mpv's comparable GPL→LGPL relicensing (mpv-player/mpv#2033) took 4+ years on a smaller codebase. Hitting it requires running phases in parallel rather than strictly serially. Backward-planned schedule:

Track	Window	Notes
Phase 0 (#1)	Jul 10–17	Fast — scope largely already known
Phase 1 (#2)	Jul 10–28	Starts in parallel with Phase 0 on known components
Phase 2 (#3) — Team lead consent	launched Jul 31, deadline Aug 31	Team-lead sign-off via cbioportal#12282, runs in parallel with Phase 3 tail
Phase 2 (#3) — Individual outreach	launched Jul 28, deadline Sep 20	Runs in parallel with Phase 3; closes when notice period ends
Phase 3 (#4)	Aug 21 – Sep 20	Fixed 30 days, runs in parallel with Phase 2
Sign-off Gate (#5)	Sep 20–23	Fast if the record is assembled continuously through Phases 1–3
Phase 4 (#6)	Sep 23–30	Fast if header scripts are dry-run tested during Phase 1

Critical path risk: Phase 3's fixed 30-day window (Aug 21 – Sep 20) gates the switch commit. Phase 2 individual outreach runs in parallel and closes Sep 20; team lead consent (deadline Aug 31) provides additional coverage before the notice period ends.

Scope: "cBioPortal" is not a single code boundary

The released product spans multiple separately-governed components, so the relicense scope must be defined before the audit and outreach begin (it sets the denominator for both):

• This repo is backend only (per README.md); the frontend lives in cBioPortal/cbioportal-frontend, which is itself AGPL-3.0-or-later.
• pom.xml pins and bundles the frontend via <frontend.version> (currently v7.0.0-rc.1).
• Docker images / cbioportal-docker-compose, docs & site assets, generated API docs, sample/test data, database scripts, and legacy web assets may each carry separate source/licensing/notice questions.

Implication for Phases 1–2: the SBOM (Phase 1) and the contributor-consent denominator (Phase 2's "≥95% by volume") must span every in-scope repo/component, not just this one. Per-component relicensing also does not by itself resolve the combined-work question: a Docker image that bundles an Apache backend with an AGPL frontend is still, as distributed, AGPL (incl. §13 network-use obligations). The sign-off gate (#5) must therefore assert an effective license for the combined/served distribution, not only per-artifact licenses.

Phases

• Phase 0: Release & Component Scope — RFC 86 Phase 0: Release & Component Scope #1 — Define a public component/release manifest.
• Phase 1: Compliance & Dependency Audit — RFC 86 Phase 1: Compliance & Dependency Audit #2
• Phase 2: Contributor Outreach & Consent — RFC 86 Phase 2: Contributor Outreach & Consent #3
• Phase 3: Community Feedback & Notice Period (30 days) — RFC 86 Phase 3: Community Feedback & 30-Day Notice Period #4
• Pre-Switch Sign-off Gate — RFC 86 Pre-Switch Sign-off Gate (blocks Phase 4) #5 (hard blocker on RFC 86 Phase 4: Technical Execution (Switch Commit) #6; consolidates the signed relicensing record)
• Phase 4: Technical Execution (Switch Commit) — RFC 86 Phase 4: Technical Execution (Switch Commit) #6
• Phase 5: Future Governance (DCO + license scanning) — RFC 86 Phase 5: Future Governance (DCO + License Scanning) #7

References

• RFC86: Change the cBioPortal Open Source License from AGPL to a more permissive Apache 2.0 license
• Preliminary SBOM/dependency PR: Add RFC86 dependency-license audit doc for Apache-2.0 relicensing readiness (backend + frontend) cbioportal#12125 (closed 2026-07-10, superseded by RFC 86 Phase 1: Compliance & Dependency Audit #2's dependency-audit.md)
• AI authorship PR: Add ORDER BY for deterministic query results cbioportal#12014

[jjgao]

Process review note: I’d add one explicit cross-phase gate before Phase 4: legal/project-owner sign-off on the complete relicensing record. The epic already has phase blockers; the missing artifact is a single public index that links:

• final SBOM/dependency resolution table
• contributor/rightsholder consent matrix
• unreachable-contributor disposition/removal evidence
• community notice + feedback summary
• switch commit/release decision record

This makes the eventual switch commit auditable and avoids scattering the rationale across phase issues.

[jjgao]

Agree with adding this gate — a single auditable record before the Switch Commit is the right call. A few suggestions to make it enforceable rather than aspirational:

Make it a hard blocker, not a note. Add the sign-off artifact as an explicit Blocked by on #6, mirroring the existing phase blockers. Phase 4 shouldn't be startable until the index exists and is signed off.

Keep the record immutable. A GitHub issue is mutable and easy to edit after the fact. For something meant to survive an audit, commit the index into the repo (e.g. docs/relicensing/) so the "switch commit/release decision record" lives in git history alongside the switch itself, with the issue just linking to it.

Two line items I'd add to the index:

• AI-authorship determination. Phase 1 (#12157) flags Co-Authored-By: Claude commits for legal review (PR Add ORDER BY for deterministic query results cbioportal#12014). The legal conclusion on those belongs as its own entry in the record, not buried in the Phase 1 report — it's the most novel question here and the most likely thing an outside reviewer asks about.
• Dependency closure, not just inventory. Phase 1 produces an SBOM + "resolution plan." The gate should show each AGPL/incompatible dependency was actually resolved (replaced/removed/permitted), not merely planned. Same for the Phase 2 ≥95% threshold: the record should reconcile that the remaining <5% was in fact rewritten or removed, with commits linked — the Vanish List alone documents who was unreachable, not how their code was disposed of.

Name the signatories. "legal/project-owner sign-off" is stronger if it names them — counsel plus the Tier-1 institutions that hold the bulk of the copyright (MSKCC, DFCI, PMCC, CHOP, Hyve, SE4BIO per #3). Their explicit sign-off on the final record is what makes the switch defensible.

_{Drafted with Claude Code.}

[jjgao]

One additional epic-level gap I’d track: define the release/component scope explicitly before Phase 3/4.

The epic says “cBioPortal”, but the released product is not a single code boundary. This repo’s README points out that this repository contains the backend while cBioPortal/cbioportal-frontend is a separate repo; pom.xml also pins a frontend artifact via <frontend.version>. PR cBioPortal/cbioportal#12125 already found that the frontend repo itself is AGPL-3.0-or-later and has its own copyleft/manual-review dependency questions. Docker images, docs/site assets, generated API docs, sample/test data, database scripts, and legacy web assets may also have separate source/licensing/notice questions.

I’d add a public component/release manifest to the pre-switch gate. For each artifact shipped or referenced by the Apache 2.0 release, record: repo/path/artifact, exact tag/SHA/version, current license, rightsholder/consent status, dependency-scan status, target treatment (relicensed, excluded, externally provided, or historical only), required notices, and the PR/tag that closes it. Phase 4’s switch commit and signed release tag should point at this manifest.

This avoids an ambiguous outcome where the backend repo is switched, but downstream users reasonably read the combined portal distribution as Apache 2.0 while bundled/pinned components are still AGPL or unresolved.

[jjgao]

Strongly agree, and I think this is the most consequential gap raised so far — it's a scope/boundary problem, which is more fundamental than the audit-trail point above. Confirming the facts against the current tree:

• pom.xml pins <frontend.version>v7.0.0-rc.1</frontend.version> and bundles that artifact at build time.
• Backend LICENSE and the frontend's LICENSE / package.json ("license": "AGPL-3.0-or-later") are both AGPL-3.0.
• README.md states outright: "This repo only contains the backend part," pointing to the separate frontend repo.

So the per-artifact manifest is the right instrument. Two things I'd add:

1. The manifest should come first, not just before the switch — it reshapes Phase 1 and 2. Phase 2's "≥95% of the codebase by volume" is undefined until the boundary is fixed: which codebase? If the frontend is in scope, the contributor-consent denominator and the outreach list (#12158) must span both repos, and the Phase 1 SBOM (#12157) must too. As written, those phases implicitly assume a single repo. Defining the component scope is an input to the audit, not an artifact assembled just before Phase 4.

2. Per-component treatment doesn't by itself resolve the combined-work question. Even with every artifact individually labeled, the Docker distribution ships backend + pinned AGPL frontend together, and a user pulling that image reasonably reads the whole portal as one license. The manifest needs one field above the per-row treatment: the effective license of the combined/served distribution. Until the frontend is also relicensed (or swapped/excluded), the honest answer for the combined product is still AGPL — including AGPL §13 network-use obligations for anyone running the stack. The pre-switch gate should assert that combined-distribution license explicitly, so "backend is Apache now" can't be misread as "the portal is Apache now."

_{Drafted with Claude Code.}

[jjgao]

Process consistency review: the epic and subissues are now mostly coherent.

The main flow is aligned: Phase 0 (#12182) defines the component/release scope; Phase 1 (#12157) and Phase 2 (#12158) consume that scope; Phase 3 (#12159) feeds the pre-switch sign-off gate; the gate (#12183) blocks Phase 4 (#12160); and Phase 4 is now framed as mechanical execution after eligibility/consent/sign-off are complete. The prior comments on audit scope, rights-holder tracking, notice contents, switch mechanics, DCO timing, component scope, and combined-distribution licensing are all represented.

A few remaining consistency cleanups I’d make:

1. Small dependency cycle in RFC 86 Pre-Switch Sign-off Gate (blocks Phase 4) #5. The gate says every line item must be closed before Phase 4 starts, but one line item is “Switch commit / release decision record — the signed Phase 4 tag should point at this record.” The signed Phase 4 tag cannot exist before Phase 4. I’d change the gate item to require the planned switch release/commit decision record, and leave signed-tag verification in RFC 86 Phase 4: Technical Execution (Switch Commit) #6.

2. Narrow Phase 4’s boundary statement. RFC 86 Phase 4: Technical Execution (Switch Commit) #6 still says “All code before this commit = AGPL; all code after = Apache 2.0.” That is slightly broader than the Phase 0/1 model, because third-party, vendored, generated, excluded, externally provided, and historical-only artifacts may retain separate treatment. I’d narrow it to “all in-scope, project-owned code selected for relicensing.”

3. Fix the rendered pom.xml property name. In RFC86: Relicense cBioPortal from AGPL to Apache 2.0 [Epic] #8 and RFC 86 Phase 0: Release & Component Scope #1, the frontend.version reference appears to render as empty inline code (via ```). Use frontend.versionor escaped<frontend.version>` so the property is visible.

4. Clarify Phase 5 wording around DCO. RFC 86 Phase 5: Future Governance (DCO + License Scanning) #7 is substantively okay, but “Blocked by Phase 4” plus “DCO enforcement must precede Phase 4” is a little awkward. Cleaner wording would say Phase 5 is post-switch governance, while the DCO setup/enforcement task is pulled forward and tracked as a pre-switch gate item in RFC 86 Pre-Switch Sign-off Gate (blocks Phase 4) #5.

No major structural inconsistency beyond those. The current issue set is much more auditable than the original version.

[jjgao]

Thanks — applied 1, 2, and 4:

1. Gate dependency cycle (#12183). Changed the line item to the planned switch release/commit decision record (target boundary + go decision); the signed tag is produced and verified in Phase 4 (#12160), not in the gate. The gate no longer depends on an artifact that can't exist until after it.

2. Phase 4 boundary (#12160). Narrowed "all code before/after" to all in-scope, project-owned code selected for relicensing; third-party / vendored / generated / excluded / externally-provided / historical-only artifacts retain their Phase 0 manifest (#12182) treatment.

4. Phase 5 DCO wording (#12161). Reframed Phase 5 as post-switch governance, with DCO setup/enforcement explicitly pulled forward and tracked as a pre-switch gate item in #5 — removes the "blocked by Phase 4 but must precede Phase 4" contradiction.

3. pom.xml rendering — couldn't reproduce, left as-is. Rendering the live text through GitHub's own markdown API (GFM mode, this repo as context) returns:

input:  via `<frontend.version>`
output: via <code class="notranslate">&lt;frontend.version&gt;</code>   →  displays as: <frontend.version>

Inside backticks the angle brackets are literal, not stripped, and all live instances (#12156, #1) are backticked — so there's nothing to fix; likely a client/cache quirk. Happy to switch to <…> if it still shows blank on your end.

_{Drafted with Claude Code.}