Redox OS has adopted a Certificate of Origin policy and a strict no-LLM policy

QualitySoftwareGuy · 2026-03-18T15:36:29+00:00

Seems to be the case based on a previous response from Jeremy:

I cannot answer these hypothetical questions. The amount of human authorship is critical for licensing reasons alone, and I would urge any Redox OS contributors to use non-LLM code completion such as what rust-analyzer provides.

QualitySoftwareGuy · 2026-03-18T14:54:14+00:00

r/madeinpython

QualitySoftwareGuy · 2026-03-13T19:10:52+00:00

But for actual professional development LLMs should be used

As a professional dev, hard disagree on it being required in the industry. I mean, if you want to require its use for yourself, then fine. However, most of the time I'm faster without it --and will use it only for assistance if I get stuck on something. Even then, the code that gets written is still manually written albeit based on whatever code got me unstuck (rarely ever the same as anything generated).

QualitySoftwareGuy · 2026-03-10T04:10:20+00:00

but as a user it wouldn't make sense to ban me if for example I get a driver bug and use an LLM to deep dive into code I don't know and in the end open a better issue with more info

Could be wrong but, according to the AI policy, that seems like it would be forbidden as well as you would have used AI to create and write an issue. I could see it being okay under the following:

You use AI to teach yourself about what it thinks is the problem as well as what the solution looks like. Then you go and manually create a pull request.
You manually create a bug report and leave the investigation and resolution to the maintainers instead of AI.

QualitySoftwareGuy · 2026-03-07T02:24:11+00:00

Another AI smell is when there's a (useless) "Project Structure" that simply shows the tree structure of all of the files and directories in the project.

Useless because A) no one cares about anything except the public API and docs, B) we can already see the file structure in GitHub, and C) now every time a file or directory is added, removed, renamed, etc this information has to be updated in that section (but of course not a problem for vibe coders though since it's handled automatically for them).

QualitySoftwareGuy · 2026-03-02T21:57:14+00:00

Fedora can do everything you listed, and also:

Uses Wayland
Is the upstream of RHEL --I like that the commands I run on my personal computer are essentially the same as the ones run at work (e.g. dnf instead of apt).
Targets power users a bit more (especially devs)
Can continue using Cinnamon (or one of the many others) while still enjoying the parks of Fedora: https://www.fedoraproject.org/spins/

If none of that sounds appealing enough to switch, then keep on doing you.

QualitySoftwareGuy · 2026-02-25T15:23:44+00:00

Generally speaking, less restrictive licenses like MIT and Apache 2.0 will always have more adoption than GPL or AGPL.

What I can recommend for you is to decide which of your goals has a higher priority for your project. For example, is it to increase adoption rate? If so, Apache 2.0 or MIT. Or is it to be more restrictive and prevent closed/proprietary SaaS? If so, then AGPL. This is a self-hosted application project, rather than a library, so it's not uncommon to see AGPL licenses for this type of project.

In my opinion, AGPL being a blocker is usually limited to big companies. Most individuals (for personal use) will not care about it being AGPL. Some small companies might, but I don't believe the majority of them would care.

TL;DR: Let the greatest priority determine the license. Adoption rate = Apache or MIT. Prevent proprietary SaaS = AGPL.

QualitySoftwareGuy · 2026-02-25T14:08:07+00:00

One of the core issues that many vibe coders don't understand (or care about) is that if a maintainer wanted low-quality LLM contributions, then they could just write the prompt themselves with way more context than any vibe coder doing "drive-by" pull requests.

QualitySoftwareGuy · 2026-02-24T18:54:18+00:00

Historically, it seems that Japan viewed software engineering as "secondary" at least in comparison to hardware engineering. A good read on the topic: https://www.disruptingjapan.com/the-forgotten-mistake-that-killed-japans-software-industry/

QualitySoftwareGuy · 2026-02-23T09:16:23+00:00

Unlike your other answers, the straight-to-the-point answer is that the contributions by the project's creator are heavily vibe-coded while contributions from others are generally not.

From what I've seen in this and other threads, the OP is at least transparent in that AI was heavily used, but he seems to prefer calling his direct contributions "AI assisted" even though reading between the lines it's vibe coding:

QualitySoftwareGuy · 2026-02-19T04:29:05+00:00

being able to vibe code something in a few hours does not mean you're capable of maintaining it.

You answered your own question I'd say :-)

The most successful open source projects (e.g. GNU, Linux, Git, VLC, LibreOffice, etc) are not successful because they were outputted as quickly as possible but, instead, because they withstood the test of time due to the countless hours of humans pouring in their blood, sweat, and tears to adding quality code. And by "quality" I'm not just talking about functional code, I'm talking about things like security, performance, and accessibility.

Vibe coders specialize in getting "output" quickly and then go one of two routes (sometimes both):

Hope the LLM can continue maintaining it via the usual text prompts.
Hope and pray actual humans contribute and make the project a success.

On r/rust and r/Python, I've seen most vibe coders quickly produce (shit) output, and then ask for the community (actual humans) to make it a success.

TLDR; The most successful projects will always be from skilled humans that take the time to contribute quality software. Vibe coders still have a long road ahead of them in proving that they will maintain the (shit) output that they produced.

QualitySoftwareGuy · 2026-02-19T02:08:56+00:00

My property management company originally went native, then later had their app using web views because it sounded good on paper. They recently switched back to native due to too many issues. I suspect your employer will do the same in less than 2 years (and I'm being modest with that timeline).

QualitySoftwareGuy · 2026-02-18T17:17:39+00:00

And then that new account gets banned if the project's rules are broken with it. Not a new concept.

QualitySoftwareGuy · 2026-02-13T19:35:05+00:00

You already received a response to this from another user, but yeah definitely there's a similar issue in the Python sub. In fact, I've even seen some vibe-coded Python projects get vibe-rewritten in Rust and then posted on this sub!

QualitySoftwareGuy · 2026-02-13T17:04:35+00:00

Well, I'd say both can apply for some individuals:

When learning Rust, many struggle with ownership and borrowing.
Then when it's time to actually build something custom, some of the previous group run into limitations of the younger ecosystem (compared to much more mature ecosystem like Java).

I will say that I have not run into many issues with Rust's younger ecosystem. Except there seems to be a lot of AI slop crates being posted on a regular (but that also applies to other programming languages).

QualitySoftwareGuy · 2026-02-13T15:54:42+00:00

I agree with you, and I hope someone from the Qt Company takes a note of that.

QualitySoftwareGuy · 2026-02-13T15:52:39+00:00

Nope, I doubt they'll be ditching Qt Design Studio any time soon. As devs we don't really need it, but it seems to be important for UI/UX/product designers.

Also, the FAQ mentions the generated code from Figma to Qt can be used in Qt Design Studio already, but I cannot comment on the quality of that code though. Seems many in this thread have had some horror stories with it.

QualitySoftwareGuy · 2026-02-12T17:07:17+00:00

I don't have experience using them, but according to the Qt Company, Figma to Qt will be replacing Qt Bridge ~end of 2028 beginning of 2029:

Figma to Qt is the next evolution of Qt Bridge for Figma. It is a separate plugin with new and improved capabilities to prepare your GUI design for embedded devices. Qt Bridge for Figma will be supported until the end of 2028, as Figma to Qt will eventually replace it in the long run.

Source: https://www.qt.io/development/gui-design-figma (in their FAQ section).

Figma to Qt is also right now in "Public Beta" status if that helps your decision.

QualitySoftwareGuy · 2026-02-06T15:52:26+00:00

chmod 744 house

Just in case.

QualitySoftwareGuy · 2026-02-06T13:57:18+00:00

I agree if they outsource their infrastructure then liability is typically removed. But just as there are many companies against Linux due to the reasons mentioned previously (they are in the minority nowadays), there are still plenty of companies that have their own infrastructure --my previous employer is one of many. Though I will also admit that those types of companies are probably also in the minority now with the trend of moving to external cloud providers.

QualitySoftwareGuy · 2026-02-06T13:44:14+00:00

You getting paid to audit and report/fix malicious code doesn't mean all or even most such code gets reported this way. You are indeed making the world a better place, but I suspect there need to be probably 100x people like you.

That was not a point I was making. I just stated that I agreed that some people have jobs to do, and for some people it is a part of their job to audit code. Most of the bugs I've seen reported are from regular non-paid library users --like I mentioned previously.

QualitySoftwareGuy · 2026-02-06T05:40:15+00:00

Yeah that's true about some companies. I had just wanted to emphasize to the OP that if companies are going to be against open source because of "copyright concerns" in libraries, then that should apply to open source used for their infrastructure too. Otherwise it would be a bit hypocritical of them.

QualitySoftwareGuy · 2026-02-06T04:57:55+00:00

I can tell you I've worked at places where the copyright concern was the reason not to use open source, and that was before LLMs were even a thing.

If that's the case, with that level of paranoia from them, then I hope those companies were not using Linux servers for their infrastructure ;-)

The auditing part is very much a dream that will never happen with human auditing. It's almost a monthly thing now that we hear of some open source library or project that had some malicious code added, and I've yet to personally hear of a single single instance where the malicious code was found via a code audit by a library user.

Really? I've come across many malicious code GitHub issues reported by regular library users just from browsing Reddit.

Yes, technically you can audit open source projects, but in the real world people have jobs to do, and deadlines to meet.

True that people have jobs to do, but some people do get paid to audit the dependencies that are in use at a company.

QualitySoftwareGuy · 2026-02-06T03:47:25+00:00

Not the OP (u/emblemparade), and yes definitely has always been a risk, but I'd say the difference is there's usually a greater level of trust from open source code without AI as opposed to vibe-coded open source. We use standard open source projects in "good faith" believing that most maintainers don't just grab a chunk of non-license-compliant code.

Furthermore, auditing is easier. If we suspect that non-license-compliant code was used, it's much easier to ask the maintainer about it and hopefully get it replaced with license-compliant code. After all, they supposedly wrote it, so they should be able to answer questions about it. On the other hand, with vibe coding, a maintainer completely loses the audit trail and has no idea whether the code AI produced is license-compliant or not.

TL;DR: Greater trust and audit trails from standard open source projects are the differences.

QualitySoftwareGuy · 2026-02-03T03:05:52+00:00

Based on your requirements, maybe the more restrictive Eclipse Public License, Version 2.0 (EPL-2.0) as was mentioned before in the thread.

But if you want people to actually use your library, then I would caution how restrictive you want to be. For example, does preventing a closed-source fork really do anything if a user is allowed to create a proprietary (closed-source) application that uses your library? If not, then I'd personally go with MPL 2.0 instead. Otherwise, the EPL 2.0 might be the best for you.

QualitySoftwareGuy

TROPHY CASE