Re: Current policy on AI-generated code in NumPy

Also I'd like to be on record with the unpleasant part out loud. I have
been in many discussions also at work and in OSS circles so I have quite a
bit of debate ammo accumulated from both sides. Let me jump into it without
the fluff to save space;

Currently, LLMs are getting really good at what they are tasked to do. If
you put in the work (just like you would when you are the one writing the
code), the output is quite acceptable and I feel like I'm reviewing
somebody else's Pull request. Fix "this" part, change "that" part and done.
If folks can't use these tools, it's a "they" problem. I just used it to
translate entire LAPACK to C11 (why, mostly for the lolz, don't ask, it's a
disease), ported all the tests and passing, now polishing it up. I mean
look at this silly thing

[image: image.png]


No way in hell, I'd type this much code myself. And it is a 1-to-1
mechanical translation, no creativity involved except hacking into PyData
theme because I always wanted to tweak it. Now who owns the copyright;
Dennis Ritchie or LAPACK folks, or is it the entire C codebase of the world
that trained this machine to write this mechanical code, or is it me who
paid for it and worked with it etc.? The source of the algorithm is BSD3,
would you be using this if this was available in BSD3 (I mean it will be
obviously very soon).

As a comparison, the entire SciPy Fortran codebase, ~85,000 SLOC, took me 2
years and 7 months to translate manually. Entire LAPACK codebase 300,000
SLOC (just the functions) and including the testing, documentation etc.
took me exactly 1 month and 19 days (Claude Pro something MAX level
subscription with ~200€ per month from my own pocket). The agent still
fails spectacularly if you let it run free, but I do put in the work to do
a proper code review, tweak rules, then force it to read the rules
periodically, (and most importantly, I know what I am looking at) so this
went fairly well. It still took insane amount of time to bring the agent
back on track. force explicit testing, Not to use C++ practices on C code
so on.

At this point, I can confirm that "Agents can do this much but they cannot
do that much" is rapidly becoming a "God of the Gaps" argument with every
new version release LLMs chasing a receding horizon, not towards
intelligence, but precision at parsing and following orders.

However, in my opinion, our dilemma is not a whether their output is
potentially GPL'd/copyrighted code or not. Every bit of output of these
tools is stolen by being trained on copyrighted data. For the folks who did
not see it, there is a screenshot of VS Code offering me a comment at the
beginning of the file from a company that does not apparently have any
public repositories
https://discuss.scientific-python.org/t/a-policy-on-generative-ai-assisted-contributions/1702/5


Therefore, we are, in fact, trying to guess, whether it looks like a
copyrighted code after the fact, ignoring where the code is pulled from.
These companies pretty much stole everything; music, science articles, code
(not just GPLd code, but private repositories), this, that, everything.
Their practices were/are seriously unethical. It is not a political
statement but facts. However, it seems like they are getting away with it,
incredibly, even after they admitted it multiple times all the way at the
CEO level (in particular, recently, SUNO CEO is pretty bullish, even
defending why this stealing is fair use while individuals are rapidly being
prosecuted for the same actions, not to mention Sci-Hub). And some of us
are working for these companies or working for in the secondary circles.

Funnily enough, we are tasked with this mordant task of trying to come up
with a stance on LLM usage. I claim that we should not be spending too much
time on the epistemological aspects of LLM usage. I can't see any way other
than being utilitarian about it. Because PRs keep coming and maintainers
are also using it. So when stuck between a rock and a hardware, I think we
should be admitting these properly and then choose a path knowingly fully
aware that we might be making a mistake. Being open about the fact that we
are going blind into this is probably make more sense instead of some
serious sounding untested-unvetted legal text and checkboxes. Because
really nobody knows when we will correct course, if ever.

So we can

1- "Stallman" it, with "no AI allowed" stance, while having absolutely no
way of knowing how the code is generated. So it is a stance based on
principles. I don't have a problem with it, and can accept it. It is a
viable and respectable choice. The downside is we will be forcing people to
lie. Because they will use it and we will not notice it until it is very
late.
2- or find a sentence that is pragmatic enough; something like
    "Even if you used LLMs, you should be able to explain the changes
yourself. LLM based PRs are held to heightened levels of scrutiny and lower
levels of patience" or something offered in this thread.
    I can also accept this, it is also a viable option. The downside is
that it will make us more hostile, as Sebastian mentioned, and paranoid.
Occasionally, it will make us accuse innocent folks for using LLMs.

Once we can choose this, then we can add agent markdowns, boilerplate
responses and other details. But it seems like we got stuck at this choice
level in our last attempts for a policy alignment. I would be much happier
if we can be a bit more explicit and forthcoming about what we are doing
and not make it an in vitro Open Source problem. We don't need to use
strong words like stealing etc. obviously since there is no legal basis for
it. But we all know what happened so there are much softer versions of
saying the same thing. I just did not spend the time to make these proper
ala Pascal, and it's my lack of manners leaking out though I strongly
believe that they stole everything.

I am fully aware that this might not be everyone's take (or anyone for that
matter), so please take it as a rather brazen take though I hope the
message gets across.

Very weird times indeed.
ilhan


On Fri, Feb 13, 2026 at 12:03 PM Matthew Brett via NumPy-Discussion <
[email protected]> wrote:

> Hi,
>
> On Thu, Feb 12, 2026 at 7:02 AM Sebastian Berg
> <[email protected]> wrote:
> >
> > On Wed, 2026-02-11 at 23:22 +0000, Matthew Brett via NumPy-Discussion
> > wrote:
> > > Hi,
> > >
> > > On Wed, Feb 11, 2026 at 11:02 PM Lucas Colley via NumPy-Discussion <
> > > [email protected]> wrote:
> > >
> > > > Hi Matthew,
> > > >
> > > > That all sounds reasonable to me so far, but what are the next
> > > > steps?*
> > > >
> > > > > put a heavy requirement on contributors to either a) write the
> > > > > code
> > > > themselves, perhaps having asked for preliminary analysis (but not
> > > > substantial code drafts) from AI
> > > >
> > > > Is this enforceable to a significant extent? If not, in what sense
> > > > could
> > > > it pose a genuinely ‘heavy requirement’?
> > > >
> > > > > or b) write the code with AI, but demonstrate that they have done
> > > > > the
> > > > research to establish the generated code does not breach copyright.
> > > >
> > > > Perhaps this is more enforceable? But to be honest it is still
> > > > quite
> > > > unclear to me how I would establish with certainty that code I’ve
> > > > had
> > > > generated does not breach copyright, much less code that is being
> > > > presented
> > > > to me by a contributor. Do you see how to realise a ‘heavy
> > > > requirement’
> > > > here?
> > > >
> > > > I agree with the spirit of the thought that the burden (if it is to
> > > > exist)
> > > > needs to be shifted away from maintainers, but it’s unclear to me
> > > > how we
> > > > can actually shift it elsewhere.
> > > >
> > > > As we discussed last year, I think we have a start at a decent
> > > > argument
> > > > towards including a checkbox in PR templates which contributors
> > > > must tick
> > > > to state that they recognise the risk of copyright violation via
> > > > LLM
> > > > generated code and take responsibility for the code they are
> > > > submitting:
> > > >
> https://github.com/matthew-brett/sp-ai-post/issues/2#issuecomment-2935428854
> > > > .
> > > >
> > > > Even there though, there are still multiple debatable premises. Of
> > > > course,
> > > > we can hardly aim for some sort of logical proof of the right way
> > > > forward,
> > > > but I think we need more focused attention and argument towards a
> > > > specific
> > > > and understandable goal if we are to be able to come to consensus
> > > > on some
> > > > concrete steps forward. It is to this thread's merit that the
> > > > discussion
> > > > has been so varied and touched on many topics, but it is also
> > > > demonstrative
> > > > of the problem that broad and vague back-and-forths don’t really
> > > > help
> > > > settle on anything concrete.
> > > >
> > >
> > > Just to clarify - in case it wasn't clear, what I'm floating as a
> > > proposal,
> > > would be something like this, as a message to PR authors:
> > >
> > > Please specify one of these:
> > >
> > > 1) I wrote this code myself, without looking at significant AI-
> > > generated
> > > code OR
> > > 2) The code contains AI-generated content, but the AI-generated code
> > > is
> > > sufficiently trivial that it cannot reasonably be subject to
> > > copyright OR
> > > 3) There is non-trivial AI-generated code in this PR, and I have
> > > documented
> > > my searches to confirm that no parts of the code are subject to
> > > existing
> > > copyright.
> > >
> >
> > While I am not particularly enthusiastic about focusing on copyright,
> > adding such a checkbox on a PR, I would be happy with.
> > (If it was focused on copyright, then it seems to me we would need to
> > ask more things, like "I used a source, but it had no code" to "I used
> > a source with code but I checked it's license". If we want this, I
> > would prefer a single fuzzy sentence that links out to elsewhere that
> > can also discuss pitfalls around copyright+AI.)
> >
> > Not sure that asking for a checkbox there will be honored, but I like
> > the thought.
> > First, it will increase the chance of getting the information (which I
> > want as a reviewer).
> > Second, my unfortunate feeling is that we'll get more aggressively/less
> > friendly about closing PRs and that is a shame, and having the checkbox
> > makes that pat a bit easier on us and maybe also more transparent to
> > the user that we are struggling with this (the worry of course is
> > closing a genuine human PR by accident).
> >
> > I think I largely understand the concerns around copyright and maybe I
> > am a bit not careful/understanding enough by not being overly
> > worried?...
> > But to my very personal feeling the product of how much I feel we
> > should worry and how much I feel that stressing issues will help us as
> > a project/open source just doesn't make me enthusiastic about being
> > aggressively to pointing it out these possible issues.
> >
> > There are many things to discuss around this. What does eroding
> > copyright here mean for us as a project, for open source (GPL?), for
> > open but not free code, for code that is leaked but sold?
> > How will enforcement of actual copyright issues plays out in practice?
> > I just don't think this is the venue for settling these questions [1]
> > and I would need a lot more clarity to even form a strong opinion that
> > I would be willing to announce to the world with the weight of NumPy
> > behind it.
>
> I do understand that this is not the kind of issue that many of us
> enjoy discussing, but it seems to me that it is:
>
> a) of central importance to the future of open-source, and
> b) very urgent, and
> c) fairly straightforward.
>
> To focus the discussion - the only thing of interest to us here, is
> the acceptability or otherwise of large chunks of code generated by
> AI.    I doubt that anyone has strong objections to AI for code review
> or code analysis.
>
> For the central importance, imagine a world where copyright has become
> irrelevant.  There are ways we could approach this issue, where that
> is a likely outcome.   We might have different views on whether that
> is acceptable, but at very least, it will be a very major change, with
> unpredictable consequences.   We are used to open-source copyright as
> it exists.   If we don't consciously address this now, or very soon,
> we'll have another world, with consequences that are difficult to
> predict.
>
> Of course, some of us don't care all that much about our own
> copyright, but bear in mind, that by choosing not to defend it, we
> take away the ability of others to defend theirs.   Specifically, if
> we choose to accept large AI-generated PRs, the copyright that will be
> violated is not ours, but that of others.   Do we claim that right, to
> void the copyright of our fellow authors?
>
> Returning to the central question - of large AI-generated PRs.   It
> seems to me this is not a week of work to analyze.   I don't think
> there's any controversy that making no effort to control copyright
> will, over the medium term, make copyright very difficult to honor.
> As I said before, the legal issues of enforcement are difficult, but
> not relevant to us, because we are considering our own ethics in
> observing copyright, and that will be a superset of the legal
> constraints.   It would be an error to defer to legal arguments for an
> ethical question, if only because the legal arguments are sufficiently
> complicated that we'd likely have lost the ability to enforce
> copyright before they are resolved.   And, as I say, I think the legal
> arguments - on enforcement - are more or less irrelevant to our
> ethical decisions on copyright.
>
> So, accepting large AI-generated PRs would be a significant threat to
> copyright - what do we get in return?
>
> Ralf pointed out one benefit - that we are not seen to disapprove of
> the chosen workflows of our fellow developers.   I think this is a
> weak argument.   It seems to me perfectly reasonable to point out that
> contributing to the code-base has some constraints, and copyright is
> one of them, and that AI-generated code runs the risk of violating
> copyright.
>
> The second potential benefit is that, by accepting large AI-generated
> PRs, we will gain greatly in code coverage and quality, and that this
> is a benefit great enough that it is worth paying the price in terms
> of copyright.   First - we have been prepared to pay a high price for
> observing copyright in the past - there are many GPL algorithms that
> we could have copied, to our benefit, but did not.  Second, it seems
> to me we can wait on this.   It is not yet clear that we would gain
> significantly, compared to our traditional requirement that people
> write their own code.   When the gains are still unclear, the cost in
> terms of voiding copyright is too high.
>
> Lastly - I was proposing a compromise - that we (Scientific Python
> projects) do not forbid AI-generated PRs, but place an extra burden on
> contributors to research any possible copyright violations.  That
> seems like a reasonable compromise to me.   What do you think?
>
> Cheers,
>
> Matthew
> _______________________________________________
> 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]