AI and LLM policy

The purpose of this document is to gradually set boundaries about the use of LLMs, in order to avoid licensing conflicts and low effort contributions. We also want to be transparent about the way we use those tools, and about the way we expect others to do so when they contribute to this project. Keep in mind that AI tooling evolves rapidly, so we might have to frequently update this policy.

Logos, icons, and other assets

Using LLMs to generate assets is strictly prohibited. Our branding should reflect the purpose of the project, and there is clearly no room for licensing ambiguities in this case. We also have very strict rules regarding iconography (see src/icons/README.md).

Documentation

Using LLMs for extensive documentation or even for generating simple docstrings is strongly prohibited. Documentation should help clarify things that are not apparent. In our experience, LLMs tend to do the exact opposite. They state the obvious and pollute the project with noise. Using them for a final pass to catch typos and other simple mistakes should be fine.

Core

Code contributions generated by AI tools will be rejected. The birth of this project predates LLMs. Its core is written by hand with minimal AI assistance, and we want to keep it that way to maintain ownership and control. Contributions partially assisted by AI tools are allowed, as long as they are not used to generate code. Using LLMs to ask questions, research, and to catch minor errors or fix typos before submitting a PR is allowed and does not require notice.

Testing

Using LLMs to write tests is also prohibited. We prefer adding tests selectively, instead of blindly try to increase our test coverage. The "why" and "how" is more important than quantity.

Reviews

We do not use LLMs to review contributions. We might use various models from time to time to review the whole project. The purpose is to find random issues that we missed (bugs, typos, misleading naming etc). Although LLMs can produce a lot of false positives, they can also quickly identify problems that would normally require a very thorough pass to catch them.

Translations and dev tools

Those are the areas where we allow generating content using LLMs. Translations make the project widely accessible, and we don't have the capacity to maintain user generated translations yet. They are also isolated, so replacing or removing them won't affect the core product. Using LLMs to update or add new languages under src/lang is allowed, but human intervention is required to validate that the changes don't break existing unctionality, or reduce the quality of existing translations.

The same is also true for our dev tools under src/build. They usually contain throw-away code, since we are mainly interested in the artifacts they produce. Those contributions should be reviewed and tested, regardless of the way they were generated, to make sure that they don't introduce any bugs, or reduce the quality of the code.

Since we did not produce those files for the most part, I don't think we are allowed to license them. Even marking them as public domain requires owning the intellectual rights. Treating files under src/lang and src/build as source available seems to be the safest option for now.

Contributors should always ensure that their work does not violate any copyright laws. This also applies to AI generated code. Check the tool’s terms of use, to make sure you are not using copyrighted sources. You are advised to use models trained on content with compatible licensing.

Those PRs should be marked by adding an "Assisted-by: MODELS" label at the end of the pull requests. MODELS should be replaced by a comma-separated list of the utilized models.