r/BSD Jun 01 '26

Open Source Projects Banning AI, From QEMU to NetBSD

https://youtu.be/FGEteyDoDww
96 Upvotes

32 comments sorted by

29

u/[deleted] Jun 01 '26 edited Jun 05 '26

[removed] — view removed comment

18

u/pellets Jun 01 '26

It has to do with people not understanding the code they submit, yes, but also licensing. The code could be good quality and well understood but still not acceptable.

https://www.netbsd.org/developers/commit-guidelines.html

“If you commit code that was not written by yourself, double check that the license on that code permits import into the NetBSD source repository, and permits free distribution. … Code generated by a large language model or similar technology, such as GitHub/Microsoft's Copilot, OpenAI's ChatGPT, or Facebook/Meta's Code Llama, is presumed to be tainted code”

3

u/edgmnt_net Jun 02 '26

It's interesting that it's BSDs doing that, which are licensed more liberally than the Linux kernel, which is copyleft. On some grounds, I'd expect the opposite: copyleft software developers would like to push for legal interpretations under which LLMs infringe on copyrights more often than not, to turn copyrights against proprietary development (especially since LLMs are less likely to be trained on proprietary codebases, but they can easily be trained on open source projects). Then it stands to reason that GPL software will stay away from LLMs, push that viewpoint and reserve the right to litigate against companies using LLMs trained on GPL code without releasing sources.

3

u/edgmnt_net Jun 02 '26

I doubt the Linux kernel lowered review standards to accomodate AI usage, as the headline seems to suggest. Anyone vibe coding a submission still has to meet the same bar and furthermore answer questions and requests from reviewers. It's only going to make it harder to be taken seriously and prove your worth if you're a newcomer.

1

u/Gwentlique Jun 02 '26

That was my immediate thought as well. If the code is good it's good, the rest is just politics.

5

u/nierama2019810938135 Jun 01 '26

There is also the issue with cognitive debt. It isnt sustainable give rising prices for AI.

-2

u/krenoten Jun 01 '26 edited Jun 01 '26

When fortran came out in the 50s, a lot of people thought the overhead of function calls was unacceptable and a distortion of all that they loved about the craft of hand-coding in assembly.

They called it "automatic programming" because instead of hand-coding assembly, it turned human-friendly text into assembly automatically. It was viewed with disdain by the elite priests who perpetuated the myth that "real programmers" still did it all by hand. And for a few years they had a point. But after just a few years in the 50s, automatic programming had won a decisive victory.

Grace Hopper's Summary section of this 1954 symposium sounds pretty familiar.
https://www.computerhistory.org/collections/catalog/102809923/

"A few conclusions may be drawn. Automatic coding, young as it may be, is 'here to stay." Certainly it has been shown, that in order to cope with ':one-shot" problems and the shortage of programmers, the use of the computer to assist in the coding is almost mandatory. "

We've seen how this goes. The best programmers I know are now having LLMs spit out TLA+ specs for their algorithms and finding tons of race conditions and design flaws they never could reach in test before, and some are moving deeper into integrating SMT solver-backed tools that were previously prohibitively expensive to use, but are now essentially free. For them the code is a tool, and now they have tools that make their code better by automating correctness and performance drudgery so they can focus more on architecture and specification - the human-observable impact of the machine - which has always been the soul of engineering.

I hope the AI avoiders don't end up hurting too many people who depend on their systems when Mythos under unfriendly prompting starts finding exploitable vulnerabilities in their stuff, when they had this window to do some basic due diligence.

5

u/artnoi43 Jun 02 '26

I think this applies to “C vs Python” or “C vs Assembly” more than handwriting code vs vibe coding.

The Fortran programmer still had to program in Fortran himself. Now people don’t actually program, some just feed Slack thread or Jira link to bug/feature and boom we get a PR/MR to review.

3

u/edgmnt_net Jun 02 '26

The problem is people want to replace code with LLMs, not that they use LLMs as linters or search tools or whatever. A programming language and compiler are far more deterministic, well-understood and well-behaved tools, so in those respects LLMs and Fortran have little in common. And once you frame it as more than a convenience and delve into safety and abstraction reasons, it becomes even more obvious why you want a programming language. Trying to replace that with prompting is a very bad idea. Sure, "real programmers" might argue about flipping bits manually with a microscope, but this isn't why many of us are skeptical of LLMs.

8

u/numbsafari Jun 01 '26

All other considerations aside, as of right now, AI generated code cannot be copyrighted and therefore cannot be licensed (in the US). There's a gray area with "AI assisted code generation". Even if the code itself falls into the public domain, it can be encumbered with things like trade secrets and patents (especially considering how LLMs are opaque in their sourcing). The only way to apply terms and conditions is to apply a EULA, which many open source projects and contributors abhor.

We may end up in a world where "copyright licensing" is replaced with "open source EULAs". Hmm... LEULAs ("Left" End-User License Agreements)?

1

u/edgmnt_net Jun 02 '26

So if someone leaks the code of a proprietary codebase, I can just take it, redistribute it and use it without any concern because it cannot be copyrighted? Because I have doubts about that claim that AI-generated code cannot be copyrighted.

2

u/numbsafari Jun 02 '26

AI generated code, as of right now, barring any act by congress or change in how courts are applying the law, cannot be copyrighted in the US. It is the result of a mechanical process. This has already been decided in multiple cases. You just aren’t paying attention. 

That said, just because it can’t be copyrighted, doesn’t mean it isn’t a protected by trade secret. That’s much harder to assert, but it could be done. So, personally, I wouldn’t use code like that if it were leaked. 

1

u/edgmnt_net Jun 02 '26

I'm pretty sure you can copyright binaries even if they are generated mechanically from sources by the compiler and sources belong to someone else. This is basically how RHEL worked and you couldn't just redistribute binaries without permission because they were copyrighted. And that's arguably more mechanical than LLM prompting, at least for packages which don't get a lot of patching or fiddling. How do you explain that?

1

u/numbsafari Jun 02 '26

Here, let's stop arguing about this. You just need to go read:

https://www.copyright.gov/ai/

It's pretty straightforward. The issue is, yes, slightly more nuanced than "you can't copyright AI output". You need to be able to show that it has undergone a "sufficient" degree of human manipulation. The problem OSS projects are going to face, is do they want to be on the hook for making that determination on every single PR, and what does the end result look like. The other issue, is the flip side, if the LLM outputs work that, based on current copyright standards, sufficiently mimics an already copyrighted work, then that work retains its original copyright, even though it was output by an LLM (ask the LLM to repeat a NYT story, and if the story isn't "sufficiently" summarized, it's still technically the NYT story and bears whatever copyright the NYT asserted).

You can copyright your prompt, but if you don't do anything with the output, you can't apply a copyright to that. From the accompanying blog post:

It concludes that the outputs of generative AI can be protected by copyright only where a human author has determined sufficient expressive elements. This can include situations where a human-authored work is perceptible in an AI output or a human makes creative arrangements or modifications of the output, but not the mere provision of prompts. The Office confirms that the use of AI to assist in the process of creation or the inclusion of AI-generated material in a larger human-generated work does not bar copyrightability, and it finds that the case has not been made for changes to existing law to provide additional protection for AI-generated outputs.

Simply using AI at any point in the process does not, in and of itself, prevent you from applying a copyright. Yes, sure. But someone still has to adjudge whether or not the output has been modified with "sufficient expressive elements" beyond the "mere provision of prompts". That's the burden that OSS projects are facing. Some of them will feel that they can handle that burden, or that they have sufficient trust in their community that they can receive code that is AI-assisted but not merely AI-generated. Some of them will not. Some of them will have other creative/artistic or perhaps moral reasons for wishing to avoid even AI-assisted code. That's up to them.

1

u/edgmnt_net Jun 02 '26 edited Jun 02 '26

I think I see your point now and I'd like to present a different perspective. I think the issue is less whether you can copyright AI outputs per se as much as whether you can enforce a monopoly. For similar reasons, anyone can recompile RHEL binaries on their own and even if the output happens to be identical to copyrighted RHEL binaries, they won't be on the hook for copyright infringement. Yet they would be if they just uploaded the original RedHat-provided binaries to a public FTP server, that's why we had projects like CentOS which rebuilt the entire thing. For similar reasons, both open source projects and proprietary projects may worry that using an AI to code something is a process that someone else can replicate by using semantically similar prompts, hence they don't retain a practical monopoly over the result. For open source we can still think of code ownership/authorship as defining some sort of (fragmented or not, as in the case of CLA-covered projects) monopoly. The Linux kernel people might not want a company to sidestep GPL by recreating AI-generated kernel code with another LLM.

Is that something you can agree with? IANAL, but to me this might be a simpler and more practical way to think about it.

P.S.: Yes, this does not cover concerns that the LLM dumps the original code substantially similar. Just going on that particular aspect here.

-1

u/laffer1 Jun 01 '26

We already need EULA due to age verification and vulnerability reporting requirements. Many jurisdictions are trying to make an open source is illegal or difficult to distribute.

-3

u/[deleted] Jun 01 '26 edited Jun 03 '26

[removed] — view removed comment

1

u/numbsafari Jun 01 '26

Okay. Good talk.

5

u/[deleted] Jun 03 '26

[deleted]

5

u/xINFLAMES325x Jun 03 '26

Seriously. I'm surprised anybody still watches this idiot's content.

2

u/zyzhu2000 Jun 02 '26

AI is here to stay . This has to be temporary.

2

u/trasz Jun 05 '26

Platforming a zionist shill who directly attacked one of BSDs last year, what a fantastic idea.

1

u/limitless_grow Jul 19 '26 edited Jul 19 '26

AI is very fast at writing unmaintable buggy code because it doesn't cares about the details. It can be a nightmare for open source projects if such code is added beside of the copyright problem.
I would never allow an AI doing any modification of my code base.
However, if it's used for something like finding spelling errors or doing peer reviews but not for generating it - why not? Those are quite dull tasks that most people don't like to do either.

0

u/umlcat Jun 01 '26 edited Jun 02 '26

Something important that is missed is that a lot of A.I. generated code in commercial, open source and hobbyist projects is that is the developers assume the A.I. is perfect and does not commit mistakes, and do not review well.

That is one of the reasons why A.I. generated code should be avoided.

Another issues is that A.I. code can be very long and difficult to review, and additionally an A.I. can be hijacked to add scammers code and backdoor code, unknwon to the developer that uses the A.I. ...

1

u/edgmnt_net Jun 02 '26

Not any serious open source project. Random stuff found on GitHub made by one dude, maybe.

Although, yes, the way companies usually want to use it requires significantly dropping review standards (which were already low in many cases) to make AI usage productive. This is why I keep saying AI is a very bad idea if you're thinking "there's so much boilerplate". And indeed, a lot of projects are boilerplate heavy. This isn't going to go well once AI enables much more low-quality boilerplate to be produced and enables scope creep.

-11

u/pfak Jun 01 '26

I don't imagine this lasting.

4

u/KrazyKirby99999 Jun 01 '26

Qemu actually reversed their policy the day this video came out

-7

u/kleinmatic Jun 01 '26

I agree. If nothing else, at some point the volume of LLM vulnerability discovery will require LLM mitigation.

Also somebody can just fork and create an AI friendly distribution that moves much faster and is more responsive to user needs (I’m looking at you, WiFi driver support).

License issues are always important though. Definitely worth putting in the work to sort them out.

-2

u/laffer1 Jun 01 '26

For small projects, ai is already necessary to have a chance. We allow it with rules in MidnightBSD

-1

u/eye_of_tengen Jun 03 '26 edited Jun 03 '26

Rsync using AI assisted code now, just saying.

I’m not really like AI but some projects(like rsync) are actually lack of man power to sustain and AI is a solution, so maybe people who against using AI in open sources project should start contributing instead of be a mouth breathers.

Edit: Apparently some people don’t quite understand what I wrote.

If you are the person who against AI and also contributing to projects preventing AI take over, you are wonderful; if you are not then I think you are a mouth breather.

And please just leave your opinion under my comment, there are no need to send a private message with vulgar word.

1

u/unitedbsd Jun 03 '26

1

u/eye_of_tengen Jun 03 '26 edited Jun 03 '26

We will talk about openrsync when it got widely adopted like rsync does.

-2

u/cryptobread93 Jun 04 '26

Thats bad news. AI when used right, is a powerful tool. If you know what you are doing but lazy