Hi, On Thu, Jul 4, 2024 at 6:44 PM Ralf Gommers <ralf.gomm...@gmail.com> wrote: > > > > On Thu, Jul 4, 2024 at 5:08 PM Matthew Brett <matthew.br...@lis.ac.uk> wrote: >> >> Hi, >> >> On Thu, Jul 4, 2024 at 3:41 PM Ralf Gommers <ralf.gomm...@gmail.com> wrote: >> > >> > >> > >> > On Thu, Jul 4, 2024 at 1:34 PM Matthew Brett <matthew.br...@gmail.com> >> > wrote: >> >> >> >> Hi, >> >> >> >> On Thu, Jul 4, 2024 at 12:20 PM Ralf Gommers <ralf.gomm...@gmail.com> >> >> wrote: >> >> > >> >> > >> >> > >> >> > On Thu, Jul 4, 2024 at 12:55 PM Matthew Brett <matthew.br...@gmail.com> >> >> > wrote: >> >> >> >> >> >> Sorry - reposting from my subscribed address: >> >> >> >> >> >> Hi, >> >> >> >> >> >> Sorry to top-post! But - I wanted to bring the discussion back to >> >> >> licensing. I have great sympathy for the ecological and code-quality >> >> >> concerns, but licensing is a separate question, and, it seems to me, >> >> >> an urgent question. >> >> >> >> >> >> Imagine I asked some AI to give me code to replicate a particular >> >> >> algorithm A. >> >> >> >> >> >> It is perfectly possible that the AI will largely or completely >> >> >> reproduce some existing GPL code for A, from its training data. There >> >> >> is no way that I could know that the AI has done that without some >> >> >> substantial research. Surely, this is a license violation of the GPL >> >> >> code? Let's say we accept that code. Others pick up the code and >> >> >> modify it for other algorithms. The code-base gets infected with GPL >> >> >> code, in a way that will make it very difficult to disentangle. >> >> > >> >> > >> >> > This is a question that's topical for all of open source, and usages of >> >> > CoPilot & co. We're not going to come to any insightful answer here >> >> > that is specific to NumPy. There's a ton of discussion in a lot of >> >> > places; someone needs to research/summarize that to move this forward. >> >> > Debating it from scratch here is unlikely to yield new arguments imho. >> >> >> >> Right - I wasn't expecting a detailed discussion on the merits - only >> >> some thoughts on policy for now. >> >> >> >> > I agree with Rohit's: "it is probably hopeless to enforce a ban on AI >> >> > generated content". There are good ways to use AI code assistant tools >> >> > and bad ones; we in general cannot know whether AI tools were used at >> >> > all by a contributor (just like we can't know whether something was >> >> > copied from Stack Overflow), nor whether when it's done the content is >> >> > derived enough to fall under some other license. The best we can do >> >> > here is add a warning to the contributing docs and PR template about >> >> > this, saying the contributor needs to be the author so copied or >> >> > AI-generated content needs to not contain things that are complex >> >> > enough to be copyrightable (none of the linked PRs come close to this >> >> > threshold). >> >> >> >> Yes, these PRs are not the concern - but I believe we do need to plan >> >> now for the future. >> >> >> >> I agree it is hard to enforce, but it seems to me it would be a >> >> reasonable defensive move to say - for now - that authors will need to >> >> take full responsibility for copyright, and that, as of now, >> >> AI-generated code cannot meet that standard, so we require authors to >> >> turn off AI-generation when writing code for Numpy. >> > >> > >> > I don't think that that is any more reasonable than asking contributors to >> > not look at Stack Overflow at all, or to not look at any other code base >> > for any reason. I bet many contributors may not even know whether the >> > auto-complete functionality in their IDE comes from a regular language >> > server (see https://langserver.org/) or an AI-enhanced one. >> > >> > I think the two options are: >> > (A) do nothing yet, wait until the tools mature to the point where they >> > can actually do what you're worrying about here (at which point there may >> > be more insight/experience in the open source community about how to deal >> > with the problem. >> >> Have we any reason to think that the tools are not doing this now? > > > Yes, namely that tools aren't capable yet of generating the type of code that > would land in NumPy. And if it's literal code from some other project for the > few things that are standard (e.g., C/C++ code for a sorting algorithm), we'd > anyway judge if it was authored by the PR submitter or not (I've caught many > issues like that with large PRs from new contributors, e.g. translating from > Matlab code directly). > >> >> I ran one of my exercises through AI many months ago, and it found and >> reproduced the publicly available solution, including the comments, >> verbatim. > > > Not close to the same, not really a relevant data point.
The question I was trying to address was - do we have any reason to think that current AI will not reproduce publicly-available code verbatim. I don't think we do, and the example was an example of AI doing just that. >> We do agree, enforcement is difficult - but I do not think AI >> autogenerated code and looking at StackOverflow are equivalent. There >> is no reasonable mechanism by which looking at StackOverflow could >> result in copy-paste of a substantial block of GPL'ed (or other >> unsuitably licensed) code. I do not think we have to be pure here, >> just reassert - you have to own the copyright to the code, or point >> the license of the place you got it. You can't do that if you've used >> AI. Don't use AI (to the extent you can prevent it). > > > "don't use AI" is meaninglessly broad. You ignored my example about > auto-completion. It doesn't seem that hard to make it more explicit and useful for our case - which is avoiding copyright violations. And we're not writing a legal document here, we are asking contributors to help us out by avoiding AI that might have picked up copyrighted code. So, if we wanted to unpack that to more detail, we could say something like: """ Our concern is that the AI will pick up copyrighted code, for which we will not be able to give proper attribution, or which we should not use according to its license. In practice, this means we ask you not to use substantial AI generated code, by which we mean, more than one or two lines deriving from AI. Thus, editor autocompletion of code within a single line is clearly fine, but generation of whole functions or classes is not. """ I'll give you another: just a few days ago I was listening to a podcast about a developer who was fluent in Python and less fluent in Rust, asking an LLM-powered tool to literally translate code that the author themselves had written from Python to Rust. The tool didn't generate working code, but it was 90% correct. Which allowed the author to finish up the task in half an hour, rather than spending half a day or more trying to write the Rust code from scratch. > > That type of usage is very much valid, and can be a significant productivity > enhancer. Such tool-assisted developer workflows are only going to increase > over time. We shouldn't try to forbid that outright, it makes little sense to > do so nor is enforceable. I really don't think we need to go into the question of whether AI is good or bad, valid or invalid. It's clearly a risk, in the sense of including copyrighted code. That risk is obvious and current. It may be a substantial benefit in due course, over what a skilled programmer can do, for tasks other than generating stuff that is more or less boilerplate, or language translation. But for now, I think it's fair to say that there is nothing for which we _need_ AI, and therefore, on balance, it seems reasonable to me to have a careful policy, at least for now. Cheers, Matthew _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
