AI code کے لیے open source policies: PR سے پہلے کیا کریں

AI کی مدد سے تیار کردہ code upstream بھیجنے سے پہلے کیا کریں

اب open source projects، AI کی مدد سے تیار کردہ code کے بارے میں policies شائع کرتے ہیں، اور یہ policies ایک دوسرے سے متفق نہیں ہوتیں۔ اس لیے طریقہ سادہ ہے: patch لکھنے سے پہلے policy تلاش کریں، اور اسے بھیجتے وقت درست طور پر disclosure کریں۔ دونوں کے پیچھے ایک اصول ہے۔ review میں ایسی کوئی line submit نہ کریں جس کی وضاحت آپ نہ کر سکیں۔

درست patch بھی close ہو سکتا ہے اگر project generated code پر پابندی لگاتا ہو، یا آپ نے code کے ماخذ کو چھپایا ہو۔ اس کا بوجھ آپ کے نام پر آتا ہے اور وہیں رہتا ہے، کیونکہ اگر maintainer کو بعد میں یہ omission معلوم ہو جائے تو اسے آپ کی باقی history پر اعتماد کرنے کی کوئی وجہ نہیں رہتی۔ پہلے چند اصطلاحات واضح کر لیں، کیونکہ policies میں یہی استعمال ہوتی ہیں۔ LLM (large language model) وہ model ہے جو آپ کے coding agent کے پیچھے کام کرتا ہے۔ GitHub پر PR (pull request)، GitLab پر MR (merge request) کہلاتا ہے، اور ذیل کی تمام باتیں دونوں پر لاگو ہوتی ہیں۔ DCO (developer certificate of origin) commit message کے آخر میں موجود sign-off line ہے، اور معلوم ہوتا ہے کہ پوری بحث کا مرکز یہی ہے۔

AI code کے بارے میں open source پالیسیوں کا موجودہ رخ

Projects چار زمروں میں تقسیم ہو چکے ہیں۔ ذیل کی ہر مثال کے ساتھ تاریخ دی گئی ہے، کیونکہ یہ متون بدلتے رہتے ہیں۔

ممنوع۔

Gentoo کی council نے 14 April 2024 کو فیصلہ کیا کہ "Natural Language Processing artificial intelligence tools کی مدد سے تیار کردہ کسی بھی مواد کو Gentoo میں شامل کرنا صراحتاً ممنوع ہے۔" NetBSD کی commit guidelines، LLM کے output کو "tainted code" کہتی ہیں، جسے core کی پیشگی تحریری منظوری کے بغیر "commit نہیں کیا جا سکتا۔" QEMU کی code provenance دستاویز، August 2026 تک، اب بھی کہتی ہے کہ project "ایسی تمام contributions کو مسترد کرے گا جن کے بارے میں یقین ہو کہ ان میں AI generated content شامل ہے یا وہ اس سے ماخوذ ہیں۔"

صرف analysis۔

زیادہ تر پابندیاں سرخی سے زیادہ محدود ہوتی ہیں۔ QEMU کی دستاویز کہتی ہے کہ policy "AI کے دیگر استعمالات، مثلاً APIs یا algorithms کی تحقیق، static analysis یا debugging، پر لاگو نہیں ہوتی، بشرطیکہ ان کا output contributions میں شامل نہ ہو۔" آپ agent کو code پڑھنے کے لیے استعمال کر سکتے ہیں۔ آپ اس کے لکھے ہوئے code کو release نہیں کر سکتے۔ زیادہ تر restrictive projects میں عملی حد یہی ہے، اور لوگ عموماً اسی فرق کو نظرانداز کرتے ہیں۔

Disclosure ضروری ہے۔

Fedora کی council نے October 2025 میں AI-assisted contributions کے بارے میں policy منظور کی۔ یہ tools کے استعمال کی اجازت دیتی ہے اور ذمہ داری contributor پر عائد کرتی ہے: contributor ہی author ہوتا ہے، پوری contribution کے لیے مکمل طور پر جواب دہ ہوتا ہے، اور جب contribution کا کوئی اہم حصہ کسی tool سے بغیر تبدیلی کے حاصل کیا گیا ہو تو اسے اس کا disclosure کرنا ہوگا۔ Linux kernel کی process documentation میں December 2025 کو coding assistants کا صفحہ شامل کیا گیا، جس میں tool record کرنے کے لیے trailer اور sign off کرنے والے فرد کے بارے میں ایک واضح لازمی اصول موجود ہے۔

کچھ تحریری شکل میں موجود نہیں۔

اب بھی یہی عام صورت ہے۔ May 2026 کے ایک preprint نے 1,000 مقبول GitHub repositories کا جائزہ لیا اور پایا کہ صرف 118 repositories میں AI کے بارے میں کوئی تحریری policy موجود تھی۔ خاموشی اجازت نہیں ہوتی۔ patch لکھنے سے پہلے issue tracker میں ایک جملے میں پوچھ لیں۔ اس طرح جواب public record بن جاتا ہے، جس کا بعد میں حوالہ دیا جا سکتا ہے۔

منتظمین نے یہ قواعد کیوں لکھے

پہلی وجہ جائزوں کا بوجھ ہے، اور حساب ہمیشہ ایک ہی سمت میں جاتا ہے۔ ایک agent ایک منٹ میں بظاہر قابلِ قبول 400 سطروں والی merge request تیار کر دیتا ہے۔ اس request کا درست جائزہ لینے میں maintainer کی پوری دوپہر لگ سکتی ہے، اور زیادہ تر maintainers رضاکار ہوتے ہیں۔ submission کی لاگت تقریباً صفر رہ گئی ہے۔ review کی لاگت میں کوئی کمی نہیں آئی۔

curl اس رجحان کی دوسری انتہا دکھاتا ہے۔ Daniel Stenberg نے 2025 کے وسط میں بتایا کہ project کے bug bounty پروگرام کے ذریعے موصول ہونے والی security reports میں تقریباً پانچواں حصہ وہ تھا جسے وہ AI slop کہتے ہیں: ایسی reports جن میں حقیقی functions اور حقیقی code paths کے نام، ایک قابلِ عمل معلوم ہونے والا attack، اور اس کے سوا کچھ نہیں ہوتا۔ flood کی funding جاری رکھنے کے بجائے project نے 2026 کے آغاز میں bounty ختم کر دی۔ وہ reports تھیں، patches نہیں، لیکن mechanism وہی ہے جس کی وجہ سے maintainer آپ کی PR پہلے ہی تھکا ہوا کھولتا ہے۔

GNOME Calendar نے اس مسئلے کو ایک label کی صورت میں درج کیا۔ جون 2026 میں project نے ان merge requests کے لیے "Probabilistically Automated" متعارف کرایا جن میں code تیار کرنے کے لیے artificial 'intelligence' پر "major or total reliance" دکھائی دے، اور اس علامت کو واضح الفاظ میں بیان کیا: "usually accompanied by a lack of proper testing, and finalizing patches based on theoretical intended behavior rather than correctness of code"۔ آخری فقرہ دوبارہ پڑھیں۔ code ایسا دکھائی دیتا ہے جیسے اسے کام کرنا چاہیے۔ کسی نے یہ جانچ نہیں کی کہ وہ واقعی کام کرتا ہے یا نہیں۔

دوسری وجہ provenance ہے، یعنی code کہاں سے آیا اور کس license کے تحت آیا۔ QEMU اس تنازعے کو واضح طور پر بیان کرتا ہے: sign-off کرنے کا مطلب یہ یقین دلانا ہے کہ آپ اپنے contributed content کی "copyright and license status" کو "fully understand" کرتے ہیں، جبکہ model output کی copyright حیثیت ابھی غیر واضح ہے۔ Gentoo کی council نے بھی quality اور ethics کے ساتھ یہی وجہ بیان کی۔ قانونی تشریح سے آپ کا متفق ہونا ضروری نہیں۔ لیکن آپ کو یہ سمجھنا ہوگا کہ فیصلہ maintainer کو کرنا ہے، آپ کو نہیں۔

میں کسی project کی AI policy کیسے تلاش کروں؟

ان مقامات کو اسی ترتیب سے دیکھیں۔

• repository root میں CONTRIBUTING.md، پھر .github/CONTRIBUTING.md، اور اس کے بعد اس کے ساتھ موجود کوئی بھی DCO file۔
• developer docs۔ QEMU اپنی rule docs/devel/code-provenance.rst میں رکھتا ہے۔ kernel اپنی rule Documentation/process/coding-assistants.rst میں رکھتا ہے۔
• project کی website یا wiki۔ Gentoo کی policy council کی wiki page پر موجود ہے، جبکہ NetBSD کی policy commit guidelines میں موجود ہے۔
• issue tracker اور mailing list archive۔ عموماً policy وہاں کئی ماہ پہلے سے موجود ہوتی ہے، اس سے پہلے کہ کوئی اسے repository میں شامل کرے۔

checkout کے اندر ایک grep زیادہ تر مقامات کا احاطہ کر لیتا ہے:

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

اس کے بعد project کی اپنی history پڑھیں، کیونکہ committed convention اس کے کسی بھی summary سے زیادہ معتبر ہوتی ہے:

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 value کے ساتھ موجود count آپ کو بتاتا ہے کہ یہ project حقیقت میں کون سا form استعمال کرتا ہے۔ خالی result کا مطلب ہے کہ یہاں کسی نے اس form میں disclosure نہیں کیا، اور یہ بھی مفید information ہے۔ اگر project GitHub پر موجود ہے اور یہ workflow آپ کے لیے نیا ہے تو GitHub پر pull requests اور forks کیسے کام کرتے ہیں اس section میں فرض کیے گئے طریقہ کار کی وضاحت کرتا ہے۔

commit trailer میں اعلان کریں، comment میں نہیں

Trailer، commit message کے آخری پیراگراف میں موجود Key: value لائن ہوتی ہے۔ Git پہلے ہی Signed-off-by: اور Co-authored-by: کے لیے یہی فارمیٹ استعمال کرتا ہے، اور tools اسے parse کرتے ہیں۔ اس لیے یہی وہ واحد اعلان ہے جو code کے ساتھ 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 اس فارمیٹ کو Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] کے طور پر document کرتا ہے، اور لائن کی حد واضح طور پر بتاتا ہے: "AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)." Agent کا نام Assisted-by میں جاتا ہے۔ آپ کا نام Signed-off-by میں جاتا ہے۔ کسی tool کو دوسری entry لکھنے نہ دیں، اور اسے ایسا Co-authored-by address ایجاد نہ کرنے دیں جو کسی کا نہ ہو۔

نام مختلف ہو سکتے ہیں، اس لیے اپنا نام ایجاد کرنے کے بجائے مقامی format copy کریں۔ May 2026 میں QEMU list پر بھیجی گئی ایک patch میں اس project کی پابندی mechanical changes، tests، docs اور بیس یا اس سے کم lines کی bug fixes کے لیے نرم کرنے کی تجویز دی گئی تھی۔ اسے AI-used-for: tests, docs جیسے trailer کے ذریعے record کیا جاتا۔ August 2026 تک یہ mailing list پر موجود ایک proposal ہے، اور committed document اب بھی generated content کو قبول نہیں کرتا۔ ایک project نے 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 یا اس کے بعد کا version درکار ہے۔ دوسری command کو value براہ راست واپس print کرنی چاہیے۔ خالی لائن کا مطلب ہے کہ git نے trailer parse نہیں کیا۔ اس کی تقریباً ہمیشہ وجہ یہ ہوتی ہے کہ message کے آخر میں trailer block کے اندر کوئی blank line یا عام sentence موجود ہے۔ پہلے سے لکھی گئی series کے لیے git rebase --signoff origin/main ہر commit میں sign-off شامل کرتا ہے، جبکہ git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt message file میں ترمیم کرتا ہے۔

دو failure modes کے لیے پہلے سے منصوبہ بنائیں۔ Squash merge commit message کو دوبارہ لکھتا ہے۔ اس لیے squash کرنے والے project میں PR description میں بھی یہی اعلان دہرائیں، جہاں maintainer اسے پڑھتا ہے۔ Review comment record نہیں ہوتا، کیونکہ comments میں ترمیم ہو سکتی ہے اور وہ کبھی git history میں شامل نہیں ہوتے۔

درستگی دونوں طرف لاگو ہوتی ہے۔ اپنے ہاتھ سے لکھے گئے commit پر Assisted-by غیر ضروری شور ہے، اور اس سے آپ کے حقیقی اعلانات کی اہمیت کم ہوتی ہے۔ Agent کے لکھے ہوئے commit میں اسے شامل نہ کرنا ہی وہ عمل ہے جو تعلق ختم کر دیتا ہے۔

Signed-off-by در حقیقت کس بات کی تصدیق کرتا ہے؟

DCO ایک مختصر متن ہے، ورژن 1.1، جو developercertificate.org پر شائع ہوا ہے۔ اسے kernel، QEMU اور بہت سے دوسرے منصوبے استعمال کرتے ہیں۔ Signed-off-by: Your Name <you@example.com> شامل کرنے کا مطلب ہے کہ آپ اس کی تصدیق کرتے ہیں۔ پہلے پڑھیں کہ آپ کس بات کی تصدیق کر رہے ہیں، کیونکہ زیادہ تر لوگ اسے کبھی پڑھے بغیر sign کر دیتے ہیں۔

شق (a) کہتی ہے کہ contribution "مکمل یا جزوی طور پر میری تخلیق ہے اور مجھے اسے file میں درج open source license کے تحت جمع کرانے کا حق حاصل ہے"۔ شق (b) پہلے سے موجود open source code پر مبنی کام کا احاطہ کرتی ہے، بشرطیکہ آپ کو اسے ترمیم کے ساتھ آگے فراہم کرنے کا حق حاصل ہو۔ شق (c) اس code کا احاطہ کرتی ہے جو آپ کو ایسے شخص نے فراہم کیا ہو جس نے اسی بات کی تصدیق کی ہو۔ شق (d) کہتی ہے کہ آپ سمجھتے ہیں کہ contribution اور آپ کے sign-off میں موجود ذاتی معلومات عوامی ہوں گی اور غیر معینہ مدت تک محفوظ رہیں گی۔

غور کریں کہ اس میں کیا شامل نہیں ہے۔ DCO کبھی یہ نہیں کہتا کہ ہر character آپ نے خود type کیا ہے۔ اس میں کہا گیا ہے کہ آپ کو اس code کو اس license کے تحت جمع کرانے کا حق حاصل ہے۔ اسی لیے generated code اس معاملے میں ایک پیچیدہ صورت پیدا کرتا ہے: سوال authorship کا نہیں، بلکہ code کے ماخذ کی وضاحت کرنے کی صلاحیت کا ہے۔ زیادہ تر منصوبے جو sign-off لازمی قرار دیتے ہیں، حقیقی نام بھی لازمی قرار دیتے ہیں، اس لیے pseudonym اس جانچ میں ناکام ہو جاتا ہے۔ git commit -s والی line شامل کریں، جو user.name اور user.email کو آپ کی git config سے پڑھتی ہے۔ جب DCO bot آپ کے PR کو مسترد کرے اور اس commit کا نام دے جس میں یہ line موجود نہ ہو، تو git rebase --signoff origin/main اور اپنی branch پر force push کرنے سے مسئلہ حل ہو جاتا ہے۔

Commit پر دستخط کرنا sign-off کرنے کے برابر نہیں

git commit -s متن کی ایک سطر شامل کرتا ہے۔ git commit -S آپ کی GPG یا SSH key استعمال کرتے ہوئے commit object پر cryptographic signature بناتا ہے۔ یہ دونوں مختلف سوالات کا جواب دیتے ہیں۔ signature اس بات کی تصدیق کرتا ہے کہ یہ commit اس key کے حامل کی طرف سے آیا ہے اور اس کے بعد اس میں کوئی تبدیلی نہیں کی گئی۔ اس سے یہ معلوم نہیں ہوتا کہ اندر موجود code کہاں سے آیا ہے۔ اس لیے undisclosed generated code سے بھرا ہوا signed commit دستخط شدہ تو ہے، لیکن پھر بھی policy کی خلاف ورزی ہو سکتا ہے۔ sign-off اصل ماخذ سے متعلق دعویٰ ہے۔ signature شناخت سے متعلق دعویٰ ہے۔ جو projects دونوں چاہتے ہیں، وہ دونوں کا مطالبہ کریں گے۔

جس code کی وضاحت review میں نہ کر سکیں، اسے کبھی submit نہ کریں

یہ اصل امتحان ہے، اور اس کا تعلق حقیقتاً دیانت داری سے نہیں۔ ہر line کے بارے میں بتائیں: یہ کس کام کے لیے ہے، اور اس کے بغیر کیا خراب ہوگا؟ اگر دونوں میں سے کوئی جواب موجود نہ ہو تو patch تیار نہیں ہے، کیونکہ review comment آئے گا اور آپ کا جواب generation کے ایک اور دور پر مشتمل ہوگا۔ Reviewers یہ بات سمجھ لیتے ہیں۔ یہی وہ لمحہ ہے جب contributor ایک لاگت بن جاتا ہے۔ یہی سوال edges، empty input، failure path اور دوسرے caller کے بارے میں بھی پوچھیں۔

اسے چلائیں۔ اسے build کریں، project کی test suite چلائیں، اور جس bug کو ٹھیک کرنے کا دعویٰ کرتے ہیں اس کے لیے reproducer لکھیں۔ kernel documentation واضح الفاظ میں دیانت دار fallback فراہم کرتی ہے: "اگر fix کو build یا test نہیں کیا جا سکا، یا reproducer تیار نہیں کیا جا سکا، تو یہ بات واضح طور پر بتائیں: maintainers اس وقت unverified reports اور untested fixes کا تجزیہ کرنے میں بہت زیادہ وقت ضائع کرتے ہیں۔" یہ لکھنے میں آپ کا کچھ خرچ نہیں ہوتا کہ "میں اسے real hardware پر test نہیں کر سکا۔" یہ تاثر دینا کہ آپ نے test کیا ہے، project کو نقصان پہنچاتا ہے۔

Review comments کا جواب خود دیں، اپنے الفاظ میں اور اپنی رفتار کے مطابق۔ Comment کے تیس سیکنڈ بعد آنے والا ایسا reply جو اسے پانچ paragraphs میں دوبارہ بیان کرے، maintainer کو فوراً بتا دیتا ہے کہ کیا ہوا ہے۔ Diff بھی چھوٹا رکھیں۔ چالیس lines جنہیں آپ مکمل طور پر سمجھتے ہیں، project کے لیے اس چار سو lines کے refactor سے زیادہ قیمتی ہیں جس کی آپ نے صرف نگرانی کی ہو۔ اگر آپ کا agent بار بار آپ کی درخواست سے زیادہ code واپس کرتا ہے تو ایسی skill جو اسے کام کرنے والی کم سے کم تبدیلی تک محدود رکھے patch کو اتنا چھوٹا رکھنے کا ایک طریقہ ہے کہ آپ اب بھی line by line اس کا دفاع کر سکیں۔

ایجنٹ کی ہدایات repository میں رکھیں

آپ اپنے ایجنٹ کو جو ہدایات دیتے ہیں، وہ آپ کے toolchain کا حصہ ہوتی ہیں، اس لیے انہیں code کی طرح سمجھیں۔ عموماً repository کے root میں موجود AGENTS.md فائل build command، test command، commit message format، sign-off کی ضرورت اور project میں پہلے سے دستاویزی style rules رکھتی ہے۔ یہ فائل versioned اور reviewable ہوتی ہے، اور آج بھی وہی رہتی ہے جو کل تھی۔ ہر session میں یادداشت سے دوبارہ لکھی گئی ہدایات ہر session میں مختلف patch تیار کرتی ہیں، اور آپ کو معلوم نہیں ہوگا کہ rejected patch کس session میں تیار ہوا تھا۔ ایسی AGENTS.md لکھنا جسے ایجنٹ اور انسان دونوں پڑھ سکیں خود اس فائل کا احاطہ کرتا ہے۔

دوسرے لوگوں کی repositories کے بارے میں ایک احتیاط ضروری ہے۔ ایسے project میں، جسے آپ maintain نہیں کرتے، اپنی پہلی contribution کے طور پر agent instruction file شامل کرنے والی PR نہ بھیجیں۔ اس سے ایسا لگتا ہے جیسے آپ باہر سے project کی tooling policy مقرر کرنے کی کوشش کر رہے ہیں۔ اس طرح آپ کا account فوراً اس چیز سے وابستہ ہو سکتا ہے جس سے maintainers پہلے ہی تنگ ہیں۔ فائل اپنے fork میں رکھیں، جب تک کوئی خود اس کا مطالبہ نہ کرے۔

آپ agent کہاں چلاتے ہیں، یہ بھی اسی وجہ سے اہم ہے۔ ایسا agent جو آپ کے زیرِ کنٹرول sandbox کے اندر project build کر سکے اور اس کے tests چلا سکے، آپ کو ایسا patch دیتا ہے جس کی آپ نے حقیقتاً تصدیق کی ہو۔ یہی assistance disclose کرنے اور محض ایک guess disclose کرنے کے درمیان فرق ہے۔ اپنے VPS پر coding agent چلانا اس setup کا احاطہ کرتا ہے، جبکہ Claude Code، Cursor، Codex اور Copilot کے عملی اختلافات بتاتا ہے کہ یہ tools روزمرہ استعمال میں کیسے مختلف ہیں۔

پالیسی تبدیل ہونے کے بعد طریقہ

1. کچھ بھی لکھنے سے پہلے بیان کردہ پالیسی تلاش کریں: repository، developer docs، website، tracker۔
2. اگر پالیسی موجود نہ ہو تو issue میں ایک جملے میں پوچھیں، اور جواب محفوظ رکھیں۔
3. جس format کو project استعمال کرتا ہے، اسی میں disclosure دیں، commit trailer میں بھی شامل کریں، اور اگر project squash کرتا ہو تو اسے PR body میں دوبارہ لکھیں۔
4. اپنے اصل نام سے sign off کریں، کیونکہ یہ سطر اس بات کا دعویٰ ہے کہ آپ کو code جمع کرانے کا حق حاصل ہے۔
5. اپنے patch کا ایسے جائزہ لیں جیسے اسے کسی اجنبی نے لکھا ہو، کیونکہ اسے واقعی کسی اور نے لکھا ہے۔

اس صفحے پر درج ہر project آپ کے یہ پڑھنے تک تبدیل ہو چکا ہوگا۔ یہ پانچ مراحل تبدیل نہیں ہوں گے۔

FAQ

کیا مجھے یہ بتانا ہوگا کہ میں نے AI coding agent استعمال کیا تھا؟

پروجیکٹ کی ہدایات دیکھیں، کیونکہ جواب مقامی پالیسی کے مطابق ہوتا ہے۔ Fedora اس وقت disclosure کا تقاضا کرتا ہے جب contribution کا بڑا حصہ کسی ایسے tool سے آیا ہو اور اس میں تبدیلیاں نہ کی گئی ہوں۔ Linux kernel میں Assisted-by trailer درکار ہوتا ہے۔ August 2026 تک Gentoo اور QEMU ایسی contribution بالکل نہیں چاہتے۔ جہاں کچھ تحریری طور پر درج نہ ہو، وہاں بھی commit trailer میں disclosure کر دیں۔ اگر maintainer کو بعد میں معلوم ہو جائے تو اس کا ردعمل tool کے بجائے omission پر ہوتا ہے، اور یہ ردعمل آپ کی بھیجی ہوئی باقی تمام چیزوں تک پھیل جاتا ہے۔

کون سے open source projects AI-generated code پر پابندی لگاتے ہیں؟

August 2026 کی صورتِ حال کے مطابق: Gentoo نے April 2024 سے پابندی عائد کر رکھی ہے، NetBSD، LLM output کو ایسا tainted code سمجھتا ہے جس کے لیے core approval درکار ہے، QEMU generated content سے حاصل ہونے والی contributions مسترد کرتا ہے، اور GNOME کی کئی applications، جن میں Loupe اور Calendar شامل ہیں، بھی ایسی پابندیاں رکھتی ہیں۔ اس فہرست کے بجائے ہر project کی اپنی تحریر پڑھیں، کیونکہ یہ معلومات وقت کے ساتھ بدل سکتی ہیں۔ ان میں سے اکثر کا مشترک استثنا بھی نوٹ کریں: API پر تحقیق، static analysis چلانے یا debugging میں مدد کے لیے model استعمال کرنا عموماً قابلِ قبول ہے، بشرطیکہ اس کا output patch میں شامل نہ ہو۔

Signed-off-by اور signed commit میں کیا فرق ہے؟

Signed-off-by ایک plain text line ہے جسے git commit -s شامل کرتا ہے۔ یہ developer certificate of origin کی تصدیق کرتا ہے، یعنی آپ کو project کے license کے تحت یہ code submit کرنے کا حق حاصل ہے۔ git commit -S سے بنایا گیا signed commit، آپ کی GPG یا SSH key کے ذریعے commit object پر کی گئی cryptographic signature ہوتا ہے۔ اس سے ثابت ہوتا ہے کہ commit آپ کی key سے آیا ہے اور اس میں تبدیلی نہیں کی گئی۔ Origin اور identity الگ دعوے ہیں، اس لیے signed commit پھر بھی AI policy کی خلاف ورزی کر سکتا ہے۔

کیا میں disclosure کو commit message کے بجائے pull request description میں شامل کر سکتا ہوں؟

اسے commit message میں شامل کریں، کیونکہ یہی وہ record ہے جو git history میں محفوظ ہوتا ہے اور بعد میں repository clone کرنے والے ہر شخص تک code کے ساتھ پہنچتا ہے۔ Pull request description بعد میں edit کی جا سکتی ہے اور hosting platform پر موجود رہتی ہے۔ جب project squash merge کرتا ہو تو اسے PR body میں بھی شامل کریں، کیونکہ squash آپ کے commit message کو دوبارہ لکھ سکتا ہے اور trailer حذف ہو سکتا ہے۔

میری pull request کو AI-generated ہونے کی وجہ سے بند کر دیا گیا۔ اب کیا کروں؟

Thread میں policy پر بحث نہ کریں، کیونکہ اسے بند کرنے والے شخص نے یہ rule اکیلے نہیں لکھا اور thread وہ جگہ نہیں جہاں یہ rule تبدیل ہوتا ہے۔ Policy کا متن پڑھیں، پھر فیصلہ کریں کہ آیا آپ اس پر عمل کر سکتے ہیں۔ جہاں project generated patches پر پابندی لگاتا ہو، وہاں reproducer کے ساتھ واضح bug report اور patch کے بغیر contribution پھر بھی قابلِ قبول ہوتی ہے، اور اکثر یہی زیادہ مفید contribution ہوتی ہے۔ اگر code کے ساتھ دوبارہ آئیں تو چھوٹی تبدیلی لائیں، جس کی line by line وضاحت اور دفاع کر سکیں۔