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

تصور کنید مسئولیت امنیت و پایداری میلیون‌ها سرور در جهان بر دوش شماست؛ آیا جرئت می‌کنید کدی را بپذیرید که نمی‌دانید یک انسان نوشته یا یک ماشین؟ پروژه دبیان (Debian) اکنون دقیقاً در همین نقطه است و باید تصمیم بگیرد که آیا ربات‌ها را اخراج کند یا به آن‌ها اجازه ورود دهد. در حالی که برخی توسعه‌دهندگان مشتاق پذیرش هوش مصنوعی زاینده هستند و برخی دیگر خواهان ممنوعیت کامل آن، پروژه دبیان در حال تصمیم‌گیری است که آیا باید بات‌ها را بسوزاند یا رهایشان کند.

این تصمیم در حالی گرفته می‌شود که دنیای متن‌باز بر سر ادغام هوش مصنوعی دچار شکاف شده است. مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — برای برخی توسعه‌دهندگان ابزاری برای سرعت بخشیدن به کار است و برای برخی دیگر، یک ریسک حقوقی و اخلاقی. همان‌طور که در بحث‌های گذشته ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد در دنیای لینوکس بر پایه شفافیت است، نه سرعت. برای پروژه‌ای با این ابعاد، این تصمیم مستقیماً بر بنیادهای توزیع لینوکس تأثیر می‌گذارد. در این راستا، ظهور مدل‌های قدرتمندتر با قابلیت‌های پردازش گسترده، مانند مدل SuperQwen3.8 با پنجره متنی یک میلیون توکنی، وسوسه استفاده از این ابزارها را برای مدیریت کدهای حجیم افزایش داده است.

به نقل از گزارش The Register در ۲۶ اوت ۲۰۲۶، «سروتی چاندران»، رهبر پروژه که در مارس ۲۰۲۶ در اولین نظرسنجی پروژه در سال ۲۰۲۶ انتخاب شد، مهلت رای‌گیری برای قطعنامه‌ای گسترده با عنوان «استفاده از LLM در دبیان» را تمدید کرد. این رای‌گیری که شامل یک سند جامع ۵۰۰۰ کلمه‌ای است، توسعه‌دهندگان را مجبور می‌کند از میان ۸ پیشنهاد متمایز درباره استفاده از هوش مصنوعی زاینده، یکی را انتخاب کنند. این پیشنهادها هم به صورت شماره و هم به صورت حروف دسته‌بندی شده‌اند و هر یک از آن‌ها توسط ۶ تا ۱۷ توسعه‌دهنده تأیید (Seconded) شده است. لازم به ذکر است که تنها توسعه‌دهندگان شناخته‌شده‌ی دبیان واجد شرایط رای دادن هستند.

برای درک ابعاد این تصمیم و مقیاس پروژه، کافی است به آمار اعلام شده در خبر انتشار نسخه ۱۳ دبیان نگاه کنیم:

• ۶۹,۸۳۰ بسته نرم‌افزاری
• ۴۰۳ گیگابایت فضای دیسک در مجموع
• ۱,۴۶۳,۲۹۱,۱۸۶ خط کد

پیشنهادهای مطرح شده در این رای‌گیری طیف گسترده‌ای از سخت‌گیری مطلق تا پذیرش عمل‌گرایانه را شامل می‌شوند:

موضع سخت‌گیرانه (ممنوعیت کامل)

• پیشنهاد A: هرگونه مشارکت نوشته شده با کمک LLM یا سایر ابزارهای هوش مصنوعی زاینده (Generative AI) را صراحتاً ممنوع می‌کند. این یکی از طولانی‌ترین پیشنهادهاست و برای تصویب نیاز به اکثریت ۳ به ۱ دارد.
• پیشنهاد C: خواستار ممنوعیت کامل «تا حد امکان» است. این پیشنهاد توسط ایان جکسون، از بزرگان دبیان، خالق dpkg و اپراتور Chiark، حمایت می‌شود.
• پیشنهاد H: بر اثرات محیط‌زیستی تمرکز دارد و استدلال می‌کند که استفاده از LLMها تخریب سیاره زمین را تسریع می‌کند و این موضوع یک «خط قرمز» (Deal-breaker) است. این پیشنهاد تفاوتی بین LLMهای محلی و ابری قائل نمی‌شود.

رویکرد میانه (پذیرش مشروط)

• پیشنهاد B: مشارکت‌های AI را به شرط رعایت ۶ معیار سخت‌گیرانه مجاز می‌داند: سازگاری حقوقی، لایسنس و انتساب (Attribution)، پاسخگویی، افشای استفاده از AI، بحث قبلی درباره تغییرات انبوه یا خودکار، و حفظ محرمانگی و حریم خصوصی.
• پیشنهاد D: اذعان می‌کند که شیوه‌های استفاده از AI در حال حاضر در جریان است و «ماندنی» است. این پیشنهاد استدلال می‌کند که ممنوعیت‌ها ضدبهره‌ور و غیرقابل اجرا هستند و در عوض پیشنهاد می‌کند دستورالعمل‌هایی تدوین شود؛ مثلاً اینکه کارها باید به وضوح توصیف شوند و با دستورالعمل‌های نرم‌افزار آزاد دبیان (DFSG) مطابقت داشته باشند.
• پیشنهاد E: مشابه پیشنهاد D، تأکید می‌کند که مسئولیت هر مشارکت بر عهده انسان ارسال‌کننده است و او باید پاسخگوی کیفیت فنی، پذیرفتنی بودن حقوقی و مناسب بودن کد باشد.

رویکرد محتاطانه

• پیشنهاد F: صرفاً توسعه‌دهندگان را تشویق می‌کند که در صورت امکان و تا حد عملی، از هوش مصنوعی زاینده دوری کنند.
• پیشنهاد G: هدفش این است که اطمینان حاصل شود مشارکت‌ها توسط انسان‌ها خلق شده‌اند. این پیشنهاد اجازه می‌دهد از ابزارهای LLM در «فرآیند» خلق کد استفاده شود، اما خروجی مستقیم هوش مصنوعی زاینده را به عنوان یک مشارکت نمی‌پذیرد.

این کشمکش داخلی بازتاب‌دهنده یک روند گسترده‌تر در پروژه‌های BSD و لینوکس است. در آوریل ۲۰۲۴، پروژه‌های Gentoo و NetBSD هر دو تصمیم گرفتند کدهای تولید شده توسط AI را ممنوع کنند. پروژه OpenBSD مانعی نفوذپذیر ایجاد کرده است؛ این پروژه کدهای AI را به دلیل عدم امکان ثبت حق چاپ (Copyright) رد می‌کند، اما کدهای پروژه Tmux را که اجازه مشارکت‌های به کمک LLM را می‌دهد، به عنوان موارد استثنا پذیرفته است.

سایر پروژه‌ها همچنان در وضعیت بلاتکلیفی هستند. طبق گزارش سپتامبر ۲۰۲۵، پروژه FreeBSD تمایل خود را برای اجتناب از کدهای AI ابراز کرده اما هنوز دستورالعمل‌های رسمی خود را به‌روز نکرده است. اگرچه این موضوع عمومی نشده، اما گزارش‌ها حاکی از آن است که بحث‌های فعالی در FreeBSD در جریان است و احتمالاً یک رای‌گیری در راه است.

در همین حال، غول‌های صنعت در جهت مخالف حرکت می‌کنند. هسته لینوکس (Linux Kernel) رسماً ضد-AI نیست و شرکت رد هت (Red Hat) که زیرمجموعه IBM است، کاملاً با ابزارهای AI ادغام شده است. این تضاد یک پارادوکس عجیب ایجاد می‌کند: کدهای بنیادینی که اکثر توزیع‌ها از آن‌ها استفاده می‌کنند (مثل کرنل) راه‌راه با AI نوشته می‌شوند، حتی اگر خودِ توزیع‌ها استفاده از آن را ممنوع کنند.

برای یک توسعه‌دهنده معمولی، این بدان معناست که «پاکی حقوقی» یک توزیع ممکن است به زودی اهمیت کمتری نسبت به واقعیت کدهای بالادستی (Upstream) داشته باشد. اگر کرنل و کتابخانه‌های اصلی با کمک AI توسعه یابند، ممنوعیت در سطح توزیع بیشتر به یک حرکت نمادین تبدیل می‌شود تا یک واقعیت فنی.

گام بعدی شما

• اگر توسعه‌دهنده هستید، بررسی کنید که آیا توزیع مورد استفاده شما سیاست‌های صریحی برای کدهای AI دارد یا خیر.
• نتایج نهایی بیش از ۳۵۰ رای ثبت شده را دنبال کنید تا ببینید جامعه دبیان اخلاقیات محیط‌زیستی، امنیت حقوقی یا سرعت توسعه را در اولویت قرار می‌دهد.
• مستندات Debian Free Software Guidelines را بخوانید تا بفهمید چرا تعریف «نرم‌افزار آزاد» با AI در تضاد است.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell و هزینه استنتاج مدل‌ها مراجعه کنید. در این زمینه، بررسی مدل‌های زبانی کوچک و کاهش هزینه‌های استنتاج نشان می‌دهد که چگونه بهینه‌سازی سخت‌افزاری می‌تواند تعادلی میان کارایی و هزینه‌های محیط‌زیستی ایجاد کند.