QGIS Introduces a Ban on AI Contributions: 289 Points and 299 Comments on HN

QGIS, the most prominent open-source geographic information system, has put a ban on AI-assisted contributions up for discussion. The proposal is pull request #387 in the QGIS-Enhancement-Proposals repository, where the team reviews major changes to its rules and architecture. By 12 October 2026, the link to the PR had collected 289 points and 299 comments on Hacker News. That is a lot for a niche GIS topic.

An important caveat: the source material contains only the link to the PR and the HN metrics, not the text of the policy. The exact wording (what counts as AI assistance, how it would be verified, what sanctions apply) and the final status of the proposal need to be checked in the pull request itself. The HN headline speaks of a ban, but the decision process in the QEP repository may include a vote and revisions.

Why These Decisions Are Appearing Now

QGIS lives on GitHub, is written mostly in C++ and Python, and is distributed under the GPL. The project relies on a limited number of maintainers who manually review patches from hundreds of people. Any tool that makes code cheaper to produce but not cheaper to review hits the bottleneck: reviewer time.

Beyond the workload, there are two legal and technical problems. The first is code provenance. Models were trained on huge collections of repositories, and maintainers have no way to confirm that a generated snippet does not reproduce someone else's code under an incompatible license. For a GPL project, this is a question of license cleanliness. The second is accountability. A patch author must understand what they are submitting and be able to defend the solution in review. If they did not write the code themselves and do not fully understand it, the dialogue turns into relaying messages between the reviewer and a chatbot.

Not the First Project to Take This Course

QGIS joins an already notable group. In 2024, Gentoo banned code written with generative models. NetBSD, the same year, declared LLM-generated code potentially "tainted" from a licensing standpoint and required prior approval. In 2025, QEMU also refused to accept such patches, citing copyright concerns and the Developer Certificate of Origin (DCO). Other projects take a softer path: they allow AI assistance but require disclosure and hold the author responsible.

What the Metrics Show

• Subject of discussion: pull request #387 in qgis/QGIS-Enhancement-Proposals.
• Discussion venue: Hacker News, 289 points.
• Activity: 299 comments, roughly one per point. The topic is contentious, and the thread has no consensus.
• Project license: GPL, which makes the question of code provenance especially sensitive.
• Date of publication on the aggregator: 12 October 2026.

Practical Takeaways for Contributors and Teams

If you contribute to QGIS or its plugins, read the final text of the policy before submitting your next patch. Find out whether the ban covers editor autocomplete, test and documentation generation, translation and typo fixes, or only substantive code. The boundary in such documents is usually blurry, and it is better to settle borderline cases with maintainers in advance.

Maintainers of other open-source projects may find the format itself useful: the rule was put into a public proposal process rather than adopted as a closed decision by the core team. This reduces conflicts later. Teams that use QGIS internally and write patches for upstream should set a separate rule for which internally produced AI-assisted code may be sent outside. The simplest approach is to keep such changes in your own fork or plugin.

The final verdict will come only after the discussion in the PR itself. But 299 comments on HN show that the question of whether to let AI-generated code into open-source projects has long outgrown the debates around a single repository.