Re: Common Lisp with no AI (that's ironic I suppose)

I may not like it but ultimately it is up to the maintainers to determine -
they seem willing to accept the overhead and I respect that decision. It's
their project and if they feel comfortable reviewing and merging stuff like
that there's not much I can say to convince them otherwise. Also think the
mailing list probably isn't the right place for this thread, although other
Lisp implementations may have a well-defined policy on LLM usage it doesn't
look like that will happen for SBCL.

That being said if you do have concerns I think maintaining your own fork
should be a serious consideration - as a Lisper the solution for me is to
start understanding the review and release process, and setting myself up
to not be totally reliant on SBCL devel - if there's decisions/patches that
I want to keep out of my fork I then have the flexibility to do that.

Best,
Richard

On Fri, Feb 27, 2026, 10:59 AM Matthew Weber <[email protected]>
wrote:

> >> Two things are happening rapidly: LLMs are getting better at
> programming, and people are learning how to get better work out of them
>
> There's not a lot of information out yet, but I was seeing news that
> perceptions were that people are getting better, but not actual
> workflow:
> https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
>
> I can't speak for the dev team but I'd be concerned about the
> considerable additional overhead in the vetting process even
> disregarding other issues.
>
> On Fri, Feb 27, 2026 at 3:28 PM Robert Goldman <[email protected]>
> wrote:
> >
> > AFAICT, this is a red herring.
> >
> > From OpenAI terms of use:
> >
> > > Ownership of content. As between you and OpenAI, and to the extent
> permitted by applicable law, you (a) retain your ownership rights in Input
> and (b) own the Output. We hereby assign to you all our right, title, and
> interest, if any, in and to Output.
> >
> > For Anthropic (Claude) things are a little more complicated.  See
> https://www.arsturn.com/blog/who-owns-claude-generated-code-a-guide-for-developers-and-businesses
> for a discussion.
> >
> > There may be lots (99!) of issues with AI-assisted code, but this is not
> a big one.
> >
> > On 27 Feb 2026, at 10:19, Brett Mahar wrote:
> >
> > > On Fri, 27 Feb 2026 10:02:11 -0500
> > > Robert Goldman <[email protected]> wrote:
> > >
> > >> On 26 Feb 2026, at 23:51, Brett Mahar wrote:
> > >>
> > >>> One thing that I think has been overlooked in the recent "should AI
> be allowed?" thread was: how about the copyright? How can the "author"
> grant copyright when they did not write the code? I'm not a lawyer but from
> what I understand the answer is "they can't" and Microsoft or Google or
> whoever can issue an injunction at any moment, or 10 years down the track
> when 5000 more commits have been done on top of the work of various agents
> and humans.
> > >>
> > >> Do you have a source for this claim?
> > >
> > > For the US law, you can see section 201(c) here:
> https://www.law.cornell.edu/uscode/text/17/201. Common law across the
> English-speaking world says basically the same thing, if you wrote you it
> you have automatic copyright, if you didn't write it you don't have any
> copyright.
> > >
> > > If you don't have any copyright, you cannot license it under MIT or
> GPL or any license for others to use. If the AI agent wrote it, its the
> AI's owner has the copyright, not the "viber" who went through iterations
> of asking to do things.
> > >
> > > Note that its not just the facts of who wrote what that is important,
> if I'm the CEO of Don't Be Evil and want to get rid of most open source
> projects, all I need is more money than the open source projects, whose
> contributors can't afford to be in and out of court for the next 3-5 years
> proving that the AI just did the documentation or analysis or whatnot.
> >
> >
> > _______________________________________________
> > Sbcl-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/sbcl-devel
>
>
> _______________________________________________
> Sbcl-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel
>

_______________________________________________
Sbcl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-devel