‫BSL و‫SSPL: مخاطر تراخيص المصدر المتاح

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

حتى الاستخدام الداخلي البحت قد يكون معنياً إذا كانت مؤسستك تُفوتر خدمات لأطراف خارجية أو تعرض الأداة عبر واجهة برمجية خارجية. والحدّ الفاصل بين «الاستخدام الداخلي» و«الخدمة المكشوفة» هو بالضبط ما تختلف فيه ‫SSPL عن ‫BSL.

منذ عام 2021، طالت أربع موجات من إعادة الترخيص مكوّنات حاضرة في آلاف البنى التحتية الإنتاجية: ‫Elasticsearch (يناير 2021 ← ‫SSPL)، ‫Redis (مارس 2024 ← ‫RSALv2+SSPL، ثم مايو 2025 ← ‫AGPLv3 متاحة)، ‫Terraform (أغسطس 2023 ← ‫BSL)، ‫MariaDB MaxScale (يناير 2025 ← مغلق بالكامل).

فهم السياق وراء كل قرار يُعين على توقّع ما قد يأتي بعده. إليك التسلسل الذي أعاد تشكيل النظام البيئي للبنية التحتية مفتوحة المصدر:

يناير 2021 — ‫Elasticsearch و‫Kibana (‫Elastic). تنتقل ‫Elastic من ‫Apache 2‎.0 إلى ‫SSPL / ‫Elastic License 2‎.0 بدءاً من الإصدار 7‎.11. ردّت ‫AWS بتفريع ‫Elasticsearch 7‎.10‎.2 (آخر إصدار بترخيص ‫Apache 2‎.0) وأطلقت ‫OpenSearch في أبريل 2021 بترخيص ‫Apache 2‎.0، ثم نقلته إلى مؤسسة ‫Linux Foundation في سبتمبر 2024. في أغسطس 2024، أضافت ‫Elastic خيار ‫AGPLv3 — لتعود ‫Elasticsearch مفتوحة المصدر بمفهوم ‫OSI.

أكتوبر 2018 / مارس 2024 — ‫MongoDB و‫Redis (‫SSPL). كانت ‫MongoDB أول مَن تبنّى ‫SSPL عام 2018، وهو السابقة التي اقتدت بها ‫Redis في 20 مارس 2024 بالانتقال من ‫BSD-3-Clause إلى ‫RSALv2+SSPL بدءاً من الإصدار 7‎.4. أطلقت ‫Linux Foundation ‫Valkey في 28 مارس 2024 — بعد أربعة أيام من إعلان ‫Redis — كتفريع من ‫Redis 7‎.2‎.4 بترخيص ‫BSD-3-Clause، واعتمدته ‫Ubuntu 24‎.04 (الصادر في أبريل 2024) حزمةً افتراضية. في مايو 2025، أضافت ‫Redis خيار ‫AGPLv3 بتأثير من مبدعها الأصلي ‫Salvatore Sanfilippo (‫antirez) الذي عاد إلى ‫Redis Inc. في نوفمبر 2024.

أغسطس 2023 — ‫Terraform و‫HashiCorp (‫BSL). في 10 أغسطس 2023 حوّلت ‫HashiCorp ‫Terraform من ‫MPL-2‎.0 إلى ‫BSL 1‎.1 بدءاً من الإصدار 1‎.6. ظهر بيان ‫OpenTF في 15 أغسطس وجمع 32‎000 نجمة على ‫GitHub في عشرة أيام، وقبلت ‫Linux Foundation مشروع ‫OpenTofu في 20 سبتمبر 2023. صدر ‫OpenTofu 1‎.6‎.0 في يناير 2024 بترخيص ‫MPL-2‎.0.

يناير 2025 — ‫MariaDB MaxScale (مغلق بالكامل). تجاوزت ‫MariaDB حدود ‫BSL: ‫MaxScale 25‎.01 يصدر بترخيص تجاري مغلق بالكامل يشترط اشتراكاً نشطاً. الإصدارات السابقة (24‎.02، 23‎.08) تظل تحت ‫BSL وستتحوّل إلى ‫GPL وفق بند التحويل الزمني.

‫BSL (رخصة المصدر التجاري) ترخيص مؤقت: الشيفرة متاحة المصدر اليوم وستصبح مفتوحة المصدر — في الغالب ‫Apache 2‎.0 أو ‫GPL — بعد مهلة محددة (أربع سنوات لدى ‫HashiCorp). بند التقييد يستهدف «الاستخدام الإضافي المُجاز» الذي تحدّده الجهة الناشرة: في ‫HashiCorp، هو تقديم خدمة مُدارة منافسة. الاستخدام الداخلي، حتى التجاري منه، حرّ.

‫SSPL (رخصة الخادم العام من جانب الخادم) تذهب أبعد: كشف الأداة كخدمة لأطراف خارجية يُفعّل التزام نشر البنية البرمجية الكاملة — برامج الإدارة، والواجهات، والأدوات التشغيلية. تنشر ‫MongoDB أسئلة شائعة توضّح أن الالتزام لا يتفعّل إلا عند تقديم ‫MongoDB «كخدمة»؛ استخدامها قاعدةً لتطبيقك الخاص لا يُفعّله. لا تعترف ‫OSI بـ‫SSPL ترخيصاً مفتوح المصدر.

‫AGPLv3، الوحيدة من الثلاثة المعتمدة من ‫OSI، هي حقوق نشر شبكية مُعدية: لا تحظر الاستخدام التجاري، لكنها تُلزم بفتح شيفرة أي تطبيق يضمّ مكوّناً بـ‫AGPLv3 متى خدم مستخدمين عبر الشبكة. للمستضيف الذاتي الذي لا يوزّع تطبيقه، القيد شبه معدوم؛ لناشر ‫SaaS يدمج مكتبة ‫AGPLv3 في منتج مغلق، القيد وجودي.

تراخيص ‫BSD / ‫MIT / ‫Apache 2‎.0 تبقى خالية من أي التزام بالنشر في جميع حالات الاستخدام. لهذا تختار التفريعات المجتمعية (‫Valkey، ‫OpenTofu، ‫OpenSearch) ‫BSD-3-Clause أو ‫Apache 2‎.0.

‫Redis ← ‫Valkey أو ‫Redis 8 بترخيص ‫AGPLv3.
‫Redis 7‎.2‎.x (‫BSD-3-Clause) يبقى قابلاً للاستخدام بحرية. من ‫Redis 7‎.4 فصاعداً أنت تحت ‫RSALv2+SSPL: إن كان استخدامك داخلياً فلا التزام فوري، لكنك لا تستطيع إعادة توزيعه بترخيص ‫BSD. الخيار العملي: الانتقال إلى ‫Valkey (تفريع ‫BSD متوافق ‫API مع ‫Redis 7‎.2، الحزمة الافتراضية على ‫Ubuntu 24‎.04 و‫Debian 13، مُصان من قِبل ‫AWS و‫Google و‫Oracle)، أو اختيار نسخة ‫AGPLv3 من ‫Redis 8 (متاحة منذ مايو 2025). الانتقال إلى ‫Valkey غير مُتلف: بروتوكول ‫RESP والأوامر متطابقة، وعملاء ‫Redis الحاليون (‫redis-py، ‫ioredis، ‫Jedis) يعملون دون تعديل.

‫Elasticsearch ← ‫OpenSearch أو ‫Elasticsearch AGPLv3.
‫OpenSearch 1‎.0 (تفريع ‫Elasticsearch 7‎.10‎.2، ‫Apache 2‎.0) في الإنتاج منذ يوليو 2021. إن بقيت على ‫Elasticsearch 7‎.x دون ترحيل، فأنت على إصدار بلا تصحيحات أمنية منذ منتصف 2023. نسخة ‫AGPLv3 من ‫Elasticsearch 8‎.x (منذ أغسطس 2024) هي الخيار الأنظف للمستضيف الداخلي.

‫Terraform ← ‫OpenTofu.
‫OpenTofu 1‎.6+ هو الاستمرارية المباشرة لـ‫Terraform 1‎.5 بترخيص ‫MPL-2‎.0. صياغة ‫HCL متطابقة، والمزوّدون (‫providers) متوافقون.

‫MongoDB ← الاستخدام الداخلي حرّ، الخدمة المُدارة تستوجب التحقق.
للمستضيف الذاتي الذي يستخدم ‫MongoDB قاعدةً لتطبيق داخلي، لا يتفعّل قيد ‫SSPL. إن كنت تعتزم تقديم «‫MongoDB كخدمة» لأطراف أخرى، إما تفتح بنيتك الكاملة أو تأخذ رخصة ‫MongoDB Enterprise التجارية.

‫MariaDB MaxScale 25‎.01 ← الإصدار 24‎.02 BSL أو بديل.
‫MaxScale 24‎.02 يبقى تحت ‫BSL وسيتحوّل إلى ‫GPL. ‫ProxySQL (‫GPL-2‎.0) و‫HAProxy مع وحدة ‫MySQL بديلان راسخان لتوجيه حركة مرور ‫MySQL/MariaDB.

قبل الاختيار بين الأداة الأصلية وتفريعها، اطرح ثلاثة أسئلة بالترتيب:

1. ما استخدامك الفعلي؟ داخلي بحت (لا طرف خارجي يستهلك الخدمة) ← ‫BSL و‫SSPL لا يُفرزان التزامات فورية، لكنك تتنازل عن حرية إعادة التوزيع. خدمة مكشوفة لشركاء أو عملاء ← تحقق إن كانت حالتك تقع تحت تعريف «الخدمة المنافسة» (‫BSL) أو «تقديم الخدمة لأطراف خارجية» (‫SSPL).

2. هل ثمة تفريع مُصان بنشاط؟ لـ‫Terraform ← ‫OpenTofu (‫Linux Foundation). لـ‫Redis ← ‫Valkey (‫Linux Foundation، ‫AWS + ‫Google + ‫Oracle). لـ‫Elasticsearch ← ‫OpenSearch (‫Linux Foundation منذ سبتمبر 2024).

3. هل التفريع متوافق ‫API؟ ‫Valkey و‫Redis 7‎.2: توافق 100‎% (بروتوكول ‫RESP، نفس الأوامر). ‫OpenTofu و‫Terraform 1‎.5: ‫HCL متطابق، مزوّدون متطابقون. ‫OpenSearch و‫Elasticsearch 7‎.10: متوافق لمعظم استعلامات ‫DSL، لكن إضافات ‫Elasticsearch 8‎.x غير قابلة للنقل.

إن وُجد تفريع مُصان، متوافق ‫API، يُصدر تصحيحات أمنية بانتظام: انتقل إليه. تكلفة الترحيل الاحترازي قابلة للقياس؛ تكلفة الامتثال تحت الضغط — خاصةً إن فُعّل بند ‫SSPL بتغيّر في الاستخدام — ليست كذلك.

تحقق من الترخيص قبل إضافة أي تبعية. الترخيص يُقرأ من ملف LICENSE في جذر المستودع ومن سجل تغييرات الإصدارات الرئيسية الأخيرة. أداة كانت تحت ‫MIT قبل عامين قد تكون اليوم تحت ‫BSL — تحديث docker-compose.yml لن يُنبّهك بذلك.

اشترك في إشعارات إصدارات ‫GitHub. زر «‫Watch → Custom → Releases» على مستودع أي مكوّن حيوي يُرسل إليك بريداً إلكترونياً لكل إصدار جديد. إنه القناة الوحيدة التي تضمن رؤية تغيير الترخيص قبل تضمينه في apt upgrade أو helm upgrade القادم.

ميّز حالتك الفعلية عمّا يستهدفه الترخيص. استهدفت ‫BSL الخاصة بـ‫HashiCorp كلاً من ‫AWS و‫Azure و‫Google — لا الفِرَق التي تُؤتمت بنيتها الخاصة. استهدفت ‫SSPL الخاصة بـ‫MongoDB مزوّدي الخدمات السحابية — لا المطوّرين الذين يستخدمون ‫MongoDB قاعدةً لمنتج ‫SaaS. قراءة الأسئلة الشائعة الرسمية لكل ترخيص تُجنّبك قرارات محافظة لا لزوم لها.

قيّم التفريع مسبقاً لا تحت الضغط. ‫Valkey و‫OpenTofu و‫OpenSearch موجودة تحديداً لتتمكن الفِرَق من الانتقال دون استعجال. اختبار التوافق في بيئة التطوير يستغرق ساعات قليلة؛ أما الترحيل في الإنتاج خلال أسبوع إثر إعلان إعادة ترخيص فشأن آخر.

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