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. > 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. 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. Cheers, Ralf
_______________________________________________ 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
