Item — HN Reader

That would imply it'd be fine for me to contribute AI assisted work if I did so politely and honestly. I just need to respect the maintainer's time and I'm golden, right?

That's not what the policy says, is it?

It's a shame, really. I had some GCC patches under development, and now I simply won't submit them. Not the first time I ended up sitting on perfectly good patches after running smack into such a policy either.

3 comments

The thing they want is clear legal standing. If your submission is majority LLM generated, you can't really confirm that "your" code isn't a copy of something in the training set that has an incompatible license (or a clear copyright violation). That might not be a big deal for some projects, but being this is GNU and their entire identity is centered around free software and licensing, it's kind of a big deal to them.

That's just not an issue in practice. All major AI labs match generated code against their training data to prevent outputting verbatim copies. They're so confident they won't output copyrighted code that they offer copyright indemnification to paid users.

They do? Last I remember microsoft's license for copilot was saying that any copyright violation is on the user and they were disclaiming all responsibility (which would probably not hold up in court).

Yes, they do.

> Specifically, if a third party sues a commercial customer for copyright infringement for using Microsoft’s Copilots or the output they generate, we will defend the customer and pay the amount of any adverse judgments or settlements that result from the lawsuit, as long as the customer used the guardrails and content filters we have built into our products.

https://blogs.microsoft.com/on-the-issues/2023/09/07/copilot...

> Under the updated terms, we will defend our customers from any copyright infringement claim made against them for their authorized use of our services or their outputs, and we will pay for any approved settlements or judgments that result.

https://www.anthropic.com/news/expanded-legal-protections-ap...

> Output indemnity. OpenAI’s indemnification obligations to Enterprise customers under the Agreement include claims that Customer’s use or distribution of Output infringes a third party’s intellectual property right.

https://openai.com/policies/service-terms/

Wow, I didn't know that. Never seen a corporation do anything like it. Usually it's just "we guarantee nothing and you agree to fully idemnify us for any damages" legal boilerplate.

Do they offer the same indemnification that the code they generate IS subject to copyright and that you own that?

Because the US Copyright begs to differ.

My understanding is that "one shotting" a C compiler from a single prompt would not be covered by copyright, but a large project like GCC containing thousands of individual contributions which each require human input most likely would (even if some of the code is LLM generated).

Also, it's worth noting that the USCO does not actually have the final say here. It's possible to register works that don't hold up in court or to fail to register works that do hold up. It's the courts that ultimately decide what the law is.

And yet Anthropic was penalized 1.5B. "Trust me bro" does not work with companies that pretty much show they can't be trusted on the daily.

This policy means that the GCC maintainers have defined "perfectly good" differently then you have.

I think they meant it as "indistinguishable from a human contribution".

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.

> I had some GCC patches under development, and now I simply won't submit them.

Of course, of course… I also had found a proof to fermat's last theorem that fits in a single page but I'm not publishing it as well :D

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 than I got on my first try. Once I got that merged and perfected the contribution process, I was also planning to work on some of the feature requests that I posted on GCC's bugzilla, mainly an analyzer feature for tagged unions in C that verifies field accesses match their associated tags, and also a way to rename the "internal" symbols that GCC generates purely for aesthetic reasons.

Looks like all that stuff is gone now. Maybe it's for the best. Attempting to contribute to GNU projects hasn't exactly been a pleasant experience.

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.

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.

> 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.

You just call syscall(syscall number, arguments) in glibc

I don't want to have to link against glibc. Nobody should need to do that.

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.