شرح تراخيص برمجيات الذكاء الاصطناعي ومفتوحة المصدر: MIT مقابل Apache مقابل GPL مقابل AGPL مقابل الترخيص الملكي

حقائق سريعة

• MIT هو أقصر وأشهر ترخيص متساهل — نحو 170 كلمة، دون بند خاص بالبراءات.
• Apache-2.0 يضيف منح براءة اختراع صريح لا يملكه MIT، وهذا سبب تفضيل شركات كثيرة له في المشاريع ذات الأصل المؤسسي.
• GPL يشترط الإفصاح عن الكود المصدري فقط عند توزيع البرمجية؛ يوسّع AGPL-3.0 هذا الشرط ليشمل تشغيلها كخدمة عبر الشبكة.
• "المصدر المفتوح" المعتمد من OSI شهادة محددة تمنحها Open Source Initiative؛ أما "source-available" و"fair-code" فهما مصطلحان تسويقيان لتراخيص لا تستوفي ذلك التعريف.
• تراخيص نماذج الذكاء الاصطناعي فئة منفصلة تماماً عن تراخيص الكود. قد يكون كود أداة ما مرخّصاً بموجب Apache-2.0 بينما تحمل أوزان النموذج التي تنزّلها شروطاً مختلفة تماماً وأكثر تقييداً.

ما هي التراخيص المتساهلة؟ MIT وApache-2.0 وBSD

• ترخيص MIT نشأ في معهد ماساتشوستس للتقنية (MIT) كوسيلة لإصدار برمجيات طوّرتها الجامعة بأقل قيود ممكنة. يبلغ طوله نحو 170 كلمة، ويمنح حقوقاً تكاد تكون غير محدودة، ولا يطلب سوى بقاء نص حقوق النشر والترخيص الأصلي مرفقاً بأي نسخة أو جزء جوهري تعيد توزيعه.
• رخصة Apache 2.0 تأتي من مؤسسة Apache Software Foundation، التي تأسست لتمنح المساهمين من الشركات والمجتمع إطاراً قانونياً مشتركاً للمشاريع التعاونية الكبيرة. وخلافاً لـMIT، تتضمن منح براءة اختراع صريح — يمنح المساهمون حقوق براءاتهم المتعلقة بالكود للمستخدمين — وهذا سبب تفضيل كثير من الشركات ذات محافظ البراءات لها.
• تراخيص BSD (بنسختَي بندَين وثلاثة بنود) نشأت في جامعة كاليفورنيا في بيركلي لنظام تشغيل Berkeley Software Distribution. تضيف نسخة الثلاثة بنود شرط "عدم التأييد" الذي يمنع استخدام أسماء المؤلفين الأصليين للترويج لمنتج مشتق دون إذن.
• الأثر العملي على من يعتمدها: يمكنك عمل fork وتعديل ودمج وبيع أداة مرخّصة ترخيصاً متساهلاً كجزء من منتج مغلق دون نشر كودك المصدري إطلاقاً — الخطر الحقيقي الوحيد هو إسقاط إشعار حقوق النشر/الترخيص المطلوب من توزيعك.
• أمثلة حقيقية من مراجعات هذا الموقع: يُوزَّع كل من Ollama وllama.cpp بموجب MIT؛ ويُوزَّع vLLM بموجب Apache-2.0 — يمكن دمج الثلاثة في منتج تجاري دون تفعيل أي التزام بالإفصاح عن الكود المصدري.

ما هو Copyleft؟ عائلة GPL وLGPL

• رخصة GNU العمومية العامة (GPL) كتبها ريتشارد ستولمان ومؤسسة البرمجيات الحرة كترخيص لمشروع GNU، مبنية على فكرة أن حرية البرمجيات يجب أن تُحفظ للمستقبل — من يتلقى نسخة معدّلة يجب أن يتمتع بالحقوق نفسها التي كانت للمؤلف الأصلي.
• يختلف GPL v2 وGPL v3 بشكل أساسي في لغة البراءات وأحكام التوافق؛ أضاف الإصدار 3 بنوداً صريحة للانتقام من البراءات ومكافحة "التيفوة" (منع أجهزة تعرقل تشغيل برمجية معدّلة لديك الحق القانوني في تشغيلها).
• تُخفّف رخصة GNU العمومية الصغرى (LGPL) من قيود GPL خصيصاً للمكتبات — يمكنك ربط مكتبة LGPL بتطبيق ملكي دون فتح مصدر التطبيق نفسه، طالما بقي مكوّن المكتبة قابلاً للاستبدال وبقي كوده المصدري الخاص متاحاً.
• ما الذي يفعّل الالتزام فعلياً: توزيع نسخة معدّلة من الكود المشمول بـGPL. مجرد استخدام برمجية GPL غير معدّلة داخلياً، أو تشغيل برمجية ملكية على نظام تشغيل مرخّص بموجب GPL، لا يُخضع كودك الخاص تلقائياً لـGPL.
• من يجب أن يتوخى الحذر: شركة ناشئة تخطط لعمل fork لأداة GPL وتعديلها لتكون نواة منتج تجاري تحتاج إلى خطة — إما فتح تلك التعديلات أو تجنب الـfork؛ أما شركة تشغّل أداة GPL غير معدّلة داخلياً فقط، فلا يقع عليها هذا الالتزام.

كيف يسد AGPL-3.0 ثغرة SaaS

• الثغرة التي يسدّها: بموجب GPL وحده، تشغيل نسخة معدّلة كخدمة ويب مستضافة لا يشكّل "توزيعاً" بالمعنى القانوني الذي يفعّل الترخيص — كان بإمكان شركة أخذ كود GPL وتعديله وتقديمه فقط كمنتج SaaS دون الحاجة أبداً لنشر التعديلات. عُرف هذا بشكل غير رسمي بـ"ثغرة ASP" (مزود خدمة التطبيقات) أو "ثغرة SaaS".
• كُتب AGPL-3.0 خصيصاً لسد هذه الثغرة بإضافة بند تفاعل عبر الشبكة: تقديم وظائف البرمجية المعدّلة للمستخدمين عبر الشبكة يُعدّ بمثابة تفعيل التزام إتاحة الكود المصدري نفسه الذي تفعّله توزيع نسخة فعلية.
• لماذا يهم ذلك للاستضافة وإعادة البيع: وكالة أو مزوّد استضافة يأخذ أداة مرخّصة بموجب AGPL ويعدّلها ويقدّمها للعملاء كخدمة مستضافة يجب أن يُتيح الكود المصدري المعدّل لهؤلاء المستخدمين — تشغيلها دون تعديل لا يُنشئ هذا الالتزام.
• أمثلة حقيقية من مراجعات هذا الموقع: يُوزَّع كل من Jan وKoboldCpp وSillyTavern وtext-generation-webui بموجب AGPL-3.0 — لا مشكلة في الاستضافة الذاتية غير المعدّلة للاستخدام الشخصي أو الداخلي؛ لكن الأمر يختلف جوهرياً بمجرد تعديل إحداها وإعادة بيع وصول مستضاف إليها.
• هذا شرح عام لآلية عمل الترخيص، وليس استشارة قانونية — ما إذا كان نشر معيّن يُعدّ "تقديماً عبر الشبكة" وفق النص الدقيق لـAGPL-3.0 هو سؤال يستحق استشارة محامٍ يراجع بنيتك المعمارية المحددة.

ما هي تراخيص Source-Available و"الكود العادل"؟

• رخصة Business Source License (BSL، وتُعرف أيضاً بـBUSL) تمنح منذ البداية وصولاً للكود المصدري وحقوق استخدام واسعة، مع تاريخ مستقبلي محدد تتحوّل عنده الرخصة إلى ترخيص مصدر مفتوح حقيقي (غالباً Apache-2.0 أو ترخيص متساهل مشابه) — وحتى ذلك التحول، ينطبق قيد استخدام تجاري معلن، يهدف عادة لمنع عرض مستضاف منافس.
• رخصة Server Side Public License (SSPL)، التي أنشأتها MongoDB، تشترط على من يقدّم البرمجية كخدمة أن يفتح أيضاً مصدر كامل مكدس الخدمة الذي بناه حولها — التزام أوسع بكثير من التزام AGPL-3.0، كُتب عمداً لجعل الاستضافة التجارية غير عملية لمزوّد سحابي منافس.
• بند Commons Clause قيد إضافي يُضاف فوق ترخيص أساسي متساهل أو copyleft، يحظر تحديداً بيع البرمجية أو تقديمها كخدمة مستضافة مدفوعة، مع السماح مع ذلك بالاستخدام والتعديل الحرَّين.
• سبب انتقال بعض المشاريع لهذه التراخيص: مشروع يبدأ بترخيص مفتوح بالكامل ثم يعتمد لاحقاً ترخيص source-available يستجيب عادة لمزوّد سحابي كبير يقدّم المشروع كخدمة مستضافة دون المساهمة في تطويره — الانتقال إلى ترخيص source-available يتيح للقائم على الصيانة الحفاظ على معظم الانفتاح مع منع هذا الاستخدام المنافس المحدد.
• الأثر العملي على من يعتمدها: عادة يمكنك قراءة برمجية source-available واستضافتها ذاتياً وتعديلها للاستخدام الداخلي دون مشكلة؛ يُفعَّل القيد عندما تحاول إعادة بيعها كمنتج مستضاف ينافس عرض مالك الترخيص نفسه — اقرأ بند الاستخدام التجاري المحدد، لأن الصياغة تختلف كثيراً بين المشاريع.

ماذا تعني التراخيص الملكية وFreemium "المجانية"؟

• "مجاني (مغلق)" في جدول مقارنة يعني برمجية ملكية دون تكلفة. يمكنك استخدام التطبيق المُجمَّع بموجب شروط خدمة المزوّد، لكن ليس لديك وصول للكود المصدري ولا حق في تعديله أو تدقيقه أو عمل fork له.
• المقايضة الأساسية مقابل بدائل المصدر المفتوح: يميل تطبيق ملكي مجاني إلى أن يكون أكثر صقلاً وأسهل تركيباً، لأن مزوّداً واحداً يتحكم في كامل تجربة المستخدم — لكنك تعتمد كلياً على استمرار رغبة ذلك المزوّد في إبقائه مجانياً وآمناً ومصاناً.
• مخاطر الارتباط بمزوّد واحد (vendor lock-in): دون وصول للكود المصدري، لا يمكنك استضافة نسخة معدّلة ذاتياً، ولا تدقيق ما يفعله التطبيق بدقة ببياناتك، ولا مواصلة التطوير إذا توقف المزوّد عن الصيانة أو غيّر نموذج التسعير أو أغلق.
• من يجب أن يهتم أكثر: أي شخص يبني سير عمل أو عملية تجارية حول أداة ملكية مجانية ينبغي أن تكون لديه خطة بديلة موثّقة — العناية الواجبة نفسها التي تطبّقها على أي اعتماد على مزوّد، لأن "مجاني" لا تعني "دائم" أو "مضمون".
• ليست مثل source-available: تراخيص source-available (BSL، SSPL) تتيح على الأقل قراءة الكود وتدقيقه حتى لو كان الاستخدام التجاري مقيّداً؛ أما الأداة الملكية بالكامل فلا تمنحك لا الكود ولا تلك الضمانات.

كيف تعمل تراخيص نماذج الذكاء الاصطناعي؟ Open Weights وRAIL وقيود الاستخدام المقبول

• أوزان متساهلة بالكامل: تصدر بعض عائلات النماذج أوزانها بموجب ترخيص برمجيات متساهل قياسي (غالباً Apache-2.0)، مما يمنح نفس حقوق الاستخدام الواسعة التي يمنحها ذلك الترخيص للكود، بما في ذلك الاستخدام التجاري دون قيد على مجال الاستخدام.
• تراخيص RAIL وOpenRAIL (ترخيص الذكاء الاصطناعي المسؤول) نشأت مع إصدار BigScience لنموذج BLOOM، وصُممت بالتعاون مع باحثين قانونيين للجمع بين الوصول المفتوح وقائمة محددة من الاستخدامات المحظورة — عادة تمنع استخدامات مثل توليد المعلومات المضللة أو اتخاذ قرارات تمييزية أو محتوى يخالف القانون، مع السماح بخلاف ذلك باستخدام تجاري واسع.
• تراخيص "مجتمعية" أو "مفتوحة الأوزان" مخصصة: يصدر عدد من مزوّدي النماذج الرئيسيين أوزانهم بموجب ترخيص مصمَّم خصيصاً يبدو كترخيص مفتوح لكنه يضيف شروط مجال استخدام. المثال الأكثر استشهاداً هو الترخيص المجتمعي الذي تلحقه Meta بأوزان النماذج التي تصدرها علناً، والذي يمنح استخداماً مجانياً واسعاً لكنه يضيف عتبة حجم استخدام يتطلب تجاوزها اتفاقاً تجارياً منفصلاً، إلى جانب قيود استخدام مقبول.
• ما يجب التحقق منه تحديداً: هل الاستخدام التجاري مسموح به أصلاً، وهل توجد عتبة حجم استخدام أو إيرادات تغيّر الشروط، وما الذي تحظره سياسة الاستخدام المقبول، وهل يقيّد الترخيص استخدام مخرجات النموذج لتدريب نموذج منافس — وهو قيد ظهر في عدة تراخيص خاصة بنماذج ولا يوجد له نظير في تراخيص البرمجيات القياسية.
• هذا ليس استشارة قانونية — تتغير شروط ترخيص النماذج بين الإصدارات من المزوّد نفسه، لذا تحقق من نص الترخيص الدقيق المرفق بأوزان النموذج المحددة التي تخطط لنشرها بدلاً من افتراض استمرارية مع إصدار سابق من المؤسسة نفسها.

من يجب أن يهتم بأي ترخيص؟

قائمة التحقق قبل اعتماد أداة: 7 أمور للتحقق قبل نشرها

1. 1
   اقرأ ملف LICENSE الفعلي في المستودع
   Why it matters: قد يكون ادعاء "مصدر مفتوح" على صفحة هبوط تسويقاً لا حقيقة قانونية — ملف LICENSE (أو NOTICE/COPYING) في مستودع المصدر هو الوثيقة الرسمية، لا شارة أو صفحة أسعار.
2. 2
   تحقق مما إذا تغيّر الترخيص مؤخراً
   Why it matters: تنتقل بعض المشاريع من ترخيص متساهل أو copyleft إلى ترخيص source-available بعد اكتساب زخم تجاري — تكرر هذا النمط عبر صناعة البرمجيات مع بدء مزوّدين سحابيين استضافة مشاريع مفتوحة المصدر شهيرة دون المساهمة بالمقابل. تحقق من تاريخ ترخيص المستودع، لا الملف الحالي فقط.
3. 3
   تحقق مما إذا كان الترخيص معتمداً فعلياً من OSI إذا كان ذلك مهماً لك
   Why it matters: تُسوَّق تراخيص source-available مثل BSL وSSPL عادة كمصدر مفتوح لكنها ليست ضمن قائمة Open Source Initiative المعتمدة — إذا كانت موافقة OSI شرطاً لحالة استخدامك، تحقق من القائمة مباشرة بدلاً من الوثوق بوصف المشروع لنفسه.
4. 4
   اقرأ بنود الاستخدام التجاري ومجال الاستخدام الخاصة بنماذج الذكاء الاصطناعي تحديداً
   Why it matters: قد يسمح ترخيص نموذج ما بالاستخدام التجاري على نطاق واسع، أو يقيّده فوق عتبة حجم استخدام، أو يحظر تطبيقات محددة تماماً — تقع هذه البنود خارج لغة تراخيص البرمجيات القياسية ويسهل إغفالها إذا اكتفيت بفحص ترخيص الكود.
5. 5
   حدد ما إذا كانت الاستضافة الذاتية مقابل استضافة SaaS تغيّر التزاماتك
   Why it matters: بموجب AGPL-3.0، يُفعّل تقديم برمجية معدّلة عبر الشبكة نفس التزام الإفصاح الذي تفعّله توزيع نسخة بموجب GPL — تأكد من الفئة التي يقع فيها نشرك المخطط قبل تعديل الكود.
6. 6
   تحقق من وجود اتفاقية ترخيص مساهم (CLA) إذا كنت تخطط للمساهمة
   Why it matters: قد تمنح CLA للقائم على صيانة المشروع حقوقاً أوسع على مساهمتك مما يمنحه ترخيص المشروع نفسه للمستخدمين — يهم هذا بشكل أساسي إذا كنت تنوي إرسال كود إلى المشروع، لا إذا كنت تستهلكه فقط.
7. 7
   تحقق من قيود العلامة التجارية بشكل منفصل عن ترخيص الكود
   Why it matters: لا يمنح ترخيص كود متساهل أو copyleft تلقائياً حقوقاً على اسم المشروع أو شعاره — يمكن أن يمنع قانون العلامات التجارية عمل fork وإعادة تسمية أداة حتى عندما يسمح ترخيص الكود بالـfork من الناحية الأخرى.

الأخطاء الشائعة

• الوثوق بادعاء "مصدر مفتوح" في صفحة تسويقية بدلاً من قراءة ملف LICENSE الفعلي في المستودع.
• افتراض أن AGPL-3.0 يهم فقط إذا وزّعت نسخة من البرمجية — فهو ينطبق أيضاً على تقديم كود معدّل كخدمة مستضافة.
• معاملة ترخيص كود النموذج وترخيص أوزانه كوثيقة واحدة — غالباً ما لا يكونان كذلك.
• عمل fork وإعادة تسمية أداة دون التحقق من قيود العلامة التجارية بشكل منفصل عن ترخيص الكود.
• افتراض أن ترخيصاً كان متساهلاً عند إطلاق مشروع ما زال ساري المفعول بعد إعادة ترخيص لاحقة — تحقق من الترخيص الحالي، لا الذي تتذكره.
• تخطي المراجعة القانونية لأداة copyleft أو source-available لأنها "مجانية" — المجانية في الاستخدام والخلو من الالتزامات ليسا الشيء نفسه.

المصادر

• Open Source Initiative — The Open Source Definition — التعريف الرسمي الذي يجب أن يستوفيه الترخيص ليُعتمد كمصدر مفتوح من OSI.
• مشروع GNU — Free Software Licenses — شرح مؤسسة البرمجيات الحرة الخاص بـGPL وLGPL وAGPL.
• مؤسسة Apache Software Foundation — Apache License 2.0 — النص الكامل للترخيص.
• نص ترخيص MIT (Open Source Initiative) — النص الكامل للترخيص.
• MongoDB — Server Side Public License — شروط SSPL وتبريراتها الخاصة.
• الأسئلة الشائعة حول Business Source License — شرح لكيفية عمل تحويل BSL/BUSL من جهة معتمِدة معروفة للترخيص.

الأسئلة الشائعة

قراءات ذات صلة

• الدليل الكامل لبرمجيات LLM المحلية — أكثر من 160 أداة LLM محلية مع الترخيص المذكور لكل عنصر.
• مراجعة Dify AI Workflow Builder — مراجعة تذكر ترخيصها؛ استخدم هذا الدليل لفهم ما يعنيه ذلك الترخيص لنشرك.
• المحتوى المولَّد بالذكاء الاصطناعي ومخاطر الملكية الفكرية — مسائل الملكية الفكرية المصاحبة للترخيص عند نشرك مخرجات مولَّدة بالذكاء الاصطناعي تجارياً.
• أمن الذكاء الاصطناعي الوكيلي: الهوية والوصول — اعتبارات الأمن والحوكمة لعمليات نشر الذكاء الاصطناعي المستضافة ذاتياً، مسألة مصاحبة للامتثال للترخيص.
• RAG محلي متوافق مع GDPR للمستندات الحساسة — مخاطر الترخيص ومخاطر إقامة البيانات/الامتثال قائمتا تحقق منفصلتان؛ يغطي هذا الدليل جانب الامتثال.