Q3 ships under Apache-2.0. That is only true if nothing in the tree is a derivative work of code under an incompatible license. This document explains the mechanism, draws the line between what is and is not a derivative work, and gives a procedure that keeps you on the right side of it.
It binds humans and AI coding agents equally. CONTRIBUTING.md § "Provenance
policy" states the rules; this file is the reasoning and the recipe behind them.
Engineering guidance, not legal advice. When a specific case is genuinely unclear, stop and escalate rather than deciding alone.
Computational materials science is a small field with a few reference implementations, and the useful ones are either strong-copyleft open source (GPLv2-or-later) or proprietary and licensed. Both create problems, for opposite reasons.
Copyleft. If a work is a derivative of GPL code, the whole work must be distributed under the GPL. The incompatibility runs one way: Apache-2.0 code can be absorbed into a GPL project, but GPL code cannot be absorbed into an Apache one. So a single GPL-derived file makes two things true at once:
The second is the one that ends adoption. "This Apache project may be GPL-encumbered" is the single sentence that makes an industrial legal team say no, and it is not repairable by apologising later.
Proprietary. Licensed source usually carries confidentiality obligations as well as copyright. Consulting it while implementing a competing feature creates exposure that no amount of later rewriting removes, because the problem is the act, not the artifact. See § 6.
Courts filter a program into layers, discard everything unprotectable, and compare only what is left: ideas, anything dictated by external constraints or efficiency, and public-domain material all fall out first.
Copying the expression, meaning:
Translating code is explicitly a derivative work, exactly as translating a novel is. Rewriting a Fortran routine in C++ launders nothing. This is the single most likely way to create a problem in a codebase like this one, and the reason the red-flag phrases in § 4.2 are forbidden: they describe the act that creates a derivative.
For a closed-form expression, there is essentially one reasonable way to write it — the expression merges with the idea, and it is not protectable. A smearing function or a Bessel recurrence transcribed from anywhere is almost certainly fine on the merits.
For a 200-line routine with a distinctive internal structure, it is not fine. The more scaffolding a piece of code has — ordering, decomposition, bookkeeping — the more of it is protectable expression rather than mathematics.
Follow this whenever you implement anything that another computational materials science code also does.
Find the paper. Nearly every algorithm here has one: a smearing scheme, a mixing method, a correction term, a PAW construction. Implement from the mathematical statement. If you cannot find a published description, that is itself a signal — ask before proceeding.
| Source | May you read it? |
|---|---|
| Public, permissively licensed | Yes, freely |
| Public, strong copyleft (GPL) | In a research session only (below) — never to copy |
| Proprietary / licensed source | No. Do not open it. See § 6 |
| Public documentation, manuals, wikis | Yes |
| Another engine's output files | Yes — outputs are data, not expression |
If you consulted another implementation: close it before you write. Do not have it open in a second buffer, and do not paste it into a scratch file to "work from". Write from your understanding plus the paper.
For an AI agent this is a hard rule with a specific failure mode: never place license-incompatible source into your context and then generate the corresponding implementation in the same session. That is machine-assisted translation, and it produces a derivative work. The two kinds of session below make this rule operational.
Use the naming conventions in AGENTS.md (no abbreviations), the layer structure, and the decomposition that fits Q3 — not the one that fitted the other code. If your implementation's structure closely mirrors theirs, treat that as a signal to restructure, not as confirmation that you got it right.
Compare numbers, not code. Q3's cross-code gates already do this: same inputs, compare energies, forces, stresses to a tolerance. Numerical agreement is the evidence that the implementation is correct, and it says nothing about how either side is written. This is why validating against a reference code is not only safe but desirable.
Provenance comments are an asset. Keep writing them — just describe what actually happened (§ 4).
Step 3 separates reading from writing. For AI-assisted work that separation is a property of the session: one conversation context, including everything carried into it — summaries of earlier context, forks of another session, and files or notes it was handed. A person's session is a stretch of work on one task. Every session is exactly one of two kinds, decided before it starts.
A session does not change kind partway through. A research session that finds a defect reports it; the fix is written in a separate implementation session. A fork or continuation of a research session is a research session.
Research notes pass to an implementation session as prose. If a note quotes source code, it is not a research note: remove the quotation before it is handed over.
The check § 4.4 says nothing cheaper can replace — reading an implementation next to the code it might derive from — is a research session, done by someone who did not write the code under review: a person, or an AI session run by someone other than the module's author. The reviewer compares structure (decomposition, naming, control flow, the order of operations where alternatives existed; § 2), not numbers. Reviews are recorded per module in the provenance register, which also lists each module's published sources and validation gates; § 7 says when to update it.
Naming another engine as a reference you validated against, or whose convention you matched, is accurate, useful, and safe. Keep doing it.
Each describes creating a derivative work. If one of these is the honest description of what you did, the problem is the code, not the comment — go back to § 3.
The red-flag list is a wording check, and wording is the easy half. A mechanical search finds phrases and recognisable foreign syntax. It does not find carried-over structure — and structure is what makes a work derivative.
A concrete case from this codebase: a verbatim line of upstream Fortran survived in a symmetry routine as an array-index expression. It contained no red-flag phrase and no distinctive foreign syntax, so both a transcription-wording search and a Fortran-syntax search were structurally blind to it. It was found by reading the implementation against the upstream source, and nothing cheaper would have found it.
So treat § 7's checklist as a floor, not a proof. The only reliable check is reading the implementation next to the thing it might derive from — which is why § 3's discipline (write from the paper, close the source before writing) matters far more than any audit run afterwards. An audit is a backstop for process failures, not a substitute for the process.
Removing a provenance comment does not change whether the code is a derivative. It removes the evidence that provenance was tracked in good faith, and if the question is ever raised, a deletion reads as concealment rather than diligence. Rewrite the code if it needs rewriting; never quietly strip the trail.
Citing the reference implementation of an on-disk format — including specific line numbers — is allowed. A format is a specification, not an algorithm: implementing it is interoperability, and removing such citations would make the readers and writers unmaintainable with no offsetting benefit. Existing citations of this kind stay by owner decision.
Cite the published specification first, and the converter only for what it leaves open. A published spec is strictly better provenance than a converter's source: it removes the licensing question entirely, and it does not rot the way a citation pinned to a dated checkout of a moving branch does. Where a format has no spec, or the spec is silent on a detail, the program that writes the files is the authority. Cite it by release tag, subroutine and record, never by line number on a development branch, and state what the code computes in this codebase's notation, never as a quoted expression in the other code's variable names.
The BerkeleyGW export resolved this question on 2026-10-20 as follows:
vxc.dat in J. Deslippe et al., Comput. Phys. Commun. 183, 1269 (2012), Appendix 11.1 (arXiv:1111.4429). It gives each header record's contents, order and units, the body layout, the normalization of RHO's G = 0 component, and vxc.dat's line contents in eV. The BerkeleyGW 4.0 manual specifies only the HDF5 variant (wfn_h5_spec). The readers and writers in src/io/mean_field_export/berkeleygw/ and tests/helpers_berkeleygw.py cite the appendix as their authority.vxc.dat's column widths, or the exact transposition and pairing of the symmetry records. For these the citation is Quantum ESPRESSO's pw2bgw.x at release 7.5 (tag qe-7.5, the version of the local reference build), named by subroutine (write_wfng, write_rhog, write_vxc_g, write_vxc_r) and record. The symmetry conventions are also pinned by unit tests against that release's output.parabands.f90 for VSC (read with the RHO/VXC routines) and pp_read_header/pp_read_beta in MeanField/ParaBands/pseudopot_vkb.f90 for VKB, with the contraction Σ β D β† from ham_build_column_nl_col in hamiltonian.f90. That Vxc is evaluated at the valence density follows pw2bgw's documented input vxc_zero_rho_core (INPUT_pw2bgw, the public manual). No GPL source was opened; both were validated against pw2bgw.x's output files and through parabands.develop checkout, and the Fortran expressions quoted with QE's variable names, were replaced by the record they describe and the mathematics it carries. No citation was removed without a replacement.Instructions for running another engine to regenerate reference data — executable names, input decks, build paths — reference programs, not source. Keep them: without them the validation data cannot be reproduced.
A GPL dependency is not a provenance problem for our source, but it is a distribution problem for our binaries:
So a permissively licensed backend must be the default in anything we publish as a binary. Check this before adding a dependency, not after.
Tests that deliberately contain forbidden strings — to prove a guard rejects them — are correct and must not be "cleaned". They are the guard's evidence that it still works.
For licensed, non-public source, the rule is not "be careful", it is do not open it. Ground the work instead in:
This is stricter than the GPL rule because the obligation is different: a confidentiality term is breached by the access, not by the artifact, so there is no later rewrite that undoes it.
This list is a floor, not a proof — see § 4.4 for what it cannot catch.
Do not delete the comment, and do not quietly rewrite the file.
An honest report is cheap to fix. A concealed one is not, and concealment is the part that turns a technical question into a credibility problem.
1.9.8