مجوزهای نرم‌افزاری اسناد و متون حقوقی هستند که توسط حقوقدانان و کارشناسان حوزه فناوری تدوین می‌شوند تا شرایط استفاده، تغییر، توسعه و بازنشر یک برنامه یا کد منبع را مشخص کنند.
این متون در قالب چندین بند و تبصره نوشته می‌شوند و برای توسعه‌دهندگان و کاربران مشخص می‌کنند که دقیقاً چه حقوقی در برابر آن کد دارند و پدیدآورنده پروژه چه انتظارات یا شروطی تعیین کرده است.
دسته‌بندی کلی مجوزهای نرم‌افزاری
مجوزهای نرم‌افزاری را می‌توان به دو دسته کلی تقسیم کرد:
۱. مجوزهای انحصاری و مالکیتی (Proprietary): در نرم‌افزارهای تجاری و بسته (مانند سیستم‌عامل ویندوز یا فتوشاپ)، کاربر صرفاً حق استفاده محدود از برنامه را تحت یک توافق‌نامه کاربری نهایی (EULA) دریافت می‌کند. در این حالت، کاربر مالک نرم‌افزار نیست و حق دسترسی به سورس‌کد، مهندسی معکوس، تغییر یا بازتوزیع برنامه را ندارد.
نکته فنی-حقوقی: وارد کردن کلید فعالسازی (Product Key) یا فعالسازی آنلاین صرفاً ابزارهای فنی برای مدیریت حقوق دیجیتال و کنترل دسترسی (DRM) هستند و نباید با خودِ سند حقوقی مجوز اشتباه گرفته شوند. مثلاً در اصطلاح رایج «خرید لایسنس ویندوز»، آنچه در عمل مبادله می‌شود «کلید فعالسازی» است، در حالی که مجوز، همان متن شروط و توافق‌نامه‌ای است که هنگام نصب می‌پذیرید.
۲. مجوزهای آزاد و متن‌باز (Free & Open Source): مجوزهایی مانند GPL، MIT و Apache که به کاربران اجازه می‌دهند سورس‌کد برنامه را بخوانند، آن را مطابق نیاز خود تغییر دهند و حتی نسخه جدید را بازنشر کنند.
مهم‌ترین تغییر اینه که این سوییچ سراسریه. توی نسخه ۱۵ می‌شد PPR رو صفحهبهصفحه روشن کرد، ولی در نسخه ۱۶ اون فلگهای قدیمی حذف شدن. وقتی روشنش کنی، مدل PPR برای کل App Router فعال می‌شه. پایینتر میگم این موضوع چه تأثیری روی تصمیم‌گیری داره.
تستی که من گرفتم
پروژه تست من حدود ۱۰۰۰ صفحه داشت که ترکیبی از پستهای بلاگ و صفحههای داکیومنت بود. اپ رو به‌صورت سلفهاست بالا آوردم و دو حالت رو مقایسه کردم:
با PPR روشن: مصرف رم پروسه Node به حدود ۱.۵ گیگابایت رسید و حتی بعد از تموم شدن درخواستها هم پایین نیومد.
با PPR خاموش: همون اپ با همون صفحهها حدود ۱۵۰ مگابایت رم مصرف کرد.
یعنی ده برابر رم بیشتر، برای سایتی که محتواش عملاً ثابته. برای یه VPS کوچیک، این فرق بین «راحت اجرا می‌شه» و «هر چند وقت یه بار کرش میکنه» ـه.
چرا رم آزاد نمیشه؟
برای این رفتار دو دلیل محتمل وجود داره:
کش درونحافظهای: در مدل Cache Components، خروجیهای کششده به‌صورت پیشفرض توی رم سرور و در یه کش LRU نگه داشته میشن. مستندات خود Next.js میگه در حالت سلفهاست این ورودیها بین درخواستها باقی میمونن. وقتی ۱۰۰۰ صفحه داری، این کش خیلی سریع بزرگ می‌شه.
رفتار حافظه در V8: حتی وقتی یه آبجکت آزاد می‌شه، موتور جاوااسکریپت معمولاً حافظه رو سریع به سیستم‌عامل پس نمیده. برای همین عددی که مانیتورینگ نشون میده ممکنه بالا بمونه.
نتیجه اینه که هر چی تعداد صفحهها بیشتر باشه، این هزینه محسوستر می‌شه.
بلاگ و داکیومنت اصلاً به PPR نیاز دارن؟
جواب کوتاه: معمولاً نه.
محتوای یه پست بلاگ یا یه صفحه داکیومنت برای همه کاربرها یکیه. حفره داینامیکی هم وجود نداره که بخواد استریم بشه. برای این نوع صفحهها همون تولید استاتیک کلاسیک کاملاً کافیه:
اینجا کاربر محصول رو همون لحظه میبینه و سبد خریدش چند صدم ثانیه بعد ظاهر می‌شه. این همون تجربهایه که PPR براش ساخته شده.
چطور PPR رو فقط جایی که لازمه استفاده کنیم
پیشنهاد من سادهست: PPR رو روی کل سایت روشن نکن. فقط برای صفحههایی ازش استفاده کن که واقعاً بخش داینامیک دارن. چون سوییچش در نسخه ۱۶ سراسریه، برای این کار چند راه داری.
راه اول: جدا کردن بخش‌ها با مولتیزون
بلاگ و داکیومنت رو در یه اپ Next.js جدا با PPR خاموش نگه دار، و بخش داینامیک مثل داشبورد یا فروشگاه رو در یه اپ دیگه با PPR روشن. اپ اصلی درخواستهای بلاگ رو به اپ دوم میفرسته:
قدم بعدی اینه که اگه چند اینستنس داری یا کش بزرگ لازمه، کش رو از رم بیرون ببری. برای این کار میتونی یه cache handler مثل Redis تعریف کنی و برای داده‌های سنگین از این دایرکتیو استفاده کنی:
async function getHeavyData() {
'use cache: remote'
// ...
}
قدم آخر هم تعیین سقف حافظه برای پروسه Node ـه، که جلوی رشد بیحد رم رو میگیره:
NODE_OPTIONS="--max-old-space-size=512" next start
یه نکته امنیتی مهم
در سال ۲۰۲۶ چند آسیب‌پذیری مرتبط با PPR منتشر شد. مهاجم با فرستادن درخواستهای مخصوص به مسیر «ادامه رندر» میتونست رم سرور رو پر کنه و پروسه رو از کار بندازه. این مشکل در نسخه 16.1.7 بهطور کامل رفع شده. اگه PPR یا Cache Components رو روشن داری، حتماً حداقل به این نسخه آپگرید کن:
npm install next@latest
اگه فعلاً نمیتونی آپگرید کنی، درخواستهایی رو که این هدر رو دارن در ریورس پراکسی (مثلاً Nginx) مسدود کن، چون این هدر هیچ‌وقت نباید از سمت کاربر بیاد:
if ($http_next_resume) {
return 403;
}
جمع‌بندی: ارزشش رو داره یا نه؟
جواب: بستگی داره. PPR یه ابزار قدرتمنده، ولی راه‌حل همهچیز نیست.
برای سایتهای محتوامحور مثل بلاگ، داکیومنت و لندینگ، معمولاً ارزشش رو نداره. تولید استاتیک کلاسیک همون سرعت رو با یکدهم رم بهت میده.
برای صفحههای ترکیبی مثل فروشگاه، داشبورد یا صفحههایی با محتوای شخصی، واقعاً تجربه کاربری رو بهتر میکنه.
برای پروژه‌های بزرگ، بهترین کار جدا کردن بخشهاست تا هزینه PPR فقط برای صفحههایی پرداخت بشه که ازش سود میبرن.
قبل از روشن کردن هر فیچر جدید، روی پروژه خودت تستش کن و رم و زمان پاسخ رو اندازه بگیر. عدد ۱.۵ گیگابایت در برابر ۱۵۰ مگابایت به من یاد داد که «جدیدترین» همیشه به معنی «بهترین برای پروژه من» نیست.
یک اصل مهم: کلمه «آزاد» در نرم‌افزارهای آزاد به معنای «آزادی عمل در استفاده، مطالعه، تغییر و انتشار» است، نه «رایگان بودن». یک نرم‌افزار آزاد میتواند کاملاً به‌صورت تجاری عرضه شود و توسعهدهنده از فروش نسخهها یا ارائه خدمات پشتیبانی آن درآمدزایی کند.
تفاوت در تدوین متن مجوزها
متون مجوزهای آزاد (مانند 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)
