Live data from Hacker News

GCC steering committee announces AI policy

lwn.net

391–400 of 454 posts

Re: GCC steering committee announces AI policy

#391

I like that this policy is more specific than the Debian policy, and not overly strict as to include contributions that are not generated by LLMs, but may be the result of a conversation with LLMs. It also helps that the policy is inherited from the GNU org, way simpler than having each project have their own specific policy. Gnood job

Debian doesn't have a policy yet. It has multiple proposals that are being debated currently.

Re: GCC steering committee announces AI policy

#392
post #348

Earlier quoted context omitted.

What is the point of doing this? Why do people do this sort of thing? I'm genuinely puzzled.

Which — the policy, or the AI spam the policy targets?

Question was why ask an agent to make some cool PRs to a famous open source project. I have no clue.

Re: GCC steering committee announces AI policy

#393

Earlier quoted context omitted.

Here's to hoping LLVM will define it differently.

LLVM defined its AI policy several months ago: https://llvm.org/docs/AIToolPolicy.html (There's already some consternation that it's too permissive.)

Reasonable policy. It's fine to make it less permissive on the basis of quality. It's the "AI, therefore slop" prejudice that's problematic.

Re: GCC steering committee announces AI policy

#394

Earlier quoted context omitted.

I had human authored GCC patches that added Linux system call builtins to GCC. I was in the middle of learning how GCC's code generation worked when my laptop fell onto the floor and my hard drive crashed, leading to the loss of the work. This was years ago, and you can even find some emails from me on the mailing list defending the feature. AI helped me successfully restart that patch set, and take it much further t…

Can't you already do that with inline assembly pretty easily?

You can, and that's exactly what the libraries do, and what I did in C, Rust, and Lisp. However, you shouldn't need to drop to assembly code. It's just a special calling convention. The compiler should know how to emit this code. JIT compilers too.

Re: GCC steering committee announces AI policy

#395

Earlier quoted context omitted.

Can't speak for others but I'm just tired of hearing far-fetched copyright concerns that mask the real motivation (ideological opposition to LLMs).

There is nothing far fetched about this. GNU is an ideological organization and their ideology is "free software." Free software exists because of the copyright system. Now imagine if someone can just fork your GPL licensed software and distribute it under an incompatible license, and when you go to court, the judge tells you to punch sand because your codebase is all AI generated and therefore not copyrighted. I am…

Without code copyright we are inherently free to modify, improve and share code we have access to. FSF used copyleft as a legal hack to maintain that right in an environment where corporations where using copyright to deny that right.

I don’t think taking copyright off the table harms the practice of sharing code. They will still try to use trade secrets to restrict code sharing and contracts, but using GNU software won’t be stopped. It will reduce the ability to sue people not sharing their modifications but that was always outside the mainstream, and places like AWS, Apple, and Google find ways around it anyways since it doesn’t cover hosted services or non-linked code.

The core stream of openly developed and exponentially improving software does not need copyright to win if it cannot be sued for copyright violation.

Now I suppose some OpenAI lawyer is trying to find a way to sue humans for copyright infringement while keeping them safe from lawsuits, so we can worry about that attack.

Re: GCC steering committee announces AI policy

#396

Earlier quoted context omitted.

Can't you already do that with inline assembly pretty easily?

You generally don't have to, the Linux system calls are in the standard library anyway. Having GCC builtins for them is of questionable utility at best. Even if the GP poster submitted these patches that may or may not exist, I'm not sure they would ever get merged.

> the Linux system calls are in the standard library anyway.

Nope. Not every system call is available. It took years before glibc got getrandom, for example. Others are straight up not supported because they break glibc's internals.

One could argue that it's always possible use the generic syscall function, but then what's the point of glibc? You can just get rid of it and use minimal shims, or compiler builtins, ideally.

> Having GCC builtins for them is of questionable utility at best.

It's useful if you're writing freestanding Linux programs. Great for eliminating all of the dependencies and writing minimal applications that target Linux directly. I wrote an entire lisp interpreter on top of nothing but Linux system calls.

> Even if the GP poster submitted these patches that may or may not exist, I'm not sure they would ever get merged.

Honestly I'm not sure either. The GCC maintainers didn't seem particularly convinced on the mailing list. It's the reason why I didn't bother to restart this work until years later. Claude made it easy enough to do it all over again.

Equally easy to drop. I'm gradually switching to Rust anyway.

Re: GCC steering committee announces AI policy

#397

Earlier quoted context omitted.

You generally don't have to, the Linux system calls are in the standard library anyway. Having GCC builtins for them is of questionable utility at best. Even if the GP poster submitted these patches that may or may not exist, I'm not sure they would ever get merged.

But if you are the one writing the standard library, it's still easy. You can write asm volatile("syscall" : a bunch of stuff telling the compiler which values to put in which registers)

You can write that sort of asm code to call functions too, but the whole point of compilers is you shouldn't need to. It's a stable calling convention and I felt that the compiler should know how to emit the code.

Re: GCC steering committee announces AI policy

#398
post #331

Earlier quoted context omitted.

We almost need a proof of human check. Before submitting a PR, you must find and paste the actual lyrics of a random song as challenge-response. Lyrics seem to have the strongest safeguards out of everything. (Try it! On some APIs, you might see moderation/refusal behavior you don't see with anything else, even cyber)

Basically, any copyrighted material should do. This only covers not ablated LLMs though. Ultimately, a web of trust where someone whose humanity and integrity you trust AT THE COST OF YOUR OWN INTEGRITY vouches for an individual is likely going to be the most reliable way. New open source contributors will require proof of humanity. On top of this, you would want an expirable proof of humanity to reduce account takeo…

>Basically, any copyrighted material should do.

Anything illegal, for that matter. Crime as proof of humanity. Fun future!

Re: GCC steering committee announces AI policy

#399

Earlier quoted context omitted.

No? 1) Someone re-licenses GCC under a non-GPL license. 2) EFF sues them, to stop the behaviour 3) Court tells EFF that they have no standing to sue because LLM generated content has no copyright Obviously this happening would be in the future after someone translated GCC to Rust with LLMs or something.

> Someone re-licenses GCC under a non-GPL license. A pointless act since code is now free. The GPL exists to ensure code freedom in an era when code was expensive. Yes I'm aware that the meaning of "free" is a bit conflated here, but the point stands.

I believe you are underestimating the value of GCC and LLVM having won the compiler wars and being extremely high quality, and of Linux having won the OS wars, being extremely high quality. I use GenAI every day, but the quality is still proportional to the amount of my time - there is a multiplier for quantity of my amount but the 9s approaching 1 quality is not logarithmically different - the effort to fix one big is lower, but the total effort to make excellent software is still a process of polishing and then iterating. The embedded quality in GCC will take a similar order of magnitude investment from an LLM rewrite. These super high quality open foundations make LLMs more useful to us now, but saying that the embedded value or cost of GCC or Linux is zero I think will steer people wrong.

Re: GCC steering committee announces AI policy

#400
post #20

Earlier quoted context omitted.

AI psychosis seems to be on all sides of the debate. We've truly lost our moderate speech and the ability to discuss.

There has never been a time when open source isn't full of flame wars of one flavor or the other. Are we going to diagnose people with syetemd psychosis or X11 psychosis next?

Already have
Post reply on HN