پروژه را روی گیتهاب پیچ میکنید و با آن منوی کشویی ساده مواجه میشوید که اغلب آن را پشت سر میگذارید: انتخاب مجوز. کلمات MIT، GPL و Apache ممکن است در نگاه اول شبیه به هم به نظر برسند، اما انتخاب اشتباه میتواند اجازه دهد یک شرکت بزرگ از زحمات شما بهره ببرد و هیچ سهمی به جامعه نکشد. حتی انتخابنکردن مجوز هم به معنای آزادی استفاده نیست؛ بلکه از نظر حقوقی دسترسی غیرمجاز به کد را ایجاد میکند. پشت این گزینههای بهظاهر ساده، نبردی قدیمی بر سر ماهیت آزادی در نرمافزار جاری است که سرنوشت پروژههای میلیونی را شکل میدهد.
چرا این جنگ فقط تئوری نیست؟
در ماه آگوست ۲۰۲۳ شرکت HashiCorp مجوز پروژه معروف Terraform را از یک مجوز پرمیسیو به Business Source License تغییر داد و در عرض چند روز اکوسیستم زیرساخت ابری جهان را به لرزه درآورد. پروژههایی که ماهها بر پایه این ابزار ساخته شده بودند ناگهان با بلاتکلیفی مواجه شدند و جامعه توسعهدهندگان واکنشی قاطع نشان داد: فورک کردن کل پروژه و ساخت جایگزینی کاملاً آزاد به نام OpenTofu با پشتیبانی بنیاد لینوکس. این واقعه نشان داد که یک تغییر کوچک در پاراگرافهای حقوقی میتواند مسیر دهها شرکت و هزاران مهندس زیرساخت را عوض کند.
شکاف بزرگ: دو مکتب فکری در کنار هم
تمام مجوزهای اوپن سورس را میتوان در دو دسته اصلی طبقهبندی کرد که درک تفاوت آنها کلید حل این معماست. گروه نخست شامل مجوزهای پرمیسیو یا MIT، Apache و BSD است که شعارشان ساده است: کد را بردار، تغییر بده و در نرمافزارهای تجاری و بستهات استفاده کن. تنها شرط آنها حفظ نام نویسنده اصلی است. نویسنده عمداً کنترل نهایی بر کد را واگذار میکند تا بیشترین میزان پذیرش را به دست آورد. گروه دوم یعنی کپیلفتها مانند GPL، AGPL و LGPL فلسفه متفاوتی دارند. آنها میگویند اگر کد ما را در پروژهات دخیل کردی و آن را توزیع میکنی، باید تمام کد نهاییات را هم با همان شرایط آزاد منتشر کنی. این پدیده که آن را اثر ویروسی مینامند، در واقع یک سپر دفاعی است تا شرکتهای غولپیکر نتوانند حاصل همکاریهای رایگان جامعه را بسته کرده و به تنهایی بفروشند.
مجوز MIT: سریعترین مسیر برای رشد
با حدود ۳۵ درصد سهم بازار گیتهاب، مجوز MIT محبوبترین و کوتاهترین سند حقوقی در دنیای توسعه نرمافزار است. این مجوز تقریباً هیچ مانعی سر راه استفادهکنندگان نمیگذارد و دقیقاً همان چیزی است که پروژههای عظیمی مثل React، Ruby on Rails و Node.js را به موفقیت جهانی رساند. وقتی کد شما را با MIT منتشر میکنید، از یک فریلنسر تا یک شرکت چند میلیارد دلاری میتوانند بدون نگرانی از چالشهای حقوقی از آن استفاده کنند. تنها هزینه فلسفی این آزادی، عدم الزام به بازگرداندن تغییرات به مخزن اصلی و نداشتن پوشش مشخص برای حق اختراع است. برای آشنایی با جزئیات حقوقی، میتوانید متن رسمی مجوز MIT را مطالعه کنید.
مجوز Apache 2.0: پل ارتباطی میان آزادی و امنیت
اگر MIT را آزادی مطلق بدانیم، Apache 2.0 تعادلی هوشمندانه میان انعطافپذیری و حفاظت قانونی ایجاد میکند. این مجوز علاوه بر شرایط مشابه MIT، یک بند حیاتی دیگر هم دارد: اعطای صریح حق بهرهبرداری از پتنتها. یعنی اگر شرکتی از کد Apache استفاده کند و بعداً ادعای پتنتی روی آن داشته باشد، قانوناً حق شکایت ندارد. همچنین این مجوز از توسعهدهنده میخواهد تغییرات اعمالشده روی کد را مستند کند. به همین دلیل است که Apache 2.0 در پروژههای سازمانی و بانکی که نگرانیهای حقوقی پتنت آنها را تهدید میکند، به شدت طرفدار دارد. آگهی رسمی بنیاد Apache درباره ساختار این مجوز در اینجا در دسترس است.
مجوز GPL: آخرین خط دفاعی اوپن سورس
وقتی هدف اصلی شما این باشد که پروژهتان هرگز در قفسه انحصار محبوس نشود، GPL گزینه طبیعی شماست. این مجوز با اصرار بر باز بودن کد در تمام لایههای توزیع، تضمین میکند که هر بهبودی که روی پایههای کد شما ساخته شود، مجدداً در اختیار عموم قرار میگیرد. توزیعکنندگان اصلی لینوکس سالهاست که برای حفظ اکوسیستم توزیعهای یونیکسمحور از این سپر استفاده میکنند. البته استفاده از GPL ریسکهایی هم دارد؛ اگر کدی با مجوز GPL را در پروژهای ادغام کنید که قصد دارید آن را تجاری و بسته بفروشید، قانوناً مجاز به انجام این کار نیستید. جامعه پیشکسوتان اوپن سورس در شبکه توزیعکنندگان پروژه GNU این فلسفه را با جزئیات فنی شرح دادهاند.
چگونه بهترین مجوز را برای پروژهتان انتخاب کنید؟
انتخاب نهایی کاملاً به هدف استراتژیک شما گره خورده است. مسیرهای پیشرو را با دقت بسنجید:
- رشد سریع و پذیرش حداکثری: اگر کتابخانهای میسازید که میخواهید توسط همه و بدون ترس استفاده شود، MIT یا Apache بهترین گزینهاند.
- حفاظت حقوقی و پتنت: برای پروژههای سازمانی که نگرانیهای امنیتی و حقوقی دارند، Apache 2.0 با پوشش صریح پتنت پیشنهاد میشود.
- حفظ ماهیت اوپن سورس: اگر نمیخواهید کدهایتان روزی به محصول تجاری بسته تبدیل شود، GPL یا AGPL تنها خطوط دفاعی قطعی هستند.
پیش از انتشار نهایی، سازگاری مجوز انتخابی با تکنولوژیهای شخص ثالث را بررسی کنید تا از بنبستهای حقوقی جلوگیری شود.
آینده مجوزها در عصر تولید کد خودکار
با ورود مدلهای زبانی بزرگ و ابزارهای تولید کد به خطوط مقدم توسعه نرمافزار، نبردهای حقوقی قدیمی با چالشهای جدیدی مواجه شدهاند. شرکتها اکنون به جای جنگ بر سر مجوزهای کدهای آماده، بیشتر روی مالکیت خروجیهای هوش مصنوعی تمرکز کردهاند. نحوه تعریف مجوزها در سالهای آینده احتمالاً از مفاهیم سنتی کپیرایت فاصله گرفته و به سمت مدلهای مبتنی بر داده و مدلهای آموزشی حرکت خواهد کرد. توسعهدهندگانی که امروز ساختار کدهای خود را میسازند، در واقع پایههای حقوقی نسل بعدی نرمافزارها را ترسیم میکنند.
