تفاوت مجوزهای GPL، MIT و Apache چیست؟

تفاوت GPL، MIT و Apache: هر مجوز چه انتظاری از شما دارد

مجوزهای GPL، MIT و Apache 2.0 به یک پرسش واحد به شیوه‌های متفاوتی پاسخ می‌دهند: هنگامی که نرم‌افزار را در اختیار دیگران قرار می‌دهید، چه تعهدی نسبت به آن‌ها دارید؟ مجوز MIT تنها خواستار حفظ اعلامیه حق تکثیر (copyright notice) است و هیچ شرط دیگری ندارد. مجوز Apache 2.0 علاوه بر آن اعلامیه، یک توافق‌نامه حق اختراع (patent) را میان تمام کسانی که با کد کار می‌کنند، الزامی می‌سازد. مجوز GPL از شما می‌خواهد که سورس‌کد آنچه را بر پایه آن ساخته‌اید، تحت همان مجوزی که دریافت کرده‌اید، منتشر کنید.

این موضوع تا روزی که پروژه‌ای که اجرا می‌کنید مجوز خود را تغییر داده و به دو شاخه تقسیم شود، صرفاً یک مسئله حقوقی به نظر می‌رسد. در آن صورت، این یک مسئله عملیاتی است. شما باید میان دو مخزن بسته (package repository) یکی را انتخاب کنید و با کتابخانه‌های کلاینتی مواجه می‌شوید که دیگر با یکدیگر سازگار نیستند. این راهنما درباره مجوزها و سازوکار آن‌هاست، نه درباره جنبشی که آن‌ها را به وجود آورده است؛ بنابراین هر بخش در جایی به پایان می‌رسد که با کار شما تلاقی پیدا می‌کند: یعنی شخصی که باید ارتقا (upgrade) را انجام دهد.

چرا GPL وجود دارد: چاپگری که هیچ‌کس اجازه تعمیر آن را نداشت

در حدود سال 1980، آزمایشگاه هوش مصنوعی MIT یک چاپگر لیزری Xerox 9700 دریافت کرد. این آزمایشگاه نرم‌افزار چاپگر قبلی را اصلاح کرده بود تا در صورت گیر کردن کاغذ، به کاربر اطلاع دهد. برای چاپگر جدید، کد منبعی وجود نداشت و درخواست دریافت آن به دلیل توافق‌نامه عدم افشا (NDA) رد شد. ریچارد استالمن، که در آن زمان برنامه‌نویس آزمایشگاه بود، این امتناع را نه به عنوان یک اتفاق موردی، بلکه به عنوان یک رویه کلی در نظر گرفت و پروژه GNU را در 27 سپتامبر 1983 اعلام کرد.

کپی‌لفت (Copyleft) بر پایه قانون کپی‌رایت بنا شده است، نه علیه آن. به‌طور پیش‌فرض، شما هیچ حقی برای کپی کردن کد شخص دیگری ندارید. GPL این حق را تحت یک شرط اعطا می‌کند: اگر برنامه را به شخص دیگری می‌دهید، باید کد منبع آن را نیز تحت همان شرایط به او ارائه دهید تا آن‌ها بتوانند کاری را انجام دهند که آزمایشگاه نتوانست. این شرط قابل اجرا است، زیرا بدون این مجوز، شما در وهله اول هیچ اجازه‌ای برای کپی نداشتید.

استالمن ابتدا مجوزی برای GNU Emacs نوشت و سپس آن را در 25 فوریه 1989 به نسخه 1 از GPL تعمیم داد. نسخه 2 از GPL در ژوئن 1991 منتشر شد و همچنان مجوزی است که بر اکثر نرم‌افزارهای سیستمی که اجرا می‌کنید، حاکم است. Lesser GPL برای کتابخانه‌ها ایجاد شد تا یک کتابخانه کپی‌لفت بتواند توسط برنامه‌ای با هر مجوزی لینک شود، بدون اینکه آن برنامه را مجبور به تبعیت از GPL کند.

یک جزئیات تعیین می‌کند که GPL چگونه بر یک کاربر self-hoster تأثیر می‌گذارد. تعهدات GPL هنگام توزیع (distribution) فعال می‌شوند، نه هنگام استفاده. شما می‌توانید یک برنامه تحت GPL را تغییر دهید، آن را روی سرور شخصی خود اجرا کنید، به عموم خدمات ارائه دهید و به هیچ‌کس بدهکار نباشید، زیرا هرگز نسخه‌ای از آن را به کسی تحویل نداده‌اید. همین شکاف دلیلی است که AGPL وجود دارد.

سنت مجوزهای آزاد: BSD و سپس MIT

دانشگاه برکلی مسیر متفاوتی را در پیش گرفت. گروه تحقیقاتی سیستم‌های کامپیوتری، کارهای خود روی Unix را تحت مجوزی منتشر کرد که تنها خواستار حفظ اعلامیه حق تکثیر (copyright) بود و هرگونه ضمانتی را سلب می‌کرد. نسخه اصلی دارای 4 بند بود؛ بند چهارم که به «بند تبلیغاتی» معروف بود، الزام می‌کرد که در تمامی مواد تبلیغاتی که به ویژگی‌های نرم‌افزار اشاره دارند، از دانشگاه یاد شود. این بند مقیاس‌پذیر نبود. استالمن در نسخه‌ای از NetBSD در سال 1997، تعداد 75 تقدیرنامه جداگانه را شمارش کرد. دانشگاه کالیفرنیا، برکلی، در تاریخ 22 ژوئیه 1999 طی نامه‌ای از سوی ویلیام هاسکینز از دفتر صدور مجوز فناوری، این بند را حذف کرد.

آنچه باقی مانده، مجوز 3-بندی BSD است که ممنوعیت استفاده از نام مشارکت‌کنندگان برای تأیید محصول شما را اضافه می‌کند، و نسخه 2-بندی که حتی آن مورد را نیز حذف کرده است. متن مجوز MIT در دهه 1980 از دل دانشگاه MIT بیرون آمد و سیستم X Window را پوشش می‌داد؛ در عمل، این مجوز همان کاری را انجام می‌دهد که نسخه 2-بندی BSD انجام می‌دهد.

انگیزه‌ها متفاوت بودند. دانشگاهی که با بودجه عمومی تأمین مالی می‌شد، می‌خواست کارهایش در همه جا، از جمله توسط شرکت‌ها، استفاده شود. پروژه GNU به دنبال ایجاد یک فضای اشتراکی بود که نتوان آن را محدود کرد. هر دو موضع صادقانه هستند و هر دو حالت شکست خاص خود را دارند. کدهای دارای مجوز آزاد (Permissive) می‌توانند به کدهای اختصاصی تبدیل شوند و شما هیچ چیزی در ازای آن دریافت نمی‌کنید. کدهای دارای مجوز Copyleft توسط شرکت‌هایی که وکلای آن‌ها شرایط مجوز را نمی‌پذیرند، رد می‌شوند.

درس دومی از برکلی وجود دارد که این مطلب مدام به آن بازمی‌گردد. آزمایشگاه‌های سیستم Unix شرکت AT&T در سال 1992 از شرکت Berkeley Software Design بر سر کدهای BSD شکایت کرد و این پرونده در اوایل سال 1994 با توافق طرفین مختومه شد. به مدت 2 سال هیچ‌کس مطمئن نبود که آیا ساخت‌وساز بر پایه BSD امن است یا خیر، و در حالی که Linux رشد می‌کرد، پذیرش BSD متوقف شد. عدم قطعیت حقوقی، بسیار سریع‌تر از فقدان یک ویژگی فنی، مانع از پذیرش یک فناوری می‌شود.

چرا Apache 2.0 یک حق امتیاز (patent grant) اضافه کرد

اولین مجوز Apache Group مشتقی از BSD 4-clause بود که همان مشکل تبلیغاتی را داشت. نسخه 1.1 در سال 2000 آن بند را حذف کرد. نسخه 2.0 که در ژانویه 2004 منتشر شد، به جای یک وصله (patch)، بازنویسی کامل بود.

افزونه مهم، حق امتیازها (patents) است. مجوزهای MIT و BSD اصلاً در این مورد چیزی نمی‌گویند. یک مشارکت‌کننده می‌تواند مجوز کپی‌رایت شفافی برای کد خود به شما بدهد، اما همچنان حق امتیازی داشته باشد که بر عملکرد آن کد صدق کند و سپس از افرادی که از آن استفاده می‌کنند شکایت کند. مجوز Apache 2.0 این حفره را می‌بندد: هر مشارکت‌کننده یک مجوز حق امتیاز برای مشارکت خود اعطا می‌کند و هر کسی که با ادعای نقض حق امتیاز توسط این اثر شکایت کند، مجوز حق امتیاز خود را برای آن اثر از دست می‌دهد. این تهدید متقابل است، بنابراین در عمل کسی اقدام به شکایت نمی‌کند.

بقیه موارد نسخه 2.0 جنبه اداری دارند و به همین دلیل شرکت‌ها آن را می‌پسندند. یک فایل NOTICE تعریف شده وجود دارد، بنابراین انتساب (attribution) به جای پراکنده شدن در کل درخت فایل‌ها، یک جای مشخص دارد. این مجوز می‌تواند به جای کپی شدن در هر فایل منبع، با ارجاع اعمال شود. مشارکت‌ها تحت شرایط صریحی پوشش داده می‌شوند. علائم تجاری (trademarks) مستثنی شده‌اند. بررسی حقوقی یک وابستگی (dependency) با مجوز Apache 2.0 نشان می‌دهد که هر پرسشی که تیم حقوقی ممکن بود داشته باشد، قبلاً در متن مجوز پاسخ داده شده است؛ بنابراین تأیید آن به یک روال عادی تبدیل می‌شود، که این همان معنای اصلی «پیش‌فرض شرکتی» (corporate default) است.

تغییرات GPLv3 و دلیل ماندن لینوکس بر روی GPLv2

شرکت TiVo یک دستگاه ضبط ویدیو عرضه کرد که لینوکس را اجرا می‌کرد و کد منبع هسته را دقیقاً مطابق الزامات GPLv2 منتشر کرد. سخت‌افزار دستگاه در هنگام بوت، یک امضای رمزنگاری‌شده را بررسی می‌کرد و از اجرای هسته‌ای که آن را شناسایی نمی‌کرد، خودداری می‌نمود. شما می‌توانستید کد منبع را بخوانید، آن را تغییر دهید و کامپایل کنید، اما نمی‌توانستید آن را روی دستگاهی که از آن آمده بود اجرا کنید. متن مجوز رعایت شده بود اما هدف آن خنثی گشت و این رویه به نام tivoisation شناخته شد.

نسخه 3 مجوز GPL که در 29 ژوئن 2007 منتشر شد، مستقیماً به این موضوع پاسخ می‌دهد. هنگامی که شما یک فایل باینری را درون یک دستگاه مصرف‌کننده ارائه می‌دهید، باید «اطلاعات نصب» (Installation Information) را نیز فراهم کنید: یعنی کلیدها یا دستورالعمل‌های لازم برای نصب نسخه تغییریافته و اجرای آن. نسخه 3 همچنین یک اعطای حق امتیاز (patent grant) صریح اضافه کرد؛ شرایطی که در واکنش به توافق‌نامه حق امتیاز مایکروسافت و ناول در نوامبر 2006 نوشته شد و همچنین سازگاری یک‌طرفه با Apache 2.0 را فراهم کرد.

لینوکس از این تغییر پیروی نکرد. هسته لینوکس فقط تحت نسخه 2 مجوز GPL است و هیچ بند فراری با عنوان «یا هر نسخه بعدی» ندارد و فایل COPYING آن نیز همین را بیان می‌کند. لینوس توروالدز به‌طور عمومی با شرایط ضد-tivoisation برای سخت‌افزارهای امضاشده مخالفت کرد. مانع عملی بزرگ‌تر از این اختلاف‌نظر است: هسته هزاران دارنده حق تکثیر دارد، بنابراین حتی اگر همه بخواهند، هیچ‌کس نمی‌تواند مجوزهای لازم برای تغییر مجوز را جمع‌آوری کند. همین واقعیت، قوی‌ترین محافظتی است که یک پروژه می‌تواند داشته باشد و هنگام بررسی پروژه‌ای که متعلق به یک شرکت واحد است، ارزش به خاطر سپردن دارد.

مجوز دیگر سال 2007 برای شما اهمیت بیشتری دارد. مجوز GNU Affero GPL نسخه 3 که در نوامبر همان سال منتشر شد، تعهد ارائه کد منبع را به افرادی که از طریق شبکه با برنامه تعامل دارند، گسترش می‌دهد. اگر یک سرویس AGPL تغییریافته را برای عموم اجرا کنید، باید کد منبع را به آن کاربران ارائه دهید. به همین دلیل است که بسیاری از نرم‌افزارهای وب self-hosted تحت مجوز AGPL هستند. Nextcloud یک نمونه است و اگر در حال مقایسه جایگزین‌های self-hosted برای Nextcloud هستید، خط مربوط به مجوز در مخزن هر کاندیدا، بیش از لیست ویژگی‌های آن، درباره پنج سال آینده‌اش به شما اطلاعات می‌دهد.

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

سازگاری مجوزها یک‌طرفه است؛ از مجوزهای permissive (مجاز) به سمت copyleft (کپی‌لفت).

• کدهای تحت مجوز MIT و BSD را می‌توان در هر پروژه‌ای، از جمله محصولات متن‌بسته (closed source)، استفاده کرد.
• کدهای تحت مجوز Apache 2.0 را می‌توان در پروژه‌های GPLv3 گنجاند و اثر ترکیبی حاصل، تحت مجوز GPLv3 خواهد بود.
• کدهای تحت مجوز Apache 2.0 را نمی‌توان در پروژه‌هایی که صرفاً تحت GPLv2 هستند استفاده کرد. شرایط مربوط به فسخ حق اختراع (patent termination) و غرامت در Apache 2.0، شروط اضافه‌ای هستند که GPLv2 اجازه افزودن آن‌ها را نمی‌دهد. هم FSF و هم ASF بر این نتیجه‌گیری توافق دارند.
• شما نمی‌توانید کدهای تحت مجوز GPL را به یک مجوز permissive منتقل کنید. تنها دارندگان حق تکثیر (copyright holders) قادر به انجام این کار هستند که این موضوع شما را دوباره به پرسشِ شناسایی آن‌ها بازمی‌گرداند.

عصر تغییر مجوزها: SSPL، BUSL و آنچه نیستند

انگیزهٔ این تغییرات تجاری بود. شرکتی حق تکثیر یک محصول را در اختیار دارد، یک ارائه‌دهندهٔ خدمات ابری آن را در مقیاس بزرگ به‌عنوان یک سرویس مدیریت‌شده می‌فروشد و سهم ناچیزی در توسعهٔ آن دارد؛ بنابراین شرکت مذکور مجوز را تغییر می‌دهد تا جلوی این کار را بگیرد. Redis Labs اولین حرکت مشهود را در اوت 2018 با افزودن Commons Clause به بالای مجوز Apache 2.0 برای چندین ماژول خود انجام داد. MongoDB در 16 اکتبر 2018 با تغییر از AGPLv3 به Server Side Public License از آن پیروی کرد.

مجوز SSPL همان AGPL است که یک بخش آن بازنویسی شده است. اگر برنامه را به‌عنوان یک سرویس به اشخاص ثالث ارائه دهید، باید سورس‌کد تمام مواردی که برای ارائهٔ آن استفاده کرده‌اید، از جمله نرم‌افزارهای مدیریت و ارکستراسیون پیرامون آن را منتشر کنید. این تعهد مرز مشخصی ندارد و هیچ دادگاهی آن را بررسی نکرده است. OSI هرگز این مجوز را تأیید نکرد و MongoDB درخواست خود را در مارس 2019 پس گرفت. دبیان (Debian) در دسامبر 2018 اعلام کرده بود که نرم‌افزار SSPL جایی در آرشیو آن ندارد و فدورا (Fedora) در ژانویه 2019 حکم داد که این مجوز آزاد نیست؛ پس از آن Red Hat، نرم‌افزار MongoDB را از فدورا و Red Hat Enterprise Linux حذف کرد. این نتیجهٔ مکانیکی یک تغییر مجوز است: توزیع‌کننده دیگر نرم‌افزار را بسته‌بندی نمی‌کند، بنابراین به‌روزرسانی‌های شما اکنون از مخزن فروشنده و طبق زمان‌بندی او انجام می‌شود.

مجوز Business Source License ابزار متفاوتی است. این مجوز از سوی بنیان‌گذاران MariaDB ارائه شد و نسخه 1.1 آن مربوط به سال 2017 است. این مجوز نه کپی‌لفت (copyleft) است و نه متن‌باز (open source). سورس‌کد عمومی است و استفاده از آن رایگان است، مگر برای مواردی که فروشنده استثنا کرده است که معمولاً شامل اجرای یک سرویس میزبانی‌شدهٔ رقیب می‌شود. هر نسخه به‌طور خودکار در یک تاریخ مشخص که حداکثر 4 سال پس از انتشار آن است، به یک مجوز متن‌باز واقعی تبدیل می‌شود. مجوزی که به آن تبدیل می‌شود باید با GPLv2 سازگار باشد. HashiCorp در 10 اوت 2023، نرم‌افزار Terraform و سایر محصولات خود را به BUSL 1.1 منتقل کرد. Outline نیز از این مجوز استفاده می‌کند که اگر در حال انتخاب از میان جایگزین‌های Notion برای میزبانی شخصی هستید، دانستن آن مفید است: اجرای آن برای تیم خودتان مجاز است، اما ساختن یک سرویس بر پایهٔ آن مجاز نیست.

هیچ‌کدام از این مجوزها فریبکارانه نیستند. هر دو به‌صراحت اعلام می‌کنند که سورس‌کد در دسترس (source available) است. هیچ‌کدام طبق تعریف OSI متن‌باز نیستند و تفاوت آن‌ها بیش از آنکه متوجه ارائه‌دهندهٔ خدمات ابری باشد، متوجه شماست.

OpenSearch: هزینه انشعاب (fork) مجوز برای اپراتور چیست

شرکت Elastic در تاریخ 14 ژانویه 2021 اعلام کرد که Elasticsearch و Kibana از نسخه 7.11 به بعد، مجوز Apache 2.0 را کنار گذاشته و به سراغ SSPL یا Elastic License می‌روند. نسخه 7.10.2 آخرین نسخه با مجوز Apache 2.0 بود. حدود یک هفته بعد، AWS اعلام کرد که یک انشعاب (fork) با مجوز Apache 2.0 برای هر دو پروژه ایجاد و نگهداری خواهد کرد. این انشعاب در تاریخ 12 آوریل 2021 با نام OpenSearch معرفی شد و نام Kibana نیز به OpenSearch Dashboards تغییر یافت. نسخه OpenSearch 1.0 در تاریخ 12 ژوئیه 2021 به صورت عمومی عرضه شد که بر پایه Elasticsearch 7.10.2 و Kibana 7.10.2 ساخته شده بود.

ببینید این موضوع چه هزینه‌ای برای کسانی که کلاسترها را مدیریت می‌کردند داشت. نام بسته‌ها و مخازن تغییر کرد. هر ارجاعی به Kibana در راهنماهای عملیاتی (runbook) به OpenSearch Dashboards تبدیل شد. نام پلاگین‌ها تغییر کرد. سپس این شکاف به کد برنامه رسید: از نسخه 7.13 کتابخانه‌های کلاینت رسمی Elastic، کلاینت بررسی می‌کند که به چه چیزی متصل شده است و اگر مقصد Elasticsearch نباشد، از ادامه کار خودداری کرده و گزارش می‌دهد که سرور یک محصول ناشناخته است. تصمیم مربوط به مجوز در شرکتی که شما در آن کار نمی‌کنید، به شکل یک فراخوانی ناموفق در داخل برنامه خودتان ظاهر شد.

داستان سپس دو بار دیگر تغییر کرد. Elastic در تاریخ 29 اوت 2024 مجوز AGPLv3 را به عنوان گزینه سوم اضافه کرد، بنابراین Elasticsearch فعلی دوباره یک نرم‌افزار متن‌باز با تأییدیه OSI است. در تاریخ 16 سپتامبر 2024، AWS پروژه OpenSearch را به OpenSearch Software Foundation منتقل کرد که تحت میزبانی Linux Foundation قرار دارد؛ این کار باعث شد انشعاب مذکور صاحب یک ساختار حاکمیتی شود که متعلق به یک شرکت واحد نیست. پنج سال پس از این جدایی، هر دو پروژه متن‌باز هستند، هر دو نگهداری می‌شوند و OpenSearch تا اوت 2026 در سری 3.x خود قرار دارد.

پایان این ماجرا، درس آن است. مجوزها به حالت قبل بازگشتند اما انشعاب باقی ماند. وقتی یک اکوسیستم برای همه چیز دو نسخه دارد، اصلاح اسناد اداری باعث ادغام دوباره آن‌ها نمی‌شود.

عددی که تعیین می‌کند تغییر مجوز چقدر آسیب‌زا است، فاصله زمانی بین اعلامیه و یک انشعاب پایدار است که واقعاً بتوانید آن را مستقر کنید.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

هر فاصله زمانی از تاریخ اعلام عمومی توسط فروشنده تا اولین نسخه پایدار انشعاب، با استفاده از تاریخ‌های فهرست‌شده در زیر محاسبه می‌شود. عرضه OpenSearch 1.0 به 179 روز زمان نیاز داشت، زیرا انشعاب باید تغییر نام می‌یافت و از نو ساخته می‌شد و هیچ انشعاب قبلی برای کپی‌برداری وجود نداشت. OpenTofu به 153 روز زمان نیاز داشت. Valkey به 27 روز زمان نیاز داشت، زیرا از Redis 7.2.4 انشعاب گرفته بود و پروتکل و فرمت ذخیره‌سازی روی دیسک را کاملاً یکسان نگه داشت. جهت‌گیری این موضوع بخش مفید ماجراست: یک انشعاب معتبر اکنون در عرض چند هفته از راه می‌رسد و از همان روز اول، یک بنیاد و نگهداری‌کنندگان حقوق‌بگیر دارد.

Valkey و OpenTofu: همان الگو، با سرعت بیشتر

شرکت Redis Ltd در تاریخ 20 مارس 2024، مجوز Redis را از BSD 3-clause به انتخابی بین RSALv2 یا SSPLv1 تغییر داد. هشت روز بعد، بنیاد لینوکس (Linux Foundation) پروژه Valkey را معرفی کرد که از نسخه 7.2.4 نرم‌افزار Redis منشعب شده و تحت مجوز BSD 3-clause باقی ماند. نسخه 7.2.5 از Valkey در 16 آوریل 2024 با همان پروتکل و همان فایل‌های داده منتشر شد، بنابراین برای اکثر اپراتورها، مهاجرت تنها به تغییر نام بسته محدود می‌شد. سپس Redis در ماه مه 2025، مجوز AGPLv3 را به عنوان گزینه سوم در Redis 8 اضافه کرد که طبق تعریف OSI، آن را دوباره به یک نرم‌افزار متن‌باز تبدیل می‌کند، در حالی که Valkey به فعالیت تحت حاکمیت مستقل خود ادامه می‌دهد. این الگو شباهت زیادی به وضعیت Elasticsearch دارد.

Terraform نیز همین مسیر را با یک فصل اضافه طی کرد. پروژه OpenTofu آخرین نسخه منتشر شده تحت مجوز Mozilla Public License 2.0 را منشعب کرد، در سپتامبر 2023 به بنیاد لینوکس پیوست و نسخه 1.6.0 را در 10 ژانویه 2024 عرضه کرد. در 3 آوریل 2024، وکلای HashiCorp با ارسال نامه‌ای مبنی بر توقف فعالیت (cease and desist)، ادعا کردند که کدی از نسخه Terraform با مجوز BUSL به این انشعاب کپی شده است. OpenTofu در 11 آوریل 2024 پاسخ مفصلی منتشر کرد و ضمن رد این ادعا، منشأ کد مورد مناقشه را به تاریخچه تحت مجوز MPL که هر دو پروژه در آن مشترک هستند، نسبت داد. پس از آن هیچ اقدام عمومی دیگری صورت نگرفت. ریسک واقعی در این ماجرا همان نکته‌ای است که باید به خاطر سپرد: صرفِ یک اتهام می‌تواند پذیرش یک فناوری را برای یک فصل متوقف کند؛ همان اثری که شکایت حقوقی Berkeley در سی سال پیش داشت.

هر انشعابی با موضوع مجوز شروع نمی‌شود. پروژه Forgejo در سال 2022 از Gitea منشعب شد، پس از آنکه توسعه Gitea تحت کنترل یک شرکت قرار گرفت؛ این یک اختلاف بر سر حاکمیت بود تا مجوز. Forgejo تا سری نسخه 8 تحت مجوز MIT باقی ماند، سپس از نسخه 9.0 در سال 2024 مجوز خود را به GPLv3 یا بالاتر تغییر داد تا کارهایش نتواند دوباره به یک محصول تحت کنترل تجاری بازگردانده شود. اگر در حال بررسی گزینه‌های سرور Git خود-میزبان هستید، این جفت، واضح‌ترین نمونه زنده از یک کدبیس با دو فلسفه متفاوت است.

آزمونی که باید پیش از پذیرش هر چیزی انجام دهید

چهار پرسش، پیش از اولین نصب و نه پس از آن.

1. حق تکثیر (copyright) در اختیار کیست؟ تغییر مجوز (relicensing) نیازمند اجازه از تک‌تک دارندگان حق تکثیر است؛ بنابراین پروژه‌ای با صدها مشارکت‌کننده مستقل که هیچ‌گونه واگذاری حقوقی انجام نداده‌اند، عملاً قابل تغییر مجوز نیست. پروژه‌ای که یک شرکت مالک تمام حقوق آن است، می‌تواند در یک جلسه هیئت‌مدیره تغییر مجوز دهد.
2. آیا CLA وجود دارد و چه حقوقی اعطا می‌کند؟ توافق‌نامه مشارکت‌کننده (CLA) که به شرکت اجازه می‌دهد مشارکت شما را تحت هر شرایطی که می‌خواهد تغییر مجوز دهد، دقیقاً همان مکانیزمی است که پشت تمام تغییر مجوزهای ذکرشده قرار دارد. DCO (گواهی مبدأ توسعه‌دهنده)، همان خط sign-off که هسته Linux در سال 2004 اتخاذ کرد، هیچ حقی را منتقل نمی‌کند. CLA که توسط یک بنیاد نگهداری می‌شود، امن‌تر از CLA متعلق به یک شرکت است، زیرا شرکت‌ها قابل خرید و فروش هستند.
3. مالک علامت تجاری کیست؟ شرکت Elastic نام Elasticsearch را حفظ کرد، بنابراین fork (انشعاب) مجبور شد نام خود را تغییر دهد و تمام runbookهایی که به Kibana اشاره داشتند، باید بازنویسی می‌شدند.
4. تغییر مجوز مشخصاً برای شما چه هزینه‌ای دارد؟ فرمت داده‌ها، کتابخانه‌های کلاینت، پیکربندی‌هایی که باید بازنویسی کنید و اینکه آیا یک fork سازگار از قبل وجود دارد یا خیر را محاسبه کنید.

دو دستور بخشی از این پاسخ را در چند ثانیه مشخص می‌کنند.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

هر بسته Debian و Ubuntu فایلی را در مسیر /usr/share/doc/<package>/copyright ارائه می‌دهد که مجوز نسخه نصب‌شده شما را ثبت می‌کند، نه مجوزی که پروژه امروز از آن استفاده می‌کند. برای bash در Ubuntu 24.04، آن فایل به GNU General Public License version 3 اشاره دارد. دستور دوم را داخل یک source checkout اجرا کنید تا تاریخچه خود فایل مجوز را دریافت کنید. یک commit در آن فایل طی دو سال گذشته، ارزش خواندن دارد پیش از آنکه چیزی بر پایه آن پروژه بسازید. اگر دستور چیزی چاپ نکرد، مخزن نام دیگری برای فایل مجوز خود انتخاب کرده است؛ پس دایرکتوری ریشه را لیست کنید و جستجو کنید.

هیچ مجوزی شما را در برابر تمام پیامدها محافظت نمی‌کند و انتخاب بر اساس ایدئولوژی، همان چیزی است که باعث غافلگیری افراد می‌شود. پروژه‌هایی را ترجیح دهید که حق تکثیر آن‌ها بین افراد زیادی پخش شده یا توسط یک بنیاد نگهداری می‌شود و داده‌های خود را در فرمتی نگه دارید که بتوانید خروجی بگیرید. سپس مشخص کنید که در صورت نیاز به کدام fork کوچ خواهید کرد و نام آن را پیش از نیاز یادداشت کنید. اعمال این بررسی برای هر گزینه کمتر از یک ساعت زمان می‌برد و همان چیزی است که هنگام تصمیم‌گیری برای آنچه در 2026 باید self-host کنید، تفاوت بین یک ارتقا و یک مهاجرت را تعیین می‌کند.

FAQ

آیا مجوز MIT با مجوز BSD یکسان است؟

در عمل، MIT با مجوز 2-بندی BSD مطابقت دارد: اعلامیه حق تکثیر (copyright) و سلب مسئولیت گارانتی را حفظ کنید و سپس هر کاری که می‌خواهید انجام دهید، از جمله ساخت یک محصول تجاری (closed source). مجوز 3-بندی BSD یک مورد اضافه دارد: ممنوعیت استفاده از نام مشارکت‌کنندگان برای تأیید محصول شما بدون اجازه. نسخه قدیمی‌تر 4-بندی نیز نیازمند ذکر نام در تبلیغات بود که دانشگاه کالیفرنیا، برکلی در تاریخ 22 ژوئیه 1999 آن بند را حذف کرد؛ بنابراین تقریباً هیچ نرم‌افزار امروزی دیگر آن را شامل نمی‌شود.

آیا می‌توانم کد Apache 2.0 را در یک پروژه GPLv2 قرار دهم؟

خیر. مجوز Apache 2.0 شرایطی را اضافه می‌کند که GPLv2 اجازه افزودن آن‌ها را نمی‌دهد؛ به‌ویژه بند خاتمه حق اختراع (patent termination). بنابراین یک اثر ترکیبی نمی‌تواند همزمان هر دو مجوز را ارضا کند. بنیاد نرم‌افزارهای آزاد (FSF) و بنیاد نرم‌افزار آپاچی (ASF) هر دو این نتیجه‌گیری را منتشر کرده‌اند. جهت عکس این موضوع امکان‌پذیر است: کد Apache 2.0 می‌تواند در یک پروژه GPLv3 گنجانده شود و نتیجه نهایی تحت مجوز GPLv3 خواهد بود. به همین دلیل است که کد Apache 2.0 نمی‌تواند در هسته لینوکس ادغام شود، چرا که هسته لینوکس فقط تحت نسخه 2 مجوز GPL است.

آیا SSPL یک مجوز متن‌باز (Open Source) است؟

خیر، و این پاسخ پیامدهای عملی دارد. سازمان OSI هرگز آن را تأیید نکرد و MongoDB درخواست خود را در مارس 2019 پس گرفت. دبیان در دسامبر 2018 اعلام کرد که نرم‌افزارهای تحت SSPL در مخازن آن جایگاهی ندارند و فدورا در ژانویه 2019 حکم داد که این مجوز آزاد نیست؛ پس از آن، Red Hat نرم‌افزار MongoDB را از فدورا و Red Hat Enterprise Linux حذف کرد. برای شما این به آن معناست که بسته‌ای که توزیع شما قبلاً نگهداری می‌کرد، اکنون از مخزن فروشنده و طبق زمان‌بندی پشتیبانی همان فروشنده ارائه می‌شود. مجوز Business Source License نیز به‌جای متن‌باز، «در دسترس بودن سورس» (source available) محسوب می‌شود، اگرچه هر نسخه پس از 4 سال به یک مجوز متن‌باز تبدیل می‌شود.

آیا تغییر مجوز شامل نسخه‌ای که در حال حاضر اجرا می‌کنم می‌شود؟

خیر. مجوزی که با یک نسخه (release) اعطا شده است، نمی‌تواند از نسخه‌هایی که قبلاً منتشر شده‌اند پس گرفته شود؛ دقیقاً به همین دلیل است که ایجاد فورک (fork) امکان‌پذیر است. OpenSearch از Elasticsearch 7.10.2 ساخته شد، که آخرین نسخه‌ای بود که Elastic تحت مجوز Apache 2.0 منتشر کرد. آنچه از دست می‌دهید آینده است، زیرا وصله‌های امنیتی بعدی تحت شرایط جدید ارائه می‌شوند. ثابت نگه‌داشتن (pinning) آخرین نسخه با مجوز آزاد، تنها چند ماه برای شما زمان می‌خرد و این یک استراتژی بلندمدت نیست.