قوانین استفاده از کد هوش مصنوعی در پروژه‌های متن‌باز

اقداماتی که باید پیش از ارسال کد تولیدشده توسط هوش مصنوعی به مخازن بالادستی انجام دهید

پروژه‌های متن‌باز اکنون سیاست‌هایی را در مورد کد تولیدشده توسط هوش مصنوعی منتشر می‌کنند که با یکدیگر همخوانی ندارند. بنابراین، روال کار ساده است: پیش از نوشتن وصله (patch)، سیاست پروژه را پیدا کنید و هنگام ارسال آن، به‌طور دقیق اطلاع‌رسانی کنید. یک قانون کلی در هر دو حالت وجود دارد: هرگز خط کدی را که نمی‌توانید در مرحله بازبینی (review) توضیح دهید، ارسال نکنید.

حتی اگر وصله شما صحیح باشد، در صورتی که پروژه استفاده از کد تولیدشده را ممنوع کرده باشد یا شما منبع کد را پنهان کرده باشید، آن وصله رد خواهد شد. هزینه این کار به نام شما ثبت می‌شود و باقی می‌ماند، زیرا نگهدارنده‌ای (maintainer) که متوجه این پنهان‌کاری شود، دلیلی برای اعتماد به سایر سوابق کاری شما نخواهد داشت. ابتدا چند واژه را تعریف می‌کنیم، زیرا سیاست‌ها از آن‌ها استفاده می‌کنند. یک LLM (مدل زبانی بزرگ) همان مدلی است که در پس‌زمینه دستیار کدنویسی شما قرار دارد. یک PR (درخواست pull) در GitHub معادل یک MR (درخواست merge) در GitLab است و تمام موارد زیر برای هر دو صدق می‌کند. DCO (گواهی مبدأ توسعه‌دهنده) همان خط sign-off در انتهای پیام commit است که در نهایت به کانون اصلی تمام این بحث‌ها تبدیل شده است.

سیاست‌های پروژه‌های متن‌باز در قبال کدهای تولیدشده توسط هوش مصنوعی

پروژه‌ها در چهار دسته کلی قرار گرفته‌اند. تمامی مثال‌های زیر دارای تاریخ هستند، زیرا این متون به‌طور مداوم تغییر می‌کنند.

ممنوع. شورای Gentoo در تاریخ 14 آوریل 2024 رأی داد که «مشارکت دادن هرگونه محتوایی که با کمک ابزارهای هوش مصنوعی پردازش زبان طبیعی ایجاد شده باشد، در Gentoo صراحتاً ممنوع است». دستورالعمل‌های commit در NetBSD، خروجی‌های LLM را «کد آلوده» می‌نامند که «نباید بدون تأیید کتبی قبلی از سوی هسته مرکزی پروژه، commit شود». سند منشأ کد QEMU، تا اوت 2026، همچنان بیان می‌کند که این پروژه «هرگونه مشارکتی را که تصور شود شامل محتوای تولیدشده توسط هوش مصنوعی باشد یا از آن مشتق شده باشد، رد خواهد کرد».

فقط برای تحلیل. اکثر ممنوعیت‌ها محدودتر از آن چیزی هستند که در تیترها به نظر می‌رسند. سند QEMU بیان می‌کند که این سیاست «شامل سایر کاربردهای هوش مصنوعی، مانند تحقیق در مورد APIها یا الگوریتم‌ها، تحلیل ایستا (static analysis) یا دیباگ کردن نمی‌شود، مشروط بر اینکه خروجی آن‌ها در مشارکت‌ها گنجانده نشود». شما می‌توانید از عامل هوش مصنوعی برای خواندن کد استفاده کنید. شما اجازه ندارید آنچه را که هوش مصنوعی نوشته است، منتشر (ship) کنید. این تمایز، خط‌مشی عملی در اکثر پروژه‌های محدودکننده است و همان نکته‌ای است که افراد از آن غافل می‌شوند.

الزام به افشا. شورای Fedora در اکتبر 2025 سیاستی را در مورد مشارکت‌های با کمک هوش مصنوعی تصویب کرد. این سیاست استفاده از ابزارها را مجاز می‌داند و مسئولیت را بر عهده فرد می‌گذارد: مشارکت‌کننده، نویسنده اثر محسوب می‌شود، مسئولیت کامل کل مشارکت را بر عهده دارد و در صورتی که بخش قابل‌توجهی از آن بدون تغییر از ابزار گرفته شده باشد، باید آن را افشا کند. هسته لینوکس (Linux kernel) در دسامبر 2025 صفحه‌ای برای دستیاران کدنویسی در مستندات فرآیند خود اضافه کرد که شامل بخشی برای ثبت ابزار استفاده‌شده و قانونی سخت‌گیرانه در مورد اینکه چه کسی اجازه sign off کردن دارد، است.

بدون سیاست مکتوب. این همچنان حالت رایج است. یک پیش‌چاپ از مه 2026 که 1000 مخزن محبوب در GitHub را بررسی کرده، نشان می‌دهد که تنها 118 مورد دارای سیاست مکتوب در مورد هوش مصنوعی هستند. سکوت به معنای اجازه نیست. پیش از نوشتن پچ، در issue tracker با یک جمله سؤال بپرسید؛ پاسخ دریافتی به یک سند عمومی تبدیل می‌شود که بعداً می‌توانید به آن استناد کنید.

چرا نگهدارندگان این قوانین را وضع کردند

دلیل نخست، حجم بررسی است و محاسبات در یک جهت پیش می‌رود. یک عامل (Agent) می‌تواند در یک دقیقه یک merge request با 400 خط کدِ به‌ظاهر معقول تولید کند. بررسی دقیق آن درخواست برای یک نگهدارنده، یک بعدازظهر کامل زمان می‌برد و اکثر نگهدارندگان داوطلب هستند. هزینه ارسال درخواست به نزدیک صفر رسیده است، اما هزینه بررسی آن هیچ تغییری نکرده است.

پروژه curl انتهای این منحنی را نشان می‌دهد. Daniel Stenberg در اواسط سال 2025 گزارش داد که حدود یک‌پنجم گزارش‌های امنیتی دریافتی از طریق برنامه bug bounty پروژه، چیزی است که او آن را «آشغال‌های هوش مصنوعی» (AI slop) می‌نامد: گزارش‌هایی که توابع و مسیرهای کد واقعی را نام می‌برند، یک حمله محتمل را توصیف می‌کنند، اما در واقعیت هیچ محتوایی ندارند. این پروژه در اوایل سال 2026 به جای ادامه تأمین مالی این سیل، برنامه پاداش خود را متوقف کرد. این‌ها گزارش بودند نه وصله (patch)، اما همان مکانیزمی است که باعث می‌شود یک نگهدارنده، PR شما را در حالی باز کند که از قبل خسته است.

پروژه GNOME Calendar این مشکل را در قالب یک برچسب (label) تعریف کرد. در ژوئن 2026، این پروژه برچسب "Probabilistically Automated" را برای merge requestهایی معرفی کرد که «اتکای عمده یا کامل به هوش مصنوعی برای تولید کد» نشان می‌دهند و علامت آن را دقیقاً این‌گونه نامید: «معمولاً با فقدان تست مناسب همراه است و وصله‌ها بر اساس رفتار مورد انتظارِ تئوریک نهایی می‌شوند، نه بر اساس صحت کد». آن عبارت آخر را دو بار بخوانید. کد به‌گونه‌ای است که انگار باید کار کند، اما هیچ‌کس بررسی نکرده که آیا واقعاً کار می‌کند یا خیر.

دلیل دوم، منشأ (provenance) است؛ یعنی کد از کجا آمده و تحت چه مجوزی است. QEMU این تضاد را به‌صراحت بیان می‌کند: امضای تأیید (sign-off) به این معناست که شما «وضعیت کپی‌رایت و مجوز محتوایی» که مشارکت می‌دهید را کاملاً درک کرده‌اید، در حالی که وضعیت کپی‌رایت خروجی مدل‌ها هنوز نامشخص است. شورای Gentoo نیز همین دلیل را در کنار کیفیت و اخلاق مطرح کرد. شما مجبور نیستید با این برداشت حقوقی موافق باشید، اما باید توجه داشته باشید که این تصمیم بر عهده نگهدارنده است، نه شما.

چگونه می‌توانم خط‌مشی هوش مصنوعی یک پروژه را پیدا کنم؟

به ترتیب در مکان‌های زیر جستجو کنید:

• CONTRIBUTING.md در ریشه مخزن، سپس .github/CONTRIBUTING.md، و در نهایت هر فایل DCO که در کنار آن قرار دارد.
• مستندات توسعه‌دهندگان. پروژه QEMU قوانین خود را در docs/devel/code-provenance.rst نگهداری می‌کند. هسته لینوکس نیز قوانین خود را در Documentation/process/coding-assistants.rst قرار داده است.
• وب‌سایت یا ویکی پروژه. خط‌مشی Gentoo در صفحه ویکی شورا قرار دارد و خط‌مشی NetBSD در دستورالعمل‌های commit ذکر شده است.
• سیستم ردیابی مشکلات (issue tracker) و آرشیو لیست‌های پستی. معمولاً یک خط‌مشی ماه‌ها پیش از آنکه در مخزن ثبت شود، در این مکان‌ها وجود دارد.

از داخل یک checkout، دستور grep زیر اکثر موارد را پوشش می‌دهد:

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

سپس تاریخچه خود پروژه را مطالعه کنید، زیرا رویه ثبت‌شده در commitها از هر خلاصه‌ای معتبرتر است:

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 میزبانی می‌شود و گردش کار آن برای شما جدید است، نحوه عملکرد 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>

هسته (kernel) این فرمت را به عنوان Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] مستند کرده است و در مورد محدودیت آن صراحت دارد: «عوامل هوش مصنوعی (AI agents) نباید تگ‌های Signed-off-by را اضافه کنند. تنها انسان‌ها می‌توانند به‌طور قانونی گواهی مبدأ توسعه‌دهنده (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 امضای تأیید را به هر کامیت اضافه می‌کند و git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt یک فایل پیام را ویرایش می‌کند.

دو حالت شکست وجود دارد که باید برای آن‌ها برنامه‌ریزی کرد. یک squash merge پیام کامیت را بازنویسی می‌کند، بنابراین در پروژه‌ای که از squash استفاده می‌کند، افشای اطلاعات را در توضیحات PR که نگهدارنده (maintainer) آن را می‌خواند، تکرار کنید. همچنین، کامنت‌های بررسی (review comment) یک رکورد محسوب نمی‌شوند، زیرا کامنت‌ها قابل ویرایش هستند و هرگز در تاریخچه git ثبت نمی‌شوند.

دقت در هر دو جهت اهمیت دارد. Assisted-by روی کامیتی که خودتان دستی نوشته‌اید، نویز محسوب می‌شود و ارزش افشاگری‌های واقعی شما را کاهش می‌دهد. حذف آن از کامیتی که توسط عامل (agent) نوشته شده، همان چیزی است که به رابطه کاری پایان می‌دهد.

عبارت Signed-off-by دقیقاً چه چیزی را گواهی می‌کند؟

DCO یک متن کوتاه نسخه 1.1 است که در developercertificate.org منتشر شده و توسط هسته لینوکس، QEMU و بسیاری پروژه‌های دیگر استفاده می‌شود. افزودن Signed-off-by: Your Name <you@example.com> به این معناست که شما آن را تأیید می‌کنید. آنچه را که گواهی می‌کنید بخوانید، زیرا اکثر افراد بدون خواندن، آن را امضا می‌کنند.

بند (a) می‌گوید که مشارکت «تماماً یا بخشی از آن توسط من ایجاد شده است و من حق دارم آن را تحت مجوز متن‌بازی که در فایل مشخص شده، ارسال کنم». بند (b) کارهایی را پوشش می‌دهد که بر اساس کدهای متن‌باز قبلی هستند و شما حق دارید آن‌ها را با تغییرات منتقل کنید. بند (c) کدی را پوشش می‌دهد که توسط شخصی به شما تحویل داده شده که همان موارد را گواهی کرده است. بند (d) می‌گوید شما درک می‌کنید که مشارکت و اطلاعات شخصی موجود در sign-off شما عمومی هستند و برای مدت نامحدود نگهداری می‌شوند.

به آنچه وجود ندارد دقت کنید. DCO هرگز نمی‌گوید که شما تک‌تک کاراکترها را تایپ کرده‌اید. بلکه می‌گوید شما حق دارید کد را تحت این مجوز ارسال کنید. به همین دلیل است که کدهای تولیدشده (generated code) در اینجا وضعیت مبهمی دارند: مسئله، مالکیت معنوی نیست، بلکه این است که آیا می‌توانید منشأ کد را اثبات کنید یا خیر. اکثر پروژه‌هایی که به sign-off نیاز دارند، نام واقعی را نیز الزامی می‌دانند، بنابراین استفاده از نام مستعار باعث رد شدن بررسی می‌شود. این خط را با git commit -s اضافه کنید که user.name و user.email را از تنظیمات git شما می‌خواند. هنگامی که یک ربات DCO درخواست PR شما را رد کرد و commit فاقد این خط را مشخص نمود، git rebase --signoff origin/main و یک force push به شاخه (branch) خود، مشکل را برطرف می‌کند.

امضای کامیت با Sign-off متفاوت است

git commit -s یک خط متن به کامیت اضافه می‌کند. git commit -S با استفاده از کلید GPG یا SSH شما، یک امضای رمزنگاری‌شده روی شیء کامیت ایجاد می‌کند. این دو به پرسش‌های متفاوتی پاسخ می‌دهند. امضا تأیید می‌کند که این کامیت از سوی دارندهٔ آن کلید ارسال شده و از آن زمان تاکنون تغییر نیافته است. این امضا هیچ اطلاعاتی دربارهٔ منشأ کد موجود در کامیت ارائه نمی‌دهد؛ بنابراین یک کامیت امضاشده که حاوی کدهای تولیدشدهٔ افشانشده باشد، همچنان امضاشده محسوب می‌شود اما نقض سیاست‌های پروژه است. Sign-off ادعایی دربارهٔ منشأ کد است، در حالی که امضا ادعایی دربارهٔ هویت نویسنده است. پروژه‌هایی که به هر دو نیاز دارند، هر دو را درخواست خواهند کرد.

هرگز کدی را که نمی‌توانید در بازبینی توضیح دهید، ارسال نکنید

این یک آزمون است و موضوع واقعاً صداقت نیست. برای هر خط کد بپرسید: این برای چیست و بدون آن چه چیزی از کار می‌افتد؟ اگر پاسخ هر یک از این دو پرسش را ندارید، وصله (patch) آماده نیست؛ زیرا نظر بازبین (reviewer) در راه است و پاسخ شما تنها باعث یک دور تولید کد دیگر می‌شود. بازبین‌ها متوجه می‌شوند. آن لحظه‌ای است که یک مشارکت‌کننده به یک هزینه برای پروژه تبدیل می‌شود. همین پرسش‌ها را درباره لبه‌های کارکردی، ورودی خالی، مسیر شکست و دومین فراخواننده (caller) بپرسید.

کد را اجرا کنید. آن را بسازید، مجموعه تست‌های پروژه را اجرا کنید و یک بازتولیدکننده (reproducer) برای باگی که ادعای رفع آن را دارید، بنویسید. مستندات هسته (kernel) راهکار صادقانه را به زبان ساده بیان می‌کند: «اگر اصلاحیه قابل ساخت یا تست نبود، یا اگر امکان تولید بازتولیدکننده وجود نداشت، صراحتاً اعلام کنید: نگهداران پروژه در حال حاضر زمان زیادی را صرف تحلیل گزارش‌های تأییدنشده و اصلاحیه‌های تست‌نشده می‌کنند.» نوشتن جمله «من نتوانستم این را روی سخت‌افزار واقعی تست کنم» هزینه‌ای برای شما ندارد. اما القای اینکه این کار را انجام داده‌اید، باعث طرد شدن شما از پروژه می‌شود.

به نظرات بازبینی شخصاً، با کلمات خودتان و در زمان خودتان پاسخ دهید. پاسخی که سی ثانیه پس از نظر ارسال شود و آن را در پنج پاراگراف بازنویسی کند، دقیقاً به نگهدار پروژه می‌گوید که چه اتفاقی افتاده است. همچنین diff را کوچک نگه دارید. چهل خط کدی که کاملاً به آن مسلط هستید، برای یک پروژه ارزشمندتر از یک بازنویسی چهارصد خطی است که فقط بر آن نظارت داشته‌اید. اگر عامل (agent) شما همچنان بیش از آنچه خواسته‌اید تحویل می‌دهد، مهارتی که آن را به کوچک‌ترین تغییرِ کارآمد محدود می‌کند، یکی از روش‌هایی است که وصله را در سطحی نگه می‌دارد که بتوانید خط به خط از آن دفاع کنید.

دستورالعمل‌های ایجنت را در مخزن نگه دارید

دستورالعمل‌هایی که به ایجنت خود می‌دهید، بخشی از زنجیره ابزارهای شما هستند؛ بنابراین با آن‌ها مانند کد رفتار کنید. فایلی در ریشه مخزن، معمولاً AGENTS.md، دستور ساخت (build)، دستور تست، فرمت پیام کامیت، الزامات sign-off و قواعد سبک نگارشی که پروژه از قبل مستند کرده است را در خود جای می‌دهد. این فایل نسخه‌بندی شده و قابل بازبینی است و محتوای آن امروز و فردا یکسان باقی می‌ماند. دستورالعمل‌هایی که در هر نشست از حفظ تایپ می‌شوند، در هر بار خروجی متفاوتی تولید می‌کنند و شما متوجه نخواهید شد کدام نشست منجر به تولید وصله‌ای (patch) شده که رد شده است. نوشتن یک فایل AGENTS.md که هم برای ایجنت و هم برای انسان قابل خواندن باشد به بررسی خود این فایل می‌پردازد.

یک هشدار در مورد مخازن دیگران: اولین مشارکت خود را به صورت یک PR که یک فایل دستورالعمل ایجنت به پروژه‌ای که مدیریت آن را بر عهده ندارید اضافه می‌کند، انجام ندهید. این کار به عنوان تلاشی برای تعیین سیاست ابزاری پروژه از بیرون تلقی می‌شود و راهی سریع برای مرتبط شدن حساب کاربری شما با موضوعی است که نگهداران پروژه از قبل از آن خسته شده‌اند. این فایل را در fork خود نگه دارید تا زمانی که کسی آن را درخواست کند.

محل اجرای ایجنت نیز به همان دلیل اهمیت دارد. ایجنتی که می‌تواند پروژه را بسازد و تست‌های آن را در یک sandbox تحت کنترل شما اجرا کند، وصله‌ای به شما می‌دهد که واقعاً آن را تأیید کرده‌اید؛ این تفاوت میان افشای کمک و افشای یک حدس است. اجرای یک ایجنت کدنویسی روی VPS شخصی این تنظیمات را پوشش می‌دهد و تفاوت‌های عملی میان Claude Code، Cursor، Codex و Copilot به بررسی تفاوت‌های روزمره این ابزارها می‌پردازد.

روش کار پس از تغییر سیاست

1. پیش از نوشتن هر چیزی، سیاست اعلام‌شده را پیدا کنید: مخزن، مستندات توسعه‌دهنده، وب‌سایت یا سیستم ردیابی.
2. اگر سیاستی وجود ندارد، در یک جمله در issue مربوطه سؤال کنید و پاسخ را نزد خود نگه دارید.
3. افشای اطلاعات را طبق فرمتی که پروژه استفاده می‌کند در commit trailer انجام دهید و اگر پروژه از squash استفاده می‌کند، آن را در بدنه PR تکرار کنید.
4. با نام واقعی خود sign off کنید، با آگاهی از اینکه این خط ادعایی درباره حق شما برای ارسال کد است.
5. وصله (patch) خود را طوری بازبینی کنید که انگار فرد دیگری آن را نوشته است، چرا که در واقعیت چنین بوده است.

هر پروژه‌ای که در این صفحه نام برده شده، تا زمانی که شما این متن را می‌خوانید تغییر مکان داده است. این 5 مرحله تغییر نمی‌کنند.

FAQ

آیا باید اعلام کنم که از یک دستیار کدنویسی هوش مصنوعی استفاده کرده‌ام؟

پروژه را بررسی کنید، زیرا پاسخ در سطح محلی تعیین می‌شود. Fedora زمانی که بخش قابل‌توجهی از مشارکت بدون تغییرات توسط یک ابزار ایجاد شده باشد، الزام به افشا دارد. هسته Linux درخواست یک trailer از نوع Assisted-by می‌کند. پروژه‌های Gentoo و QEMU، تا اوت 2026، اصلاً چنین مشارکتی را نمی‌پذیرند. در مواردی که چیزی مکتوب نشده است، در هر صورت آن را در یک commit trailer اعلام کنید. نگهدارنده‌ای (maintainer) که بعداً متوجه این موضوع شود، به جای خود ابزار، به پنهان‌کاری شما واکنش نشان می‌دهد و این واکنش به تمام کارهای دیگری که ارسال کرده‌اید نیز تعمیم می‌یابد.

کدام پروژه‌های متن‌باز کد تولیدشده توسط هوش مصنوعی را ممنوع کرده‌اند؟

به عنوان یک وضعیت کلی در اوت 2026: Gentoo از آوریل 2024، NetBSD که خروجی LLM را به عنوان کد آلوده تلقی کرده و نیازمند تأیید هسته اصلی است، QEMU که مشارکت‌های مشتق‌شده از محتوای تولیدشده را رد می‌کند، و چندین برنامه GNOME از جمله Loupe و Calendar. به جای تکیه بر این لیست، متن اختصاصی هر پروژه را بخوانید، زیرا این اطلاعات قدیمی می‌شوند. به استثنایی که اکثر آن‌ها در آن اشتراک دارند توجه کنید: استفاده از یک مدل برای تحقیق درباره یک API، اجرای تحلیل ایستا (static analysis) یا کمک به دیباگ کردن معمولاً مشکلی ندارد، به شرطی که خروجی آن در patch نهایی نباشد.

تفاوت بین Signed-off-by و یک commit امضاشده چیست؟

Signed-off-by یک خط متن ساده است که توسط git commit -s اضافه می‌شود. این خط گواهی مبدأ توسعه‌دهنده (DCO) را تأیید می‌کند، به این معنی که شما حق دارید این کد را تحت مجوز پروژه ارسال کنید. یک commit امضاشده که با git commit -S انجام می‌شود، یک امضای رمزنگاری‌شده روی شیء commit با کلید GPG یا SSH شماست. این امضا ثابت می‌کند که commit از کلید شما آمده و تغییر نیافته است. مبدأ و هویت ادعاهای جداگانه‌ای هستند، بنابراین یک commit امضاشده همچنان می‌تواند قوانین مربوط به هوش مصنوعی را نقض کند.

آیا می‌توانم افشای استفاده از هوش مصنوعی را به جای پیام commit، در توضیحات pull request بنویسم؟

آن را در پیام commit قرار دهید، زیرا این سندی است که در تاریخچه git ثبت می‌شود و با کد به دست هر کسی که بعداً مخزن را clone کند، می‌رسد. توضیحات pull request بعداً قابل ویرایش است و فقط روی پلتفرم میزبانی باقی می‌ماند. اگر پروژه از squash merge استفاده می‌کند، آن را در بدنه PR نیز اضافه کنید، زیرا squash پیام commit شما را بازنویسی می‌کند و ممکن است trailer را حذف کند.

pull request من به دلیل تولید شدن توسط هوش مصنوعی بسته شد. حالا چه کار کنم؟

در آن بحث، درباره سیاست پروژه جدل نکنید، زیرا شخصی که آن را بسته است به تنهایی قانون را ننوشته و آن بحث جای تغییر دادن قوانین نیست. متن سیاست پروژه را بخوانید و سپس تصمیم بگیرید که آیا می‌توانید آن را رعایت کنید یا خیر. در مواردی که پروژه patchهای تولیدشده را ممنوع می‌کند، یک گزارش باگ شفاف همراه با روش بازتولید (reproducer) و بدون patch همچنان مورد استقبال است و اغلب مشارکت مفیدتری محسوب می‌شود. اگر دوباره با کد بازگشتید، با تغییر کوچکی بیایید که بتوانید خط به خط از آن دفاع کنید.