WELP I can no longer say that #FreeBSD's draft policy on LLM code contributions was leaning towards #NetBSD's way of thinking of banning the slop code entirely. I was going off what was said at last year's BSDCan.

Apparently it's shifted since then. https://reviews.freebsd.org/differential/changeset/?ref=1487182

Hopefully it shifts back, before it's finalized. I feel a bit crushed. I've been talking about that prior draft policy as a positive indicator for months. Im realizing I had pinned a lot of hope on it.

I've been trying REALLY hard to stay away from software with LLM generated code. (sigh). Ive dived back into FreeBSD hard after many years away, and have even been trying to contribute some stuff to ports.

I guess if this goes south, ill be re-evaluating things. Maybe NetBSD? Though I know it's missing some things from pkgsrc that will hurt to do without. #bsd

⚙ Changeset View

@trashheap before this heads off on rampant speculation, the Project doesn't yet have consensus on how to handle this, & we are working towards one. There are 2 drafts in circulation that I'm aware of.

Within the Project there are at least 3 groups:

- No AI (absolutists)
- Pro AI (accelerators)
- everybody in the middle

Yesterday's core meeting (which I attended) agreed to:

- publish a pragmatic policy for the interim
- consolidate the existing draft options if possible
- if not possible, at provide 2 options that can then be voted on in our next formal Elections, and discussed prior

There is no question that AI is very controversial, and also that FreeBSD the Project has committers who will have differing views across this space.

From the wider environmental picture, through concerns about copyright issues & licence erosion, and to the very real impact on code review effort from AI-generated or AI-assisted systems, and how AI is being used extensively by potential newcomers to the project, it's very easy to pick a side, and then be outraged that the Project hasn't taken *your* side.

@dch @trashheap different policies for different parts of the source? a pretty conservative stance for kernel/drivers, and a lean one for tests/docs, etc.
@charlesrocket that’s a good idea, but could a single license still cover this? The license is a critical part of BSD history and our culture @trashheap
The FreeBSD Documentation License

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.

The FreeBSD Project
@grahamperrin it’s still the BSD 2-clause version tho @charlesrocket @trashheap
@dch @grahamperrin @charlesrocket Ive missed the thread on something. What does the license have to do with AI/LLM code-commit policy?

@trashheap the license encompasses the whole work the project produces. You can’t claim copyright in the US on wholly machine generated content (Copyright protection requires human authorship, Thaler v Perlmutter ) is a nice write up https://www.jdsupra.com/legalnews/the-supreme-court-declines-to-answer-ai-8916744/

Whether this applies to software, and “how much” mixing is required to move to allow copyright attribution by a Person isn’t clear yet.
@grahamperrin @charlesrocket

The Supreme Court Declines to Answer AI’s Authorship Question—For Now | JD Supra

On March 2, 2026, the U.S. Supreme Court denied certiorari in Thaler v. Perlmutter, ending—at least for the moment—the most prominent effort to secure...

JD Supra

RE: https://mastodon.bsd.cafe/@grahamperrin/116230481229885068

@dch @trashheap @charlesrocket similarly,

"No Serious Implications for FOSS from SCOTUS' Denial"

@dch @trashheap the policy can highlight that every commit will have the project’s current license, and any overrides of this would be discarded. i'd say this is a bit redundant, but i can see why one would want to add this