حروب تراخيص المصادر المفتوحة: كيف غيرت HashiCorp وRedis وElastic القواعد

النمط المتكرر

ثلاثة من أكثر مشاريع البرمجيات التحتية استخدامًا في العالم غيرت تراخيصها في غضون بضع سنوات من بعضها البعض. غيرت HashiCorp ترخيص Terraform من Mozilla Public License 2.0 إلى Business Source License (BSL) في أغسطس 2023. غيرت Redis ترخيصها من BSD إلى Server Side Public License (SSPL) في مارس 2024. كانت Elastic قد نقلت بالفعل Elasticsearch وKibana إلى SSPL في عام 2021. قدمت الشركات الثلاث تفسيرات مماثلة: كان مزودو الخدمات السحابية يستخدمون برامجهم لبناء خدمات مدارة منافسة دون المساهمة مرة أخرى.

واجهت الشركات الثلاث انقسامات مجتمعية فورية. ظهر OpenTofu (Terraform) في غضون أسابيع من إعلان HashiCorp، بدعم من مؤسسة Linux. أُطلق Valkey (Redis) في مارس 2024، أيضًا تحت مظلة مؤسسة Linux، مع مساهمات من مهندسي AWS وGoogle وOracle وAlibaba. كان OpenSearch (Elasticsearch) قد أُطلق بالفعل في عام 2021، بقيادة AWS. النمط متسق بما يكفي ليشكل دليلًا إرشاديًا — لكلا الجانبين.

ما تفعله تغييرات الترخيص فعليًا

يسمح ترخيص Business Source License (BSL)، الذي طورته MariaDB واعتمدته HashiCorp، بالاستخدام المجاني لمعظم الأغراض ولكنه يحظر استخدام البرنامج في منتج تجاري منافس دون ترخيص تجاري. والأهم من ذلك، أن البرامج المرخصة بموجب BSL تتحول إلى ترخيص مفتوح المصدر (عادةً Apache 2.0) بعد أربع سنوات. حددت HashiCorp نافذة تحويل مدتها أربع سنوات: سيصبح Terraform 1.6 الذي صدر في أغسطس 2023 بموجب Apache 2.0 في أغسطس 2027.

SSPL، الذي أنشأته MongoDB، أكثر عدوانية: فهو يتطلب من أي شخص يقدم البرنامج كخدمة مدارة أن يفتح المصدر الكامل للمكدس المستخدم لتقديم تلك الخدمة — بما في ذلك التنسيق والمراقبة والبنية التحتية الداعمة. نظرًا لأنه من المستحيل عمليًا لمزود سحابة لديه بنية تحتية مملوكة الامتثال لهذا، فإن SSPL يعمل كحظر عملي على تقديم الخدمات المدارة. لا تعترف مبادرة المصادر المفتوحة (OSI) بـ SSPL كترخيص مفتوح المصدر. ولا تفعل ذلك مؤسسة البرمجيات الحرة (FSF). كل من Redis وElasticsearch بموجب SSPL هما، وفقًا للتعريفات الأكثر أهمية في الصناعة، برمجيات مملوكة تنشر كودها المصدر فقط.

HashiCorp: الاستحواذ الذي تبع ذلك

التطور الأكثر أهمية تجاريًا في هذه القصة هو ما حدث لـ HashiCorp بعد تغيير الترخيص. استحوذت IBM على HashiCorp في أبريل 2024 مقابل 6.4 مليار دولار — واحدة من أكبر عمليات الاستحواذ في برمجيات البنية التحتية للمؤسسات. تدير IBM Red Hat، المبنية بالكامل تقريبًا على برمجيات مفتوحة المصدر وهي أكبر شركة Linux للمؤسسات في العالم. يجلب استحواذ HashiCorp Terraform وVault وConsul وNomad إلى محفظة IBM جنبًا إلى جنب مع OpenShift وAnsible من Red Hat.

في هذه الأثناء، وصل انقسام OpenTofu إلى الإصدار 1.7 في مايو 2024، مطبقًا ميزات لم يشحنها Terraform بعد. يعني دعم مؤسسة Linux أن OpenTofu لديه دعم مؤسسي ومن غير المرجح أن ينهار بسبب إرهاق المشرفين — وهو مصير العديد من الانقسامات المجتمعية. أصبح OpenTofu الآن بديلًا موثوقًا طويل الأجل لـ Terraform للمؤسسات غير المريحة مع قيود BSL أو ملكية IBM.

السؤال العملي للفرق التي تستخدم Terraform حاليًا هو مباشر: إذا كنت لا تقدم Terraform كخدمة تجاريًا وليس لديك مزود سحابة، فإن BSL لا يقيدك. معظم مستخدمي المؤسسات غير متأثرين. يهم تغيير الترخيص أكثر للشركات التي ترغب في بناء خدمات Terraform مُدارة — وبالنسبة لهم، OpenTofu هو المسار الواضح.

Redis: الانقسام الأسرع

كان تغيير ترخيص Redis الأكثر دراماتيكية من حيث السرعة واتساع نطاق الاستجابة. في غضون أسبوع من إعلان مارس 2024، التزمت AWS وGoogle Cloud وOracle وAlibaba Cloud جميعًا بموارد هندسية لـ Valkey — انقسام مؤسسة Linux لـ Redis 7.2.4، آخر إصدار بموجب ترخيص BSD القديم. كان لمستودع Valkey على GitHub مساهمون في شهره الأول أكثر مما تجمعه معظم مشاريع المصادر المفتوحة في سنوات.

حافظت Redis Ltd. (الشركة، المتميزة عن مشروع Redis) على أن Redis لم يكن أبدًا "مصدرًا مفتوحًا مجتمعيًا" بنفس طريقة Linux أو PostgreSQL — لقد كانت دائمًا تحت سيطرة الشركة. هذا صحيح من الناحية الفنية: امتلكت Redis Ltd. حقوق النشر، وطلبت اتفاقية ترخيص المساهم (CLA) للمساهمات، واتخذت جميع القرارات المعمارية الرئيسية. كان ترخيص BSD خيارًا تجاريًا، وليس مبدأً تأسيسيًا. عندما تغيرت الحسابات التجارية — وتحديدًا، عندما نمت AWS ElastiCache وخدمات Redis المُدارة الأخرى بما يكفي لتقليل السوق القابلة للتوجيه لـ Redis Ltd. بشكل ملحوظ — تغير الترخيص.

أصبح Valkey 7.2 الآن العرض الافتراضي المتوافق مع Redis على العديد من منصات السحابة الرئيسية. بالنسبة للمشاريع الجديدة التي تبدأ اليوم، الاختيار العملي هو بين Valkey (مؤسسة Linux، Apache 2.0، دعم سحابي أصلي) وRedis 7.4+ (SSPL، Redis Ltd.، ترخيص تجاري للخدمات المُدارة). كلاهما ناضج، وكلاهما عالي الأداء، وواجهة برمجة التطبيقات (API) متطابقة تقريبًا. النظام البيئي ينقسم.

Elastic: الحالة الأقدم التي تبدو الآن كالنموذج

كان تغيير ترخيص Elastic لعام 2021 هو الأقدم وهو إلى حد ما الحالة الأوضح. نقلت Elastic Elasticsearch وKibana إلى SSPL كرد مباشر على تقديم Amazon لخدمة Elasticsearch مُدارة — Amazon Elasticsearch Service — دون مساهمات جوهرية مرة أخرى إلى المشروع. كان رد Amazon هو انقسام Elasticsearch 7.10 (آخر إصدار Apache 2.0) وإنشاء OpenSearch، الذي تديره الآن وساهمت به في مؤسسة Linux.

بعد أربع سنوات، تباعد OpenSearch بشكل ملحوظ عن Elasticsearch. تشحن AWS ميزات في OpenSearch ليس لها مثيل في Elastic، وشحنت Elastic ميزات في Elasticsearch غير موجودة في OpenSearch. الاثنان لم يعودا متوافقين تمامًا لحالات الاستخدام المتقدمة. الفرق التي تختار بينهما اليوم تختار فعليًا بين منتجين مختلفين يشتركان في سلف مشترك، وليس بين "الشيء الحقيقي" و"انقسام".

نموذج النواة المفتوحة وحدوده

الشركات التي تجنبت هذا الديناميكي بنجاح هي تلك التي بنت نماذج نواة مفتوحة من البداية بدلاً من الاعتماد على تراخيص متساهلة لمنتجات شائعة كانت تأمل في تحقيق الدخل منها لاحقًا. GitLab وGrafana وVault الخاص بـ HashiCorp هي أمثلة حيث المنتج الأساسي مفتوح المصدر ولكن ميزات المؤسسات الكبيرة (SSO، تسجيل التدقيق، RBAC المتقدم، أدوات الامتثال) هي تجارية فقط. هذا يخلق قيمة واضحة دون تقييد الاستخدام المجتمعي الذي يدفع نحو التبني.

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

بالنسبة للمطورين وفرق البنية التحتية، الخلاصة العملية هي: تعامل مع أي مشروع مفتوح المصدر يسيطر عليه شركة واحدة مع شرط CLA على أنه قد يكون مملوكًا. الترخيص الذي تراه اليوم قد لا يكون الترخيص الذي يحكم البرنامج في غضون ثلاث سنوات. البرمجيات مفتوحة المصدر الأكثر أمانًا، من منظور مخاطر الترخيص، هي المملوكة لمؤسسة (مؤسسة Linux، مؤسسة Apache للبرمجيات، CNCF) أو لديها حوكمة موزعة حقيقية بدلاً من سيطرة شركة واحدة.

ماذا بعد

حروب التراخيص لم تنته بعد. العديد من مشاريع البنية التحتية الأخرى المستخدمة على نطاق واسع — التي تديرها شركات ممولة جيدًا مع منافسة من مزودي السحابة — تواجه ديناميكيات مماثلة. شاهدت الشركات ما حدث لـ HashiCorp وRedis وElastic وتتخذ قرارات الترخيص وفقًا لذلك.

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