رسمت Codeberg خطاً واضحاً بين open source كترخيص وبين free software كممارسة تعاون بشرية.

في 23 يوليو نشرت Codeberg e.V. نتائج تصويتين بين أعضائها حول LLMs. القرار الأول يقول إن forge والخدمات المرتبطة به لن تستخدم بيانات المشاريع أو المستخدمين لتدريب generative AI. القرار الثاني أكثر جدلاً: تعديل Terms of Use لمنع "vibe-coded projects"، أي المشاريع التي تُنشأ أو تُصان أساساً عبر heavy use of LLMs.

منصة open source مستقلة مع مراجعة بشرية للكود وفرع مولد بالذكاء الاصطناعي خارج العملية

Codeberg ليست GitHub من حيث الحجم. إنها أصغر، مجتمعية، وقريبة من عالم FLOSS وForgejo. لذلك القرار مهم: المنصات الكبيرة ترى AI كطبقة إنتاجية، أما Codeberg فتسأل إن كان على forge ممول بالتبرعات أن يستضيف مستودعات مفتوحة الترخيص لكنها تكاد تخلو من صيانة بشرية حقيقية.

الاقتراح المثير للجدل مرّ بـ 358 موافقة، و144 اعتراضاً، و14 امتناعاً، مع turnout يقارب 50% من active members. وتقول Codeberg إنها لن تبدأ حذفاً جماعياً فورياً. المشاريع ذات المجتمع النشط أو pre-LLM history أو بعض LLM-generated contributions المقبولة ليست الهدف إذا لم يكن المشروع قائماً على heavy LLM use.

لماذا يهم هذا forge مستقل

الحجة ليست ثقافية فقط. Codeberg تشير إلى crawlers تجمع الكود لتدريب النماذج وتسبب ضغطاً على البنية التحتية. هناك أيضاً storage وCI/CD وrelease artifacts لمشاريع تبدو نشطة لكنها لا تملك مستخدمين أو مجتمع صيانة حقيقياً.

النقطة الثانية هي الثقة. Maintainers يراجعون patches مولدة بـ LLM تبدو مرتبة لكنها تستهلك وقتاً كبيراً. وتذكر Codeberg أيضاً license laundering، حين يعود copyleft code عبر model output بلا التزامات واضحة.

الدرس العملي

مصطلح "vibe-coded" صعب القياس. يمكن استخدام AI في الاختبارات أو التوثيق أو autocomplete أو refactoring أو حتى معظم التنفيذ. لذلك تحتاج المشاريع إلى AI contribution policy واضحة: هل يلزم disclosure؟ هل يجب أن يستطيع contributor شرح patch؟ كيف تُراجع tests وsecurity وcopyright وmaintainability؟

Codeberg اختارت forge يضع التعاون البشري أولاً. منصات أخرى ستختار مساراً مختلفاً، وهذا مقبول إذا كانت القواعد واضحة قبل pull request.