تاریخچه نرم‌افزار متن‌باز و تحول مجوزهای آن

نرم‌افزار متن‌باز چیست و از کجا آمده است

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

این نسخه کوتاه ماجراست. نسخه طولانی اهمیت دارد، زیرا نرم‌افزاری که امروز روی سرور خود اجرا می‌کنید، همچنان تحت تأثیر آن تصمیمات است. برخی از آن تصمیمات در سال 1983 گرفته شده‌اند. برخی دیگر در سال گذشته اتخاذ شده‌اند و همین تصمیمات دلیل آن هستند که چرا برخی از برنامه‌های موجود در راهنماهای self-hosting ما، اکنون در دو نسخه با نام‌های متفاوت عرضه می‌شوند.

نرم‌افزار پیش از فروش، به اشتراک گذاشته می‌شد

در دهه‌های 1950 و 1960، نرم‌افزار همراه با ماشین ارائه می‌شد. شرکت IBM کد منبع را به همراه سیستم‌های خود عرضه می‌کرد و گروه‌های کاربری مانند SHARE که در سال 1955 تأسیس شد، برنامه‌ها را روی نوار (tape) بین یکدیگر رد و بدل می‌کردند. دو عامل به این وضعیت پایان داد. IBM در سال 1969 اعلام کرد که قیمت‌گذاری نرم‌افزار را از سخت‌افزار جدا می‌کند؛ این کار بازاری مستقل برای نرم‌افزار ایجاد کرد. سپس قانون نیز با این تغییرات همگام شد. قانون حق تکثیر نرم‌افزارهای کامپیوتری مصوب 1980 در ایالات متحده، تأیید کرد که برنامه‌ها آثار مشمول حق تکثیر هستند. پس از سال 1980، کدی که خودتان ننوشته بودید به‌طور پیش‌فرض بسته (closed) محسوب می‌شد، بنابراین اشتراک‌گذاری آن نیازمند کسب اجازه کتبی از نویسنده بود.

باشگاه کامپیوتر Homebrew و نامه سرگشاده به علاقه‌مندان

باشگاه کامپیوتر Homebrew نخستین جلسه خود را در مارس 1975 در گاراژی در Menlo Park کالیفرنیا برگزار کرد. اعضا سخت‌افزار و نوارهای کاغذی به همراه می‌آوردند و کپی‌کردن بخشی از جلسات بود. نرم‌افزار Altair BASIC که توسط Bill Gates و Paul Allen نوشته شده بود، روی نوارهای کپی‌شده در میان حاضران دست‌به‌دست می‌شد. در فوریه 1976، Gates در خبرنامه باشگاه با «نامه‌ای سرگشاده به علاقه‌مندان» پاسخ داد.

همان‌طور که اکثر علاقه‌مندان باید آگاه باشند، بیشتر شما نرم‌افزارهای خود را می‌دزدید.

او نوشت که کمتر از یک نفر از هر 10 مالک Altair برای BASIC پول پرداخت کرده‌اند و زمان کامپیوتری که صرف نوشتن آن شده، بیش از 40,000 دلار ارزش داشته است. تمام استدلال‌های مدرن امروزی از همان نامه آغاز شده است. کپی‌کردن نرم‌افزار هزینه‌ای ندارد و به هر کسی که آن را کپی می‌کند کمک می‌کند. اما نوشتن آن همچنان برای کسی هزینه یک سال از عمرش را در بر داشته است. هر مجوزی که در ادامه شرح داده می‌شود، تلاشی برای پاسخگویی همزمان به هر دوی این واقعیت‌هاست.

پروژه GNU در سال 1983 و اختراع حقوقی GPL

ریچارد استالمن پروژه GNU را در سپتامبر 1983 در Usenet اعلام کرد؛ شبکهٔ گروه خبری که مردم پیش از ظهور وب از آن استفاده می‌کردند. عبارت GNU مخفف "GNU's Not Unix" است. برنامه این بود که یک سیستم کاملاً سازگار با Unix ساخته شود که هر کسی بتواند آن را کپی و تغییر دهد.

یونیکس آزاد! از این عید شکرگزاری، قصد دارم یک سیستم نرم‌افزاری کامل و سازگار با Unix به نام GNU (مخفف Gnu's Not Unix) بنویسم و آن را به‌صورت رایگان در اختیار هر کسی که بتواند از آن استفاده کند، قرار دهم.

بنیاد نرم‌افزارهای آزاد (FSF) در سال 1985 تأسیس شد. «تعریف نرم‌افزار آزاد» این بنیاد، چهار آزادی را فهرست می‌کند که از شماره صفر شروع می‌شوند: اجرای برنامه برای هر هدفی، مطالعه و تغییر آن، بازنشر نسخه‌ها، و توزیع نسخه‌های تغییریافتهٔ خود. آزادی شماره 1 مستلزم دسترسی به سورس‌کد است، زیرا هیچ‌کس نمی‌تواند یک فایل باینری را به شکل عملی مطالعه کند. واژه "Free" در اینجا به معنای آزادی است و نه قیمت. عبارت اختصاصی FSF این است: آزاد به معنای آزادی بیان، نه آزاد به معنای آبجوی رایگان.

مانیفست، اختراع اصلی نبود؛ بلکه مجوز آن بود. مجوز عمومی همگانی گنو (GPL) از حق تکثیر (copyright) برای الزام به اشتراک‌گذاری استفاده می‌کند، نه برای جلوگیری از آن. شما این چهار آزادی را با یک شرط دریافت می‌کنید: هر کسی که نرم‌افزار را به او می‌دهید نیز باید آن‌ها را به همراه سورس‌کد دریافت کند. استالمن این مفهوم را copyleft نامید. این مجوز اولین بار در سال 1985 همراه با GNU Emacs عرضه شد، در سال 1989 به نسخه 1 از GPL تبدیل شد و در ژوئن 1991 نسخه 2 آن منتشر گردید.

مجوز GPL به این دلیل کارآمد است که بر پایه قانون حق تکثیر بنا شده، نه در تقابل با آن. بدون مجوز، شما اصلاً حقی برای توزیع کد شخص دیگری ندارید. GPL این حق را اعطا کرده و شرایطی را به آن پیوست می‌کند. بنابراین، فروشنده‌ای که کد تغییریافتهٔ GPL را در یک روتر عرضه می‌کند و از ارائه سورس‌کد خودداری می‌ورزد، تنها یک وعده را زیر پا نگذاشته است؛ بلکه در حال نقض حق تکثیر است که دارندهٔ حق تکثیر می‌تواند آن را در دادگاه پیگیری کند. به همین دلیل است که اجرای آن ممکن شده است؛ از پرونده‌های gpl-violations.org هارالد ولته در دهه 2000 گرفته تا شکایت Software Freedom Conservancy علیه Vizio که در سال 2021 ثبت شد و استدلال می‌کند شخصی که تلویزیون را خریده است، می‌تواند سورس‌کد آن را نیز مطالبه کند.

تکمیل سیستم‌عامل توسط Linux

تا سال 1991، پروژه GNU شامل کامپایلر، کتابخانه C، شل و اکثر ابزارهای مورد نیاز بود. این پروژه فاقد یک هسته (kernel) عملیاتی بود، زیرا توسعه هسته اختصاصی GNU یعنی Hurd، بسیار طولانی‌تر از زمان‌بندی پیش‌بینی‌شده به طول انجامید. در اوت 1991، یک دانشجو در هلسینکی پیامی را در گروه خبری comp.os.minix منتشر کرد:

من در حال ساخت یک سیستم‌عامل (رایگان) برای کامپیوترهای 386(486) AT هستم (فقط یک سرگرمی است، قرار نیست مثل gnu بزرگ و حرفه‌ای باشد).

نسخه 0.01 از Linux در سپتامبر 1991 تحت مجوزی که خود Linus Torvalds نوشته بود منتشر شد؛ مجوزی که فروش آن را ممنوع می‌کرد. او در اوایل سال 1992 این مجوز را با GPLv2 جایگزین کرد و از آن زمان اعلام کرده است که این یکی از بهترین تصمیمات او بوده است. این مجوز همان عاملی بود که مشارکت شرکت‌ها را امن کرد: یک شرکت می‌توانست مهندسان خود را برای کار روی هسته اختصاص دهد، با این اطمینان که رقیب نمی‌تواند آن بهبودها را به صورت خصوصی تصاحب کند.

یک سیستم‌عامل Unix آزاد پیش‌تر در Berkeley وجود داشت. دلیل اینکه Linux و نه BSD (مخفف Berkeley Software Distribution) به Unix آزاد پیش‌فرض تبدیل شد، تا حدی به یک دعوی حقوقی بازمی‌گردد. شرکت Unix System Laboratories در سال 1992 از Berkeley Software Design شکایت کرد و این پرونده تا اوایل سال 1994 ادامه داشت. در طول آن دو سال، سیستم‌های BSD دارای ریسک حقوقی بودند اما Linux هیچ ریسکی نداشت، و دقیقاً در همان زمان بود که کاربران به سمت آن جذب شدند. بنیاد FSF از مردم می‌خواهد که این سیستم ترکیبی را GNU/Linux بنامند، زیرا Linux تنها هسته است و اکثر ابزارهای پیرامون آن متعلق به GNU هستند. اکثر مردم از نام Linux استفاده می‌کنند. هر دو نام به یک مجموعه نرم‌افزاری واحد اشاره دارند.

1998: تغییر برند متن‌باز و شکافی که هرگز ترمیم نشد

در ژانویه 1998، شرکت Netscape اعلام کرد که کد منبع مرورگر خود را منتشر خواهد کرد. این بزرگ‌ترین شرکتی بود که تا آن زمان چنین اقدامی انجام می‌داد و همین موضوع یک مشکل عملی را آشکار کرد. عبارت "free software" در زبان انگلیسی به معنای "نرم‌افزاری که هزینه‌ای ندارد" برداشت می‌شود و مدیران اجرایی دقیقاً همین برداشت را داشتند. گروهی در فوریه 1998 در پالو آلتو گرد هم آمدند تا اصطلاح بهتری بیابند و کریستین پیترسون پیشنهاد داد از عبارت "open source" استفاده شود. در عرض چند هفته، اریک ریموند و بروس پرنز سازمان Open Source Initiative (OSI) را تأسیس کردند. این سازمان "تعریف متن‌باز" (Open Source Definition) را پذیرفت که از "دستورالعمل‌های نرم‌افزار آزاد دبیان" (Debian Free Software Guidelines) که پرنز در سال 1997 نوشته بود، اقتباس شده بود.

تعریف متن‌باز دارای 10 معیار است. دو مورد از آن‌ها تعیین‌کننده اکثر بحث‌های مدرن هستند: کد منبع باید در دسترس باشد و مجوز نباید محدود کند که چه کسی می‌تواند از برنامه استفاده کند یا برای چه هدفی می‌تواند از آن استفاده نماید. مجوزی که می‌گوید "شما نمی‌توانید این را به عنوان یک سرویس تجاری ارائه دهید"، در این آزمون مردود می‌شود، فارغ از اینکه چه موارد دیگری را مجاز می‌شمارد. این جمله را به خاطر بسپارید. این همان خط قرمزی است که مجوزهای source-available امروزی از آن عبور می‌کنند.

شکافی که در سال 1998 ایجاد شد، بر سر دلایل است، نه بر سر اینکه کدام مجوزها قابل‌قبول هستند. استدلال FSF اخلاقی است: کاربری که نمی‌تواند برنامه را تغییر دهد، کنترلی بر رایانه خود ندارد. استدلال OSI که توسط مقاله اریک ریموند با عنوان "The Cathedral and the Bazaar" برای کسب‌وکارها مطرح شد، عملی است: توسعه باز، نرم‌افزار بهتری تولید می‌کند و یک شرکت می‌تواند از این مزیت بهره‌مند شود. پاسخ استالمن با عنوان "Why Open Source Misses the Point of Free Software" همچنان در gnu.org منتشر می‌شود و او هرگز اصطلاح جدیدتر را نپذیرفته است. پرنز که در ایجاد آن نقش داشت، در سال 1999 از هیئت مدیره OSI استعفا داد و گفت که این جنبش از نرم‌افزار آزاد فاصله گرفته است.

دقت در مورد اینکه شکاف عملی چقدر کوچک است، ارزشمند است. لیست مجوزهای آزاد FSF و لیست مجوزهای تأییدشده OSI تقریباً در همه موارد، از جمله GPL، MIT، Apache 2.0 و BSD با هم توافق دارند. نویسندگانی که نیاز دارند هر دو معنا را همزمان برسانند، از FOSS (نرم‌افزار آزاد و متن‌باز) یا FLOSS (نرم‌افزار آزاد/لیبره و متن‌باز) استفاده می‌کنند.

چگونه شرکت‌ها یاد گرفتند کد را عرضه کنند

عرضهٔ سهام Red Hat در بازار بورس در سال 1999 نشان داد که سود اصلی در پشتیبانی و بسته‌بندی است، نه در فروش نسخه‌های نرم‌افزار. IBM در سال 2001 مبلغ یک میلیارد دلار را به Linux اختصاص داد. مدیرعامل Microsoft در سال 2001، Linux را «یک سرطان» نامید، اما همین شرکت در سال 2016 به عنوان عضو پلاتینیوم به Linux Foundation پیوست و سپس در سال 2018، GitHub را با مبلغ 7.5 میلیارد دلار سهام خریداری کرد. IBM در سال 2019، Red Hat را به مبلغ 34 میلیارد دلار خرید. هیچ‌کدام از این موارد به معنای تغییر عقیده دربارهٔ مجوزها نبود؛ بلکه نشان‌دهندهٔ تغییر در محل تمرکز سود مالی بود. وقتی یک سیستم‌عامل به هزینه‌ای مشترک تبدیل می‌شود، پرداخت هزینه برای نگهداری نسخهٔ اختصاصی خود گران تمام می‌شود و هر فروشنده‌ای ترجیح می‌دهد در لایهٔ بالاتر از آن رقابت کند.

مالکیت شرکتی جنبهٔ دیگری هم دارد. وقتی Oracle در سال 2010 شرکت Sun را خرید، مالکیت MySQL و OpenOffice.org را نیز به دست آورد و هر دو جامعهٔ کاربری از آن جدا شدند. MariaDB از دل MySQL رشد کرد و LibreOffice در سپتامبر 2010 از OpenOffice.org انشعاب (fork) یافت. انشعاب تنها رأیی است که یک جامعهٔ کاربری واقعاً در اختیار دارد و مجوز نرم‌افزار همان چیزی است که این رأی را ممکن می‌سازد.

چرا برخی از برنامه‌هایی که خود میزبانی می‌کنید اکنون دارای انشعاب (Fork) هستند

از سال 2018 به بعد، گروهی از شرکت‌ها شرایط استفاده از نرم‌افزارهایی را که قبلاً منتشر کرده بودند، تغییر دادند. وضعیت در هر مورد مشابه بود. یک شرکت تقریباً تمام توسعه‌دهندگان را در استخدام داشت، یک ارائه‌دهندهٔ ابری بسیار بزرگ‌تر همان نرم‌افزار را به‌عنوان یک سرویس مدیریت‌شده می‌فروخت و شرکت کوچک‌تر به این نتیجه رسید که دلیل عدم توانایی‌اش در رقابت، مجوز نرم‌افزار است.

• MongoDB در اکتبر 2018 مجوز SSPL (Server Side Public License) را اتخاذ کرد. SSPL بیان می‌کند که اگر نرم‌افزار را به‌عنوان سرویس به دیگران ارائه دهید، باید سورس‌کد تمام مواردی را که برای ارائهٔ آن سرویس استفاده می‌کنید، منتشر کنید. سازمان OSI این مجوز را به‌عنوان متن‌باز نپذیرفت و MongoDB در سال 2019 آن را از فرایند بررسی خارج کرد.
• Redis در سال‌های 2018 و 2019 محدودیت‌های استفاده را به برخی ماژول‌ها اضافه کرد و سپس در مارس 2024 با نسخه 7.4، سرور اصلی را به شرایط دوگانهٔ «سورس-موجود» (source-available) منتقل کرد. چند روز بعد، انشعابی از آخرین نسخه با مجوز BSD تحت عنوان Valkey و زیر نظر بنیاد لینوکس، با حمایت شرکت‌هایی نظیر آمازون، گوگل و اوراکل ایجاد شد. در مه 2025، Redis مجوز AGPLv3 (Affero General Public License version 3) را که مورد تأیید OSI است، به‌عنوان گزینهٔ سوم برای Redis 8 اضافه کرد.
• Elastic در ژانویه 2021، Elasticsearch و Kibana را از مجوز Apache 2.0 به شرایط دوگانهٔ SSPL و Elastic License منتقل کرد. آمازون پروژه OpenSearch را انشعاب داد. Elastic در اوت 2024 مجوز AGPLv3 را به‌عنوان گزینهٔ سوم اضافه کرد و OpenSearch در سپتامبر 2024 تحت عنوان OpenSearch Software Foundation به بنیاد لینوکس منتقل شد.
• HashiCorp در اوت 2023، Terraform و سایر ابزارهای خود را به مجوز BUSL (Business Source License) منتقل کرد. BUSL تا زمانی که معتبر است، یک مجوز متن‌باز محسوب نمی‌شود، زیرا استفادهٔ تجاری رقابتی را ممنوع می‌کند. هر نسخه پس از یک تاریخ مشخص (برای Terraform چهار سال بعد) به یک مجوز متن‌باز تبدیل می‌شود. OpenTofu در عرض چند هفته انشعاب داده شد و اکنون آن نیز تحت نظر بنیاد لینوکس قرار دارد.

هر دو طرف این ماجرا استدلال‌های واقعی دارند و هیچ‌کدام با سوءنیت عمل نمی‌کنند. شرکتی که حقوق 50 کارمند را می‌پردازد در حالی که یک شرکت بسیار بزرگ‌تر کار او را بازفروش می‌کند، با مشکلی مواجه است که با حسن‌نیت حل نمی‌شود. کاربری هم که بر اساس شرایط Apache 2.0 سیستم خود را ساخته و ناگهان با شرایط جدید مواجه شده، با مشکل روبروست و کسی پیش از تغییر، از او نظرخواهی نکرده است. به آنچه در دو مورد از این پرونده‌ها رخ داد توجه کنید. پس از آنکه انشعاب‌ها شکل گرفتند، Elastic و Redis هر دو دوباره مجوزهای کپی‌لفت (copyleft) قوی را اضافه کردند. کپی‌لفت به شکایت اصلی پاسخ داد، زیرا AGPLv3 ارائه‌دهندهٔ سرویس را ملزم می‌کند تغییراتی را که اجرا می‌کند، منتشر نماید. تا اوت 2026، هر دو پروژه و هر دو انشعاب همچنان فعال هستند که این همان نتیجه‌ای است که مجوزها برای امکان‌پذیر ساختن آن طراحی شده‌اند.

چه کسی مجاز به تغییر مجوز است

یک پروژه تنها در صورتی می‌تواند تغییر مجوز (relicense) دهد که یک طرف، حق تکثیر (copyright) تمام بخش‌های آن را در اختیار داشته باشد. شرکت‌ها از دو طریق به این کنترل دست می‌یابند. واگذاری حق تکثیر (Copyright assignment)، مالکیت هر مشارکت را به شرکت منتقل می‌کند. توافق‌نامه مجوز مشارکت‌کننده (CLA)، مالکیت را برای شما حفظ می‌کند اما حقوقی به اندازه کافی گسترده به شرکت اعطا می‌کند تا بتواند اثر شما را با مجوز دیگری منتشر کند. هر یک از این موارد معمولاً با کلیک روی لینکی که یک ربات در اولین pull request شما ارسال می‌کند، امضا می‌شود.

پروژه Linux فاقد CLA است. مشارکت‌ها تحت مجوز GPLv2 و با گواهی مبدأ توسعه‌دهنده (Developer Certificate of Origin) ارسال می‌شوند و حق تکثیر بین هزاران نفر و شرکت توزیع شده است. هیچ‌کس نمی‌تواند مجوز Linux را تغییر دهد، زیرا هیچ‌کس نمی‌تواند تمام آن امضاها را جمع‌آوری کند. همین محافظت برای هر پروژه‌ای با تعداد زیادی دارنده مستقل حق تکثیر اعمال می‌شود و این محافظت، قوی‌تر از یک وعده است، زیرا واقعیتی درباره مالکیت دارایی‌هاست.

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

بنیادها واقعاً چه چیزی برای شما فراهم می‌کنند

یک بنیاد، دارایی‌ها را حفظ کرده و قوانینی را برای نحوه اتخاذ تصمیمات تعیین می‌کند. Apache Software Foundation، Linux Foundation، Cloud Native Computing Foundation (که زیرمجموعه آن است) و Software Freedom Conservancy، هر کدام نسخه‌ای از این وظیفه را انجام می‌دهند. یک بنیاد به‌طور جادویی بی‌طرف نیست. اعضا برای کرسی‌های خود هزینه پرداخت می‌کنند و اکثر افرادی که به‌صورت تمام‌وقت روی یک پروژه بزرگ در بنیاد کار می‌کنند، حقوق خود را از شرکت‌های عضو دریافت می‌کنند. آنچه شما به دست می‌آورید محدودتر است اما همچنان ارزش زیادی دارد: علامت تجاری (trademark) و فرآیند انتشار (release process) متعلق به یک فروشنده خاص نیست، بنابراین هیچ شرکت واحدی نمی‌تواند پروژه را به مالکیت خصوصی خود درآورد.

علامت تجاری بخشی است که افراد از آن غافل می‌شوند. کد دارای مجوز (license) است. نام یک علامت تجاری است و علامت تجاری تحت پوشش مجوز کد قرار نمی‌گیرد. شما همیشه می‌توانید کد را fork کنید. اما معمولاً نمی‌توانید نام آن را حفظ کنید. به همین دلیل است که forkهای مطرح‌شده در این داستان، Valkey، OpenSearch، OpenTofu و Forgejo نامیده می‌شوند.

مسئله نگهدارنده

زیرساخت‌های مدرن بر پایه پروژه‌هایی استوار هستند که توسط یک یا دو نگهدارنده بدون حقوق اداره می‌شوند و خرابی‌ها همان چیزی است که این واقعیت را آشکار می‌کند. باگ Heartbleed در OpenSSL در سال 2014، کتابخانه‌ای را هدف قرار داد که بخش بزرگی از ترافیک رمزنگاری‌شده وب را حمل می‌کرد و توسط تعداد انگشت‌شماری از افراد با بودجه‌ای تقریباً صفر نگهداری می‌شد. Log4Shell در دسامبر 2021، تیم‌های واکنش به حوادث در سراسر جهان را درگیر یک تیم داوطلب کوچک در پروژه Apache Log4j کرد.

در پشتی XZ Utils که در مارس 2024 کشف شد، بارزترین نمونه است؛ زیرا حمله به‌جای کد، نگهدارنده را هدف قرار داد. یک حساب کاربری حدود 2 سال صرف ارائه مشارکت‌های واقعاً مفید در یک کتابخانه فشرده‌سازی کرد که در توزیع‌های مختلف Linux استفاده می‌شد. حساب‌های دیگر، نگهدارنده اصلی و خسته را تحت فشار قرار دادند تا کمک بپذیرد. سپس نگهدارنده جدید، یک در پشتی را در آرشیوهای release قرار داد که سیستم‌هایی را هدف می‌گرفت که در آن‌ها daemon مربوط به SSH (secure shell) به liblzma لینک شده بود. یک توسعه‌دهنده هنگام بررسی علت این‌که چرا ورود به سیستم حدود نیم ثانیه بیشتر از حد انتظار طول می‌کشد، آن را کشف کرد. این یک شانس بود و تمام افراد درگیر به‌طور عمومی به این موضوع اذعان کرده‌اند.

پول شروع به سرازیر شدن کرده است: GitHub Sponsors از سال 2019، Open Collective، صندوق Sovereign Tech Fund آلمان از سال 2022 و پروژه Alpha-Omega از OpenSSF. این بودجه به‌طور نابرابر توزیع می‌شود و معمولاً به پروژه‌هایی می‌رسد که از قبل مشهور هستند. مقررات نیز در راه است. قانون تاب‌آوری سایبری اتحادیه اروپا در دسامبر 2024 لازم‌الاجرا شد و اکثر وظایف آن از دسامبر 2027 اعمال می‌شود. پیش‌نویس‌های اولیه، مسئولیت تولیدکننده را بر دوش داوطلبان بدون حقوق می‌گذاشت، بنابراین متن نهایی پس از لابی‌گری طولانی توسط بنیادها و توزیع‌ها، دسته‌بندی سبک‌تری به نام "مباشر نرم‌افزار متن‌باز" ایجاد کرد.

تاریخچه متن‌باز چه معنایی برای نرم‌افزارهای روی VPS شما دارد

هر برنامه‌ای که در راهنماهای self-hosting ما معرفی شده، تحت تأثیر این تصمیمات قرار دارد. Nextcloud به دلیل یک fork به وجود آمد: در سال 2016، بنیان‌گذار ownCloud و بخش بزرگی از تیم، پروژه را ترک کردند و آن را تحت مجوز AGPLv3 دوباره راه‌اندازی کردند؛ از آن زمان تاکنون، این دو محصول به‌صورت موازی توسعه یافته‌اند. این تاریخچه، پیش‌زمینهٔ جایگزین‌های Nextcloud که ارزش بررسی دارند و جایگزین‌های self-hosted برای Dropbox است که با هر دوی آن‌ها رقابت می‌کنند.

همین الگو در میزبانی Git نیز دیده می‌شود. خود Gitea در سال 2016 به عنوان یک fork از Gogs آغاز شد. در اواخر سال 2022، علامت تجاری و دامنه‌های این پروژه به یک شرکت واگذار شد، در دسامبر همان سال Codeberg پروژه Forgejo را fork کرد و Forgejo در سال 2024 با نسخه 9 از مجوز MIT به GPLv3 تغییر وضعیت داد. هر دو در گزینه‌های سرور Git برای self-hosting بررسی شده‌اند و تفاوت در مجوز، بخش بزرگی از دلیل واگرایی مداوم آن‌هاست. در همین حال، بیشتر نرم‌افزارهای آزاد روی GitHub توسعه می‌یابند؛ پلتفرمی بسته که متعلق به Microsoft است. این موضوع بحثی قدیمی با استدلال‌های معتبر در هر دو سو است: به اینکه GitHub واقعاً چیست مراجعه کنید.

پیش از آنکه سروری را به یک پروژه اختصاص دهید، چهار بررسی ده دقیقه‌ای ارزش انجام دادن دارند:

• فایل LICENSE را در مخزن (repository) بخوانید، نه در صفحه تبلیغاتی آن. وب‌سایت‌ها مدت‌ها پس از آنکه فایل مجوز تغییر کرده باشد، همچنان از عبارت "متن‌باز" استفاده می‌کنند.
• به دنبال CLA یا واگذاری حق کپی‌رایت (copyright assignment) بگردید. اگر چنین چیزی وجود داشته باشد، یک مالک واحد می‌تواند شرایط نسخه‌های آینده را تغییر دهد.
• بررسی کنید چه کسی حق کپی‌رایت را در اختیار دارد: یک شرکت، مشارکت‌کنندگان متعدد یا یک بنیاد.
• تعداد نگهدارندگان (maintainers) فعال را بشمارید. پروژه‌ای که تنها یک نگهدارنده دارد، هم برای آن شخص و هم برای شما یک ریسک محسوب می‌شود.

هیچ‌کدام از این موارد به معنای اجتناب از نرم‌افزارهای تک‌فروشنده (single-vendor) نیست. بسیاری از آن‌ها عالی هستند و دریافت هزینه اغلب دلیلی است که باعث می‌شود پروژه همچنان نگهداری شود. این نکات به شما می‌گوید که در معرض چه چیزی قرار دارید. هنگام تصمیم‌گیری درباره اینکه چه چیزی ارزش self-hosting دارد، مجوز را در کنار نیازهای حافظه (RAM) در مقایسه قرار دهید.

شما می‌توانید بخشی از این تاریخچه را روی ماشینی که در مقابلتان است بخوانید. هر بسته در سیستم‌های Debian یا Ubuntu شرایط خاص خود را دارد:

ls /usr/share/doc | wc -l
head -n 20 /usr/share/doc/bash/copyright

عدد اول نشان‌دهنده تعداد بسته‌های نصب‌شده‌ای است که فایل کپی‌رایت دارند؛ که معمولاً در یک VPS کوچک چند صد مورد است. دستور دوم، ابتدای فایل مربوط به bash را چاپ می‌کند که به GNU General Public License نسخه 3 اشاره دارد. نبود این فایل به این معنی است که بسته طبق سیاست‌های Debian ساخته نشده است؛ این مورد نادر است و پیش از اعتماد به آن، ارزش بررسی مجدد دارد.

FAQ

تفاوت نرم‌افزار آزاد و متن‌باز چیست؟

این دو اصطلاح تقریباً مجموعه‌ای یکسان از مجوزها را پوشش می‌دهند، اما در مورد دلیل اهمیت این مجوزها اختلاف‌نظر دارند. «نرم‌افزار آزاد» اصطلاحی قدیمی‌تر است که توسط بنیاد نرم‌افزارهای آزاد در سال 1985 مطرح شد و استدلال آن اخلاقی است: کاربری که نمی‌تواند برنامه را تغییر دهد، کنترلی بر رایانه خود ندارد. «متن‌باز» در فوریه 1998 ابداع شد تا توضیح همان مجوزها برای شرکت‌ها آسان‌تر شود و استدلال آن کاربردی است. مجوزهای GPL، MIT، BSD و Apache 2.0 همگی در هر دو فهرست رسمی قرار دارند. نویسندگانی که می‌خواهند به هر دو مفهوم اشاره کنند، از FOSS یا FLOSS استفاده می‌کنند.

آیا نرم‌افزار با سورس در دسترس (source-available) همان متن‌باز است؟

خیر. سورس در دسترس به این معنی است که می‌توانید کد را بخوانید. متن‌باز، طبق تعریف Open Source Definition، به این معنی است که مجوز نباید استفاده‌کنندگان از نرم‌افزار یا هدف استفاده آن‌ها را محدود کند. مجوزهای SSPL و Business Source License هر دو استفاده تجاری رقابتی را محدود می‌کنند، بنابراین هیچ‌کدام طبق آن تعریف متن‌باز نیستند، حتی اگر هر دو سورس خود را منتشر کنند. اگر فقط برای خودتان سرویس را میزبانی می‌کنید، ممکن است این محدودیت هرگز شامل حال شما نشود. اگر قصد دارید محصولی بر پایه آن بسازید، ابتدا متن مجوز را به‌دقت مطالعه کنید.

آیا یک شرکت می‌تواند مجوز متن‌بازی را که قبلاً اعطا کرده است، پس بگیرد؟

برای کدی که قبلاً منتشر کرده است، خیر. آن نسخه تحت همان مجوزی باقی می‌ماند که با آن عرضه شده است؛ دقیقاً به همین دلیل است که فورک‌هایی مانند Valkey و OpenTofu توانستند از آخرین commit دارای مجوز آزاد شروع به کار کنند. کاری که یک شرکت می‌تواند انجام دهد این است که نسخه‌های آینده را تحت شرایط جدید قرار دهد، و این کار را تنها در صورتی می‌تواند انجام دهد که حق کپی‌رایت کل پروژه را از طریق واگذاری یا توافق‌نامه مجوز مشارکت‌کننده (CLA) در اختیار داشته باشد. پروژه‌هایی با دارندگان کپی‌رایت مستقل متعدد، از جمله Linux، توسط هیچ‌کس قابل تغییر مجوز نیستند.

در نرم‌افزارهای self-hosted باید به دنبال چه مجوزی باشم؟

برای نرم‌افزاری که خودتان اجرا می‌کنید و آن را نمی‌فروشید، هر مجوزی که توسط OSI تأیید شده باشد، مانند GPL، AGPL، MIT یا Apache 2.0، تمام نیازهای شما را برآورده می‌کند. بررسی مفیدتر این است که چه کسی حق کپی‌رایت را در اختیار دارد، زیرا این موضوع تعیین می‌کند که آیا شرایط بعداً می‌تواند علیه شما تغییر کند یا خیر. پروژه‌ای که توسط یک بنیاد یا توسط مشارکت‌کنندگان مستقل متعدد نگهداری می‌شود، نمی‌تواند برخلاف میل کاربرانش تغییر مجوز دهد. پروژه‌ای که متعلق به یک فروشنده واحد است و توافق‌نامه مجوز مشارکت‌کننده دارد، می‌تواند تغییر مجوز دهد. هر دو می‌توانند نرم‌افزارهای خوبی باشند. فقط یکی از آن‌ها می‌تواند قوانین را به‌صورت یک‌جانبه تغییر دهد.