منبع باز (Open Source) دنیای فناوری را به حرکت درمی‌آورد و تا ۹۰٪ از عقبه نرم‌افزاری مدرن را از طریق چارچوب‌ها (frameworks)، کتابخانه‌ها (libraries)، پایگاه‌های داده (databases)، سیستم‌های عامل (operating systems) و تعداد بی‌شماری از برنامه‌های مستقل تشکیل می‌دهد.
مزایای نرم‌افزارهای منبع باز به خوبی درک شده‌اند و کنترل و شفافیت بیشتری را وعده می‌دهند. با این حال، یک کشمکش همیشگی بین دنیای منبع باز و نرم‌افزارهای انحصاری (proprietary) وجود دارد که باعث می‌شود بسیاری از شرکت‌ها برای محافظت از منافع تجاری خود از منبع باز فاصله بگیرند. در قلب همه این مسائل، موضوع پیچیده مجوزها (licensing) قرار دارد.
دو نوع کلی از مجوزها وجود دارند که با تعریف رسمی منبع باز از سوی ابتکار منبع باز (Open Source Initiative یا OSI) مطابقت دارند. مجوزهای "آسان‌گیر" (Permissive) محدودیت‌های کمی در مورد چگونگی تغییر و توزیع نرم‌افزار دارند و همین موضوع آن‌ها را برای شرکت‌هایی که می‌خواهند از نرم‌افزار به صورت تجاری استفاده کنند، محبوب کرده است. از سوی دیگر، مجوزهای "کپی‌لفت" (Copyleft) آزادی‌های مشابهی ارائه می‌دهند اما با یک شرط مهم: هر نسخه تغییر یافته از نرم‌افزار نیز باید تحت همان مجوز کپی‌لفت اولیه توزیع شود. این موضوع برای کسب‌وکارهایی که می‌خواهند کارهای انحصاری خود را محافظت کنند، چندان جذاب نیست.
اما این موضوع فراتر از این است و در هر دسته‌بندی، مجوزهای مختلفی وجود دارند. علاوه بر این، تعداد بی‌شماری از مجوزها وجود دارند که اگرچه به طور دقیق منبع باز محسوب نمی‌شوند، اما ارزش دانستن دارند.
مجوز MIT (مجوز آسان‌گیر)
مجوز MIT که در دهه ۱۹۸۰ در مؤسسه فناوری ماساچوست (MIT) ایجاد شد، با نام مناسب خود، محبوب‌ترین مجوز منبع باز از نظر بسیاری از معیارهاست و برای سال‌ها در صدر فهرست مجوزهای مورد استفاده در جامعه توسعه‌دهندگان GitHub قرار داشته است.
این مجوز توسط پروژه‌هایی مانند React (کتابخانه جاوااسکریپت برای فرانت‌اند) و Ruby (زبان برنامه‌نویسی همه‌منظوره) استفاده می‌شود و به توسعه‌دهندگان اجازه می‌دهد از نرم‌افزار به هر شکلی که مایل هستند استفاده کنند. مانند اکثر مجوزهای مشابه، این مجوز بدون هیچ گونه ضمانتی ارائه می‌شود، به این معنی که نویسندگان از هرگونه مسئولیت ناشی از خسارات ایجاد شده توسط نرم‌افزار خود (مانند از دست دادن داده‌ها) مبرا هستند. تنها چیزی که توسعه‌دهندگان باید رعایت کنند، این است که اطلاعیه کپی‌رایت اصلی و مجوز MIT را در هر کار مشتق‌شده قرار دهند.
با این حال، مجوز MIT یک نقطه ضعف دارد: این مجوز به طور صریح حقوق مربوط به اختراعات (پتنت) را اعطا نمی‌کند. این بدان معناست که اگر یک نرم‌افزار خاص به فناوری‌های دارای پتنت متکی باشد، ممکن است برای توسعه‌دهندگانی که این نرم‌افزار را بدون اخذ مجوزهای جداگانه برای آن فناوری‌های دارای پتنت استفاده می‌کنند، ابهامات قانونی ایجاد کند.
اما این موضوع یکی از نقاط قوت کلیدی مجوز MIT را نیز نشان می‌دهد: این مجوز تنها با ۲۰۰ کلمه، زبانی ساده و مختصر دارد. اضافه کردن عبارات پیچیده و مبهم مربوط به پتنت‌ها، تنها باعث افزایش پیچیدگی‌های غیرضروری برای پروژه‌هایی می‌شد که احتمالاً نگرانی‌ای در مورد پتنت‌ها ندارند، مانند زبان‌های برنامه‌نویسی سطح بالا یا چارچوب‌های وب.
با این حال، بسیاری از پروژه‌های منبع باز با فناوری‌های دارای پتنت در ارتباط هستند، مانند نرم‌افزارهای مرتبط با سخت‌افزار مانند اندروید.
مجوز Apache 2.0
بنیاد نرم‌افزار Apache (Apache Software Foundation) مجوز Apache 2.0 را در سال ۲۰۰۴ منتشر کرد، که به‌روزرسانی‌ای از یک مجوز قدیمی‌تر بود و شامل اعطای صریح حقوق پتنت برای محافظت از کاربران در برابر دعاوی حقوقی می‌شد. به عنوان مثال، اگر یک توسعه‌دهنده الگوریتم پردازش تصویر منحصر به فردی را به یک پروژه تحت مجوز Apache 2.0 اضافه کند، هرگونه پتنتی که آن توسعه‌دهنده برای آن الگوریتم دارد، به طور خودکار به تمام کاربران آن نرم‌افزار اعطا می‌شود.
بسیاری از افراد با برند اندروید گوگل آشنا هستند، که شامل فروشگاه اپلیکیشن (Google Play) و مجموعه‌ای از ابزارها و خدمات داخلی است. اما پروژه منبع باز اندروید (Android Open Source Project یا AOSP) به طور عمده تحت مجوز Apache 2.0 در دسترس است. این اقدام عمدی گوگل در سال ۲۰۰۸ برای مقابله با اپل و تشویق تولیدکنندگان تلفن‌های همراه به استفاده از اندروید در مقابل دیگر رقبای انحصاری آن زمان (مانند سیمبیان) بود. و این استراتژی جواب داد. شرکت‌هایی مانند سامسونگ، اچ‌تی‌سی، الجی و بقیه به اندروید پیوستند.
با این حال، یک محصول جانبی این تصمیم این است که مجوز Apache 2.0 به دلیل متن مربوط به اعطای حقوق پتنت و سایر اضافات و توضیحات، حدود پنج برابر طولانی‌تر از مجوز MIT است. اما این یک معامله است و تفاوت‌های کلیدی بین دو مجوز آسان‌گیر (permissive) منبع باز را نشان می‌دهد.
کپی‌لفت (Copyleft)
مجوز عمومی همگانی گنو (GNU General Public License یا GPL) نسخه‌های ۲.۰ و ۳.۰
بنیاد نرم‌افزار آزاد (Free Software Foundation یا FSF) مجوز عمومی همگانی گنو (GPL) را در سال ۱۹۸۹ منتشر کرد، که یکی از اولین مجوزهای کپی‌لفت برای استفاده عمومی بود.
مجوزهای کپی‌لفت اغلب برای پروژه‌هایی که نیازمند مشارکت جامعه هستند، مناسب‌ترند تا پروژه‌هایی که توسط یک نهاد شرکتی واحد پشتیبانی می‌شوند. با الزام به اینکه تمام تغییرات تحت همان مجوز منبع باز باقی بمانند، این مجوزها به مشارکت‌کنندگان اطمینان می‌دهند که زحمات آن‌ها بدون سود رساندن به جامعه گسترده‌تر، در نرم‌افزارهای انحصاری استفاده نخواهد شد — حداقل در تئوری، زیرا کشف هرگونه تخلف و اجرای شرایط مجوز می‌تواند دشوار باشد.
مجوز GPL 3.0 که در سال ۲۰۰۷ راه‌اندازی شد، بر اساس داده‌های GitHub، سومین مجوز محبوب است. این مجوز به‌روزرسانی‌های قابل توجهی نسبت به GPL 2.0 ارائه کرد، از جمله مفاد مربوط به اعطای حقوق پتنت و بهبود سازگاری با سایر مجوزهای منبع باز که کلی از دردسر های احتمالی را می کاهد. همچنین این مجوز از پدیده‌ای به نام "تیووی‌سازی" (Tivoization) جلوگیری می‌کند، جایی که سازندگان سخت‌افزار که از نرم‌افزارهای تحت مجوز GPL بهره می‌برند، با استفاده از مکانیزم‌های مدیریت حقوق دیجیتال (DRM)، کاربران را از نصب نسخه‌های تغییر یافته آن نرم‌افزار منع می‌کنند.
از جمله پروژه‌های مشهوری که از GPL استفاده می‌کنند، می‌توان به وردپرس اشاره کرد که تحت مجوز GPL 2.0 "یا بالاتر" در دسترس است. این به توسعه‌دهنده اجازه می‌دهد تصمیم بگیرد که هرگونه تغییر را تحت کدام نسخه از مجوز توزیع کند.
لینوکس نیز یکی از موفق‌ترین پروژه‌های منبع باز در تمام دوران است که در سرورها، زیرساخت‌های ابری، سیستم‌های توکار و حتی اندروید استفاده می‌شود. با این حال، هسته لینوکس تنها تحت مجوز GPL 2.0 در دسترس است، زیرا لینوس توروالدز، خالق لینوکس، با برخی از مفاد اضافه‌شده در نسخه ۳.۰ این مجوز — از جمله بند مربوط به تیووی‌سازی — مخالف است.
مجوز عمومی همگانی Affero گنو (GNU Affero General Public License یا AGPL) نسخه ۳.۰
مجوز عمومی همگانی Affero (AGPL) شباهت زیادی به GPL 3.0 دارد، به این معنا که یک مجوز کپی‌لفت "قوی" است که آزادی‌های نرم‌افزاری را ترویج می‌کند و تضمین می‌کند که نسخه‌های تغییر یافته نیز تحت مجوز منبع باز باقی بمانند. با این حال، یک تفاوت کلیدی در AGPL این است که این مجوز بر روی سرویس‌ها و برنامه‌های مبتنی بر وب متمرکز است، جایی که نرم‌افزار از سرورها اجرا می‌شود و نه به عنوان فایل‌های اجرایی توزیع می‌شود.
تحت مجوز GPL 3.0، توسعه‌دهندگان ملزم نیستند کد منبع نرم‌افزار تغییر یافته را منتشر کنند اگر این نرم‌افزار از طریق شبکه اجرا شود، مانند برنامه‌های SaaS. مجوز AGPL این خلأ را پر می‌کند و از طرف‌های سوم می‌خواهد که حتی اگر نرم‌افزار تغییر یافته فقط از روی سرور اجرا می‌شود، کد منبع آن را در دسترس قرار دهند.
مجوز AGPL 3.0 که در سال ۲۰۰۷ توسط بنیاد نرم‌افزار آزاد (Free Software Foundation) منتشر شد، به دلیل رشد فزاینده رایانش ابری و SaaS، محبوبیت زیادی پیدا کرده است و امروزه پنجمین مجوز منبع باز محبوب محسوب می‌شود.
مجوز عمومی موزیلا (Mozilla Public License یا MPL) نسخه ۲.۰
مجوز عمومی موزیلا (MPL) 2.0 که در سال ۲۰۱۲ توسط بنیاد موزیلا منتشر شد، بر اساس معیارهای مجوزهای GitHub، دهمین مجوز منبع باز محبوب امروز است. MPL نیز یک مجوز کپی‌لفت "ضعیف" است که برای محافظت از کدهای انحصاری طراحی شده است، در حالی که به توسعه‌دهندگان اجازه می‌دهد از نرم‌افزارهای منبع باز بهره‌مند شوند.
با این حال، در حالی که LGPL بر سطح کتابخانه‌ها (libraries) متمرکز است و GPL بر سطح پروژه، MPL در سطح فایل‌های فردی عمل می‌کند و از کاربر می‌خواهد مجموعه محدودتری از کد را به اشتراک بگذارد.
محدوده عمومی (Public Domain) و Creative Commons
در حالی که یک "مجوز منبع باز" حقوق خاصی را اعطا می‌کند، همیشه شرایطی به آن‌ها پیوست شده است. با این حال، کسانی که می‌خواهند نرم‌افزار خود را بدون هیچ قید و شرطی به طور کامل در محدوده عمومی (Public Domain) قرار دهند، می‌توانند این کار را از طریق روش‌های دیگر انجام دهند.
فقط انتشار نرم‌افزار بدون مجوز کافی نیست؛ قانون کپی‌رایت به طور پیش‌فرض برای اکثر آثار خلاقانه، از جمله نرم‌افزار، اعمال می‌شود. اینجاست که یک "اهدای عمومی" (Public Domain Dedication) می‌تواند کمک کند.
Unlicense که به طور خاص برای نرم‌افزار طراحی شده است، نهمین مجوز محبوب در GitHub است (اگرچه این بحث‌برانگیز است که آیا واقعاً می‌توان آن را یک "مجوز" نامید یا خیر). حتی اگر OSI آن را در سال ۲۰۲۰ به عنوان یک مجوز تأیید کرد، اشاره کرد که این سند "به‌دقت تنظیم نشده" است و کارایی قانونی آن را در حوزه‌های قضایی خاص (مانند آلمان) زیر سؤال برد، جایی که اهدای کار به محدوده عمومی امکان‌پذیر نیست.
مانند Unlicense، ابزار CC0-1.0 از Creative Commons نیز یک ابزار اهدای عمومی است، اما تمرکز آن بیشتر بر روی آثار خلاقانه به طور کلی است. این ابزار از زبان حقوقی واضح‌تر و حرفه‌ای‌تری استفاده می‌کند که ممکن است با قوانین بین‌المللی سازگارتر باشد. لازم به ذکر است که Creative Commons در سال ۲۰۱۲ درخواست کرد تا CC0-1.0 به عنوان یک مجوز سازگار با منبع باز تأیید شود، اما پس از اینکه OSI نگرانی‌هایی را مطرح کرد مبنی بر اینکه این مجوز به صراحت حقوق پتنت را مستثنی می‌کند، درخواست خود را پس گرفت.
ابزارهای دیگری نیز برای اهدای عمومی وجود دارند، مانند Zero-Clause BSD، که ممکن است به دلیل زبان ساده‌تر آن جذاب باشد. با این حال، هیچ اجماعی در مورد بهترین مکانیزم برای واگذاری تمام حقوق یک نرم‌افزار خاص وجود ندارد.