مقدمه
در دنیای پویای توسعه نرمافزار، انتخاب مجوز مناسب برای پروژههای متنباز (Open Source Software - OSS) همواره یک موضوع حیاتی بوده است. مجوزها نهتنها شرایط استفاده، توزیع و تغییر نرمافزار را تعیین میکنند، بلکه بر نحوه تعامل پروژهها با جامعه توسعهدهندگان و مدلهای کسبوکار مرتبط با آنها نیز تأثیرگذار هستند. در سالهای اخیر، شاهد تغییرات قابل توجهی در رویکرد پروژههای تجاری متنباز به صدور مجوز بودهایم. از طرفی، مسائل مربوط به حاکمیت و نقش بنیادهای متنباز نیز به طور فزایندهای مورد توجه قرار گرفتهاند. این مقاله به بررسی این تحولات کلیدی، با تمرکز بر تغییرات اخیر در مجوزها و چالشهای پیش روی بنیادهای متنباز، میپردازد و تلاش میکند تا تصویری منسجم از وضعیت کنونی اکوسیستم توسعه ارائه دهد.
تحولات در مجوزدهی نرمافزار متنباز
در گذشته، بسیاری از پروژههای متنباز تجاری برای دستیابی به گستردگی استفاده، از مجوزهای تسهیلگر (Permissive Licenses) مانند آپاچی (Apache) استفاده میکردند. با این حال، با بلوغ این پروژهها و تغییر تمرکز از رشد صرف به کسب ارزش انحصاری، برخی از شرکتها به دنبال مجوزهای با محافظت قویتر رفتند. این امر منجر به ظهور مجوزهای «منبع در دسترس» (Source Available Licenses) شد که در عین ارائه کد منبع، محدودیتهای بیشتری نسبت به مجوزهای متنباز سنتی اعمال میکنند.
یکی از این مجوزها، مجوز عمومی سرور ساید (Server Side Public License - SSPL) بود که توسط MongoDB ابداع شد. هدف اصلی SSPL، مقابله با استفاده شرکتهای بزرگ، به ویژه ارائهدهندگان خدمات ابری (Cloud Providers)، از نرمافزار متنباز بدون مشارکت فعال یا ارائه نسخه متنباز از خدمات خود بود. SSPL با گسترش الزامات متقابل (Reciprocal Provisions) فراتر از خود نرمافزار و شامل نرمافزارهای مجاور که برای ارائه آن به عنوان سرویس استفاده میشوند، سعی در بستن به اصطلاح «رخنه» موجود در مجوز عمومی گنو (GNU General Public License - GPL) و مجوز عمومی آفرو (Affero General Public License - AGPL) داشت.
با این حال، SSPL با مخالفتهایی از سوی جامعه متنباز و سازمان ابتکار متنباز (Open Source Initiative - OSI) روبرو شد و در نهایت به عنوان یک مجوز متنباز به رسمیت شناخته نشد. دلیل اصلی این امر، مغایرت SSPL با بند نهم تعریف متنباز بود که محدود کردن نرمافزارهای دیگر توزیعشده همراه با نرمافزار دارای مجوز را منع میکند.
علیرغم عدم پذیرش گسترده، برخی دیگر از فروشندگان تجاری مانند Elastic و Redis نیز به استفاده از SSPL روی آوردند. با این حال، اخیراً شاهد تغییر جهت در این روند بودهایم. هم Elastic و هم Redis، مجوز AGPL را به عنوان گزینه دیگری در کنار یا جایگزین SSPL ارائه کردهاند. سالواتوره سانفیلیپو، نویسنده اصلی Redis، دلیل این تغییر را عدم پذیرش SSPL توسط جامعه متنباز و OSI عنوان کرد.
AGPL، که خود یک مجوز متنباز مورد تأیید OSI است، نسخه اصلاحشده GPL است که مقررات کپیلفت (Copyleft Provisions) را به برنامههای کاربردی میزبانیشده در شبکهها گسترش میدهد. در حالی که GPL اصلی، تغییرات در نرمافزاری که به صورت باینری توزیع میشود را مشمول الزامات متقابل میداند، AGPL این الزامات را به نرمافزارهایی که از طریق شبکه ارائه میشوند نیز تعمیم میدهد.
حرکت پروژههایی مانند Grafana، MinIO و Zitadel به سمت AGPL نیز نشاندهنده تمایل پروژههای تجاری متنباز به استفاده از مجوزهای با محافظت قویتر است که در عین حال توسط OSI به عنوان متنباز شناخته میشوند. به نظر میرسد که AGPL در حال تبدیل شدن به یک نقطه تعادل برای این پروژهها است، زیرا هم محافظت قابل توجهی ارائه میدهد و هم از نظر OSI یک مجوز متنباز معتبر محسوب میشود. این امر نشان میدهد که پروژههای تجاری متنباز همچنان به دنبال راههایی برای محافظت از کد خود در برابر سوءاستفاده، به ویژه توسط ارائهدهندگان خدمات ابری بزرگ، هستند، بدون اینکه از مزایای یک مجوز متنباز مورد تأیید جامعه محروم شوند.
نتیجهگیری
به طور خلاصه، اکوسیستم متنباز در زمینه دستیابی به اجماع در مورد مجوزهای متنباز که از نظر تجاری قابل قبول باشند، پیشرفتهایی داشته است. حرکت پروژههای تجاری به سمت AGPL نشاندهنده تمایل به محافظت قویتر از کد در عین حفظ ماهیت متنباز مورد تأیید جامعه است. حفظ اعتماد و اطمینان در این نهادها برای سلامت و پایداری بلندمدت اکوسیستم متنباز حیاتی است. به نظر میرسد که در حال حاضر، اکوسیستم متنباز با دو گام رو به جلو در زمینه مجوزدهی و یک گام به عقب در زمینه انسجام و اعتماد در بنیادها مواجه است.