But if you actually described this methodology in your PR, then it’d no doubt be closed immediately, based on the spirit of the rules rather than the exact letter of the rules.

Rules like these ultimately presuppose that the contributor is acting in good faith. Because otherwise the contributor could just lie about using an LLM. They don’t need to engage in rules-lawyering or jump through hoops to circumvent the rules

In practice, that would require buy-in from the apartment/house association board, since the average resident would be unlikely to care about whether or not the software was open source or owned by the association. Cost would likely be a more important metric for most members, and here a company that serviced multiple associations would likely have an edge, especially since they could also provide general support to the end-users.

If it did get approved by the associations members, then the board would then likely have to hire a third party do carry out the actual development. If you’re (very!) lucky, then one or more members might be willing to do it cheaper than a third party, but that would likely only last for however long they lived in one of the apartments or houses.

I would put this scenario down as possible in theory, but very unlikely to work out in practice. The vast majority of such associations would go with an existing (closed-source) SAS provider, since that would be a lot less work and since it would survive the constant turnover in such an association.

I honestly have an even harder time seeing how it would work out for OSS in general, since most software does not come with an existing organization, nor a community that is as directly invested as residents in an associations. For most projects, the work involved in setting up and managing such an association would greatly exceed the work involved in developing the software itself, which, similarly to the above, most of the users would not be able to contribute to

EDIT: A more plausible scenario for an house/apartment association, would be somebody setting up a company structured as a co-op and then recruiting multiple associations as co-owners/customers. Is that what you had in mind? Though that of course requires that somebody has both the funds and the interest to get it off the ground, which is unlikely to be an existing association

Neither of those terms seem problematic to me; a plain reading would be “mostly” means more than half of the code, and “tolerated” would mean that the ban is not enforced on such projects. Of course, if you are already operating under the assumption that Codeberg is acting in bad faith, then it doesn’t matter what the terms of service says nor how they they might say that they interpret them.

It is, however, not surprising that their terms of service are subject to interpretation. That was already the case before they added these particular terms. For example, the Codeberg TOS already included a prohibition against “content that harms the reputation of Codeberg” before the recent changes. Codeberg simply added projects related to cryptocurrency as an example, when the ban was voted through. It is furthermore the case that most, if not all, terms of service are subject to interpretation. We are talking about documents describing human behavior, not machine code.

If this kind of thing is not acceptable to you, then your only real solution is to self-host

Banning “AI” is too broad and too shortsighted.

They haven’t done that. The actual terms are

You must not share projects that mostly consist of code written by “generative AI”-tools (including services such as Claude, OpenAI Codex). Such projects having an unclear copyright status (see requirements § 2 (1) 1 and § 2 (1) 3) and furthermore have little safeguards to ensure that they do not include harmful code (c.f. § 2 (1) 5).

See also their blog post, where they specifically mentions experiments as “tolerated”:

Side projects and experiments with little resource usage

Rust has no Undefined Behaviour.

That is simply not true. See here for a list of behavior that is considered undefined in Rust: https://doc.rust-lang.org/reference/behavior-considered-undefined.html

However, most (all?) of these require the use of unsafe, which helps narrow down where the problem might be, if you trigger any of this behavior

Typst’s biggest weakness is that the ecosystem is still young, so you may not be able to find equivalent packages to those you’ve been using in Latex. But for me, personally, it has been a joy to use

The problem is not the conclusion*. The problem is that the method used to reach it is terrible.

As you say, you could look at license popularity on GitHub, and the author should have done something like that, but even those statistics have to be interpreted carefully:

Each data point corresponds to the rank of a license based on the count of unique developers who uploaded code to a repository subject to the terms of that license during a given quarter.

In other words, this measures how many developers are commiting code under each license, and thus is more of a reflection of the popularity of software under each license, rather than the licenses themselves.

Perhaps a more meaningful measure would be how many (unique) repositories are created with each license, since a developer commiting code to a repo does not mean that they favor the license of that repo. I couldn’t find numbers for 2025, but amusingly these totals from 2020 suggest that no license is the most popular license, followed by MIT and then Apache

* The majority of my own code is MIT, by a large margin-