AI سے تیار code: open source policy اور disclosure

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 کوڈ سے متعلق پالیسیاں کہاں تک پہنچی ہیں

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

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

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

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

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

maintainers نے یہ قواعد کیوں لکھے

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

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

GNOME Calendar نے اس مسئلے کو ایک label کی شکل میں تحریر کیا۔ June 2026 میں project نے ان merge requests کے لیے "Probabilistically Automated" متعارف کرایا جن میں "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"۔ آخری فقرہ دوبارہ پڑھیں۔ code ایسا دکھائی دیتا ہے جیسے اسے کام کرنا چاہیے۔ کسی نے یہ جانچ نہیں کی کہ آیا وہ واقعی کام کرتا ہے۔

دوسری وجہ provenance ہے، یعنی code کہاں سے آیا اور کس license کے تحت آیا۔ QEMU اس تنازعے کو صاف الفاظ میں بیان کرتا ہے: sign-off کرنے سے آپ یہ تصدیق کرتے ہیں کہ آپ اپنے contribute کردہ content کی "copyright and license status" کو "fully understand" کرتے ہیں، جبکہ model output کی copyright status ابھی غیر واضح ہے۔ Gentoo's 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 اس کے کسی بھی خلاصے سے زیادہ معتبر ہوتی ہے:

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

تبصرے کے بجائے commit trailer میں انکشاف کریں

Trailer، commit message کے آخری paragraph میں موجود 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 اس format کو 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 کو دوسرا نام لکھنے نہ دیں، اور اسے ایسا Co-authored-by address بھی نہ بنانے دیں جو کسی شخص سے متعلق نہ ہو۔

نام مختلف ہو سکتے ہیں، اس لیے اپنا نام خود بنانے کے بجائے مقامی نام copy کریں۔ May 2026 میں QEMU list پر بھیجی گئی ایک patch میں اس project کی پابندی کو mechanical changes، tests، docs اور 20 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 یا عام جملہ موجود ہے۔ پہلے سے لکھی گئی 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 کو edit کرتا ہے۔

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

درستگی دونوں سمتوں میں اہم ہے۔ اپنے ہاتھ سے لکھے گئے commit پر Assisted-by شامل کرنا غیر ضروری شور ہے، اور اس سے آپ کے حقیقی disclosures کی قدر کم ہوتی ہے۔ 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 کے تحت submit کرنے کا حق ہے"۔ شق (b) پہلے کے open source code پر مبنی کام کا احاطہ کرتی ہے، بشرطیکہ آپ کو اس میں modifications کے ساتھ code آگے منتقل کرنے کا حق حاصل ہو۔ شق (c) اس code کا احاطہ کرتی ہے جو آپ کو کسی ایسے شخص نے دیا ہو جس نے اسی بات کی تصدیق کی ہو۔ شق (d) کہتی ہے کہ آپ سمجھتے ہیں کہ contribution اور آپ کے sign-off میں شامل ذاتی معلومات public ہوں گی اور غیر معینہ مدت تک محفوظ رکھی جائیں گی۔

غور کریں کہ اس میں کیا شامل نہیں ہے۔ DCO یہ نہیں کہتا کہ آپ نے ہر character خود type کیا ہے۔ اس میں کہا گیا ہے کہ آپ کو code کو اس license کے تحت submit کرنے کا حق حاصل ہے۔ اسی لیے generated code اس معاملے میں واضح طور پر فٹ نہیں بیٹھتا: سوال authorship کا نہیں، بلکہ code کے ماخذ کی وضاحت کرنے کی اہلیت کا ہے۔ زیادہ تر projects جو sign-off لازم قرار دیتے ہیں، real name بھی لازم کرتے ہیں، اس لیے pseudonym اس check میں ناکام ہو جاتا ہے۔ git commit -s والی line شامل کریں؛ یہ آپ کی git config سے user.name اور user.email پڑھتی ہے۔ جب 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 کہاں سے آیا ہے۔ اس لیے غیر ظاہر شدہ generated code سے بھرا ہوا signed commit بھی signed ہوتا ہے اور پھر بھی policy کی خلاف ورزی ہو سکتا ہے۔ Sign-off اصل ماخذ کے بارے میں دعویٰ ہے۔ Signature شناخت کے بارے میں دعویٰ ہے۔ جو projects دونوں چاہتے ہیں، وہ دونوں کا تقاضا کریں گے۔

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

یہ اصل test ہے، اور اس کا تعلق واقعی honesty سے نہیں۔ ہر line کے بارے میں بتائیں: یہ کس مقصد کے لیے ہے، اور اس کے بغیر کیا خراب ہوگا؟ اگر ان دونوں میں سے کوئی جواب موجود نہیں تو patch تیار نہیں، کیونکہ review comment آنے والا ہے اور آپ کا جواب generation کے ایک اور round کا باعث بنے گا۔ 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 کے تیس seconds بعد آنے والا ایسا reply جو اسے پانچ paragraphs میں دوبارہ بیان کرے، maintainer کو فوراً بتا دیتا ہے کہ کیا ہوا ہے۔ diff بھی چھوٹا رکھیں۔ چالیس lines جنہیں آپ مکمل طور پر سمجھتے ہیں، project کے لیے اس four hundred line refactor سے زیادہ قیمتی ہیں جس کی آپ نے صرف نگرانی کی ہو۔ اگر آپ کا agent بار بار آپ کی درخواست سے زیادہ code واپس کرتا ہے تو ایسی skill جو اسے کام کرنے والی سب سے چھوٹی تبدیلی تک محدود رکھے patch کو اتنا چھوٹا رکھنے کا ایک طریقہ ہے کہ آپ اب بھی line by line اس کا دفاع کر سکیں۔

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

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

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

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

طریقہ، جب پالیسی تبدیل ہو جائے

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

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

FAQ

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

پروجیکٹ کے اصول دیکھیں، کیونکہ اس کا جواب مقامی پالیسی کے مطابق طے ہوتا ہے۔ Fedora میں یہ disclosure ضروری ہے جب contribution کا بڑا حصہ کسی ایسے tool سے آیا ہو جس میں بعد میں تبدیلیاں نہ کی گئی ہوں۔ Linux kernel میں Assisted-by trailer درکار ہوتا ہے۔ Gentoo اور QEMU، August 2026 تک، ایسی 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 کی اپنی تحریر پڑھیں، اس فہرست پر انحصار نہ کریں، کیونکہ یہ وقت کے ساتھ بدل سکتی ہے۔ ان میں سے زیادہ تر کا مشترک exemption بھی نوٹ کریں: API کی تحقیق، static analysis چلانے یا debugging میں مدد کے لیے model استعمال کرنا عموماً قابل قبول ہے، بشرطیکہ اس کا output patch میں شامل نہ ہو۔

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

Signed-off-by ایک سادہ متنی line ہے جو git commit -s کے ذریعے شامل کی جاتی ہے۔ یہ developer certificate of origin کی تصدیق کرتی ہے، یعنی آپ کو اس code کو project کے license کے تحت 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 وہ جگہ نہیں جہاں policy تبدیل ہوتی ہے۔ Policy کا متن پڑھیں، پھر فیصلہ کریں کہ آیا آپ اس پر عمل کر سکتے ہیں۔ جہاں project generated patches پر پابندی لگاتا ہو، وہاں reproducer کے ساتھ واضح bug report، مگر patch کے بغیر، اب بھی قابل قبول ہوتی ہے، اور اکثر یہی زیادہ مفید contribution ہوتی ہے۔ اگر code کے ساتھ واپس آئیں تو ایسی چھوٹی تبدیلی لائیں جس کی line by line وضاحت اور ذمہ داری آپ لے سکیں۔