Yes. I’d argue that this is similar in spirit to the linked proposal, which for example requires that

Nobody in KDE should know if you use an LLM — not because you’re concealing it, but because your usage of it produces output indistinguishable from what you could produce yourself. Contributions with obvious and lazy LLM usage may be ignored or closed.

That person seems to be mistaken. I could only find policies for GNOME Circle and extensions, and those seem similar in spirit to the one proposed here:

• https://gitlab.gnome.org/Teams/Releng/AppOrganization/-/blob/main/AppCriteria.md#circle-app-criteria
• https://gjs.guide/extensions/review-guidelines/review-guidelines.html?ref=itsfoss.com#extensions-must-not-be-ai-generated

Starting a fork is easy, but who is gonna maintain it? KDE is huge, at 8 million lines of code for the core software, so you’ll need a large amount of people who are willing to work on the fork to keep parity with KDE

Would you be willing to expand on what you mean by disclosure being a big part of open source?

I ask because it has not been my experience that OSS developers have ever had a habit of disclosing what tools they use. If you are lucky then a repo has instructions for contributors, that may describe tools being used, or CI configuration for running tests and linters, but most projects have neither. Mostly you just get instructions for building the project, but sometimes not even that

There’s also https://noailist.org/, which is based on projects (not just OSS) committing to not using AI. That’s probably also the only viable approach, if you want a list of projects without AI stuff, since projects can easily be using AI without it being visible to third parties inspecting the output of the projects

Having an public policy that permits the use of LLMs feels like the opposite of “hiding it”. If a project has such a policy, then you can be pretty sure that LLMs are being used, even if you cannot tell exactly what commits involved the use of LLMs. It’s probably also a lot more discoverable than disclosures in commits or PRs, which most users wouldn’t know how to look for

Thanks, fixed the typo, lol

Zellic did not write uutils/coreutils, they audited them. That is to say that they reviewed the existing source code and reported the issues they found.

Besides that, the first release of uutils/coreutils was back in April, 2020: https://github.com/uutils/coreutils/releases/tag/0.0.1

I am not familiar with Zellic, but given the popularity of Rust in the crypto space, I am also not surprised that a company that audits Rust code has ties to crypto

Only the parts written by LLMs would be public domain. Everything else would still be copyrighted by Microsoft. See https://fsfe.org/news/2026/news-20260825-01.html

And since there’s no easy way for outsiders to determine which part is what, it would be a minefield for anyone trying to use the leaked source code. ReactOS devs would have to stay far, far away to avoid giving MS an easy way to sink the project

What is “Just. Wrong”? And what does the label “Linux boosted” have to do with this?

The GPL gives you the right to access and modify the source code of software you use. A lack of copyrights does not mean that the creators have to share the source code with you. In fact, it means that anyone can take GPL software and turn it into closed source software

When did Anthropic make Claude Code a separate subscription? I ask because it is still listed as part of the Pro subscription tier on their website. And because I haven’t seen the shit-storm that would no doubt ensue if they did that

I’ve been using “oldoldstable” as my cutoff for backwards compatibility in several pieces of software I’ve released. I guess I gotta decide if I start bumping dependencies now or if I wait for the Bookworm to become “oldoldstable” in 2027

None of the proposals would have banned AI usage in upstream projects, but banning AI usage in the context of the Debian project was on the table

What is the AI policy of Arch? I ask because I was unable to find any explicit policy for the project

None of the proposals would have banned AI usage in upstream projects:

https://www.debian.org/vote/2026/vote_002

No, the idea was that apt update would keep failing while the system upgrade was running (and holding the lock):

$ apt update
E: Could not get lock /var/lib/apt/lists/lock. It is held by process 1704856 (apt)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to lock directory /var/lib/apt/lists/

But there are better ways of waiting for a process to finish, that other people have shared

If you can run sudo without a password, you could do something like:

There’s no need for password-less sudo. Instead, you can use bash -c to run a set of commands via sudo:

sudo bash -c "while true;do apt update && shutdown -h 5; sleep 5m;done"

It took a while to get used to zsh bailing on non-matching wildcards, but it honestly makes a lot more sense

Looks neat, but I don’t think that you can claim to be “Private and offline” when the default is to broadcast what you’re playing. That feature should be opt-in, not opt-out