تقريبا. العابرة. : سمحت المرونة والحريات التي توفرها تراخيص المصادر المفتوحة لمقدمي الخدمات الحديثة لحلول SaaS بالتشكيك في نجاح الشركات الصغيرة التي تقف وراء تطوير مشاريع مفتوحة المصدر. في هذه المقالة ، من مؤلفي CockroachDB - RDBMS الموزعة والمتسامحة مع الخطأ - يتم الكشف عن جوهر المشكلة والطريقة الممكنة لحلها.
تم تصميم CockroachDB كبرنامج مفتوح المصدر. في السنوات التي انقضت منذ ظهور المشروع على GitHub
(تم نشر الكود لأول مرة في فبراير 2014 - تقريبًا. الترجمة ) ، اتبعنا مسارًا نمطيًا نسبيًا للتطور ، حيث حقق التوازن بين فلسفة المصدر المفتوح وخلق نشاط تجاري قابل للتطبيق. تم ترخيص الرمز الرئيسي بموجب ترخيص Apache 2 (APL) ، وتم إطلاق خدمة مُدارة ، وتم إصدار بعض الإضافات للشركات بموجب ترخيص مؤسسة.
لكن أفكارنا السابقة حول
نموذج العمل الصحيح كانت تستند إلى المعيار الرئيسي لعالم OSS: يمكنك بناء عمل تجاري حول منتج قوي مفتوح المصدر دون افتراض أن شركة تكنولوجيا أكبر ستقدم نفس المنتج كخدمة. هذه القاعدة لم تعد صالحة.
من حيث المبدأ ، من الناحية القانونية ، لم يمنع أي شيء المنافسين من تقديم منتج OSS كخدمة تم إنشاؤه بواسطة شركة أخرى. والآن نرى أن هذا يحدث بالفعل. نشهد اليوم زيادة في عدد مقدمي الخدمات المتكاملة للغاية الذين يستفيدون من موقعهم الفريد ويقدمون إصدارات خدمة من منتجات OSS كخدمة. من الواضح أن تكاملها العالي يعزز بشكل كبير تجربة المستخدم. حدث هذا مؤخرًا مع شوكة تطبيق "البحث المرن" الذي "استعاره" من أمازون (وصف ساليل ديشباندي في
مقالة تشكرونش بمهارة ما حدث بأنه "خدمة ذاتية وعقلانية").
استجابة لمثل هذه المنافسة غير العادلة ، نقوم بتغيير شروط ترخيصنا. ترد التفاصيل أدناه على
جيثب . التغييرات الموجزة هي كما يلي:
بدءًا من اليوم ، نعرض نسخة متساهلة حصريًا من Business Source License (BSL). يمكن لمستخدمي CockroachDB توسيع نطاق قواعد بياناتنا إلى أي عدد من العقد. إنهم أحرار في استخدام CockroachDB ودمجها في تطبيقاتهم (بغض النظر عما إذا كانوا يقومون بتسليمها للمستهلكين أو تقديمها كخدمة). يمكنك أيضًا تشغيل CockroachDB كخدمة لتحقيق الأهداف الداخلية لشركتك. الشيء الوحيد الذي لا يمكنك فعله هو تقديم الإصدار التجاري من CockroachDB كخدمة دون شراء الترخيص المناسب .
لضمان المزيد من التطوير للمشروع ، فإن قيودنا لها مهلة زمنية محددة: بعد مرور ثلاث سنوات على الإصدار ، يتحول الترخيص إلى ترخيص Apache 2.0 قياسي. من خلال تغيير شروط الترخيص وإدخال حد زمني ، لدينا هدفان:
- إنشاء قاعدة بيانات تنافسية كخدمة (DbaaS)
- على طول الطريق ، تأكد من أن المنتج الرئيسي لا يزال مفتوحًا بالكامل.
مقارنة بين مختلف مناهج الترخيص مفتوحة المصدر
لقد قامت بعض الشركات بترخيص منتجاتها بالفعل لغرض مزدوج مماثل. بتقييم الأساليب الحالية ، وجدنا أنها تميل جميعًا إلى طريقتين رئيسيتين: الحقوق المتروكة والنموذج متعدد المستويات. لسوء الحظ ، لم يتوافق أي منهم مع ما نود تحقيقه عن طريق تغيير الترخيص.
نموذج الحقوق المتروكة
مؤسس تقليد الحقوق المتروكة هو GNU GPL. الغرض منه هو منع ظهور الشوكات الاحتكارية ، وفي بعض الحالات تتطلب إصدار التعليمات البرمجية المصدر. يقع Affero General Public License (AGPL) والشهادة العامة من جانب الخادم (SSPL) في هذا المخيم. في SSPL يتم إيلاء اهتمام خاص لمشكلة الخدمات المنافسة.
ومع ذلك ، نعتقد أن كل هذه التراخيص لا لزوم لها وغير كافية. فهي زائدة عن الحاجة بمعنى أن التفاصيل معقدة ، ومتطلبات الحقوق المتروكة ليست واضحة دائمًا. يتم تخويف العديد من المستخدمين المحتملين بسبب متطلبات الكشف عن الكود التي يحتمل أن تكون واسعة جدًا. فهي غير كافية بمعنى أن المنافسين جاهزون ويمكنهم الكشف عن الكود الخاص بهم بشكل كافٍ حتى لا يكون لديهم أي أسئلة ، بينما لا يحققون أي فائدة لمطوري التكنولوجيا الأساسية. فعلت أمازون هذا مع
Open Distro for Elasticsearch ، على الرغم من أن رخصة الحقوق المتروكة لم تتطلب ذلك.
كنا بحاجة إلى شيء أكثر بساطة وأكثر صلابة.
نموذج الطبقات
نظرنا أيضًا في إمكانية استخدام نموذج من ثلاثة مستويات: المكون الأساسي مفتوح المصدر ، ومكونات المؤسسة ، ومستوى متوسط معين مع وظائف يكون كود مصدرها مغلقًا ، ولكن يمكن استخدامها مجانًا تمامًا. هذا النموذج يحظى بشعبية كبيرة في عالم البرمجيات ؛ ومع بعض الاختلافات استخدمناها حتى يومنا هذا.
ومع ذلك ، فإنه يولد رسالة خاطئة لشركتنا. اتضح أنه من غير المربح بالنسبة لنا تنفيذ وظائف جديدة في لب مفتوح ومن المنطقي تركيز كل الجهود على المكونات المغلقة. في الواقع ، نحن نميل إلى خداع ثقة مستخدمينا وإخفاء الميزات الأكثر إثارة للحصول على ترخيص جماعي. على المدى الطويل ، لا يبشر هذا النهج جيدًا بالنظام البيئي مفتوح المصدر.
الحل الموجود: BSL
بدأنا في دراسة التراخيص المحدودة المدة ووجدنا أنه لا توجد حاجة لإنشاء ترخيص جديد من البداية. يحتوي الإصدار 1.1 من MariaDB's Business Source License (BSL) على كل ما تحتاجه
وتمت الموافقة عليه بالفعل
من قبل مؤسس OSI Bruce Perens. BSL عبارة عن ترخيص ذو
معلمات ، لذلك نستخدمه بشكل مختلف عن MariaDB.
الفرق الرئيسي هو منحة الاستخدام الإضافي - على سبيل المثال ، يسمح MariaDB باستخدام MaxScale
على ما يصل إلى ثلاثة خوادم .
استخدام إضافي منح Grant في CockroachDB يسمح لك باستخدام منتجاتنا على أي عدد من العقد ، شريطة أن لا تقدمه ك DbaaS التجارية. لمدة ثلاث سنوات ، يحمي إصدار BSL الخاص بنا رمز CockroachDB الحالي من الاستخدام كدالة DBaaS دون الحصول على ترخيص وحدة تخزين مناسب. بعد 3 سنوات ، تتم إزالة هذا التقييد ويصبح الرمز مفتوحًا (بمعنى أنه مضمن في ترخيص Apache) ويمكن استخدامه بحرية لأي غرض.
نحن نطبق هذا الترخيص على الإصدار الأساسي من CockroachDB (أي ، على الكود الذي كان يقع سابقًا تحت Apache 2.0). هذا يعني أن جوهر CockroachDB لم يعد مفتوحًا (وفقًا
للتعريف المفتوح المصدر لـ OSI) ، على الرغم من أن الكود الكامل ما زال متاحًا وأي استخدام تجاري مسموح به باستثناء DBaaS. نعتقد أن هذه هي أفضل طريقة لموازنة احتياجات العمل مع التزامنا بالمصدر المفتوح. يسمح الترخيص الجديد للغالبية العظمى من المستخدمين باستخدام رمز CockroachDB وتوزيعه وتعديله بحرية (وبعد ثلاث سنوات يصبح مفتوحًا دون قيد أو شرط).
ما هو: كيف يعمل BSL
نحن نقدم ترخيص CockroachDB جديد يبدأ بالإصدار 19.2. الآن لا يمكن استخدام الرمز لتنظيم قاعدة بيانات تجارية كخدمة (DBaaS) دون الدخول في اتفاقية مناسبة مع Cockroach Labs. ينطبق حد ثلاث سنوات على كل إصدار.
ستستمر إضافات CockroachDB Corporate بموجب رخصة مجتمع Cockroach (CCL). يتطلب العمل معهم اتفاقية ترخيص مناسبة مع Cockroach Labs ؛ لن يتم تحويل هذا الترخيص إلى Open Source بعد ثلاث سنوات.
دعونا شرح مع مثال محدد. سيكون CockroachDB 19.2 (المقرر إجراؤه في أكتوبر 2019) الإصدار الأول للالتزام بمخطط الترخيص الجديد. وسوف تشمل رمز تحت كل من BSL و CCL. في أكتوبر 2022 (بعد ثلاث سنوات من الإصدار) ، سيتم تحويل جزء CockroachDB 19.2 ، الذي يندرج تحت BSL ، إلى APL. لا تغير التصحيحات تاريخ التحويل: سيتم تحويل جميع إصدارات 19.2.x في أكتوبر 2022 ، على الرغم من أنه في ذلك الوقت سيتم تنفيذ الإصدار الأساسي 19.2.0 فقط لمدة ثلاث سنوات. سيتم فتح CockroachDB 20.1 (المقرر عقده في أبريل 2020) في أبريل 2023 ، وهكذا.
لن تتأثر الإصدارات القديمة: ستواصل CockroachDB 19.1 العمل بموجب ترخيص Apache ، وسيتم أيضًا إصدار جميع التصحيحات المستقبلية 19.1.x بموجب APL.
نحن ملتزمون بمثل المصدر المفتوح ونسعى جاهدين لإنشاء منتج قوي مفتوح المصدر. على الرغم من أن BSL رسميًا ليست رخصة مفتوحة المصدر ، إلا أن هذا الحل الوسط هو الأقرب إلى روح المصدر المفتوح ، ولكنه في الوقت نفسه يحمي أعمالنا. بالإضافة إلى ذلك ، بعد مرور ثلاث سنوات على الإصدار ، يتم تأكيد التزامنا بفلسفة البرامج مفتوحة المصدر تلقائيًا. نعتقد أن المسار المختار سوف يسمح لنا بدعم الشركة ، مع الحفاظ على التراث الغني للمصدر المفتوح في هذا الواقع الجديد.
PS من المترجم
اقرأ أيضًا في مدونتنا: