Sera za AI katika miradi ya chanzo huria

Nini cha kufanya kabla ya kuwasilisha msimbo uliosaidiwa na AI kwenye upstream

Miradi ya chanzo huria (open source) sasa huchapisha sera kuhusu msimbo uliosaidiwa na AI, na sera hizo hazifanani. Kwa hivyo, utaratibu ni rahisi: tafuta sera husika kabla ya kuandika patch, na uweke wazi kwa usahihi unapoiwasilisha. Kanuni moja inatumika katika hali zote mbili. Usiwahi kuwasilisha mstari wa msimbo ambao huwezi kuuelezea wakati wa ukaguzi.

Patch iliyo sahihi bado inaweza kufungwa ikiwa mradi unakataza msimbo uliotengenezwa na AI, au ikiwa ulificha chanzo cha msimbo huo. Gharama ya hatua hiyo inabaki kwenye jina lako, kwa sababu mtunza mradi (maintainer) akigundua kuwa ulificha ukweli baadaye, hatakuwa na sababu ya kuamini historia yako nyingine. Maneno machache kwanza, kwa sababu sera hutumia maneno haya. LLM (large language model) ndilo modeli lililo nyuma ya wakala wako wa kuandika msimbo. PR (pull request) kwenye GitHub ni sawa na MR (merge request) kwenye GitLab, na kila kitu hapa chini kinahusu yote mawili. DCO (developer certificate of origin) ni mstari wa uthibitisho (sign-off) ulio chini ya ujumbe wa commit, na ndio kiini cha mjadala mzima.

Mahali ambapo sera za chanzo huria kuhusu msimbo wa AI zimefika

Miradi imegawanyika katika makundi manne. Kila mfano hapa chini una tarehe, kwa sababu maandishi haya hubadilika.

Zilizopigwa marufuku. Baraza la Gentoo lilipiga kura tarehe 14 Aprili 2024 kwamba "ni marufuku kabisa kuchangia kwenye Gentoo maudhui yoyote yaliyoundwa kwa usaidizi wa zana za akili bandia za Natural Language Processing". Miongozo ya commit ya NetBSD inaita matokeo kutoka kwa LLM kuwa "msimbo uliochafuliwa" ambao "haupaswi kuingizwa (commit) bila idhini ya maandishi kutoka kwa core". Hati ya asili ya msimbo ya QEMU, kufikia Agosti 2026, bado inasema mradi huo "UTAKATAA michango yoyote inayoaminika kujumuisha au kutokana na maudhui yaliyozalishwa na AI".

Uchambuzi pekee. Marufuku nyingi ni finyu kuliko vichwa vya habari vinavyopendekeza. Hati ya QEMU inasema sera hiyo "haitumiki kwa matumizi mengine ya AI, kama vile kutafiti API au algoriti, uchambuzi tuli (static analysis), au utatuzi wa hitilafu (debugging), mradi matokeo yake hayajajumuishwa kwenye michango". Unaweza kutumia wakala kusoma msimbo. Hauruhusiwi kusambaza (ship) kile kilichoandikwa na AI. Tofauti hiyo ndiyo mstari wa kazi ndani ya miradi mingi yenye vikwazo, na ndiyo watu wanaokosa kuiona.

Ufichuzi unahitajika. Baraza la Fedora liliidhinisha sera kuhusu michango inayosaidiwa na AI mnamo Oktoba 2025. Inaruhusu zana hizo na kuweka uzito kwa mtu: mchangiaji ndiye mwandishi, anawajibika kikamilifu kwa mchango mzima, na lazima afichue wakati sehemu kubwa ya mchango huo imetoka kwenye zana bila mabadiliko. Linux kernel iliongeza ukurasa wa wasaidizi wa uandishi wa msimbo katika nyaraka zake za mchakato mnamo Desemba 2025, ikiwa na sehemu ya kurekodi zana iliyotumika na sheria kali kuhusu nani anayeweza kutoa sign off.

Hakuna kilichoandikwa. Hili bado ni jambo la kawaida. Chapisho la awali la Mei 2026 lilifanya utafiti wa hazina (repositories) 1,000 maarufu za GitHub na kupata 118 pekee zenye sera yoyote ya maandishi ya AI. Ukimya si ruhusa. Uliza kwenye issue tracker kwa sentensi moja kabla ya kuandika patch, na jibu litakuwa rekodi ya umma unayoweza kuirejelea baadaye.

Kwa nini watunza miradi waliandika kanuni hizi

Sababu ya kwanza ni mzigo wa mapitio, na hesabu yake inaelekea upande mmoja. Wakala anaweza kuzalisha merge request ya mistari 400 inayoonekana kuwa sahihi ndani ya dakika moja. Kupitia ombi hilo ipasavyo humgharimu mtunza mradi mchana mzima, na watunza miradi wengi ni watu wa kujitolea. Gharama ya kuwasilisha ilishuka hadi karibu sifuri. Gharama ya kupitia haikubadilika hata kidogo.

curl inaonyesha mwisho wa mkondo huo. Daniel Stenberg aliripoti katikati ya 2025 kwamba takriban sehemu ya tano ya ripoti za usalama zilizofika kupitia bug bounty ya mradi huo zilikuwa kile anachokiita AI slop: ripoti zinazotaja kazi na njia za msimbo halisi, zinazoelezea shambulio linalowezekana, lakini hazina kitu chochote cha maana. Mradi huo ulisitisha tuzo hiyo mapema 2026 badala ya kuendelea kufadhili mafuriko hayo. Hizo zilikuwa ripoti badala ya viraka (patches), lakini ni utaratibu uleule unaomfanya mtunza mradi kufungua PR yako akiwa tayari amechoka.

GNOME Calendar iliandika tatizo hilo kama lebo. Mnamo Juni 2026, mradi huo ulianzisha "Probabilistically Automated" kwa ajili ya merge requests zinazoonyesha "utegemezi mkubwa au kamili kwa 'akili' bandia kuzalisha msimbo", na ikataja dalili hiyo hasa: "kwa kawaida huambatana na ukosefu wa majaribio sahihi, na kuhitimisha viraka kulingana na tabia inayokusudiwa kinadharia badala ya usahihi wa msimbo". Soma sentensi hiyo ya mwisho mara mbili. Msimbo unaonekana kama unapaswa kufanya kazi. Hakuna aliyeangalia kama unafanya kazi kweli.

Sababu ya pili ni asili ya msimbo (provenance), ikimaanisha msimbo huo ulitoka wapi na chini ya leseni ipi. QEMU inaeleza mgogoro huo waziwazi: kutia saini (signing off) kunathibitisha kwamba "unaelewa kikamilifu hali ya hakimiliki na leseni ya maudhui" unayochangia, na hali ya hakimiliki ya matokeo ya modeli haijatatuliwa. Baraza la Gentoo lilitoa sababu hiyo hiyo, pamoja na ubora na maadili. Huna budi kukubaliana na tafsiri ya kisheria. Unapaswa kutambua kuwa ni uamuzi wa mtunza mradi kufanya, si wako.

Jinsi ya kupata sera ya AI ya mradi

Angalia katika maeneo haya, kwa mpangilio huu.

• CONTRIBUTING.md katika mzizi wa hazina (repository root), kisha .github/CONTRIBUTING.md, kisha faili lolote la DCO lililo karibu nalo.
• Nyaraka za msanidi programu. QEMU huweka kanuni zake katika docs/devel/code-provenance.rst. Kernel huweka zake katika Documentation/process/coding-assistants.rst.
• Tovuti ya mradi au wiki. Sera ya Gentoo inapatikana kwenye ukurasa wa wiki wa baraza, na ya NetBSD inapatikana katika miongozo ya commit.
• Kifuatiliaji cha masuala (issue tracker) na kumbukumbu za orodha ya barua pepe (mailing list). Sera kwa kawaida huwepo hapo kwa miezi kadhaa kabla ya mtu yeyote kuiandika kwenye hazina.

Ukiwa ndani ya checkout, amri moja ya grep inashughulikia sehemu kubwa ya kazi hiyo:

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

Kisha soma historia ya mradi wenyewe, kwa sababu makubaliano yaliyowekwa (committed convention) ni bora kuliko muhtasari wowote:

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

Hesabu iliyo karibu na thamani ya trailer inakuambia fomu ambayo mradi huu hutumia kihalisi. Matokeo tupu yanamaanisha hakuna aliyetoa taarifa katika fomu hiyo hapa, jambo ambalo pia ni taarifa muhimu. Ikiwa mradi upo kwenye GitHub na mtiririko wa kazi (workflow) wenyewe ni mpya kwako, jinsi pull requests na forks zinavyofanya kazi kwenye GitHub inashughulikia mbinu ambazo sehemu hii inazichukulia kuwa zinajulikana.

Fichua kwenye trailer ya commit, siyo kwenye maoni

Trailer ni mstari wa Key: value katika aya ya mwisho ya ujumbe wa commit. Git tayari hutumia umbo hili kwa Signed-off-by: na Co-authored-by:, na zana huichakata, kwa hivyo ni ufichuzi pekee unaosafiri na msimbo kwenye tree.

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>

Kernel huandika umbo hilo kama Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2], na iko wazi kuhusu kikomo cha mstari: "Mawakala wa AI HAWATAKIWI kuongeza vitambulisho vya Signed-off-by. Wanadamu pekee ndio wanaoweza kuthibitisha kisheria Developer Certificate of Origin (DCO)." Jina la wakala huwekwa kwenye Assisted-by. Jina lako huwekwa kwenye Signed-off-by. Usiruhusu zana kuandika la pili, na usiruhusu itunge anwani ya Co-authored-by ambayo si ya mtu yeyote.

Majina hutofautiana, kwa hivyo nakili lile la ndani badala ya kutunga lako. Patch iliyotumwa kwenye orodha ya QEMU mnamo Mei 2026 ilipendekeza kulegeza marufuku ya mradi huo kwa mabadiliko ya kiufundi, majaribio, nyaraka na marekebisho ya hitilafu ya mistari ishirini au chini ya hapo, yaliyorekodiwa na trailer kama AI-used-for: tests, docs. Kufikia Agosti 2026 hilo ni pendekezo kwenye mailing list na hati iliyowasilishwa bado inakataa maudhui yaliyozalishwa na mashine. Mradi mmoja ulibadilisha msimamo wake mara mbili kati ya 2023 na 2026. Hatua inayofuata haitakusubiri, ndiyo maana mbinu ni muhimu zaidi kuliko orodha.

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 inahitaji Git 2.32 au mpya zaidi. Amri ya pili inapaswa kuchapisha thamani hiyo moja kwa moja kwako. Mstari mtupu unamaanisha kuwa git haikuchakata trailer, karibu kila mara kwa sababu mstari mtupu au sentensi ya kawaida imekaa ndani ya kizuizi cha trailer chini ya ujumbe. Kwa mfululizo uliokwisha kuandika, git rebase --signoff origin/main huongeza sign-off kwenye kila commit, na git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt huhariri faili ya ujumbe.

Njia mbili za kufeli zinastahili kupangiwa. Squash merge huandika upya ujumbe wa commit, kwa hivyo kwenye mradi unaofanya squash, rudia ufichuzi katika maelezo ya PR ambapo mtunza mradi (maintainer) anausoma. Na maoni ya ukaguzi (review comment) si rekodi, kwa sababu maoni yanaweza kuhaririwa na hayafiki kamwe kwenye historia ya git.

Usahihi ni wa pande mbili. Assisted-by kwenye commit uliyoandika kwa mkono ni kelele, na hufanya ufichuzi wako wa kweli kupoteza thamani. Kuiacha kwenye commit ambayo wakala aliandika ndilo jambo linalomaliza uhusiano.

Je, Signed-off-by inathibitisha nini hasa?

DCO ni maandishi mafupi, toleo la 1.1, yaliyochapishwa katika developercertificate.org na kutumiwa na kernel, QEMU, na miradi mingine mingi. Kuongeza Signed-off-by: Your Name <you@example.com> kunamaanisha kuwa unathibitisha hilo. Soma unachothibitisha, kwa sababu watu wengi husaini bila kusoma.

Kifungu (a) kinasema kuwa mchango "uliandaliwa kwa sehemu au kwa ukamilifu na mimi na nina haki ya kuwasilisha chini ya leseni ya open source iliyoonyeshwa kwenye faili". Kifungu (b) kinahusu kazi inayotokana na msimbo wa awali wa open source ambao una haki ya kuupitisha ukiwa na marekebisho. Kifungu (c) kinahusu msimbo uliokabidhiwa na mtu aliyethibitisha jambo lilelile. Kifungu (d) kinasema kuwa unaelewa kuwa mchango huo na taarifa zako binafsi katika sign-off ni za umma na zitahifadhiwa bila kikomo.

Angalia kile kinachokosekana. DCO haisemi kamwe kuwa umeandika kila herufi. Inasema una haki ya kuwasilisha msimbo huo chini ya leseni hii. Ndiyo maana msimbo uliotengenezwa na mashine (generated code) huleta utata hapa: swali si kuhusu uandishi, bali ni kama unaweza kuthibitisha asili yake. Miradi mingi inayohitaji sign-off pia inahitaji jina halisi, kwa hivyo jina bandia (pseudonym) halikubaliki katika ukaguzi huu. Ongeza mstari huo kwa kutumia git commit -s, ambao unasoma user.name na user.email kutoka kwenye git config yako. Wakati bot ya DCO inapokataa PR yako na kutaja commit inayokosa mstari huo, git rebase --signoff origin/main na kufanya force push kwenye branch yako kutatatua tatizo hilo.

Kutia saini commit si sawa na kufanya sign-off

git commit -s huongeza mstari wa maandishi. git commit -S hutengeneza saini ya cryptographic juu ya kitu cha commit kwa kutumia ufunguo wako wa GPG au SSH. Hujibu maswali tofauti. Saini inathibitisha kuwa commit hii imetoka kwa mwenye ufunguo huo na haijabadilishwa tangu wakati huo. Haielezi chochote kuhusu asili ya msimbo uliomo, kwa hivyo commit iliyotiwa saini iliyojaa msimbo uliotengenezwa bila kufichuliwa bado ni ukiukaji wa sera. Sign-off ni madai kuhusu asili ya msimbo. Saini ni madai kuhusu utambulisho. Miradi inayohitaji yote miwili itaomba yote miwili.

Usikubali kamwe kuwasilisha msimbo usiouelewa wakati wa ukaguzi

Huu ndio mtihani, na kwa kweli hauhusu uaminifu. Kwa kila mstari: huu ni wa nini, na nini kitaharibika bila huo? Ikiwa jibu lolote linakosekana, viraka (patch) havijakamilika, kwa sababu maoni ya ukaguzi yatakuja na jibu lako litakuwa ni mzunguko mwingine wa uzalishaji. Wakaguzi wanaweza kutambua. Huo ndio wakati ambapo mchangiaji anageuka kuwa mzigo. Uliza swali hilohilo kuhusu kingo, ingizo tupu, njia ya kufeli, na mpigaji wa pili.

Endesha kitu hicho. Kijenge, endesha suite ya majaribio ya mradi, na uandike kirejeshi (reproducer) cha mdudu unayedai kurekebisha. Nyaraka za kernel hutoa njia mbadala ya uaminifu kwa maneno ya wazi: "Ikiwa marekebisho hayakuweza kujengwa au kupimwa, au ikiwa hakuna kirejeshi kilichoweza kuzalishwa, sema hivyo waziwazi: watunzaji kwa sasa wanapoteza muda mwingi kuchambua ripoti ambazo hazijathibitishwa na marekebisho ambayo hayajajaribiwa." Kuandika "Sikuweza kupima hili kwenye maunzi halisi" hakukugharimu chochote. Kudokeza kuwa ulifanya hivyo kunakugharimu mradi.

Jibu maoni ya ukaguzi wewe mwenyewe, kwa maneno yako mwenyewe na kwa wakati wako. Jibu linalofika sekunde thelathini baada ya maoni na kuyarejea katika aya tano humwambia mtunzaji kile kilichotokea hasa. Weka diff iwe ndogo pia. Mistari arobaini unayoielewa kikamilifu ina thamani zaidi kwa mradi kuliko urekebishaji wa mistari mia nne uliyoisimamia. Ikiwa wakala wako anaendelea kukupa zaidi ya uliyoomba, ujuzi unaouweka kwenye mabadiliko madogo zaidi yanayofanya kazi ni njia moja ya kuweka viraka kwenye kitu ambacho bado unaweza kukitetea mstari kwa mstari.

Hifadhi maelekezo ya wakala kwenye hazina (repo)

Maelekezo unayompa wakala wako ni sehemu ya mfumo wako wa zana, kwa hivyo yachukulie kama msimbo (code). Faili iliyo kwenye mzizi wa hazina, kwa kawaida AGENTS.md, huhifadhi amri ya ujenzi (build command), amri ya majaribio (test command), muundo wa ujumbe wa commit, hitaji la uthibitishaji (sign-off), na sheria za mtindo ambazo mradi tayari umeziorodhesha. Faili hiyo ina toleo (versioned) na inaweza kukaguliwa, na itabaki vilevile kesho kama ilivyo leo. Maelekezo yanayoandikwa upya kutoka kwenye kumbukumbu kila kikao huzalisha viraka (patch) tofauti kila kikao, na hutajua ni kikao kipi kilichozalisha kiraka kilichokataliwa. Kuandika AGENTS.md inayoweza kusomwa na wakala na binadamu inashughulikia faili hiyo yenyewe.

Tahadhari moja kuhusu hazina za watu wengine. Usifanye mchango wako wa kwanza kuwa PR inayoongeza faili ya maelekezo ya wakala kwenye mradi usioumiliki. Hilo linaonekana kama jaribio la kuweka sera ya zana za mradi kutoka nje, na ni njia ya haraka ya kufanya akaunti yako ihusishwe na jambo ambalo wasimamizi wamekwishachoka nalo. Hifadhi faili hiyo kwenye fork yako hadi mtu mwingine aiombe.

Mahali unapoiendesha wakala ni muhimu kwa sababu hiyo hiyo. Wakala anayeweza kujenga mradi na kuendesha majaribio yake ndani ya sandbox unayoimiliki hukupa kiraka ambacho umekithibitisha kikweli, ambayo ndiyo tofauti kati ya kufichua usaidizi na kufichua kubahatisha. Kuendesha wakala wa uandishi wa msimbo kwenye VPS yako mwenyewe inashughulikia usanidi huo, na tofauti za kivitendo kati ya Claude Code, Cursor, Codex na Copilot inashughulikia jinsi zana hizo zinavyotofautiana kila siku.

Mbinu, pindi sera inapobadilika

1. Tafuta sera iliyoelezwa kabla ya kuandika chochote: repository, nyaraka za msanidi, tovuti, au tracker.
2. Ikiwa hakuna sera, uliza kupitia issue kwa sentensi moja, na uhifadhi jibu hilo.
3. Toa taarifa kwa mfumo unaotumiwa na mradi huo, kwenye commit trailer, na uirudie katika mwili wa PR ikiwa mradi huo hufanya squash ya commits.
4. Tia saini kwa jina lako halisi, ukijua kuwa mstari huo ni madai kuhusu haki yako ya kuwasilisha code hiyo.
5. Kagua patch yako mwenyewe kana kwamba imeandikwa na mgeni, kwa sababu kwa hakika hivyo ndivyo ilivyo.

Kila mradi uliotajwa kwenye ukurasa huu utakuwa umehamishwa wakati utakapousoma. Hatua hizi tano hazibadiliki.

FAQ

Je, ni lazima nifichue kuwa nimetumia wakala wa uandishi wa msimbo wa AI?

Kagua mradi husika, kwa sababu jibu limewekwa ndani ya mradi huo. Fedora inahitaji ufichuzi wakati sehemu kubwa ya mchango imetokana na zana bila kufanyiwa mabadiliko. Linux kernel inaomba Assisted-by trailer. Gentoo na QEMU, kufikia Agosti 2026, hazitaki mchango huo hata kidogo. Pale ambapo hakuna maandishi yoyote, fichua hata hivyo kupitia commit trailer. Msimamizi anayegundua baadaye atajibu kulingana na kutofichua kwako badala ya zana yenyewe, na majibu hayo yataathiri kila kitu kingine ulichotuma.

Ni miradi ipi ya chanzo huria (open source) inayopiga marufuku msimbo uliotengenezwa na AI?

Kama muhtasari wa Agosti 2026: Gentoo tangu Aprili 2024, NetBSD ambayo inachukulia matokeo ya LLM kama msimbo uliochafuliwa unaohitaji idhini ya msingi, QEMU ambayo inakataa michango inayotokana na maudhui yaliyotengenezwa, na programu kadhaa za GNOME ikiwemo Loupe na Calendar. Soma maandishi ya kila mradi badala ya orodha hii, kwa sababu itapitwa na wakati. Kumbuka msamaha ambao mingi yao inashiriki: kutumia model kutafiti API, kuendesha static analysis au kukusaidia kutatua hitilafu (debug) kwa kawaida ni sawa, mradi matokeo yake hayapo kwenye patch.

Kuna tofauti gani kati ya Signed-off-by na commit iliyotiwa saini?

Signed-off-by ni mstari wa maandishi ya kawaida ulioongezwa na git commit -s. Inathibitisha cheti cha asili cha msanidi (developer certificate of origin), ikimaanisha una haki ya kuwasilisha msimbo huu chini ya leseni ya mradi. Commit iliyotiwa saini, iliyofanywa kwa git commit -S, ni sahihi ya kijiografia (cryptographic signature) juu ya kitu cha commit (commit object) kwa kutumia ufunguo wako wa GPG au SSH. Inathibitisha kuwa commit ilitoka kwenye ufunguo wako na haikubadilishwa. Asili na utambulisho ni madai tofauti, kwa hivyo commit iliyotiwa saini bado inaweza kukiuka sera ya AI.

Je, ninaweza kuweka ufichuzi kwenye maelezo ya pull request badala ya ujumbe wa commit?

Uweke kwenye ujumbe wa commit, kwa sababu huo ndio rekodi inayotua kwenye git history na kusafiri na msimbo kwa yeyote anayekopi (clone) hazina (repository) hiyo baadaye. Maelezo ya pull request yanaweza kuhaririwa baadaye na yanakaa kwenye jukwaa la hosting. Uongeze kwenye mwili wa PR pia wakati mradi unatumia squash merge, kwa sababu squash huandika upya ujumbe wako wa commit na inaweza kuondoa trailer.

Pull request yangu ilifungwa kwa sababu ilitengenezwa na AI. Nifanye nini sasa?

Usibishane kuhusu sera kwenye thread hiyo, kwa sababu mtu anayeifunga hakutunga sheria hiyo peke yake na thread hiyo si mahali ambapo sheria hubadilika. Soma maandishi ya sera, kisha amua kama unaweza kuyafuata. Pale ambapo mradi unapiga marufuku patch zilizotengenezwa, ripoti ya hitilafu iliyo wazi yenye njia ya kuzalisha hitilafu (reproducer) na bila patch bado inakaribishwa, na mara nyingi huo ndio mchango wenye manufaa zaidi. Ukirudi na msimbo, rudi na mabadiliko madogo unayoweza kuyatetea mstari kwa mstari.