Політики open source щодо коду, створеного AI

Що зробити перед надсиланням коду, створеного за допомогою AI, upstream

Проєкти з відкритим кодом тепер публікують політики щодо коду, створеного за допомогою AI, і ці політики відрізняються. Тому дотримуйтеся простого правила: знайдіть політику до написання патча й точно вкажіть це під час його надсилання. В основі обох вимог лежить одне правило. Не надсилайте жодного рядка, який не зможете пояснити під час code review.

Навіть коректний патч можуть закрити, якщо проєкт забороняє згенерований код або якщо ви приховали походження коду. Наслідки позначаться на вашому імені й залишаться надовго, оскільки мейнтейнер, який згодом виявить замовчування, не матиме підстав довіряти решті вашої історії. Спочатку визначимо кілька термінів, оскільки саме їх використовують політики. LLM (large language model) — це модель, на якій працює ваш coding agent. PR (pull request) у GitHub відповідає MR (merge request) у GitLab, і все наведене нижче стосується обох. DCO (developer certificate of origin) — це рядок sign-off внизу повідомлення коміту, і саме він є центральним елементом усієї дискусії.

Де опинилися політики open source-проєктів щодо коду, створеного за допомогою AI

Проєкти поділилися на чотири категорії. Кожен приклад нижче має дату, оскільки ці тексти змінюються.

Заборонено. 14 April 2024 рада Gentoo ухвалила, що «прямо заборонено вносити до Gentoo будь-який вміст, створений за допомогою інструментів штучного інтелекту для обробки природної мови». Правила комітів NetBSD називають результат роботи LLM «скомпрометованим кодом», який «не можна комітити без попереднього письмового схвалення core-команди». Документ QEMU про походження коду станом на August 2026 і далі зазначає, що проєкт «ВІДХИЛЯТИМЕ будь-які внески, які, на його думку, містять або походять від контенту, створеного AI».

Лише аналіз. Більшість заборон вужчі, ніж випливає із заголовків. У документі QEMU зазначено, що політика «не поширюється на інші способи використання AI, як-от дослідження API або алгоритмів, статичний аналіз чи налагодження, якщо результат не включається до внесків». Ви можете використовувати agent для читання коду. Ви не можете постачати код, написаний ним. Саме це розмежування діє всередині більшості обмежувальних проєктів, але його часто не помічають.

Потрібно розкривати використання. У October 2025 рада Fedora схвалила політику щодо внесків із використанням AI. Вона дозволяє ці інструменти й покладає відповідальність на автора: contributor є автором, повністю відповідає за весь внесок і має розкрити використання інструмента, якщо значна частина внеску надійшла з нього без змін. У December 2025 у документації Linux kernel щодо процесів з’явилася сторінка про coding assistants із trailer для фіксації використаного інструмента та чітким правилом щодо того, хто може надати sign-off.

Нічого не записано. Це досі найпоширеніший випадок. У preprint, опублікованому в May 2026, проаналізовано 1,000 популярних репозиторіїв GitHub і виявлено 118 репозиторіїв із будь-якою письмовою політикою щодо AI. Мовчання не означає дозволу. Перед написанням patch поставте одне речення в issue tracker, і відповідь стане публічним записом, на який можна буде послатися пізніше.

Чому мейнтейнери запровадили ці правила

Перша причина — навантаження на рев’ю, і розрахунок тут однозначний. Агент за хвилину створює правдоподібний merge request на 400 рядків. Належне рев’ю такого запиту забирає в мейнтейнера цілий день, а більшість мейнтейнерів працює як волонтери. Вартість подання майже впала до нуля. Вартість рев’ю не змінилася взагалі.

curl демонструє крайній прояв цієї тенденції. У середині 2025 року Daniel Stenberg повідомив, що приблизно п’ята частина звітів про вразливості, які надходили через bug bounty проєкту, була тим, що він називає AI slop: у звітах згадувалися реальні функції та реальні шляхи виконання коду, описувалася правдоподібна атака, але по суті там нічого не було. На початку 2026 року проєкт припинив bug bounty, щоб не продовжувати фінансувати цей потік. Це були звіти, а не патчі, але механізм той самий: через нього мейнтейнер відкриває ваш PR уже втомленим.

GNOME Calendar зафіксував цю проблему як окрему позначку. У червні 2026 року проєкт запровадив позначку "Probabilistically Automated" для merge request, що демонструють "major or total reliance on artificial 'intelligence' to generate code", і точно назвав симптом: "usually accompanied by a lack of proper testing, and finalizing patches based on theoretical intended behavior rather than correctness of code". Перечитайте останню фразу двічі. Код виглядає так, ніби він має працювати. Ніхто не перевірив, чи працює він насправді.

Друга причина — походження коду, тобто звідки він узявся та за якою ліцензією. QEMU прямо описує конфлікт: підписання sign-off означає, що ви "fully understand the copyright and license status of content" внесеного вами, а статус авторських прав на результат роботи моделі залишається невизначеним. Рада Gentoo назвала ту саму причину, а також якість та етичні аспекти. Ви не зобов’язані погоджуватися з юридичним трактуванням. Але ви маєте розуміти, що це рішення мейнтейнера, а не ваше.

Як знайти політику про використання AI у проєкті?

Перевірте ці місця в такому порядку.

• CONTRIBUTING.md у корені репозиторію, потім .github/CONTRIBUTING.md, а далі будь-який файл DCO поруч із ним.
• Документацію для розробників. QEMU зберігає свої правила у docs/devel/code-provenance.rst. Ядро — у Documentation/process/coding-assistants.rst.
• Вебсайт або вікі проєкту. Політика Gentoo міститься на сторінці вікі ради, а політика NetBSD — у правилах комітів.
• Систему відстеження помилок і архів списку розсилки. Зазвичай політика існує там кілька місяців, перш ніж її додають до репозиторію.

Із каталогу checkout достатньо виконати одну команду grep:

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

Потім перегляньте історію самого проєкту, оскільки зафіксоване правило важливіше за будь-який його опис:

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

Число поруч зі значенням trailer показує, яку форму фактично використовує цей проєкт. Порожній результат означає, що тут ніхто не вказував такі відомості в цій формі. Це також корисна інформація. Якщо проєкт розміщено на GitHub, а сам workflow для вас новий, у матеріалі як працюють pull request і fork на GitHub описано механіку, яку передбачає цей розділ.

Розкривайте інформацію в trailer коміту, а не в коментарі

Trailer — це рядок Key: value в останньому абзаці повідомлення коміту. Git уже використовує такий формат для Signed-off-by: і Co-authored-by:, а інструменти його обробляють. Тому саме таке розкриття інформації супроводжує код у дереві.

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

У документації ядра цей формат названо Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]. У ній прямо зазначено обмеження щодо цього рядка: «AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO).» Ім’я агента вказують у Assisted-by. Ваше ім’я вказують у Signed-off-by. Ніколи не дозволяйте інструменту записувати другий рядок. Також не дозволяйте йому вигадувати адресу Co-authored-by, яка нікому не належить.

Назви відрізняються, тому скопіюйте локальний варіант, а не вигадуйте власний. У травні 2026 року до списку QEMU надіслали патч із пропозицією послабити заборону цього проєкту для механічних змін, тестів, документації та виправлень помилок обсягом не більше двадцяти рядків. Для цього пропонували використовувати trailer на кшталт AI-used-for: tests, docs. Станом на серпень 2026 року це лише пропозиція в списку розсилки, а в чинному документі все ще відхиляється згенерований вміст. Один проєкт двічі змінював свою позицію в період із 2023 до 2026 року. Наступна зміна не чекатиме на вас, тому метод важливіший за конкретний список.

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

Для --trailer потрібен Git версії 2.32 або новішої. Друга команда має безпосередньо вивести це значення. Порожній рядок означає, що git не розібрав trailer. Майже завжди це відбувається через порожній рядок або звичайне речення всередині блоку trailer внизу повідомлення. Для вже створеної серії git rebase --signoff origin/main додає sign-off до кожного коміту, а git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt редагує файл повідомлення.

Варто заздалегідь врахувати два сценарії помилки. Під час squash merge повідомлення коміту перезаписується. Тому в проєкті, де використовують squash, повторіть це розкриття в описі PR, де його прочитає мейнтейнер. Коментар до code review не є записом, оскільки коментарі можна редагувати, і вони ніколи не потрапляють до історії git.

Точність працює в обидва боки. Assisted-by у коміті, який ви власноруч створили, є зайвим шумом і зменшує цінність ваших справжніх розкриттів. Якщо не додати його до коміту, створеного агентом, це може припинити співпрацю.

Що насправді підтверджує Signed-off-by?

DCO — це короткий текст версії 1.1, опублікований на developercertificate.org. Його використовують kernel, QEMU та багато інших проєктів. Додавання Signed-off-by: Your Name <you@example.com> означає, що ви підтверджуєте наведені в ньому положення. Прочитайте, що саме ви підтверджуєте, оскільки більшість людей підписують його, жодного разу не ознайомившись із текстом.

Пункт (a) стверджує, що внесок «повністю або частково створено мною, і я маю право подати його за open source ліцензією, зазначеною у файлі». Пункт (b) стосується роботи, створеної на основі попереднього open source коду, який ви маєте право передавати зі змінами. Пункт (c) стосується коду, переданого вам особою, яка підтвердила те саме. Пункт (d) зазначає, що ви розумієте: внесок і персональна інформація у вашому sign-off є загальнодоступними та зберігаються безстроково.

Зверніть увагу, чого тут немає. DCO не стверджує, що ви власноруч набрали кожен символ. Він стверджує, що ви маєте право подати код за цією ліцензією. Саме тому згенерований код не зовсім однозначно вписується в цю схему: питання не в авторстві, а в тому, чи можете ви підтвердити походження коду. Більшість проєктів, які вимагають sign-off, також вимагають справжнє ім’я, тому псевдонім не проходить перевірку. Додайте рядок за допомогою git commit -s. Він зчитує user.name і user.email з вашої git config. Якщо DCO bot відхилить ваш PR і вкаже commit, у якому немає цього рядка, git rebase --signoff origin/main, після чого force push до вашої гілки, виправить проблему.

Підпис коміту — це не те саме, що sign-off

git commit -s додає рядок тексту. git commit -S створює криптографічний підпис об’єкта коміту за допомогою вашого ключа GPG або SSH. Це відповідає на різні запитання. Підпис підтверджує, що цей коміт надійшов від власника відповідного ключа і відтоді не змінювався. Він нічого не говорить про походження коду всередині коміту. Тому підписаний коміт із нерозкритим згенерованим кодом залишається підписаним і водночас порушує політику. Sign-off — це твердження про походження. Підпис — це твердження про особу. Проєкти, яким потрібні обидва підтвердження, вимагатимуть обидва.

Не подавайте на review код, який не можете пояснити

Ось перевірка, і насправді вона не про чесність. Для кожного рядка запитайте: для чого він потрібен і що зламається без нього? Якщо на будь-яке з питань немає відповіді, patch не готовий, бо надійде коментар reviewer, а вашою відповіддю стане ще один раунд генерації. Reviewers це помічають. У цей момент contributor стає витратою для проєкту. Поставте ті самі запитання щодо граничних випадків, порожнього вводу, шляху помилки та другого caller.

Запустіть код. Зберіть його, запустіть test suite проєкту та напишіть reproducer для помилки, яку, за вашими словами, виправляєте. Документація kernel містить чесне правило fallback простими словами: "If the fix could not be built or tested, or if no reproducer could be produced, say so explicitly: maintainers currently waste too much time analyzing unverified reports and untested fixes." Фраза "I could not test this on real hardware" нічого вам не коштує. Натяк, що ви це зробили, завдає шкоди проєкту.

Відповідайте на коментарі review самостійно, власними словами та у зручний для вас час. Відповідь, яка з’являється через тридцять секунд після коментаря й переказує його у п’яти абзацах, одразу показує maintainer, що сталося. Також тримайте diff малим. Сорок рядків, які ви повністю розумієте, цінніші для проєкту, ніж refactor на чотириста рядків, за яким ви лише наглядали. Якщо ваш agent постійно повертає більше, ніж ви просили, skill, який обмежує його найменшою робочою зміною, допоможе зменшити patch до розміру, який ви ще можете захистити по кожному рядку.

Зберігайте інструкції для агента в репозиторії

Інструкції, які ви надаєте агенту, є частиною вашого toolchain, тому ставтеся до них як до коду. Файл у корені репозиторію, зазвичай AGENTS.md, містить команду складання, команду тестування, формат повідомлень комітів, вимогу щодо sign-off і правила стилю, які вже задокументовані в проєкті. Цей файл версіонується та доступний для перегляду. Його вміст завтра буде таким самим, як і сьогодні. Інструкції, які ви щоразу відтворюєте з пам’яті, призводять до різних патчів у кожній сесії, і ви не знатимете, під час якої сесії було створено патч, відхилений під час перевірки. У матеріалі Як написати AGENTS.md, зрозумілий і агенту, і людині описано сам файл.

Щодо репозиторіїв інших людей: не робіть свій перший внесок у вигляді PR, який додає файл з інструкціями для агента до проєкту, яким ви не керуєте. Це виглядає як спроба ззовні встановити політику toolchain для проєкту та швидко привертає увагу до вашого облікового запису через те, що вже втомило мейнтейнерів. Зберігайте цей файл у своєму fork, доки хтось не попросить додати його.

Місце запуску агента важливе з тієї самої причини. Агент, який може зібрати проєкт і виконати його тести в sandbox, яким ви керуєте, надає патч, який ви справді перевірили. Саме це відрізняє повідомлення про використання допомоги від повідомлення про припущення. У матеріалі Як запускати coding agent на власному VPS описано це налаштування, а в матеріалі Практичні відмінності між Claude Code, Cursor, Codex і Copilot — щоденні відмінності між цими інструментами.

Підхід після зміни політики

1. Знайдіть визначену політику, перш ніж щось писати: репозиторій, документацію розробників, вебсайт, трекер.
2. Якщо політики немає, поставте одне запитання в issue і збережіть відповідь.
3. Зробіть disclosure у форматі, який використовує проєкт, у commit trailer і повторіть його в тексті PR, якщо проєкт об’єднує коміти через squash.
4. Підпишіть зміни своїм справжнім ім’ям і пам’ятайте, що цей рядок підтверджує ваше право подати код.
5. Перевірте власний patch так, ніби його написав хтось інший, адже саме так і є.

До моменту, коли ви це прочитаєте, кожен проєкт, названий на цій сторінці, уже зміниться. Ці п’ять кроків не змінюються.

FAQ

Чи потрібно повідомляти, що я використовував AI coding agent?

Перевірте правила проєкту, оскільки відповідь визначається локальними вимогами. Fedora вимагає повідомляти про це, якщо значна частина внеску надійшла від інструмента без змін з боку автора. Ядро Linux вимагає trailer Assisted-by. Gentoo і QEMU станом на August 2026 взагалі не приймають такі внески. Якщо письмових правил немає, все одно додайте повідомлення в commit trailer. Якщо maintainer дізнається про це пізніше, його реакція буде спрямована на замовчування, а не на сам інструмент. Ця реакція вплине і на все інше, що ви надсилали.

Які open source проєкти забороняють код, згенерований AI?

Станом на August 2026: Gentoo — з April 2024, NetBSD вважає вихідні дані LLM tainted code, який потребує схвалення core team, QEMU не приймає внески, створені на основі згенерованого вмісту, а також кілька застосунків GNOME, зокрема Loupe і Calendar. Читайте власні правила кожного проєкту, а не покладайтеся на цей список, оскільки він застаріє. Зверніть увагу на спільний для більшості виняток: використовувати модель для дослідження API, запуску static analysis або налагодження зазвичай дозволено, якщо її вихідні дані не потрапляють до patch.

У чому різниця між Signed-off-by і signed commit?

Signed-off-by — це звичайний текстовий рядок, доданий за допомогою git commit -s. Він засвідчує developer certificate of origin, тобто ваше право передавати цей код за ліцензією проєкту. Signed commit, створений за допомогою git commit -S, містить криптографічний підпис об’єкта commit із використанням вашого GPG- або SSH-ключа. Він підтверджує, що commit походить від вашого ключа і не був змінений. Походження та ідентичність — це окремі твердження, тому signed commit все одно може порушувати AI policy.

Чи можна додати повідомлення в опис pull request замість commit message?

Додайте його до commit message, оскільки саме цей запис потрапляє до git history і передається разом із кодом усім, хто пізніше клонує repository. Опис pull request можна змінити після цього, і він зберігається на hosting platform. Додайте повідомлення також до PR body, якщо проєкт виконує squash merge, оскільки squash переписує commit message і може видалити trailer.

Мій pull request закрили, оскільки він був згенерований AI. Що робити?

Не сперечайтеся щодо policy у thread, оскільки людина, яка його закрила, не встановлювала це правило одноосібно, а thread не є місцем для його зміни. Прочитайте текст policy, а потім вирішіть, чи можете ви їй відповідати. Якщо проєкт забороняє generated patches, чіткий bug report із reproducer і без patch усе одно буде доречним. Часто це корисніший внесок. Якщо ви знову надсилаєте код, обмежтеся невеликою зміною, яку можете пояснити по кожному рядку.