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

في كل دليل تثبيت على هذا الموقع سوف تجد عبارة «مفتوح المصدر Open Source» قريبة من اسم الأداة، وسوف تجد بجانبها اسماً قصيراً مثل MIT أو GPL-3.0 أو AGPL-3.0، وغالب الظن أنك تقرأ الاسم الأول وتتجاوز الثاني، والسبب أن الكلمة الأولى تكفيك في العادة: البرنامج مجاني، والكود موجود على GitHub، وتستطيع تشغيله على سيرفرك. ولكن الحقيقة أن الاسم القصير هو الأهم، فهو الذي يقرر هل تستطيع أن تبيع خدمة مبنية على هذا البرنامج، وهل يجب أن تنشر الكود إذا عدلته، وماذا يحدث إذا أضفت مكتبة منه إلى تطبيق تبيعه لعملائك، بل إن بعض المشاريع التي شرحناها غيرت رخصتها وهي في منتصف الطريق، كما حدث مع NocoDB في يناير 2026.

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

وسوف نناقش في هذا المقال ما يلي:

• كيف بدأت البرمجيات الحرة Free Software من مختبر MIT، ولماذا أعلن ريتشارد ستالمان Richard Stallman مشروع GNU في 1983.
• الحريات الأربع ومعنى كلمة Free، وفكرة Copyleft ورخصة GPL.
• كيف ولد Linux من «هواية» لينوس تورفالدز Linus Torvalds، ولماذا انتقل إلى GPL.
• لماذا ظهر مصطلح المصادر المفتوحة Open Source في 1998، وما الذي يحدث اليوم مع تغيير الرخص.
• الفرق بين البرمجيات الحرة والمفتوحة والمجانية Freeware والمصدر المتاح Source-available والنواة المفتوحة Open Core.
• أنواع الرخص الشائعة وجدول مقارنة بينها، ثم سيناريوهات عملية لما يجوز وما لا يجوز.
• كيف تعرف رخصة أي مشروع قبل أن تعتمد عليه، والعلامات التي تستحق الانتباه.

كل شيء بدأ بطابعة

الصورة التالية تبين المحطات التي سوف نمر عليها في هذه القصة، من إعلان GNU في 1983 إلى اليوم الذي يعمل فيه Linux في كل مكان وتتغير فيه رخص مشاريع كبيرة:

عندما انضم ريتشارد ستالمان إلى مختبر الذكاء الاصطناعي في MIT في 1971، وجد مجتمعاً يتبادل الكود كما يتبادل الناس وصفات الطبخ، فالمختبر يعمل بنظام تشغيل كتبه مبرمجوه بأنفسهم اسمه ITS على حاسب PDP-10، وإذا رأيت زميلاً يستخدم برنامجاً يعجبك فمن الطبيعي أن تطلب منه الكود المصدري Source Code لتقرأه وتعدله وتأخذ منه ما تحتاج، ولم يكن أحد يسمي ذلك «برمجيات حرة» لأن المصطلح لم يكن موجوداً بعد، ولكن هذا ما كان عليه الحال فعلاً.

وفي المختبر طابعة ليزر قدمتها Xerox هدية، وكان أكبر عيوبها أن الورق ينحشر فيها Paper Jam كثيراً، ومع الطابعة القديمة كان ستالمان قد أضاف إلى برنامج التحكم بها أمراً يرسل تنبيهاً لكل مستخدم ينتظر طباعة بأن الطابعة متوقفة، فيذهب أحدهم ويصلحها بدل أن ينتظر الجميع طباعة لن تأتي. وأراد أن يفعل الشيء نفسه مع الطابعة الجديدة، فذهب إلى باحث في جامعة Carnegie Mellon يملك نسخة من الكود، ولكن الباحث رفض أن يعطيه إياها، والسبب أنه وقع اتفاقية عدم إفصاح Nondisclosure Agreement مع Xerox التي كانت تحول الطابعة إلى منتج تجاري، وكانت تلك الحادثة حوالي عام 1980 كما يرويها الفصل الأول من كتاب Free as in Freedom، وخرج منها ستالمان بقناعة أن «اتفاقيات عدم الإفصاح لها ضحايا» ("nondisclosure agreements have victims").

وقد يتساءل البعض: لماذا تصنع طابعة كل هذا الغضب؟ والإجابة أن الطابعة كانت المثال الصغير لتحول كبير، ففي 1981 استقطبت شركة Symbolics أغلب مبرمجي المختبر فتفكك المجتمع، ثم أوقفت Digital سلسلة PDP-10، وعندما اشترى المختبر جهاز PDP-10 جديداً في 1982 قرر المسؤولون أن يستخدموا نظام Digital المغلق بدل ITS، وصارت الأجهزة الحديثة تأتي بأنظمة تشغيل لا تحصل حتى على نسختها التنفيذية إلا بعد أن توقع اتفاقية عدم إفصاح، أي أن أول خطوة لاستخدام الحاسب صارت وعداً بألا تساعد جارك، وهذا ما يرويه ستالمان في قصة مشروع GNU تحت عنوان انهيار المجتمع.

إعلان GNU: نظام كامل يملكه مستخدموه

كان أمام ستالمان، كما يقول، أن يوقع اتفاقيات عدم الإفصاح ويعمل في البرمجيات المغلقة Proprietary Software، أو أن يترك مجال الحاسب كله، ولكنه اختار طريقاً ثالثاً: أن يكتب نظام تشغيل كاملاً ويجعله حراً، وبهذا الشكل يستطيع أي شخص أن يستخدم الحاسب دون أن يتخلى عن حقه في المشاركة. وفي 27 سبتمبر 1983 نشر الإعلان الأول في مجموعتي Usenet باسم net.unix-wizards وnet.usoft تحت عنوان «Free Unix!»، وبدأه بجملة: «بدءاً من عيد الشكر هذا سوف أكتب نظاماً برمجياً كاملاً متوافقاً مع Unix» ("Starting this Thanksgiving I am going to write a complete Unix-compatible software system")، وسماه GNU، وهو اختصار يحيل إلى نفسه: GNU's Not Unix.

وفي يناير 1984 ترك ستالمان وظيفته في MIT، والسبب أنه لو بقي موظفاً فيها لاستطاعت الجامعة أن تدعي ملكية الكود الذي يكتبه وتفرض عليه شروطها، وبدأ يكتب برامج GNU واحداً تلو الآخر، ومنها محرر GNU Emacs الذي بدأه في سبتمبر 1984. ولما زاد الاهتمام بالمشروع أسس في 1985 مؤسسة البرمجيات الحرة Free Software Foundation واختصاراً FSF، وهي مؤسسة غير ربحية تمول تطوير البرمجيات الحرة وتدافع عنها، وقد تأسست في 4 أكتوبر 1985 بحسب البيانات المنشورة على موقعها.

الحريات الأربع: ما معنى Free في Free Software؟

هنا نصل إلى أكثر نقطة يقع فيها الخلط، فكلمة Free في الإنجليزية تعني «حر» وتعني «مجاني» أيضاً، والمقصود في البرمجيات الحرة هو المعنى الأول، لذلك يقول تعريف البرمجيات الحرة إن عليك أن تفكر في Free «كما في حرية التعبير، لا كما في البيرة المجانية» ("free as in free speech, not as in free beer")، والمثال يبدو غريباً في ثقافتنا ولكن فكرته واضحة: المهم أن تملك الحرية، لا أن يكون السعر صفراً. ويعرف المشروع البرنامج الحر بأنه البرنامج الذي يملك مستخدموه أربع حريات أساسية:

0. الحرية 0 (Freedom 0): أن تشغل البرنامج كما تريد ولأي غرض.
1. الحرية 1 (Freedom 1): أن تدرس طريقة عمل البرنامج وتعدله ليعمل كما تريد، والوصول إلى الكود المصدري شرط لذلك.
2. الحرية 2 (Freedom 2): أن توزع نسخاً منه لتساعد غيرك.
3. الحرية 3 (Freedom 3): أن توزع نسخك المعدلة على الآخرين، فيستفيد المجتمع كله من تعديلاتك، والوصول إلى الكود شرط لذلك أيضاً.

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

رخصة GPL وفكرة Copyleft

وقد يتساءل البعض: إذا نشرت كودي للجميع بلا أي شروط، فما الذي يمنع شركة من أخذه وتعديله وبيعه برنامجاً مغلقاً؟ والإجابة أن لا شيء يمنعها، وهذه بالضبط المشكلة التي أراد ستالمان حلها، فكان الحل فكرة سماها Copyleft، وهي تستخدم قانون حقوق النشر Copyright نفسه ولكن بالعكس: بدل أن يمنعك القانون من النسخ، تعطيك الرخصة كل الحريات بشرط واحد، وهو أن من يوزع البرنامج أو نسخة معدلة منه يجب أن يعطي من بعده الحريات نفسها، وبالتالي تبقى الحرية مع الكود أينما ذهب. وكتبت هذه الفكرة في رخصة GNU General Public License واختصاراً GPL، وصدر إصدارها الأول في فبراير 1989.

طالب في هلسنكي وهواية لن تكبر

بحلول 1991 كان مشروع GNU قد كتب أغلب ما يحتاجه نظام التشغيل من أدوات: المترجم Compiler واسمه GCC، والمحرر Emacs، وال Shell، والمكتبات Libraries، ولكن بقيت قطعة واحدة لم تكتمل وهي النواة Kernel، أي الجزء الذي يتعامل مع المعالج والذاكرة والأقراص مباشرة. وفي هلسنكي كان طالب اسمه لينوس تورفالدز يكتب نواة لحاسبه الشخصي الجديد بمعالج 386، فنشر في 25 أغسطس 1991 رسالة في مجموعة comp.os.minix يسأل فيها مستخدمي Minix عما يحبونه وما يكرهونه في نظامهم، وقال إنه يكتب نظام تشغيل حراً، ووصفه بأنه «مجرد هواية، ولن يكون كبيراً واحترافياً مثل GNU» ("just a hobby, won't be big and professional like gnu").

وبعد ثلاثة أسابيع تقريباً، في 17 سبتمبر 1991، رفع الإصدار 0.01، وهو تاريخ ذكره تورفالدز بنفسه في الذكرى الثلاثين، وما زالت ملاحظات ذلك الإصدار موجودة على kernel.org، وفيها يعترف بأن الإصدار ليس منتجاً ناضجاً وأنه موجه للقراءة أكثر من التشغيل، وأن لوحة المفاتيح الفنلندية مثبتة في الكود، فإذا كانت لوحتك أمريكية فسوف تحتاج إلى «بعض التمرين». وفي الملاحظات نفسها شيء أهم لموضوعنا: رخصة النواة الأولى كانت رخصة كتبها تورفالدز بنفسه، تسمح بالتوزيع بشرط أن يكون الكود متاحاً، وتمنع بيعه أو حتى أخذ رسوم مقابل نسخه.

ولم يبق هذا الشرط طويلاً، ففي ملاحظات الإصدار 0.12 كتب تورفالدز أنه تلقى طلبات لجعل الرخصة متوافقة مع GNU copyleft وإزالة شرط منع التوزيع بمقابل، وأنه موافق، وأن الرخصة الجديدة تبدأ من أول فبراير، وكان ذلك في 1992 كما يذكر تاريخ مشروع GNU. ومنذ ذلك الحين ونواة Linux مرخصة بـ GPL، وهي اليوم GPL-2.0 فقط دون الإصدارات الأحدث. والسبب في أهمية هذا القرار أن الشركات صارت تستطيع أن تبيع أقراص التوزيعات Distributions وتقدم الدعم وتبني أعمالاً حول Linux، ولكن كل من يوزع النواة معدلة يجب أن ينشر تعديلاته، فعادت التحسينات إلى المشروع بدل أن تختفي في منتجات مغلقة.

GNU مع Linux: نظام كامل

وبهذا اكتملت الصورة، فالنواة جاءت من تورفالدز، وأغلب الأدوات حولها جاءت من مشروع GNU، والنظام الذي تعمل عليه سيرفرات Ubuntu وDebian اليوم هو مزيج من الاثنين، لذلك تطلب مؤسسة البرمجيات الحرة أن يسمى GNU/Linux وليس Linux وحده. وفي الاستخدام اليومي يقول أغلب الناس «Linux»، ونحن نفعل ذلك في أدلة الموقع أيضاً، ولكن من المفيد أن تعرف أن الأوامر التي تكتبها كل يوم مثل ls وcp وbash جاءت في الغالب من GNU وليس من النواة.

1998: لماذا ظهر مصطلح Open Source؟

بعد سبع سنوات من رسالة تورفالدز كان Linux قد انتشر في الجامعات والشركات الصغيرة، ولكن كلمة Free كانت تسبب مشكلة كلما وصل الحديث إلى مدير في شركة كبيرة، فهو يسمع «مجاني» ويفهم «بلا قيمة» أو «بلا دعم»، ويسمع «حرية» فيظنها حديثاً سياسياً لا علاقة له بالعمل. وفي بداية 1998 أعلنت Netscape، صاحبة متصفح Netscape Navigator، أنها سوف تنشر الكود المصدري لمتصفحها، ومن ذلك الكود ولد مشروع Mozilla في العام نفسه، فكانت أول مرة تفعل فيها شركة بهذا الحجم شيئاً كهذا.

ولاحظ مجموعة من المهتمين أن الاهتمام الذي صنعه إعلان Netscape فرصة يجب ألا تضيع، فاجتمعوا في 3 فبراير 1998 في Palo Alto للبحث عن اسم يقدم الفكرة للشركات بلغة الفائدة العملية، واستقروا على مصطلح «Open Source» الذي اقترحته كريستين بيترسون Christine Peterson، وكانت حينها المديرة التنفيذية لمعهد Foresight. وفي أواخر فبراير من العام نفسه أسس إريك ريموند Eric Raymond وبروس بيرنز Bruce Perens مبادرة المصادر المفتوحة Open Source Initiative واختصاراً OSI، وكتبت المبادرة تعريف المصادر المفتوحة Open Source Definition بعشرة شروط، أخذتها من إرشادات Debian للبرمجيات الحرة التي كتب بيرنز مسودتها الأولى، بعد أن حذفت منها ما يخص Debian وحده. وكان لريموند قبل ذلك مقال شهير اسمه The Cathedral and the Bazaar يقارن فيه بين طريقة «الكاتدرائية» التي يبني فيها فريق صغير مغلق البرنامج، وطريقة «السوق» المفتوحة التي طور بها Linux، وقد نشر في الفترة نفسها تقريباً وكان له أثر كبير في هذا التحول كما تذكر صفحة تاريخ OSI.

وقد يتساءل البعض: هل البرمجيات الحرة والمفتوحة شيء واحد إذاً؟ والإجابة أنها في الغالب البرامج نفسها والرخص نفسها، ولكن الدافع مختلف، فمؤسسة البرمجيات الحرة ترى أن الحرية قيمة أخلاقية تخص المستخدم، ولذلك تقول إن المصادر المفتوحة تفوت الفكرة الأساسية لأنها تتحدث عن جودة الكود وطريقة التطوير وتترك الحرية جانباً، أما حركة المصادر المفتوحة فتقدم الفكرة بلغة عملية: كود أفضل، وأخطاء تكتشف أسرع، وتكلفة أقل. لذلك سوف تجد في الوثائق الرسمية العربية والأجنبية مصطلح «البرمجيات الحرة ومفتوحة المصدر» Free and Open Source Software واختصاراً FOSS، وهو المصطلح الذي تستخدمه قواعد البرمجيات الحكومية في المملكة التي شرحناها في مقال سابق.

أين نحن اليوم؟ Linux في كل مكان، والرخص تتغير

الهواية التي «لن تكون كبيرة» تعمل اليوم في أماكن لم يتوقعها أحد، فنواة Android مبنية على نواة Linux، وكل الحواسيب العملاقة في قائمة TOP500 تعمل بـ Linux منذ سنوات، والسيرفرات التي نشرح عليها كل أدلة هذا الموقع تعمل بـ Ubuntu، وأغلب الأدوات التي نثبتها عليها، من Docker إلى Nextcloud، مفتوحة المصدر. ولكن مع هذا النجاح ظهرت مشكلة جديدة لم تكن في حسابات أحد في 1998، وهي أن شركات الحوسبة السحابية Cloud Providers صارت تأخذ البرامج المفتوحة وتبيعها خدمات مدارة Managed Services، والشركة التي تطور البرنامج لا تحصل على شيء من ذلك، فبدأت بعض هذه الشركات تغير رخصها.

في 10 أغسطس 2023 أعلنت HashiCorp نقل منتجاتها من رخصة MPL 2.0 إلى Business Source License 1.1، ومنها Terraform أشهر أداة للبنية التحتية ككود Infrastructure as Code، والرخصة الجديدة تمنع من يقدم خدمات منافسة لـ HashiCorp من استخدام الإصدارات الجديدة. ولم يمر شهر ونصف حتى أعلنت مؤسسة Linux Foundation في 20 سبتمبر 2023 تأسيس مشروع OpenTofu، وهو نسخة مفتوحة من Terraform كانت تسمى أولاً OpenTF وبنيت على آخر كود صدر بترخيص MPL، وصدر أول إصدار مستقر منه OpenTofu 1.6 في 10 يناير 2024، ثم اشترت IBM شركة HashiCorp في 27 فبراير 2025، ولذلك سوف ترى اسم IBM في ملف الرخصة عندما نفتحه لاحقاً في هذا المقال.

والقصة نفسها تكررت مع Redis، ففي 20 مارس 2024 أعلنت الشركة أن الإصدارات من Redis 7.4 وما بعده سوف تصدر برخصتي RSALv2 وSSPLv1 بدل رخصة BSD التي صدر بها المشروع خمسة عشر عاماً، واعترفت الشركة في الإعلان نفسه بأن Redis لم يعد مفتوح المصدر بحسب تعريف OSI. وبعد ثمانية أيام فقط، في 28 مارس 2024، أعلنت Linux Foundation مشروع Valkey المبني على Redis 7.2.4 برخصة BSD، وبدعم من AWS وGoogle Cloud وOracle وغيرها.

حرة أم مفتوحة أم مجانية؟ الفرق بين المصطلحات

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

• البرمجيات الحرة Free Software: برنامج يعطيك الحريات الأربع، والتسمية تركز على حق المستخدم. ومثاله أدوات GNU ونواة Linux.
• المصادر المفتوحة Open Source: برنامج رخصته معتمدة من OSI لأنها تحقق الشروط العشرة في تعريف المصادر المفتوحة، والتسمية تركز على الفائدة العملية. وفي الواقع فأغلب الرخص الحرة مفتوحة المصدر والعكس، ومثاله Kubernetes وDocker Engine.
• البرمجيات المجانية Freeware: برنامج تنزله وتستخدمه دون أن تدفع، ولكنك لا تملك الكود ولا حق تعديله، وهو بحسب تصنيف مشروع GNU ليس برنامجاً حراً، ومثاله كثير من أدوات ويندوز المجانية التي تنزلها من موقع الشركة.
• المصدر المتاح Source-available: تستطيع أن تقرأ الكود وغالباً أن تعدله وتشغله، ولكن الرخصة تمنع استخداماً معيناً، وفي الغالب تمنع تقديم البرنامج خدمة منافسة لصاحبه، لذلك هي ليست مفتوحة المصدر بحسب OSI. ومثاله Terraform من الإصدار 1.6 برخصة BUSL، وNocoDB برخصة Sustainable Use License.
• النواة المفتوحة Open Core: نموذج عمل وليس رخصة، فالنسخة الأساسية مفتوحة المصدر، والميزات التي تحتاجها المؤسسات الكبيرة في نسخة مدفوعة. ومثاله Mattermost بنسخة Team Edition المرخصة بـ MIT ونسخة Enterprise المدفوعة، وStalwart بإصداره المجتمعي المرخص بـ AGPL-3.0 وإصداره التجاري، وDokploy الذي يجمع Apache 2.0 لأغلب الكود ورخصة أخرى لمجلدات محددة.

والجدول التالي يجمع الفروق في سطر لكل مصطلح:

الحرة لا تعني بلا تكلفة، والمفتوحة لا تعني بلا دعم

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

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

أنواع الرخص للمبتدئين

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

الرخص المتساهلة Permissive: MIT وBSD وApache

هذه الرخص تقول لك تقريباً: «افعل بالكود ما تشاء، ولكن احتفظ باسمنا ونص الرخصة، ولا تحملنا أي مسؤولية»، وبالتالي تستطيع أن تضع الكود في منتج مغلق تبيعه دون أن تنشر تعديلاتك، ولهذا تحبها الشركات. وأشهرها:

• رخصة MIT: أقصر الرخص وأكثرها انتشاراً، فقرتان تقريباً، ومنها Gitea وTraefik.
• رخص BSD: قريبة جداً من MIT، والإصدار ذو البنود الثلاثة BSD-3-Clause يضيف أنك لا تستخدم اسم المشروع أو مطوريه للترويج لمنتجك دون إذن، ومن المشاريع بها nginx بنسخة البندين BSD-2-Clause، وValkey بنسخة البنود الثلاثة.
• رخصة Apache 2.0: متساهلة مثل MIT، ولكنها أطول لأنها تضيف شيئين مهمين: أن تذكر في الملفات التي عدلتها أنك عدلتها، ومنح صريح لبراءات الاختراع Patent Grant في البند الثالث، أي أن كل من ساهم في الكود يعطيك حق استخدام براءاته التي تغطي مساهمته، ومن يرفع دعوى براءة على المشروع يفقد هذا الحق. ومنها Kubernetes وDocker Engine وCaddy.

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

رخص Copyleft: من GPL إلى AGPL

هذه هي الرخص التي جاءت من فكرة ستالمان، وشرطها الأساسي: إذا وزعت البرنامج أو نسخة معدلة منه فيجب أن تعطي من يستلمها الكود المصدري بالرخصة نفسها. ولاحظ كلمة «وزعت»، فهي مفتاح فهم هذه الرخص كلها كما سيأتي في السيناريوهات.

• GPL-2.0: إصدار 1991، وهو رخصة نواة Linux، وتجد بها أيضاً WordPress بصيغة «الإصدار 2 أو ما بعده» GPL-2.0-or-later.
• GPL-3.0: إصدار 2007، ويضيف منحاً صريحاً لبراءات الاختراع، ويمنع حيلة الأجهزة التي تشغل كوداً حراً ولكنها ترفض تشغيل أي نسخة معدلة منه. ومنها mailcow الذي شرحنا تثبيته.
• AGPL-3.0: هي GPL-3.0 مع بند إضافي رقم 13 للشبكة، والسبب في وجودها أن GPL لا تلزمك بشيء إذا لم توزع البرنامج، فإذا عدلت برنامج GPL وقدمته موقعاً أو خدمة عبر الإنترنت فأنت لم توزع نسخة لأحد، وبالتالي لا يلزمك نشر تعديلاتك، وهذه الثغرة التي كتبت AGPL لإغلاقها. فالبند 13 يقول إنك إذا عدلت البرنامج فيجب أن تتيح الكود المعدل لكل المستخدمين الذين يتعاملون معه عبر الشبكة. ومنها Stalwart وNextcloud وGrafana، وRedis 8 خياراً من ثلاثة.

Copyleft الضعيفة: LGPL وMPL

وبين الطرفين نوع وسط يسمى Copyleft الضعيفة Weak Copyleft، وفكرته أن الشرط يطبق على المكتبة أو الملف نفسه فقط وليس على برنامجك كله:

• LGPL: الرخصة «الأقل» من GPL، وكتبت أصلاً للمكتبات، فتستطيع أن تربط Link برنامجك المغلق بمكتبة LGPL، ولكن إذا عدلت المكتبة نفسها فيجب أن تنشر تعديلاتها، ويجب أن يستطيع المستخدم أن يستبدل المكتبة بنسخة أخرى. ومنها FFmpeg المرخص بـ LGPL 2.1 أو ما بعدها، مع أجزاء اختيارية مرخصة بـ GPL 2.0 أو ما بعدها.
• MPL 2.0: رخصة Mozilla، وشرطها على مستوى الملف كما تشرح الأسئلة الشائعة الخاصة بها، فإذا عدلت ملفاً مرخصاً بـ MPL فيجب أن تنشر تعديله عند التوزيع، أما ملفاتك الجديدة فتستطيع أن تجعلها بأي رخصة. ومنها OpenTofu، وكان Terraform بها قبل 2023.

رخص المصدر المتاح: ليست مفتوحة المصدر

وفي آخر الخط مجموعة رخص تجعل الكود مقروءاً ولكنها تمنع استخدامات معينة، ولهذا لا تعتمدها OSI مهما بدا الكود مفتوحاً أمامك على GitHub، وأشهرها:

• Business Source License 1.1 واختصاراً BUSL أو BSL: تسمح بالنسخ والتعديل والاستخدام غير الإنتاجي، ويضيف صاحب المشروع «إذناً إضافياً» Additional Use Grant يحدد الاستخدام الإنتاجي المسموح، ولها ميزة غريبة: بعد «تاريخ التغيير» Change Date، أو بعد أربع سنوات من نشر كل إصدار أيهما أقرب، يتحول ذلك الإصدار تلقائياً إلى رخصة مفتوحة يحددها صاحبه. ومنها Terraform من الإصدار 1.6.
• Server Side Public License واختصاراً SSPL: كتبتها MongoDB على أساس AGPL، ولكنها تطلب ممن يقدم البرنامج خدمة أن ينشر كود الخدمة كلها، بما في ذلك أدوات الإدارة والمراقبة والنسخ الاحتياطي، وقد سحبت من مراجعة OSI، ثم أعلنت OSI في يناير 2021 أنها ليست رخصة مفتوحة المصدر لأنها تميز ضد مجال استخدام معين، وهو الشرط السادس في التعريف.
• Elastic License 2.0 واختصاراً ELv2، وRedis Source Available License واختصاراً RSALv2، وSustainable Use License التي تستخدمها NocoDB: كلها تسمح بالاستخدام الداخلي وتمنع بيع البرنامج خدمة مدارة للآخرين أو منافسة صاحبه.

جدول المقارنة

والجدول التالي يجمع أهم الرخص في مكان واحد، ولاحظ أن عمود «متى» هو الذي يفرق بين الرخص فعلاً، فكل الرخص المفتوحة تسمح بالاستخدام التجاري والتعديل:

ماذا يعني هذا لك عملياً؟

الآن سوف نطبق ما سبق على ثلاثة مواقف يقابلها من يعمل في الاستضافة الذاتية Self-Hosting أو يبني منتجاً، ونعتمد في كل منها على نص الرخصة والأسئلة الشائعة الرسمية لرخص GNU.

تشغيل برنامج GPL أو AGPL داخل شركتك

لنفرض أنك ثبت mailcow المرخص بـ GPL-3.0 أو Stalwart المرخص بـ AGPL-3.0 ليستخدمه موظفو شركتك، دون أن تغير في الكود شيئاً. في هذه الحالة لا تلزمك الرخصة بشيء، والأسئلة الشائعة لرخص GNU تقول ذلك حرفياً عن تشغيل البرنامج دون توزيعه: لا شيء، وهذا ما ذكرناه في مقارنة خوادم البريد عن Stalwart.

فإذا عدلت الكود لحاجة داخلية، فمع GPL تستطيع أن تستخدم النسخة المعدلة داخلياً دون أن تنشرها، والنسخ داخل المؤسسة الواحدة لا يعد توزيعاً، ولكن تذكر أن إعطاء النسخة لمقاول خارجي يعمل من مكانه يعد توزيعاً. أما مع AGPL فالبند 13 يلزمك بإتاحة الكود المعدل لكل من يستخدم البرنامج عبر الشبكة، وهؤلاء في هذه الحالة موظفوك، لذلك الحل الأنسب أن تحفظ تعديلاتك في مستودع Git داخلي Repository يصل إليه من يستخدم الخدمة.

تقديم البرنامج خدمة لعملائك

الآن لنفرض أنك تريد أن تبيع صناديق بريد لعملائك على Stalwart، أو تقدم لوحة مبنية على برنامج مفتوح. إذا كان البرنامج بـ AGPL ولم تعدله، فلا يتغير شيء، أما إذا عدلته فيجب أن تتيح الكود المعدل لعملائك، والأسئلة الشائعة تذكر حالة شركة تشغل نسخة معدلة على موقعها وتقول إنها يجب أن تنشر الكود. وإذا كان البرنامج بـ GPL فقط، فتقديمه خدمة لا يعد توزيعاً، ولذلك لا يلزمك نشر تعديلاتك، وهذا بالضبط الفرق الذي صنعت AGPL من أجله.

وأما إذا كان البرنامج برخصة مصدر متاح، فهنا يجب أن تنتبه أكثر، والسبب أن هذه الرخص كتبت لهذا الموقف بالذات، فرخصة Terraform تمنع تقديمه لطرف ثالث بشكل مستضاف ينافس النسخ المدفوعة، ورخصة Redis 7.4 تمنع تقديمه خدمة مدارة، ورخصة NocoDB تمنع بيعه خدمة لعملائك دون رخصة تجارية، لذلك اقرأ تعريف «المنافس» في الرخصة نفسها قبل أن تبني عليه خطة عمل، أو اختر النسخة المفتوحة البديلة مثل OpenTofu وValkey.

إضافة مكتبة GPL إلى تطبيق مغلق

والموقف الثالث يخص المطورين: لديك تطبيق مغلق تبيعه أو توزعه على أجهزة العملاء، وتريد أن تضيف إليه مكتبة جاهزة. إذا كانت المكتبة بـ MIT أو BSD أو Apache فتستطيع ذلك، بشرط أن تضع نص رخصتها مع تطبيقك، في صفحة «حول» أو ملف مرفق. وإذا كانت بـ LGPL فتستطيع أن تربط تطبيقك بها، بشرط أن تبقى المكتبة قابلة للاستبدال وأن تنشر أي تعديل عليها هي. أما إذا كانت بـ GPL فالأسئلة الشائعة واضحة: البرنامج الذي يرتبط بها يجب أن يكون كله بـ GPL أو برخصة متوافقة معها عند التوزيع، لذلك لا تضع مكتبة GPL في تطبيق مغلق توزعه، فإما أن تفتح تطبيقك أو تبحث عن مكتبة برخصة أخرى أو تشتري رخصة تجارية من صاحبها إن كان يبيعها. ولاحظ أن الشرط مرتبط بالتوزيع مرة أخرى، فأداة داخلية تستخدمها شركتك ولا تخرج منها لا يلزمك فيها شيء.

كيف تعرف رخصة أي مشروع قبل أن تعتمد عليه؟

المصدر الأول دائماً هو ملف الرخصة في المستودع، واسمه في الغالب LICENSE أو COPYING أو LICENSE.md، وتستطيع أن تقرأ أوله دون أن تنزل المشروع كله، والمثال التالي يقرأ أول ستة أسطر من ملف رخصة OpenTofu:

curl -s https://raw.githubusercontent.com/opentofu/opentofu/main/LICENSE | head -n 6

والمخرج سوف يكون كما يلي:

Copyright (c) The OpenTofu Authors
Copyright (c) 2014 HashiCorp, Inc.

Mozilla Public License, version 2.0

1. Definitions

لاحظ أن حقوق HashiCorp ما زالت في أول الملف، وهذا منطقي لأن OpenTofu بني على كود Terraform الذي صدر بـ MPL، والرخصة تسمح بذلك بشرط أن تبقى الحقوق الأصلية. والآن نقارن بملف رخصة Terraform نفسه، ونأخذ منه الأسطر الثلاثة التي تحدد صاحب الرخصة وتاريخ التغيير والرخصة التي يتحول إليها:

curl -s https://raw.githubusercontent.com/hashicorp/terraform/main/LICENSE | grep -E "^(Licensor|Change Date|Change License):"

والمخرج سوف يكون كما يلي:

Licensor:             International Business Machines Corporation (IBM)
Change Date:          Four years from the date the Licensed Work is published.
Change License:       MPL 2.0

في المخرج أعلاه لاحظ التالي:

• صاحب الرخصة Licensor أصبح IBM بعد شراء HashiCorp، وهو الذي يحدد الاستخدام المسموح في الإذن الإضافي.
• تاريخ التغيير Change Date أربع سنوات من نشر كل إصدار، وبعدها يتحول ذلك الإصدار إلى MPL 2.0 كما في سطر Change License.
• هذا يعني أن إصدار Terraform الذي يصدر اليوم سوف يصبح مفتوح المصدر بعد أربع سنوات، أما الإصدارات الجديدة فتبقى بـ BUSL ما لم تغير الشركة رأيها.

والطريقة الثانية هي معرفات SPDX، وهي قائمة أسماء قصيرة موحدة لكل رخصة مثل MIT وApache-2.0 وGPL-2.0-only وAGPL-3.0-or-later، ويضعها كثير من المشاريع في أول كل ملف كود، ونواة Linux تفعل ذلك في ملفاتها كلها بحسب قواعد الترخيص في النواة. والمثال التالي يقرأ السطر الأول من أحد ملفات النواة:

curl -s https://raw.githubusercontent.com/torvalds/linux/master/kernel/fork.c | head -n 1

والمخرج سوف يكون كما يلي:

// SPDX-License-Identifier: GPL-2.0-only

لاحظ الفرق بين GPL-2.0-only وGPL-2.0-or-later، فالأول يعني هذا الإصدار من الرخصة فقط، والثاني يسمح لك باختيار الإصدار 2 أو أي إصدار أحدث منه، وهذا الفرق هو سبب بقاء Linux على GPL-2.0 حتى اليوم.

وبعد ذلك توجد طرق أسهل للقراءة السريعة:

• صفحة المستودع على GitHub: يقرأ GitHub ملف الرخصة ويعرض اسمها في الجانب الأيمن من صفحة المشروع، وتشرح وثائق GitHub طريقة ذلك، ولكن إذا ظهرت كلمة Other فمعناها أن GitHub لم يتعرف على الرخصة، وعليك أن تفتح الملف بنفسك.
• موقع choosealicense.com: يشرح كل رخصة في ثلاثة أعمدة واضحة، ما تسمح به وما تشترطه وما تمنعه، وفيه جدول يقارن الرخص كلها.
• قائمة الرخص المعتمدة من OSI: إذا لم تجد الرخصة فيها، فالمشروع ليس مفتوح المصدر بالمعنى الدقيق مهما قال موقعه.

علامات تستحق الانتباه

• لا توجد رخصة إطلاقاً: كثير من المبتدئين يظنون أن الكود المنشور على GitHub دون رخصة مسموح للجميع، والعكس هو الصحيح، فبدون رخصة تطبق قوانين حقوق النشر الافتراضية ويملك الكاتب كل الحقوق، ولا يحق لك نسخه أو تعديله أو توزيعه، لذلك لا تبن على مشروع بلا رخصة، واطلب من صاحبه أن يضيف واحدة.
• اتفاقية ترخيص المساهمين Contributor License Agreement واختصاراً CLA: يطلبها بعض المشاريع قبل قبول مساهمتك، ومنها اتفاقية Redis، وهي تعطي صاحب المشروع حقوقاً واسعة على الكود الذي تساهم به، وهذه الحقوق هي التي تسمح له عادة بإصدار المشروع برخص أخرى في المستقبل، لذلك اقرأها قبل أن تساهم، واعتبرها معلومة تضعها في حسابك وليست سبباً لرفض المشروع.
• تاريخ من تغيير الرخص: راجع سجل ملف الرخصة في المستودع، فإذا غيرت الشركة رخصتها من قبل فقد تفعلها مرة أخرى، وتذكر أن التغيير لا يطبق بأثر رجعي، فالإصدارات القديمة تبقى برخصتها القديمة كما أكدت Redis، وهذا ما يسمح للمجتمع ببناء نسخة بديلة من آخر إصدار مفتوح.
• «مفتوح المصدر» في التسويق فقط: بعض المواقع تكتب Open Source في الصفحة الرئيسية والرخصة في المستودع رخصة مصدر متاح، لذلك صدق ملف الرخصة ولا تصدق الشعار.
• مشروع خلفه شركة واحدة: لا عيب في ذلك، ولكن المشروع الذي تديره مؤسسة محايدة مثل Linux Foundation أو Apache Software Foundation أقل عرضة لتغيير مفاجئ، وهذا ما قصدته Linux Foundation عندما قالت عن Valkey إنه سوف يبقى دون تغييرات مفاجئة في الرخصة.

الخلاصة

• بدأت البرمجيات الحرة بطابعة في MIT، ثم بإعلان GNU في 27 سبتمبر 1983، ومؤسسة FSF في 1985، ورخصة GPL في 1989، وكلمة Free فيها تعني الحرية وليس السعر.
• بدأ Linux «هواية» في 25 أغسطس 1991، وصار حراً بـ GPL في 1992، والنظام الذي نستخدمه مزيج من نواة Linux وأدوات GNU.
• ظهر مصطلح Open Source في فبراير 1998 بعد إعلان Netscape، وأسست OSI لتعتمد الرخص، والبرامج في الغالب نفسها، والفرق في الدافع.
• Freeware مجاني ولكنه مغلق، والمصدر المتاح Source-available يريك الكود ويمنع استخدامات معينة، والنواة المفتوحة Open Core نموذج عمل يبيع الميزات المتقدمة.
• الرخص المتساهلة MIT وBSD وApache لا تلزمك بنشر تعديلاتك، وGPL تلزمك عند التوزيع، وAGPL تلزمك أيضاً عندما يستخدم الناس نسختك المعدلة عبر الشبكة، وLGPL وMPL تطبق شرطها على المكتبة أو الملف فقط.
• تشغيل برنامج GPL أو AGPL داخل شركتك دون تعديل لا يلزمك بشيء، أما تقديمه خدمة معدلة أو إضافة مكتبة GPL إلى تطبيق مغلق توزعه فلهما شروط يجب أن تعرفها قبل البدء.
• اقرأ ملف الرخصة ومعرف SPDX قبل أن تعتمد على أي مشروع، ولا تستخدم كوداً بلا رخصة، وراقب تاريخ تغيير الرخص، وهذا المقال ليس استشارة قانونية.

وإذا أردت أن تكمل من هنا، فهذه مقالات تربط ما قرأته بقرار الاستضافة الذاتية وبسياسات المصادر المفتوحة في القطاع الحكومي:

دليللماذا الاستضافة الذاتية؟ ومتى لا تناسبكهل تستحق الاستضافة الذاتية الجهد الذي تتطلبه؟ يساعدك هذا الدليل على الحكم: متى تمنحك التحكم في بياناتك وتكاليفك، ومتى تصبح عبئاً، وكيف تحسب تكلفتها الحقيقية قبل أن تبدأ.دليلالاستضافة الذاتية (Self-Hosting): متى تصبح خياراً استراتيجياً لأعمالك؟ماذا لو ارتفعت أسعار خدمة تعتمد عليها فجأة، أو توقفت، أو فقدت بياناتك فيها؟ يشرح المقال متى تصبح الاستضافة الذاتية خياراً استراتيجياً لمؤسستك، وكيف تبدأ بها بخطوات صغيرة.دليلقواعد البرمجيات الحكومية مفتوحة المصدر في المملكة: ماذا تعني للجهات والموردين؟قراءة في قرار مجلس الوزراء رقم 14 وقواعد تنظيم البرمجيات الحكومية الحرة ومفتوحة المصدر واستراتيجيتها: ترتيب جديد لقرار الشراء، وعقود تضمن تسليم الشفرة وحقوق إعادة استخدامها، وما يعنيه ذلك للجهات والموردين والمهندسين.دليلمستقبل المصادر المفتوحة في القطاع الحكومي السعودي: من الامتثال إلى بناء القدرةالإطار التنظيمي قائم، والسؤال الأهم: هل تصبح المصادر المفتوحة ثقافة عمل وصناعة وطنية؟ رؤية لثلاثة تحولات متوقعة، والتحديات التي ستحدد النجاح، وما تحتاجه المنظومة من معرفة ومعايير ومجتمعات.

سجل التحديثات (Changelog)

• أكتوبر 2026: كتابة الدليل اعتماداً على المصادر الأصلية لمشروع GNU وFSF وOSI وkernel.org وإعلانات HashiCorp وOpenTofu وRedis وValkey وElastic، مع التحقق من ملفات الرخص في مستودعات المشاريع المذكورة.