Hey!
thanks a lot for chiming in, still watching the videos!
FWIW, I have come around in that I guess we should add something (a lot
of projects
are discussing this, I would be happy to just steal one too).
I would still focus on the transparency and social part (because I think
that
is the part that affects us more in practice) rather than copyright, but
yeah,
I guess it deserves a place.
It may well be nice to force a checkbox and a short note in the PR
template, I am
not sure what will work there, but it may also depend a bit on the "risk
assessment"
how much detail we need.
Now for copyright issues, I am still a bit unclear what we should ask
for beyond
transparency from the contributor (happy to write that
non-transparency/unclear
provenance is likely to prompt us to just close).
For the maintainer I think the "blast radius" framework could be very
useful and it
may be nice to flesh it out (I don't think there is anything NumPy
specific about it,
i.e. in my mind (1) is basically examples for the blast radius?).
I think the important part there might be to have a few rough examples
and where they
land (but I think I would find it very hard to do this with any
certainty!).
I like the risk-matrix approach, so I think what this would look like is
a risk-matrix:
Risk of
copyright | "Blast radius"
infringement |
| very small ....
----------------|--------------------------------------
very low |
low |
... |
And what we would need examples that vary on both axes and suggest a
very rough line
at which point in the matrix you should start to be very careful and do
extra verification
steps (or just close the PR if you don't want to do those).
At least that is how I would like to approach this when in doubt, but
beyond being pretty
confident that we only had pretty safe PRs for now, I am not sure I
could build up such
a matrix myself.
- Sebastian
On 2026-02-15 10:49, Peter Wang via NumPy-Discussion wrote:
Hey everyone,
Sorry to be jumping in so late on this important thread. And thanks to
everyone for the thoughtful discussion. Numpy is such a visible and
important project, I'm sure that what's decided here will have massive
downstream consequences for the rest of the tech world.
I'm happy to see that there seems to be an emerging consensus of
“principles over policing”: responsibility, understanding,
transparency. One way I think we can make this more concrete by
framing it around *where* in the project a contribution lands, and
what the “blast radius” looks like, in both space and time, if we
later need to debug, rewrite, or (worst case) roll back code for
legal/regulatory reasons.
A few thoughts / straw man of an "AI contribution policy":
(1) Defining “Zones” of the project
We can explicitly acknowledge that different areas of the codebase
that have different tolerance levels for AI-assisted generation.
"Zone" doesn’t have to mean a single folder. It can be:
* a directory tree (e.g., `numpy/core`, `numpy/linalg`, `doc/`,
`tools/`, `benchmarks/`),
* part of the import namespace (public API, internal helpers),
* or a semantic area (core algorithms, ABI-sensitive paths, numerical
stability-critical routines, tutorial content, CI glue, etc.).
For example:
* Inner ring (high scrutiny): core algorithms, numerics,
ABI/API-critical code paths, anything performance-critical or subtle
correctness-wise.
* Middle ring (moderate): tests, refactors, coverage expansion,
internal tooling, build/CI scripts.
* Outer ring (low): examples, tutorials, onboarding docs, “glue”
that’s easy to replace, small utilities, beginner-facing content.
This is explicitly saying that the question of AI isn't a binary
choice, nor e.g. "AI is forbidden in the core". Rather, the closer you
get to code with high blast radius, the more we should demand human
legibility, reviewable provenance, and high confidence in correctness
and licensing posture.
(2) "Blast radius"
When someone asks “should we accept AI-generated code here?”, I
think they have an implicit model about "blast radius" already. We can
render that model explicit with a few dimensions:
* Complexity: Is this code easy to reason about? Does it involve
numerical stability, tricky invariants, edge-case handling, low-level
memory behavior, or algorithmic subtlety?
* Impact & dependency surface: How many downstream things depend on
this? Is it part of public API? Widely imported? Affects core array
semantics? If it changes, do we risk broad downstream breakage?
* Stability & expected lifespan: Is this an area that tends to be
stable for years (core numerics), or something we expect to churn
(docs examples, CI harnesses)? The longer something is expected to
persist, the higher the cost of “oops”.
* Rollback/Replacement cost: If we had to remove it quickly, how
painful would that be? How entangled is it with other code? How hard
is it to recreate by hand?
* Legibility / testability: Can we test it robustly? Can we write
property tests? Are there known oracles? Is it feasible to get strong
confidence quickly?
(3) Transparency: make it concrete, not vague
I think “please be transparent” is right. At a minimum, I think we
need something like a lightweight attestation or affirmation from the
contributor — not a legal affidavit, not a license, not an attempt
to police workflow — but a structured statement that sets reviewer
expectations and creates an audit trail.
Something along these lines (details can be bikeshedded later):
**AI Use Attestation (for PR description template / checkboxes):**
* Did you use an AI tool to generate or substantially modify code in
this PR? (yes/no)
* If yes:
* which tool/model (and ideally version/date — these change fast),
* what parts of the PR were AI-assisted (core logic vs tests vs docs
vs refactors),
* confirm: “I understand this code, I can explain it, and I’m
responsible for it.”
Then scale the requested detail by zone / blast radius:
* Outer/middle ring: model/tool + high-level description is probably
enough.
* Inner ring / high blast radius: I’d like us to consider asking for
more:
* the prompts (or at least the key prompts) used to generate the
logic,
* any intermediate artifacts that help future maintainers understand
how we got here (e.g., the “why” behind design choices, variants
considered, constraints given to the model),
* and ideally a short human-written explanation of the algorithm and
invariants (which is good practice regardless of AI).
I can appreciate that this seems burdensome for small PRs fixing a
tiny thing. But the above is just a straw-man and perhaps there are
some nice simplifications we can engineer to make this as lightweight
a part of the workflow as possible. (Perhaps even a stub
Numpy_ai_contribution_guide.md that gives the code-gen LLM a template
to fill out and include in the PR?)
The analogy I have in mind: treat AI like a nondeterministic *semantic
compiler*. With a normal compiler, we keep intermediate info when we
care: flags, versions, debug symbols, build logs. For high blast
radius code, the prompts and intermediate reasoning are effectively
that metadata. Even if we don’t store everything in-repo, capturing
it in the PR discussion is valuable. This is literally like
preserving the seed, when we have to check in the output of an RNG.
(4) Why keep prompts / artifacts? (forward-looking CI idea)
One reason I care about preserving the trail: I can imagine a future
“AI regression / reproducibility” check.
Say it’s 6–12 months from now and AI coding tools are even
stronger. If we have prompts and model versions recorded for
high-blast-radius contributions, we could run a periodic (maybe
opt-in) workflow that:
* replays historical prompts against a current/known model
environment,
* compares the generated output structurally (or semantically) to what
we merged,
* and validates that the merged implementation still matches expected
numerical behavior (tests + known benchmarks).
Even if we never automate this, having the trace helps humans debug:
“what constraints were assumed?” “what source did it mirror?”
“what was the intended invariant?”
(5) Copyright / legality
This is the part where I think a little conservatism is justified. The
legal landscape around training data, derived works, and obligations
around GPL/AGPL/LGPL is still evolving across jurisdictions. NumPy is
permissively licensed, but that doesn’t automatically insulate us
from the provenance question if generated code ends up looking like
something from a copyleft codebase. I can tell you for a fact that
corporate legal compliance folks will not hesitate to use the
ban-hammer if, after some future court case, it's deemed that
codebases like Numpy's are "tainted" and require roll-back.
I’m not proposing we block AI tools categorically (that’s neither
realistic nor enforceable). But I do think it’s reasonable to say:
* in high blast radius zones, contributors should prefer tools with
clearer provenance and license posture, and we should be willing to
ask for extra diligence (explanations, tests, and/or avoiding “model
wrote the entire algorithm” submissions);
* in low blast radius zones, the risk/cost trade is different, and we
can be more permissive.
I also think we should explicitly acknowledge that this policy may
evolve as jurisprudence and tooling clarity improves.
As an additional note, over the last couple of years I have been
actively working on a new "AI Rights" license & tech infrastructure to
help give explicit attestation for authors of all copyrighted works,
along the lines of CC Signals[1] or IETF AI Preferences[2]. I'm
actually sending this from the AI Summit in Delhi where, as part of AI
Commons, I'm convening allies from Creative Commons, Wikimedia,
Internet Archive, Common Crawl, and others to align on shared vision
and workstreams. Those who are interested in my work on this can see
the videos at links [3][4][5].
If you're to just watch one, I'd recommend [4] then [5], or just [5].
I'm happy to chat in depth with any/all of you about these topics, but
I want to be sensitive about not hijacking the Numpy list for my
personal mad ravings, so we can take them off-list if the maintainers
deem it too off-topic. If, on the other hand, y'all want to have a
dialogue about this stuff here, I can think of no finer group to
pressure-test my ideas. :-)
Cheers,
Peter
(In the spirit of transparency and dogfooding: some parts of this
email came from a thread summarization and initial dialog with GPT 4o
and 5.2, although I only used the output as a starting point and
edited heavily afterwards.)
[1] https://creativecommons.org/ai-and-the-commons/cc-signals/
[2] https://datatracker.ietf.org/wg/aipref/about/
[3] https://www.youtube.com/watch?v=oZHl4NWaO7c
[4] "AI for All": https://www.youtube.com/watch?v=TLZ9zXnluc8
[5] "AI Training & The Data Commons in Crisis":
https://www.youtube.com/watch?v=CdKxgT1o864
_______________________________________________
NumPy-Discussion mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3//lists/numpy-discussion.python.org
Member address: [email protected]
_______________________________________________
NumPy-Discussion mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3//lists/numpy-discussion.python.org
Member address: [email protected]
