QGIS zakazuje wkładów kodowych wspieranych przez AI w repozytorium qgis/qgis
Sprostowanie, 12 października 2026 r.: W poprzedniej wersji tekstu błędnie nazwaliśmy zmianę „QEP #387” i napisaliśmy, że zakaz obejmuje także dokumentację. Numer 387 to numer pull requestu na GitHubie. Tytuł PR opisuje zmianę jako „Add QEP428”, a sam PR aktualizuje istniejący plik
qep-408-ai-tool-policy.md. Przyjęte brzmienie zakazuje wkładów kodowych wspieranych przez LLM, AI lub agentów w repozytoriumqgis/qgis; nie wymienia wprost dokumentacji. Zachowujemy dotychczasowy adres artykułu, ale poprawiamy tytuł, zakres i źródła.
Zmiana w polityce QGIS jest krótka, lecz łatwo pomylić jej identyfikatory i zakres. Najważniejsze rozróżnienie: GitHub PR #387 nie jest QEP #387, a zdanie przyjętej polityki mówi o wkładach kodowych w konkretnym repozytorium, nie o każdym użyciu AI ani o wszystkich projektach QGIS.
W skrócie: PR #387, zatytułowany „Add QEP428: No ai contributions permitted”, został scalony 7 października 2026 r. Zmienił tekst istniejącej polityki QEP 408 z modelu „human in the loop” na zakaz wspomaganego przez AI kodu w repozytorium
qgis/qgis. Dokumentacja nie jest wymieniona w operatywnym zdaniu zakazu.
Co dokładnie zakazuje przyjęta polityka QGIS?
W obowiązującym tekście znajduje się zdanie: „No LLM, AI or agent assisted code contributions are allowed in the https://github.com/qgis/qgis repository.” Dalej dokument mówi o możliwym „code reversion and contributor rights sanctioning”, jeśli użycie LLM, AI lub agenta zostanie później wykryte. Są to słowa przyjętej polityki, a nie interpretacja artykułów prasowych.
Zakres jest istotny. Zapis wskazuje wkłady kodowe kierowane do repozytorium qgis/qgis. Nie stwierdza, że zabronione jest samo korzystanie z narzędzi AI, używanie QGIS jako programu ani praca nad każdym repozytorium należącym do społeczności. Nie należy rozszerzać jednego zdania na szerszą regułę, której dokument nie formułuje. Przyjęty tekst polityki i PR wprowadzający zmianę są tu źródłami pierwszej ręki.
QEP 428, QEP 408 i PR #387 – skąd różne numery?
W relacjach o tej sprawie pojawiło się określenie „QEP #387”. To pomyłka między numerem propozycji a numerem pull requestu. Oficjalny PR ma numer 387, a jego tytuł brzmi „Add QEP428: No ai contributions permitted”. Zmieniony plik w repozytorium nadal nazywa się qep-408-ai-tool-policy.md.
Te identyfikatory opisują różne elementy historii: QEP 408 to istniejący dokument polityki AI, który wcześniej dopuszczał model z udziałem człowieka; PR #387 to konkretna zmiana na GitHubie; QEP 428 to nazwa nowej, bardziej restrykcyjnej propozycji użyta w tytule PR. Sam diff PR pokazuje, że nie dodano osobnego pliku o nazwie qep-428, lecz zastąpiono treść w pliku QEP 408 wersją 2.0. Dlatego w tym artykule odróżniamy numer PR od numerów QEP zamiast powtarzać skrótowe oznaczenie z wtórnych omówień. Metadane PR i jego diff pozwalają sprawdzić tę relację bezpośrednio.
Co przewidywała wcześniejsza polityka?
Poprzednia wersja QEP 408 dopuszczała korzystanie z narzędzi, pod warunkiem że człowiek przeczyta i sprawdzi wygenerowany kod lub tekst przed przekazaniem pracy do recenzji. Wzywała też do transparentnego oznaczania istotnego udziału narzędzi, między innymi w opisie pull requestu albo w komunikacie commita.
Stary tekst wymieniał różne formy współpracy z projektem: kod, propozycje QEP i projekty, zgłoszenia, podatności oraz komentarze. Zawierał również przykład, według którego użycie LLM do przygotowania dokumentacji, później ręcznie sprawdzonej i poprawionej przez autora, było dopuszczalne. Te fragmenty zostały usunięte w zmianie z PR #387. To porównanie wyjaśnia, dlaczego nowa polityka bywa opisywana jako odejście od „human-in-the-loop”, ale samo w sobie nie dowodzi, że obecny tekst zakazuje każdej formy pracy nad dokumentacją. Różnicę między wersjami widać w oficjalnym diffie.
Dlaczego QGIS zaostrzył podejście?
W dyskusji wokół PR uczestnicy wskazywali na obciążenie osób utrzymujących projekt i koszt recenzowania dużej liczby zgłoszeń. W wątku deweloperskim Tim Sutton opisał tę perspektywę jako próbę ochrony czasu maintainerów i przeprowadzenia zmiany przez formalny proces projektu, a nie jako automatyczne rozstrzygnięcie wszystkich możliwych przypadków użycia AI. Wątek na liście QGIS-Developer pokazuje, że zakres i sposób egzekwowania reguły były przedmiotem publicznej rozmowy.
W komentarzu do PR uczestnik uclaros podał przybliżone liczby: około 50 pull requestów oznaczono etykietą „AI Assisted”, a około 40 z nich zamknięto bez scalania. Zaznaczył też, że część innych zgłoszeń zamknięto bez takiej etykiety. To relacja uczestnika dyskusji, nie opublikowany przez QGIS audyt statystyczny; dlatego liczby należy przedstawiać jako szacunek z komentarza, nie jako precyzyjny, kompletny pomiar. Komentarz uclaros w PR #387.
Jak przebiegało przyjęcie zmiany?
PR #387 otwarto 24 września 2026 r. W jego dyskusji autor ogłosił 5 października, że okres dyskusji się zakończył i propozycja przechodzi do głosowania. 7 października Nyall Dawson odnotował zatwierdzenie propozycji, a pull request został scalony tego samego dnia. Te daty pochodzą z historii samego PR.
Dyskusja pokazała, że uczestnicy nie byli zgodni co do granic zakazu. Pytali między innymi, czy chodzi o AI-agentów, autouzupełnianie, tłumaczenie, użycie modelu do konsultacji albo teksty zgłoszeń. W komentarzu autor zaproponował rozpoczęcie od restrykcyjnej zasady i ewentualne otwieranie konkretnych wyjątków w odrębnych dyskusjach. Nie oznacza to jednak, że takie wyjątki zostały już przyjęte. Historia PR #387 zawiera daty, głosy i kontekst tych pytań.
Czy nowy zakaz obejmuje dokumentację?
Nie można rzetelnie napisać, że przyjęte zdanie wyraźnie zakazuje dokumentacji. Operatywna fraza mówi o „code contributions” w repozytorium qgis/qgis; nie wymienia dokumentacji, tłumaczeń ani tekstowych zgłoszeń. W poprzedniej wersji dokumentacji poświęcono natomiast osobny przykład i uznano ręcznie sprawdzoną dokumentację wspomaganą przez LLM za dopuszczalną.
Podczas dyskusji jedna z osób zaproponowała dopisanie dokumentacji, raportów błędów, opisów PR i komentarzy do zakazu. To, że taki postulat padł, nie znaczy, że znalazł się w finalnym zdaniu. Najbezpieczniejszy opis brzmi więc: przyjęta klauzula zakazuje wspomaganego przez AI kodu w repozytorium qgis/qgis; jej tekst nie rozstrzyga wprost, czy obejmuje wyłącznie kod, czy również inne typy wkładów. Konkretnego wkładu dokumentacyjnego nie należy z góry kwalifikować jako zakazanego na podstawie nieobecnego w tekście rozszerzenia. Odczyt należy oprzeć na wersji przyjętej polityki, nie na nagłówkach wtórnych artykułów.
Czy to techniczna blokada użycia AI?
Dokument opisuje regułę postępowania, ale nie przedstawia automatycznego detektora, który rozpoznawałby kod wygenerowany przez model. W komentarzach do PR pojawił się opis oceny zgodności jako pytania, czy autor w dobrej wierze napisał kod samodzielnie. To komentarz w dyskusji, nie dodatkowy mechanizm techniczny ustanowiony w treści polityki.
Rozróżnienie ma praktyczne znaczenie: polityka określa, czego projekt nie akceptuje, a nie technologię, która potrafi niezawodnie ustalić pochodzenie każdej zmiany. W samym tekście przewidziano możliwość późniejszego odkrycia użycia AI oraz konsekwencje w postaci cofnięcia kodu i sankcjonowania praw kontrybutora. Nie należy z tego wyciągać wniosku, że repozytorium automatycznie skanuje wszystkie zgłoszenia albo że wykrywanie działa w każdym przypadku.
Co ta zmiana oznacza dla kontrybutorów?
Osoba planująca wkład do qgis/qgis powinna przeczytać dokładne brzmienie polityki oraz aktualne instrukcje projektu. Nie warto opierać decyzji na skróconym haśle „QGIS zakazuje AI wszędzie” ani na odwrotnym założeniu, że udział człowieka automatycznie czyni każdy użytek dopuszczalnym. Tekst mówi o wspomaganych przez AI wkładach kodowych, a dyskusja ujawnia nierozstrzygnięte przykłady graniczne.
To również powód, by odróżniać regułę formalną od komentarzy uczestników. Wypowiedź o możliwych przyszłych wyjątkach nie jest wyjątkiem obowiązującym dziś; propozycja rozszerzenia zakazu na dokumentację nie jest jego przyjętą częścią; przybliżone liczby z recenzji nie są kompletnym raportem projektu. Jeśli przypadek dotyczy tłumaczenia, autouzupełniania albo pracy poza repozytorium qgis/qgis, właściwym krokiem jest sprawdzenie aktualnych wskazówek QGIS lub uzyskanie odpowiedzi od maintainerów, zamiast dopowiadania zakresu.
Często zadawane pytania
Czy QGIS zakazał wszystkich zastosowań AI?
Nie wynika to z przyjętego zdania. Mówi ono o wkładach kodowych wspieranych przez LLM, AI lub agenta w repozytorium qgis/qgis, a nie o każdym użyciu AI w programie QGIS czy całym ekosystemie.
Czy QGIS wprost zakazał dokumentacji tworzonej z pomocą AI?
Nie w operatywnym zdaniu nowej polityki. Wymienia ono wkłady kodowe, a dokumentacji nie określa osobno. Poprzedni tekst QEP 408 zawierał przykład ręcznie sprawdzonej dokumentacji jako dopuszczalnego użycia.
Który numer jest właściwy: 408, 428 czy 387?
PR na GitHubie ma numer 387. Jego tytuł nazywa zmianę „QEP428”. PR aktualizuje istniejący plik qep-408-ai-tool-policy.md, którego wcześniejsza wersja opisywała model human-in-the-loop. To różne identyfikatory, nie trzy nazwy tego samego numeru.
Kiedy zmiana została zatwierdzona?
Historia PR #387 pokazuje zatwierdzenie i scalenie 7 października 2026 r. Warto odróżnić datę scalenia propozycji od późniejszych komentarzy prasowych o jej zakresie.
Podsumowanie
- GitHub PR #387 nosi tytuł „Add QEP428: No ai contributions permitted” i został scalony 7 października 2026 r.
- PR zastąpił wcześniejszy tekst human-in-the-loop w pliku
qep-408-ai-tool-policy.md. - Przyjęte zdanie zakazuje wkładów kodowych wspieranych przez LLM, AI lub agentów w repozytorium
qgis/qgis. - Dokumentacja nie jest wprost wymieniona w nowym zdaniu, więc nie należy twierdzić, że zakaz obejmuje ją jawnie.
- Liczby o około 50 oznaczonych PR-ach i około 40 zamkniętych pochodzą z komentarza uczestnika i są przybliżone.