مجوزهای نرم‌افزاری اسناد و متون حقوقی هستند که توسط حقوقدانان و کارشناسان حوزه فناوری تدوین می‌شوند تا شرایط استفاده، تغییر، توسعه و بازنشر یک برنامه یا کد منبع را مشخص کنند.
این متون در قالب چندین بند و تبصره نوشته می‌شوند و برای توسعه‌دهندگان و کاربران مشخص می‌کنند که دقیقاً چه حقوقی در برابر آن کد دارند و پدیدآورنده پروژه چه انتظارات یا شروطی تعیین کرده است.
دسته‌بندی کلی مجوزهای نرم‌افزاری
مجوزهای نرم‌افزاری را می‌توان به دو دسته کلی تقسیم کرد:
۱. مجوزهای انحصاری و مالکیتی (Proprietary): در نرم‌افزارهای تجاری و بسته (مانند سیستم‌عامل ویندوز یا فتوشاپ)، کاربر صرفاً حق استفاده محدود از برنامه را تحت یک توافق‌نامه کاربری نهایی (EULA) دریافت می‌کند. در این حالت، کاربر مالک نرم‌افزار نیست و حق دسترسی به سورس‌کد، مهندسی معکوس، تغییر یا بازتوزیع برنامه را ندارد.
نکته فنی-حقوقی: وارد کردن کلید فعالسازی (Product Key) یا فعالسازی آنلاین صرفاً ابزارهای فنی برای مدیریت حقوق دیجیتال و کنترل دسترسی (DRM) هستند و نباید با خودِ سند حقوقی مجوز اشتباه گرفته شوند. مثلاً در اصطلاح رایج «خرید لایسنس ویندوز»، آنچه در عمل مبادله می‌شود «کلید فعالسازی» است، در حالی که مجوز، همان متن شروط و توافق‌نامه‌ای است که هنگام نصب می‌پذیرید.
۲. مجوزهای آزاد و متن‌باز (Free & Open Source): مجوزهایی مانند GPL، MIT و Apache که به کاربران اجازه می‌دهند سورس‌کد برنامه را بخوانند، آن را مطابق نیاز خود تغییر دهند و حتی نسخه جدید را بازنشر کنند.
چندتا چیز اینجا مهمه. اون ماکرویی که بالای هر تابع گذاشتیم، مسیر و متد HTTP رو مشخص می‌کنه. تابعها هم async هستن و هر چیزی که این trait رو پیاده کرده باشه میتونن برگردونن:
Responder
یعنی رشته، JSON یا یه پاسخ کاملاً دستساز، همهشون قابل برگشتان.
اکستراکتورها، قلب ماجرا
به نظر من باحالترین بخش این فریمورک اکستراکتورها (extractors) هستن. لازم نیست خودت بشینی بدنهی درخواست رو بخونی و parse کنی؛ فقط نوع ورودی رو توی امضای تابع مینویسی و تمام:
حالا فرض کن کلاینت بهجای عدد، برای سن یه رشته بفرسته. تابع تو اصلاً اجرا نمیشه و خود فریمورک یه خطای 400 برمیگردونه. همین ایده برای پارامتر مسیر، کوئریاسترینگ، فرم و هدرها هم جواب میده. خلاصه کلی از کد اعتبارسنجی که توی فریمورک‌های دیگه دستی مینوشتی، اینجا کلاً حذف می‌شه.
سرعت، و چرا نباید زیادی روش حساب باز کنی
همه‌جا میشنوی که این فریمورک توی بنچمارک TechEmpower جزو سریعترینهاست. درسته، سالها توی صدر بوده. ولی بذار رک بگم: توی بیشتر پروژه‌ها گلوگاهت دیتابیس و شبکهست، نه فریمورک. وقتی هر درخواست ۲۰ میلیثانیه منتظر PostgreSQL میمونه، فرق چند ده هزار درخواست در ثانیه دیگه خیلی معنی نداره.
چیزی که واقعاً حسش میکنی، مصرف رم پایین و تأخیر پایداره. سرویسی که با این فریمورک نوشتی معمولاً با چند ده مگابایت رم بالا میاد و زیر بار هم رفتارش قابل پیشبینیه. اگه سرور ارزون داری یا کلی کانتینر بالا میاری، این خیلی بیشتر از عدد بنچمارک به دردت میخوره.
چالهای که همه یه بار توش میافتن
یه نکته: سازندهی سرور یه closure میگیره، نه یه App آماده. چرا؟ چون فریمورک برای هر worker (معمولاً هر هستهی CPU) یه نمونهی جدا از App میسازه.
نتیجهش چی می‌شه؟ اگه داخل همون closure یه شمارنده یا کش بسازی، هر worker نسخه‌ی خودش رو داره و داده‌ها بینشون شریک نمیشه. بعد میشینی دو ساعت دیباگ میکنی که چرا شمارندهت هی صفر می‌شه. راه درستش اینه که state رو بیرون بسازی و اینطوری به اپ بدی:
این نوع در واقع یه Arcه، پس کلون کردنش ارزونه و همهی workerها به یه داده اشاره میکنن:
web::Data<T>
مقایسه با Axum و Rocket
این روزها رقیب اصلیش Axumه که تیم Tokio نگهش میداره. فریمورک Axum روی اکوسیستم Tower ساخته شده و middlewareهاش با بقیهی کتابخونههای Tower جورن. فریمورک Rocket هم سینتکس خوشگلتری داره، ولی جامعهش کوچیکتره.
خب، با انتخاب Actix Web چی از دست میدی؟ سازگاری مستقیم با Tower. این فریمورک برای middleware سیستم خودش رو داره و نوشتنش یه کم پیچیدهتره. در عوض یه فریمورک جاافتاده با مستندات کامل، کلی مثال و ابزارهای آماده برای session، CORS، فایل استاتیک و WebSocket دستت میاد.
اگه نظر من رو بخوای: اگه داری یه پروژهی جدید از صفر شروع میکنی و قبلاً با Tokio و Tower کار کردی، Axum انتخاب طبیعیتریه. ولی اگه دنبال چیزی هستی که همهچی توش باشه و سالها توی پروداکشن تست شده باشه، این فریمورک هنوزم گزینهی خیلی خوبیه.
یه هشدار تاریخی
سال ۲۰۲۰ این پروژه یه دعوای معروف رو از سر گذروند. استفادهی زیاد از کد unsafe کلی انتقاد به پا کرد و سازندهی اصلی یه مدت پروژه رو ول کرد. بعدش نگهداریش افتاد دست یه تیم جدید و بخش زیادی از اون کدها بازنویسی شد.
چرا اینو میگم؟ چون اگه توی فرومها پستهای قدیمی دیدی که میگن «سمت Actix نرو، unsafeه»، بدونی مال پنج سال پیشه. پروژه الان فعاله، مرتب نسخه‌ی جدید میده و حداقل نسخه‌ی Rust که لازم داره ۱.۸۸ه.
از کجا شروع کنی؟
اگه تازه Rust یاد گرفتی، اول با همون مثال بالا یه API کوچیک CRUD بساز و با اکستراکتورها و state ور برو. مخزن examples خود پروژه هم پر از نمونهی آماده برای دیتابیس، احراز هویت و WebSocketه.
ولی یه سؤال هست که خودت باید جوابش رو بدی: واقعاً به سرعت Rust نیاز داری، یا فقط کنجکاوی؟ هر دوش دلیل قابلقبولیه. فقط بدون که زمان کامپایل و کلنجار رفتن با borrow checker هزینهی واقعی دارن، و این فریمورک قرار نیست این هزینه رو کم کنه؛ فقط خوب ازش استفاده می‌کنه.
یک اصل مهم: کلمه «آزاد» در نرم‌افزارهای آزاد به معنای «آزادی عمل در استفاده، مطالعه، تغییر و انتشار» است، نه «رایگان بودن». یک نرم‌افزار آزاد میتواند کاملاً بهصورت تجاری عرضه شود و توسعهدهنده از فروش نسخهها یا ارائه خدمات پشتیبانی آن درآمدزایی کند.
تفاوت در تدوین متن مجوزها
متون مجوزهای آزاد (مانند GPL یا MIT) اسنادی استاندارد، ثابت و ثبت‌شده توسط نهادهای مرجع بینالمللی (مانند بنیاد نرم‌افزار آزاد FSF و بنیاد پیشگامان متن‌باز OSI) هستند؛ بنابراین یک توسعهدهنده نمیتواند متن آنها را سلیقهای تغییر دهد و همچنان آن را با همان نام معتبر منتشر کند. اما توافقنامههای انحصاری (EULA) توسط وکلای هر شرکت به صورت اختصاصی تدوین می‌شوند و ممکن است در هر نسخه جدید از نرم‌افزار دستخوش تغییر شوند.
مفهوم کپیرایت (Copyright) و کپیلفت (Copyleft) در نرم‌افزار
۱. قانون کپیرایت (Copyright)
قانون کپیرایت یا «حق پدیدآورنده» بهصورت خودکار و پیشفرض بر هر کدی که مینویسید اعمال می‌شود؛ یعنی حتی اگر هیچ فایلی به عنوان مجوز در مخزن پروژه خود قرار ندهید، کپیرایت آن منحصراً متعلق به شماست و هیچکس بدون اجازه صریح شما حق استفاده، تغییر یا انتشار آن را ندارد.
وضعیت کپیرایت نرم‌افزار در ایران: در ایران برخلاف تصور عموم، قوانین حمایتی مشخصی وجود دارند؛ از جمله «قانون حمایت از پدیدآورندگان نرم‌افزارهای رایانهای (مصوب ۱۳۷۹)» و «قانون حمایت از حقوق مؤلفان، مصنفان و هنرمندان (مصوب ۱۳۴۸)». علت تصور اشتباه عموم این است که ایران عضو پیمانهای بینالمللی کپیرایت (مانند کنوانسیون برن) نیست؛ به همین خاطر کدهای توسعه‌دهندگان خارجی در ایران مشمول حمایت کپیرایت بینالمللی نمیشوند، اما نرمافزارهایی که توسط توسعه‌دهندگان داخلی پدید آمدهاند، کاملاً تحت حمایت قوانین کپیرایت کشور قرار دارند و بازنشر غیرمجاز آنها قابل پیگرد قضایی است؛ رویکردی که پلتفرمهای پخش فیلم و محصولات بومی نیز برای صیانت از آثار خود به آن استناد می‌کنند.
۲. مفهوم کپیلفت (Copyleft)
مجوزهای نرم‌افزاری مستقل از قانون کشورها نیستند؛ بلکه مشروعیت اجرایی خود را مستقیماً از دل همان قانون کپیرایت می‌گیرند. پدیدآورنده به پشتوانه کپیرایت خود به دیگران اجازه بهرهبرداری می‌دهد، اما میتواند با سازوکار «کپیلفت» شرط بگذارد که این آزادی تا ابد برای نسخه‌های بعدی نیز حفظ شود.
از نظر کپیلفت، مجوزهای آزاد نرم‌افزاری به دو شاخه اصلی تقسیم می‌شوند:
مجوزهای آسانگیر (Permissive): مانند MIT، BSD و Apache که دست توسعهدهنده بعدی را کاملاً باز میگذارند؛ به طوری که او میتواند کد را تغییر داده و حتی در یک نرم‌افزار بسته و انحصاری بدون الزام به انتشار سورس‌کد به کار ببرد.
مجوزهای کپیلفت (Copyleft): مانند GPL که یک شرط اساسی و سفتوسخت دارند: هر پروژه یا کدی که بر پایه این نرم‌افزار ساخته یا از آن مشتق شود، باید حتماً با همان مجوز آزاد و به همراه سورس‌کد در اختیار عموم قرار گیرد تا از انحصاریسازی دستاوردهای جمعی جلوگیری شود.
ساختار و بندهای کلیدی یک مجوز نرم‌افزاری
هر مجوز نرم‌افزاری استاندارد بندهای خود را در سه دسته کلی تنظیم می‌کند:
۱. اختیارات و مجوزها (Permissions): چه کارهایی مجاز است؟
استفاده تجاری از کد، اعمال تغییرات، توزیع مجدد و استفاده در پروژه‌های خصوصی.
۲. شروط و الزامات (Conditions): چه کارهایی را موظفید انجام دهید؟
درج نام پدیدآورنده اصلی و حفظ کپیرایت (Attribution)، قرار دادن متن مجوز اصلی در کنار کدها، و در مجوزهای کپیلفت: الزام به انتشار سورس‌کد پروژه‌های مشتقشده.
۳. محدودیتها و سلب مسئولیت (Limitations): چه مسائلی بر عهده سازنده نیست؟
سلب گارانتی و ضمانت عملکرد (یعنی در صورت بروز خطا، آسیب یا باگ، سازنده هیچ مسئولیت مدنی یا مالی ندارد) و منع استفاده تجاری یا تبلیغاتی از نشان و لوگوی توسعهدهنده اصلی.
نمونههای خاص و جالب از مجوزهای نرم‌افزاری
در کنار مجوزهای رایجی مانند MIT و GPL، نمونههای کمتر شناختهشده و جالبی در دنیای برنامه‌نویسی وجود دارند:
۱. مجوز WTFPL: مجوزی بسیار کوتاه و ساختارشکن با این پیام: «هر کاری دوست داری با این کد بکن!» این مجوز با وجود لحن غیررسمیاش، توسط بنیاد نرم‌افزار آزاد (FSF) به عنوان یک مجوز معتبر و سازگار با GPL پذیرفته شده است. (مشاهده متن مجوز)
۲. مجوز بقراط (Hippocratic License): مجوزی با دغدغه اخلاقی و حقوق بشری که استفاده از کدهای نرم‌افزار را برای اهدافی نظیر نظارت جمعی، صنایع نظامی و سرکوب صراحتاً ممنوع کرده است. (وبسایت پروژه)
۳. مجوز JSON: داگلاس کراکفورد (خالق ساختار JSON) یک جمله ساده به مجوز نرم‌افزار خود اضافه کرد: «این نرم‌افزار باید برای کارهای خوب استفاده شود، نه شرورانه!» همین جمله به ظاهر ساده، سالها وکلای شرکت‌های بزرگی مثل IBM را به دردسر انداخت؛ زیرا از نظر حقوقی نمیتوانستند تضمین کنند مشتریانشان هیچ کار غیرخوبی با نرم‌افزار انجام نمیدهند! (مشاهده مجوز JSON)
نکته تخصصی درباره مجوزهای اخلاقی: شاید بپرسید چرا مجوزهایی مثل JSON یا بقراط استاندارد تلقی نمیشوند؟ از نظر مراجع رسمی نرم‌افزار آزاد و متن‌باز (FSF و OSI)، یک مجوز استاندارد نباید هیچ‌گونه تبعیضی نسبت به حوزه فعالیت، نوع استفاده یا هویت کاربر قائل شود (آزادی صفرم FSF و بند ششم تعاریف متن‌باز OSI). به همین دلیل این مجوزها رسماً جزو FOSS دسته‌بندی نمیشوند.
نحوه انتخاب مجوز برای پروژه نرم‌افزاری
هنگام انتخاب مجوز برای پروژه خود، دو فاکتور اصلی را مد نظر داشته باشید:
۱. فرهنگ اکوسیستم و زبان برنامه‌نویسی: اگر برای جامعه خاصی کد میزنید (مثلاً اکوسیستم لینوکس یا فریمورک‌های وب)، بهتر است از مجوزهای مرسوم در همان اکوسیستم استفاده کنید تا سایر توسعه‌دهندگان برای مشارکت و استفاده از کد شما با موانع حقوقی مواجه نشوند.
۲. بررسی سازگاری مجوزها (License Compatibility): اگر در پروژه خود از کتابخانهها یا پکیجهای دیگران استفاده میکنید، حتماً مجوز آنها را بررسی کنید:
اگر کتابخانهای با مجوز GPL اضافه کنید، کل پروژه شما نیز باید تحت مجوز GPL منتشر شود (به دلیل خاصیت سرایتپذیری کپیلفت).
اما اگر از کتابخانههای با مجوزهای آسانگیر مثل MIT یا Apache استفاده کنید، دست شما برای انتخاب پروانه نهایی پروژه خودتان باز خواهد بود.
شرایط تغییر مجوز (Relicensing) و تله‌های حقوقی گیت‌هاب
تغییر مجوز پروژه‌های مشارکتی: اگر پروژهای تحت مجوزی مانند GPL باشد و چندین برنامهنویس در آن مشارکت کرده باشند، هیچیک از پدیدآورندگان بهتنهایی نمیتواند مجوز کل پروژه را به یک مجوز آسانگیر (مثل MIT) تغییر دهد؛ مگر اینکه از تکتک مشارکتکنندگانی که در کدهای فعلی سهیم بودهاند رضایت مکتوب بگیرد، زیرا حق مؤلف کدها متعلق به تمام تیم توسعه است.
تله ریپوزیتوری عمومی (Public) بدون فایل مجوز: اگر کدهایتان را روی گیت‌هاب به صورت Public منتشر کنید اما فایلی به عنوان LICENSE در آن قرار ندهید، پروژه شما متن‌باز (Open Source) نیست! در این حالت حق کپیرایت انحصاری برای شما حفظ شده و دیگران از نظر قانونی حتی حق کپی، فورک و استفاده از کدهای شما را ندارند. در این شرایط اگر فرد دیگری کدی به پروژه شما اضافه کند، پروژه دچار تداخل مالکیتی شده و از نظر حقوقی برای توسعههای آینده قفل می‌شود.
آزادی فراتر از نرم‌افزار
مفهوم کپیلفت و اشتراکگذاری آزاد بعدها از دنیای برنامه‌نویسی به سایر حوزهها نیز راه پیدا کرد:
مجوزهای کریتیو کامنز (Creative Commons): برای آثاری مانند کتاب، متن، تصویر و موسیقی طراحی شدند. برای مثال، کتاب «اِدا و زِنگمَن» (کتابی با موضوع آزادی تکنولوژی) تحت مجوز آزاد CC BY-SA 4.0 منتشر شده است.
مجوز تولید همتا یا PPL (Peer Production License): که با رویکرد Copyfarleft طراحی شده است؛ به این صورت که استفاده از اثر را برای تعاونیها، افراد و نهادهای غیرانتفاعی کاملاً رایگان کرده، اما شرکت‌های تجاری را ملزم به پرداخت هزینه می‌کند (مطالعه بیشتر درباره PPL).
منابع برای تحقیق بیشتر
مقایسه خانواده مجوزهای GPL (شامل GPLv2, GPLv3, AGPL)
