جنگ‌های مجوز متن‌باز: چگونه HashiCorp، Redis و Elastic قوانین را تغییر دادند

اشتراک‌گذاری:
جنگ‌های مجوز متن‌باز: چگونه HashiCorp، Redis و Elastic قوانین را تغییر دادند

الگویی که تکرار می‌شود

سه تا از پرکاربردترین پروژه‌های نرم‌افزار زیرساخت در جهان، ظرف چند سال مجوزهای خود را تغییر دادند. HashiCorp در آگوست ۲۰۲۳ مجوز Terraform را از Mozilla Public License 2.0 به Business Source License (BSL) تغییر داد. Redis در مارس ۲۰۲۴ از BSD به Server Side Public License (SSPL) تغییر مسیر داد. Elastic قبلاً در سال ۲۰۲۱ Elasticsearch و Kibana را به SSPL منتقل کرده بود. هر سه شرکت توضیحات مشابهی دادند: ارائه‌دهندگان ابر از نرم‌افزار آنها برای ساخت سرویس‌های مدیریت‌شده رقابتی بدون مشارکت متقابل استفاده می‌کردند.

هر سه بلافاصله با فورک‌های جامعه مواجه شدند. OpenTofu (Terraform) ظرف هفته‌ها پس از اعلام HashiCorp ظاهر شد و توسط Linux Foundation پشتیبانی می‌شد. Valkey (Redis) در مارس ۲۰۲۴ راه‌اندازی شد، همچنین تحت Linux Foundation، با commitهایی از مهندسان AWS، Google، Oracle و Alibaba. OpenSearch (Elasticsearch) قبلاً در سال ۲۰۲۱ راه‌اندازی شده بود، به رهبری AWS. الگو به اندازه کافی ثابت است که یک کتاب بازی برای هر دو طرف تشکیل دهد.

تغییرات مجوز واقعاً چه می‌کنند

Business Source License (BSL)، که توسط MariaDB توسعه یافته و توسط HashiCorp اتخاذ شده، استفاده رایگان برای بیشتر اهداف را مجاز می‌کند اما استفاده از نرم‌افزار در یک محصول تجاری رقابتی بدون مجوز تجاری را ممنوع می‌کند. نکته مهم این است که نرم‌افزار دارای مجوز BSL پس از چهار سال به یک مجوز متن‌باز (معمولاً Apache 2.0) تبدیل می‌شود. HashiCorp یک پنجره تبدیل چهار ساله تعیین کرد: Terraform 1.6 که در آگوست ۲۰۲۳ منتشر شد، در آگوست ۲۰۲۷ به Apache 2.0 تبدیل می‌شود.

SSPL، که توسط MongoDB ایجاد شده، تهاجمی‌تر است: این مجوز نیاز دارد که هر کسی که نرم‌افزار را به عنوان یک سرویس مدیریت‌شده ارائه می‌دهد، باید کل پشته مورد استفاده برای ارائه آن سرویس را متن‌باز کند - از جمله orchestration، monitoring و زیرساخت پشتیبانی. از آنجایی که رعایت این امر برای یک ارائه‌دهنده ابر با زیرساخت اختصاصی اساساً غیرممکن است، SSPL به عنوان یک ممنوعیت عملی برای ارائه سرویس‌های مدیریت‌شده عمل می‌کند. Open Source Initiative SSPL را به عنوان یک مجوز متن‌باز به رسمیت نمی‌شناسد. Free Software Foundation نیز همینطور. هر دو Redis و Elasticsearch تحت SSPL، طبق تعاریفی که در صنعت بیشترین اهمیت را دارند، نرم‌افزار اختصاصی هستند که اتفاقاً کد منبع خود را منتشر می‌کنند.

HashiCorp: اکتسابی که دنبال شد

مهمترین توسعه تجاری در این داستان، اتفاقی است که پس از تغییر مجوز برای HashiCorp افتاد. IBM در آوریل ۲۰۲۴ HashiCorp را به قیمت ۶.۴ میلیارد دلار خریداری کرد - یکی از بزرگترین خریدهای نرم‌افزار زیرساخت سازمانی. IBM مالک Red Hat است که تقریباً به طور کامل بر روی نرم‌افزار متن‌باز ساخته شده و بزرگترین شرکت لینوکس سازمانی جهان است. خرید HashiCorp Terraform، Vault، Consul و Nomad را به همراه OpenShift و Ansible Red Hat به پورتفولیوی IBM می‌آورد.

فورک OpenTofu، در همین حال، در می ۲۰۲۴ به نسخه ۱.۷ رسید و ویژگی‌هایی را پیاده‌سازی کرد که Terraform هنوز ارائه نکرده بود. پشتیبانی Linux Foundation به این معنی است که OpenTofu پشتیبانی نهادی دارد و بعید است که از فرسودگی نگه‌دارنده فرو بریزد - سرنوشت بسیاری از فورک‌های جامعه. OpenTofu اکنون یک جایگزین بلندمدت معتبر برای Terraform برای سازمان‌هایی است که از محدودیت‌های BSL یا مالکیت IBM ناراحت هستند.

سؤال عملی برای تیم‌هایی که در حال حاضر از Terraform استفاده می‌کنند، ساده است: اگر شما Terraform را به عنوان یک سرویس به صورت تجاری ارائه نمی‌دهید و در یک ارائه‌دهنده ابر نیستید، BSL شما را محدود نمی‌کند. اکثر کاربران سازمانی تحت تأثیر قرار نمی‌گیرند. تغییر مجوز بیشتر برای شرکت‌هایی اهمیت دارد که می‌خواهند سرویس‌های مدیریت‌شده Terraform بسازند - و برای آنها، OpenTofu مسیر واضح است.

Redis: فورکی که سریع‌ترین حرکت را داشت

تغییر مجوز Redis از نظر سرعت و گستردگی پاسخ، چشمگیرترین بود. ظرف یک هفته از اعلام مارس ۲۰۲۴، AWS، Google Cloud، Oracle و Alibaba Cloud همه منابع مهندسی را به Valkey اختصاص دادند - یک فورک Linux Foundation از Redis 7.2.4، آخرین نسخه تحت مجوز قدیمی BSD. مخزن GitHub Valkey در ماه اول خود مشارکت‌کنندگان بیشتری نسبت به اکثر پروژه‌های متن‌باز در طول سال‌ها داشت.

Redis Ltd. (شرکت، متمایز از پروژه Redis) ادعا کرده است که Redis هرگز واقعاً "متن‌باز جامعه" به همان روشی که لینوکس یا PostgreSQL بود، نبوده است - همیشه توسط شرکت کنترل می‌شده است. این از نظر فنی درست است: Redis Ltd. حق چاپ را در اختیار داشت، برای مشارکت‌ها نیاز به CLA داشت و تمام تصمیمات معماری اصلی را می‌گرفت. مجوز BSD یک انتخاب تجاری بود، نه یک اصل بنیادین. وقتی محاسبات تجاری تغییر کرد - به طور خاص، زمانی که AWS ElastiCache و سایر سرویس‌های مدیریت‌شده Redis به اندازه کافی بزرگ شدند تا بازار قابل دسترس Redis Ltd. را به طور معناداری کاهش دهند - مجوز تغییر کرد.

Valkey 7.2 اکنون پیش‌فرض سازگار با Redis در چندین پلتفرم ابری بزرگ است. برای پروژه‌های جدیدی که امروز شروع می‌شوند، انتخاب عملی بین Valkey (Linux Foundation، Apache 2.0، پشتیبانی ابری-بومی) و Redis 7.4+ (SSPL، Redis Ltd.، مجوز تجاری برای سرویس‌های مدیریت‌شده) است. هر دو بالغ هستند، هر دو عملکرد خوبی دارند و API تقریباً یکسان است. اکوسیستم در حال تقسیم شدن است.

Elastic: مورد قدیمی‌تر که اکنون شبیه الگو است

تغییر مجوز Elastic در سال ۲۰۲۱ اولین و از برخی جهات واضح‌ترین مورد بود. Elastic Elasticsearch و Kibana را به SSPL منتقل کرد در پاسخ مستقیم به آمازون که یک سرویس مدیریت‌شده Elasticsearch - Amazon Elasticsearch Service - را بدون مشارکت قابل توجه در پروژه ارائه می‌داد. پاسخ آمازون فورک Elasticsearch 7.10 (آخرین نسخه Apache 2.0) و ایجاد OpenSearch بود که اکنون آن را نگهداری می‌کند و به Linux Foundation کمک کرده است.

چهار سال بعد، OpenSearch به طور معناداری از Elasticsearch فاصله گرفته است. AWS ویژگی‌هایی را در OpenSearch ارائه می‌دهد که معادل Elastic ندارند، و Elastic ویژگی‌هایی را در Elasticsearch ارائه کرده است که در OpenSearch نیستند. این دو دیگر برای موارد استفاده پیشرفته به صورت drop-in سازگار نیستند. تیم‌هایی که امروز بین آنها انتخاب می‌کنند، عملاً بین دو محصول مختلف که یک جد مشترک دارند انتخاب می‌کنند، نه بین "چیز واقعی" و "یک فورک".

مدل هسته باز و محدودیت‌های آن

شرکت‌هایی که با موفقیت از این پویایی اجتناب کرده‌اند، آنهایی هستند که از ابتدا مدل‌های هسته باز را ساخته‌اند، به جای تکیه بر مجوزهای مجاز برای محصولات محبوبی که امیدوار بودند بعداً از آنها کسب درآمد کنند. GitLab، Grafana و Vault خود HashiCorp نمونه‌هایی هستند که در آنها محصول اصلی متن‌باز است اما ویژگی‌های سازمانی قابل توجه (SSO، ثبت‌نام حسابرسی، RBAC پیشرفته، ابزارهای انطباق) فقط تجاری هستند. این یک جذب ارزش واضح بدون محدود کردن استفاده جامعه که باعث پذیرش می‌شود، ایجاد می‌کند.

مسیر تغییر مجوز - انتشار تحت یک مجوز مجاز، ایجاد پذیرش عظیم، سپس تغییر به یک مجوز محدودتر زمانی که یک ارائه‌دهنده ابر در حال رقابت است - به طور فزاینده‌ای به عنوان یک درب یک‌طرفه دیده می‌شود. زمانی که یک فورک جامعه وجود دارد و پشتیبانی نهادی دارد، پروژه اصلی حسن نیت جامعه را که مجوز مجاز ایجاد می‌کرد، از دست داده است. این شرکت با کسب‌وکار تجاری باقی می‌ماند، اما بدون موقعیت "پروژه متن‌بازی که همه استفاده می‌کنند" که آن را هدایت می‌کرد.

برای توسعه‌دهندگان و تیم‌های زیرساخت، نکته عملی این است: هر پروژه متن‌بازی که توسط یک شرکت واحد با نیاز CLA کنترل می‌شود را به عنوان بالقوه اختصاصی در نظر بگیرید. مجوزی که امروز می‌بینید ممکن است مجوزی نباشد که نرم‌افزار را در سه سال آینده اداره می‌کند. ایمن‌ترین نرم‌افزار متن‌باز، از منظر ریسک مجوز، متعلق به یک بنیاد (Linux Foundation، Apache Software Foundation، CNCF) است یا دارای حاکمیت توزیع‌شده واقعی به جای کنترل تک‌شرکتی است.

چه چیزی در پیش است

جنگ‌های مجوز تمام نشده است. چندین پروژه زیرساخت پرکاربرد دیگر - که توسط شرکت‌های با بودجه خوب با رقابت ارائه‌دهنده ابر نگهداری می‌شوند - با پویایی مشابهی روبرو هستند. شرکت‌ها آنچه را که برای HashiCorp، Redis و Elastic اتفاق افتاده تماشا کرده‌اند و تصمیمات مجوز را بر این اساس می‌گیرند.

یک مدل در حال ظهور: مجوز دوگانه از روز اول، که در آن نرم‌افزار هم تحت یک مجوز متن‌باز برای استفاده جامعه و هم تحت یک مجوز تجاری برای استفاده سازمانی تولید در دسترس است، با مرزهای واضحی که به صورت گذشته‌نگر تغییر نمی‌کنند. دیگری: مالکیت بنیاد از ابتدا، بدون اینکه یک شرکت واحد مجوز را کنترل کند. هیچکدام از مدل‌ها به طور کامل تنش اساسی بین پویایی پذیرش متن‌باز و کسب درآمد تجاری نرم‌افزار را حل نمی‌کنند - اما هر دو از آسیب اعتمادی که از تغییر مجوزها پس از اینکه جامعه قبلاً بر روی نرم‌افزار شما ساخته است، جلوگیری می‌کنند.

اشتراک‌گذاری: