مجوزهای نرم‌افزاری اسناد و متون حقوقی هستند که توسط حقوقدانان و کارشناسان حوزه فناوری تدوین می‌شوند تا شرایط استفاده، تغییر، توسعه و بازنشر یک برنامه یا کد منبع را مشخص کنند.
این متون در قالب چندین بند و تبصره نوشته می‌شوند و برای توسعه‌دهندگان و کاربران مشخص می‌کنند که دقیقاً چه حقوقی در برابر آن کد دارند و پدیدآورنده پروژه چه انتظارات یا شروطی تعیین کرده است.
دسته‌بندی کلی مجوزهای نرم‌افزاری
مجوزهای نرم‌افزاری را می‌توان به دو دسته کلی تقسیم کرد:
۱. مجوزهای انحصاری و مالکیتی (Proprietary): در نرم‌افزارهای تجاری و بسته (مانند سیستم‌عامل ویندوز یا فتوشاپ)، کاربر صرفاً حق استفاده محدود از برنامه را تحت یک توافق‌نامه کاربری نهایی (EULA) دریافت می‌کند. در این حالت، کاربر مالک نرم‌افزار نیست و حق دسترسی به سورس‌کد، مهندسی معکوس، تغییر یا بازتوزیع برنامه را ندارد.
نکته فنی-حقوقی: وارد کردن کلید فعالسازی (Product Key) یا فعالسازی آنلاین صرفاً ابزارهای فنی برای مدیریت حقوق دیجیتال و کنترل دسترسی (DRM) هستند و نباید با خودِ سند حقوقی مجوز اشتباه گرفته شوند. مثلاً در اصطلاح رایج «خرید لایسنس ویندوز»، آنچه در عمل مبادله می‌شود «کلید فعالسازی» است، در حالی که مجوز، همان متن شروط و توافق‌نامه‌ای است که هنگام نصب می‌پذیرید.
۲. مجوزهای آزاد و متن‌باز (Free & Open Source): مجوزهایی مانند GPL، MIT و Apache که به کاربران اجازه می‌دهند سورس‌کد برنامه را بخوانند، آن را مطابق نیاز خود تغییر دهند و حتی نسخه جدید را بازنشر کنند.
چون کامپوننت async است، میتواند وسط ساختن صفحه از دیتابیس بخواند یا بررسی کند کاربر اجازهی دیدن صفحه را دارد، و لازم نیست برای این کار یک API جدا بسازی. مسیرها هم از روی ساختار ماژولها تشخیص داده می‌شوند.
داخل view میتوانی از حلقه و شرط معمولی Rust استفاده کنی. در این مثال، منوی بالای سایت لینک صفحه‌ی فعلی را مشخص می‌کند:
view! {
<nav>
for item in nav_items {
<a
href=(item.url)
if item.url == current_path {
aria-current="page"
class="active"
}
>
(item.label)
</a>
}
</nav>
}
تعامل در مرورگر، بدون WebAssembly
در Leptos و Dioxus کد Rust به WebAssembly تبدیل می‌شود و در مرورگر اجرا می‌شود. Topcoat راه دیگری می‌رود. هر چیزی که داخل $(...) بنویسی کد Rust است و کامپایلر نوعهایش را چک می‌کند. این کد یک بار روی سرور اجرا می‌شود تا صفحه‌ی اول ساخته شود، و همان کد به JavaScript هم ترجمه می‌شود تا در مرورگر کار کند. پس نه فایل wasm داری و نه مرحلهی build جدا برای بخش کلاینت.
در مثال بعد، یک دکمه پاراگرافی را نشان می‌دهد یا پنهان می‌کند، و برای این کار اصلاً درخواستی به سرور نمی‌رود:
#[component]
async fn faq(cx: &Cx) -> Result<impl View> {
let open = signal(cx, || false);
Ok(view! {
// Runs entirely in the browser; no server round-trip.
<button @click=$(|_e| open.set(!open.get()))>"What is Topcoat?"</button>
<p :hidden=$(!open.get())>"A full-stack Rust framework."</p>
})
}
وقتی به دادهی سرور نیاز داری
بعضی کارها فقط در مرورگر انجام نمیشوند. مثلاً نتیجهی جستوجو باید از دیتابیس بیاید. برای این حالت Topcoat چیزی به اسم shard دارد. کامپوننتی که با ویژگی shard مشخص شود، هر وقت ورودیهایش عوض شوند روی سرور دوباره ساخته می‌شود و HTML جدیدش جای بخش قبلی صفحه مینشیند. در این مثال با هر حرفی که کاربر تایپ می‌کند، فقط لیست نتایج عوض می‌شود:
#[component]
async fn search(cx: &Cx) -> Result<impl View> {
let query = signal(cx, String::new);
Ok(view! {
<input @input=$(|e: Event| query.set(e.target.value))>
// Updates as the user types.
search_results(query: $(query.get()))
})
}
#[shard]
async fn search_results(cx: &Cx, query: String) -> Result<impl View> {
Ok(view! {
<ul>
// Your own server-side code, like a database query:
for product in search_products(cx, &query).await? {
<li>(product.name)</li>
}
</ul>
})
}
از جولای تا حالا این بخش‌ها پیشرفت کردهاند. طبق وبلاگ تیم، نسخه‌ی 0.9 که ۲۴ سپتامبر آمد سه چیز اضافه کرد: فرستادن چند بهروزرسانی پشتسرهم به صفحه، فرستادن تغییر از سرور با WebSocket، و دو کامپوننت آماده به اسم suspense و error_boundary. تغییرهای HTML هم طوری روی صفحه اعمال می‌شوند که فوکوس و متن واردشده در فیلدها از بین نرود.
ابزارهای دیگر
کنار اینها چیزهایی هست که معمولاً باید خودت پیدا کنی و وصل کنی. کامپوننتهای آمادهی رابط کاربری روی Tailwind ساخته شدهاند و با CLI داخل پروژهی خودت کپی می‌شوند، پس میتوانی مستقیم تغییرشان بدهی. فایل‌های استاتیک با آدرسی سرو می‌شوند که بخشی از آن هش محتوای فایل است. cookie، session، چندزبانهسازی، ارسال ایمیل و هماهنگی با htmx و Alpine AJAX و Datastar هم در فهرست قابلیتها آمده.
برای دیتابیس باید سراغ Toasty بروی، یک ORM ناهمزمان که همین تیم میسازد.
ایرادها و محدودیتها
اول، پروژه هنوز پخته نیست. فایل README صریح مینویسد که پروژه در مرحلهی اولیه و آزمایشی است و ممکن است تغییرهایی بیاید که کد تو را خراب کند. وبلاگ جولای می‌گوید Topcoat آمادهی استفاده است، ولی همانجا هم می‌گوید بخش تعامل سمت مرورگر هنوز محدودیت دارد. در پست سپتامبر هم نویسندهها میگویند هنوز دارند شکل نهایی فریمورک را پیدا می‌کنند.
دوم، فقط بخشی از زبان Rust داخل $(...) قابل ترجمه به JavaScript است. هر کدی را نمیتوانی آنجا بنویسی.
سوم، خود لرش گفته Topcoat برای برنامههای خیلی بزرگ و پیچیده، مثل Figma، ساخته نشده و برای برنامههای معمولی که با دیتابیس کار می‌کنند مناسبتر است. اگر رابط کاربریات تقریباً همهچیز را در مرورگر انجام می‌دهد، Leptos یا Dioxus انتخاب بهتری هستند.
چهارم، چند قابلیت مهم هنوز نیست. در نقشهی راه README احراز هویت، کارهای پس‌زمینه و islands جزو کارهای آینده آمدهاند. اگر پروژهات به اینها نیاز دارد، فعلاً باید خودت پیادهشان کنی.
نتیجه
اگر Rust بلدی و میخواهی یک ابزار داخلی یا یک برنامه‌ی کوچک با دیتابیس بسازی و همهچیز در یک زبان باشد، Topcoat ارزش امتحان کردن دارد. برای محصولی که باید سالها کار کند، فعلاً احتیاط کن: نسخه را ثابت نگه دار و آماده باش که API عوض شود. ستارههای گیت‌هاب (حدود ۶٫۲ هزار در زمان نوشتن) فقط نشان می‌دهد مردم به پروژه علاقه دارند، نه اینکه پایدار است.
یک اصل مهم: کلمه «آزاد» در نرم‌افزارهای آزاد به معنای «آزادی عمل در استفاده، مطالعه، تغییر و انتشار» است، نه «رایگان بودن». یک نرم‌افزار آزاد میتواند کاملاً بهصورت تجاری عرضه شود و توسعهدهنده از فروش نسخهها یا ارائه خدمات پشتیبانی آن درآمدزایی کند.
تفاوت در تدوین متن مجوزها
متون مجوزهای آزاد (مانند 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)
