لعقود، كان المطوّر يتعامل مع ملف LICENSE باعتباره شيئاً يُنسخ من مشروع سابق ولا يُقرأ. في 2026 تحوّل هذا الملف الصغير إلى ساحة الصراع الأكثر سخونة في عالم المصادر المفتوحة — لا لأن نصّه تغيّر، بل لأن الشيء الذي كان يمنحه قوّته انهار في صمت.

القوّة الحقيقية لأي رخصة برمجية لم تكن يوماً في صياغتها القانونية، بل في تكلفة تجاوزها. حين كانت إعادة كتابة مكتبة من 40 ألف سطر تستغرق فريقاً ستة أشهر، كان الالتزام بشروط الرخصة أرخص من التمرّد عليها. وهذه المعادلة تحديداً هي ما لم يعد قائماً.

الحادثة التي فجّرت النقاش

الرخصة التي لم يعد أحد يستطيع فرضها — تريندات تقنية

في مارس 2026، أصدر دان بلانشارد، صائن مكتبة بايثون الشهيرة chardet (الخاصة بكشف ترميز النصوص)، الإصدار 7.0 تحت رخصة MIT المتساهلة، بدلاً من رخصة LGPL التي حكمت المشروع منذ نشأته.

اعترض شخص قال إنه مارك بيلجريم، المؤلف الأصلي للمكتبة، بحجّة قانونية مباشرة: رخصة LGPL تُلزم الأعمال المشتقّة بالبقاء تحت الرخصة نفسها، ولا يملك صائن لاحق حق تغييرها على عمل غيره.

ردّ بلانشارد كان هو المثير للاهتمام: الإصدار الجديد ليس عملاً مشتقّاً أصلاً، بل إعادة بناء من الصفر (Clean Room Implementation) كتبها بمساعدة نموذج ذكاء اصطناعي انطلاقاً من التوثيق والمواصفات، لا من الكود القديم. ولدعم كلامه، شغّل أداة كشف الاستنساخ JPlag على الإصدارين: التشابه أقل من 1.3%، ومعظمه أنماط بايثون شائعة يكتبها أي مبرمج بالطريقة نفسها.

فجأة، لم يعد السؤال "هل خالف الرجل الرخصة؟"، بل سؤال أكبر بكثير: ماذا يبقى من رخصة يمكن تجاوزها في عطلة نهاية أسبوع؟

لماذا كانت الرخصة تعمل أصلاً؟

هنا تكمن الفكرة التي يغفل عنها معظم النقاش. رخص الحقوق المتروكة (Copyleft) مثل GPL وLGPL وAGPL لم تكن تعمل لأن الشركات تخاف المحاكم — معظم المخالفات لا تصل إلى محكمة أبداً. كانت تعمل لأن البديل كان مكلفاً بشكل غير عملي.

سلطة أي رخصة نسخية لم تكن في نصّها، بل في الاحتكاك: كان تجاوزها يكلّف أكثر من الالتزام بها. أزِل الاحتكاك، ويتحوّل الشرط القانوني إلى رجاء مهذّب.

أرمين روناخر، مطوّر إطار Flask، لخّص المسألة بدقّة: رخص الكوبي‑لفت تعتمد في فرضها على الاحتكاك، وحين يصبح إعادة كتابة الكود أمراً تافه التكلفة، تنهار آلية الفرض نفسها — لا النص.

وذهب بروس بيرنس، كاتب "تعريف المصدر المفتوح" الأصلي، إلى ما هو أبعد، بجملة صادمة: "اقتصاديات تطوير البرمجيات بأكملها ماتت" — لأن النموذج القادر على إعادة توليد قاعدة كود كاملة انطلاقاً من توثيقها يجعل الترخيص، المملوك والمفتوح على حدّ سواء، شبه غير قابل للفرض.

لاحظ أن هذا لا يمسّ الرخص المتساهلة (MIT، Apache) كثيراً: هي أصلاً لا تطلب منك شيئاً تقريباً سوى حفظ إشعار الحقوق. الضربة موجّهة تحديداً إلى الرخص التي تطلب مقابلاً: شارِك تعديلاتك، أو افتح مشروعك.

المفارقة: الكوبي‑لفت يعود في أسوأ توقيت ممكن

الغريب أن هذا يحدث بينما تشير البيانات إلى اتجاه معاكس. بحسب تحليل RedMonk لحالة الترخيص في 2026، بلغت حصّة الرخص المتساهلة ذروتها عند 82% في 2022، ثم تراجعت إلى 73% بحلول 2025 — أي أن البندول بدأ يتأرجح عائداً نحو الكوبي‑لفت لأول مرة منذ عقد.

لكن الصورة أعقد من رقم واحد:

  • Apache وMIT ما زالتا المستفيدتين الأكبر من موجة التساهل، مع قفزة لـMIT يعزوها التحليل إلى الثقل الهائل لمنظومة npm التي تتبنّى MIT افتراضياً.
  • GPL (وخصوصاً الإصدار 2) تظهر على GitHub بمعدّل 34 ضعف ظهورها في الحزم المنشورة فعلياً في الإنتاج — فجوة تكشف أنها حاضرة في المستودعات أكثر بكثير من حضورها في ما يُشحن ويُستخدم.
  • الرخص "متاحة المصدر" مثل BSL وSSPL لا تزال غير قابلة للقياس إحصائياً من حيث الانتشار، رغم أن مشاريع بعينها تحتها (مثل Terraform وMongoDB) تحتل أهمية استراتيجية تفوق حجمها العددي بكثير.

بعبارة أخرى: المجتمع يعود إلى الرخص التي تطلب مقابلاً، في اللحظة التي صارت فيها قدرة تلك الرخص على تحصيل المقابل أضعف ما تكون.

لا، هذا ليس تصريحاً بتجاوز الرخص

قبل أن يقفز أحد إلى الاستنتاج الخطأ: لا شيء ممّا سبق يجعل "أعدت كتابتها بالذكاء الاصطناعي" دفاعاً قانونياً جاهزاً.

زوي كويمان من مؤسسة البرمجيات الحرة وضعت اليد على النقطة الأضعف في الحجّة كلها: النموذج الذي دُرّب على الكود الموجود أصلاً ليس "غرفة نظيفة" بأي معنى حقيقي. مفهوم الـClean Room قانونياً يقوم على أن المنفّذ لم يرَ الكود الأصلي إطلاقاً — ونموذج رأى ملايين المستودعات، وربما المستودع المعني نفسه، لا ينطبق عليه هذا الشرط بسهولة.

والأهم عملياً: لا يوجد حتى الآن حكم قضائي مستقر يحسم هل التوليد بنموذج مدرَّب على كود مرخّص يُعدّ عملاً مشتقّاً أم لا. من يبني منتجاً تجارياً على هذا الافتراض يراهن على نتيجة غير معروفة، والمراهنة هنا ثمنها إعادة هندسة منتج كامل لاحقاً، لا غرامة بسيطة.

الجبهة الثانية: الرخصة تتغيّر من تحتك

بينما يدور هذا الجدل، هناك خطر أقرب وأكثر واقعية على أي فريق: أن تستيقظ لتجد أن المكتبة التي يقوم عليها منتجك غيّرت رخصتها بين ليلة وضحاها.

المشروع من إلى الانشقاق البديل الداعم
Terraform MPL 2.0 BSL 1.1 OpenTofu مؤسسة لينكس
Redis BSD RSAL / SSPL (ثم AGPLv3 لاحقاً) Valkey AWS، جوجل، أوراكل
Elasticsearch Apache 2.0 SSPL OpenSearch AWS
OnlyOffice AGPL (نزاع على الامتثال) Euro‑Office Nextcloud وIONOS
LibreOffice LGPL/MPL خلاف حوكمة مؤسسة الوثائق

التفاصيل تكشف كم أن الأمر ليس نظرياً:

  • Redis بررت التحوّل بأن مزوّدي السحابة يبيعون خدمة مُدارة دون مساهمة مقابلة، ثم أضافت AGPLv3 كخيار لاحقاً بعد أن أدركت حجم الضرر الذي لحق بثقة المجتمع.
  • HashiCorp بعد استحواذ IBM عليها بـ 6.4 مليار دولار، صعّدت الضغط القانوني على مساهمي OpenTofu — وهو ضغط يُنتج "أثراً مثبّطاً" يجعل المطوّرين يتجنّبون المساهمة أصلاً، بغضّ النظر عن نتيجة أي نزاع.
  • مؤسسة الوثائق أبعدت أكثر من 30 مطوّراً من Collabora على خلفية خلاف حوكمة، فخسرت مراجعين ذوي خبرة ومعرفة مؤسسية دون أن تُحلّ أسباب التوتر.

والنقطة المؤلمة للصائن المتطوّع: حين ينشقّ مشروع، يُجبَر على اختيار جانب — Terraform أم OpenTofu، Redis أم Valkey — وكل اختيار له ثمن مهني، وأحياناً مخاطرة قانونية حقيقية.

خمس خطوات عملية تبدأ اليوم

  1. افحص رخص اعتمادياتك فعلياً، لا افتراضياً. license-checker لمشاريع Node.js، وgo-licenses لـGo. معظم الفرق لا تعرف حقيقةً ما الرخص الموجودة في node_modules عندها.
  2. ثبّت إصدارات الاعتماديات، وقارن ملفات الرخص بين نسختين من ملف القفل. تغيير الرخصة يصل إليك في ترقية روتينية، لا في إعلان صحفي تقرأه.
  3. عامل مخاطر الترخيص كما تعامل مخاطر المورّد. لكل اعتمادية حرجة: ما البديل المنشقّ؟ من يدعمه؟ كم تستغرق الهجرة إليه؟ اكتب الإجابات قبل الأزمة لا بعدها.
  4. ميّز بين ما تستهلكه وما توزّعه. الاستخدام الداخلي والتوزيع للعملاء لهما التزامات مختلفة تماماً تحت AGPL تحديداً — وكثير من المخالفات تبدأ من عدم إدراك هذا الفرق.
  5. لا تبنِ استراتيجيتك على "سنعيد كتابتها بالذكاء الاصطناعي". استخدمها أداة هندسية إن شئت، لا درعاً قانونياً — الغطاء القانوني غير محسوم حتى الآن.

أسئلة شائعة

هل يعني هذا أن رخص المصادر المفتوحة أصبحت بلا قيمة؟

لا. ما ضعف هو آلية فرض الرخص النسخية عبر احتكار تكلفة الكود، وليست قيمة الرخصة كإطار للثقة والحوكمة والإسناد. المشاريع الجادّة ما زالت تختار رخصها بعناية، والشركات ما زالت ترفض اعتماديات برخص خطرة — لأن المخاطرة، لا المحكمة، هي ما يحكم القرار.

إذا أعدت كتابة مكتبة GPL بمساعدة نموذج ذكاء اصطناعي، هل أملك النتيجة؟

الإجابة القانونية الأمينة: غير محسوم. النموذج المدرّب على كود مرخّص لا يستوفي بوضوح شرط "الغرفة النظيفة"، ولا توجد سابقة قضائية مستقرة تحسم الأمر. إن كان المشروع تجارياً، استشر مختصاً قانونياً بدل الاعتماد على تحليل تشابه نصّي.

ما أسرع فحص يكشف خطر الترخيص في مشروعي؟

شغّل فاحص رخص على شجرة الاعتماديات، وافرز النتائج بحثاً عن أي رخصة نسخية قوية (GPL/AGPL) أو "متاحة المصدر" (BSL/SSPL) في ما تُوزّعه على عملائك. هذه القائمة القصيرة تحديداً هي مصدر معظم المفاجآت غير السارّة.

الخلاصة

ما يجري في 2026 ليس موت المصادر المفتوحة، بل انكشاف ما كان يسندها فعلاً: الرخصة كانت تعمل لأن الالتزام بها كان أرخص من تجاوزها، لا لأن نصّها مهيب. وحين هبطت تكلفة إعادة كتابة الكود، ظهر أن نصف قوّة الكوبي‑لفت كان اقتصادياً لا قانونياً.

النتيجة العملية لفريقك ليست فلسفية: مخاطر الترخيص انتقلت من خانة "مسألة قانونية بعيدة" إلى خانة "مخاطر مورّد نشطة". المكتبة التي تعتمد عليها قد تغيّر رخصتها في الترقية القادمة، والانشقاق الذي ستهاجر إليه يجب أن يكون معروفاً لك اليوم، لا أن تبحث عنه في يوم الأزمة.

افحص الرخص، ثبّت الإصدارات، ووثّق خطّة الهجرة لكل اعتمادية حرجة. هذا هو الجزء الذي تتحكّم فيه فعلاً.