این مطلب توسط جناب آقای «امیرحسین میرطباطبایی‌پور» نوشته شده و به دست ما رسیده است. از ایشان بابت نگارش این مطلب سپاسگزاریم.
پیشگفتار
با این که انجام پروژه‌ها محاسن بسیار و جذابیت فراوانی دارد. ولی لازم است که ابعاد حقوقی آن نیز به دقت بررسی شود تا مشکل حقوقی‌ای ایجاد نشود. انتخاب لایسنس مناسب و مسائل مربوط به آن در این مطلب بررسی می‌شود.
چکیده
برای انجام یک پروژه به شکل متن‌باز لازم است مسائل حقوقی آن رعایت شود. هر محصولی که حاصل خلاقیت و توانایی فردی افراد باشد، دارای مالکیت معنوی است که متعلق به خالق آن است. برای این که افراد دیگر نیز بتوانند از این کارها با شرایطی استفاده کنند، لازم است دامنه‌ی امکاناتی که به دیگران داده می‌شود در فایلی به نام لایسنس قید شود و همراه پروژه قرار گیرد، در غیر این صورت بقیه نمی‌توانند استفاده کنند. از طرفی برای همکاری‌ها و استفاده از این کدها نیز مواردی باید رعایت شود تا پروژه به مشکلات حقوقی برنخورد.
حقوق معنوی برنامه شما
شما عاشق برنامه‌نویسی هستید. هر روز بلند می‌شوید و در مورد آخرین زبا‌ن‌های برنامه‌نویسی، APIها و …. می‌خوانید و شب با فکر آخرین باگی که با آن درگیر بوده‌اید به خواب می‌روید. روزی در مورد این می‌شنوید که بعضی آدم‌ها برنامه‌هایی که می‌نویسند را به رایگان در اختیار دیگران قرار می‌دهند. باورتان نمی‌شود، مگر همچین چیزی ممکن است؟ برای اولین بار Github را باز می‌کنید و با دریایی از کدهای فوق‌العاده مواجه می‌شوید. در ذهنتان با کدهای موجود برنامه‌هایی فوق‌العاده می‌سازید. ولی اینجا دقیقا جاییست که باید خودتان را از خیال بیرون بیاورید. کاش همه چیز به این سادگی بود ولی استفاده کردن از حاصل کار دیگران هیچ‌وقت به این سادگی نیست و در صورتی که دقت نکنید، ممکن است درگیر امور حقوقی پیچیده و سنگینی بشوید. در این مقاله سعی می‌کنیم که بخش‌هایی از ابعاد حقوقی متن‌باز را مرور کنیم. توجه کنید که ما مشاور حقوقی یا وکیل نیستیم و نوشته‌ی زیر حاصل تجربیات ماست. به این مقاله به عنوان یک آشنایی اولیه با مسائل حقوقی در متن‌باز نگاه کنید.
چرا بعد حقوقی متن‌باز مهم است؟
خوشحالم که پرسیدین! وقتی شما هر چیزی را با استفاده از ابتکار و تواناییتان تولید می‌کنید (مثل متن، اثر گرافیکی و یا کد)، از لحاظ حقوقی، آن محصول در انحصار شماست و تمام حقوق آن که چه استفاده‌ای شما یا دیگران از آن کنید به شما تعلق دارد. به طور کلی این به این معناست که فرد دیگری حق ندارد به هیچ شکلی کار شما را کپی کند، توزیع کند و یا تغییر دهد بدون اجازه‌ی کتبی شما. در این بین کدهای متن‌باز شرایط عجیبی ایجاد کرده‌اند، چرا که شما کدهایتان را خودتان در اختیار دیگران قرار می‌دهید. نکته‌ی جالب این است که اگر در کنار کارتان لایسنسی قرار ندهید که معلوم کند دیگران چگونه می‌توانند از کد شما استفاده کنند، دیگران با این که دسترسی دارند، ولی حق استفاده از کدها را به هیچ شکلی نخواهند داشت. از طرفی این قانون در مورد تمام کسانی که به پروژه شما هم‌بخشی (contribution) می‌کنند نیز صادق است. اگر شما لایسنس مخصوصی برای پروژه در نظر نگیرید، هم‌بخشان پروژه نیز مالک کدهای خود هستند و شما بدون اجازه‌ی کتبی آن‌ها حق ندارید که کد آن‌ها را تغییر دهید یا استفاده کنید. حواستان باشد که این مسأله فقط با هم‌بخشان پیش نمی‌آید. شما به احتمال زیاد از کتاب‌خانه‌ها یا ابزارهای جانبی استفاده می‌کنید که وابستگی های (Dependencies) پروژه شما را تشکیل می‌دهند. این وابستگی‌ها نیز شامل قانون کپی‌رایت می‌شوند و باید شرایطی که آن‌ها برای استفاده از کارشان به شما اجبار می‌کنند را بپذیرید تا به مشکلات قانونی برنخورید.
من حوصله‌ی خواندن تمام این مطلب را ندارم. در یک کلام بگو چه کار کنم؟
شما بی‌حوصله‌ی محترم خیلی شانس دارین، چرا که امروزه برخلاف سال‌های شروع متن‌باز، لایسنس‌های استاندارد شده‌ای وجود دارد که افراد کاملا می‌دانند که امکان چه کارهایی به آن‌ها می‌دهد و اجازه چه کارهایی را نمی‌دهد. سه لایسنس MIT، Apache 2.0 و GPLv3 معروف‌ترین لایسنس‌ها هستند که در خیلی پروژه‌ها استفاده می‌شوند. البته که شما محدود به این لایسنس‌ها نیستید و می‌توانید هر لایسنسی که می‌خواهید را استفاده کنید و یا لایسنس مخصوص خودتان را ایجاد کنید.
کدام لایسنس مناسب پروژه من است؟
اگر هیچ ایده‌ای ندارید که چه لایسنسی را انتخاب کنید، بهتر است از لایسنس MIT شروع کنید. متن آن کوتاه است و به راحتی قابل خواندن است. به طور خلاصه به همه اجازه می‌دهد که هر کاری با کد شما کنند تا زمانی که یک نسخه از لایسنس را در پروژه نگه دارند که نشان می‌دهد که شما مالک کپی‌رایت اصلی پروژه هستید. علاوه بر آن MIT نسبت به دیگر لایسنس‌ها امکان بیشتری برای تغییر لایسنس در آینده را می‌دهد. لازم است که باز هم تاکید که کنیم که به لایسنس وابستگی‌های پروژه مراجعه کنید. بعضی لایسنس‌ها شما را مجبور می‌کنند که لایسنس خاصی را انتخاب کنید و یا از لایسنسی استفاده کنید که بعضی موارد را رعایت کند. به طور کلی قواعد زیر در انتخاب لایسنس توصیه می‌شود:
- آیا پروژه شما قرار است به عنوان زیرساخت پروژه دیگران استفاده شود و جز وابستگی دیگر پروژه‌ها باشد؟ اگر این گونه است، به جامعه پروژه‌هایی که قرار است از کار شما استفاده کند نگاه کنید و محبوب‌ترین لایسنس بین آن‌ها را انتخاب کنید. به طور مثال بین کتابخانه‌های npm، لایسنس MIT محبوب‌ترین است.
- آیا پروژه شما قرار است در سازمان‌های بزرگ استفاده شود؟ در این پروژه، شرکت‌ها معمولا به دنبال این هستند که در لایسنس قید شده باشد که هم‌بخشان پروژه، حق انحصاری کارشان را به کسانی که از پروژه قرار است استفاده کنند، واگذار کرده‌اند و هیچ پیگیری در راستای حق انحصاریشان در آینده نخواهند داشت. در این موارد لایسنس Apache 2.0 پیشنهاد می‌شود.
- آیا می‌خواهید هم‌بخشانی را جذب کنید که نمی‌خواهند کارشان در پروژه‌های متن‌بسته استفاده شود؟ در این موارد لایسنس‌های GPLv3 و AGPLv3 بهترین عملکرد را خواهند داشت.
اگر زمانی تصمیم بگیرم که لایسنس پروژه‌ام را عوض کنم چه می‌شود؟
همین اول بگویم، بسیار پیچیده است. موارد مختلفی که در این تغییر باید رعایت کنید را فقط یک تیم وکالت کامل می‌توانند بررسی کنند و مطمئن شوند که همه چیز رعایت شده است. ولی بعضی موارد مشکلاتی هستند که بیشتر از بقیه مشکلات پیش می‌آیند و می‌توانیم بررسیشان کنیم. اولین کار این است که لایسنسی که می‌خواهید به آن مهاجرت کنید را انتخاب کنید و سپس مشخص کنید که آیا لایسنس جدید با لایسنس قبلی سازگار است یا خیر. سازگاری به این معناست که لایسنس جدید در صورتی که جایگزین لایسنس قبلی بشود، مواد مندرج در لایسنس قبلی را نقض می‌کند یا خیر. در صورتی که مطمئن باشید که سازگاری وجود دارد، به راحتی می‌توانید تغییر را انجام دهید. بعضی اوقات لازم است که یک کپی از لایسنس قبلی را هم در پروژه نگه دارید ولی در عمل لایسنس جدید را مبنا قرار دهید، چرا که این دو لایسنس با یکدیگر سازگار‌اند و هیچ ماده‌ای وجود ندارد که لایسنس دوم آن را نقض کند و معمولا فقط مواردی را به لایسنس اول می‌افزاید. در صورتی که سازگاری وجود ندارد، شما لازم است که از تک تک کسانی که در پروژه دارای کپی‌رایت هستند، کسب اجازه‌ی کتبی کنید. این افراد شامل تمام کسانی است که که به پروژه‌ی شما هم‌بخشی کرده‌اند. در بعضی موارد بر اساس قرارداد‌های کاری، شرکت‌هایی که این بعضی از این افراد در آن‌ها کار می‌کنند هم به عنوان دارندگان کپی‌رایت در پروژه طبقه‌بندی می‌شوند. واضح است که این فرایند بسیار خسته کننده و طاقت‌فرساست. این دقیقا اتفاقی بود که برای Mozilla در طی سال‌های ۲۰۰۱ تا ۲۰۰۶ اتفاق افتاد. برای همین بعد از Mozilla، این رسم ایجاد شد که علاوه بر لایسنس، یک توافق هم‌بخشان هم قرار دهند تا موافقت افراد را در زمان هم‌بخشی به پروژه به صورت مستقیم دریافت کنند تا در آینده مشکلات کمتری برای تغییرات لازم وجود داشته باشد.
منابع
Creative Commons. (2018, 3 27). About The Licenses. Retrieved from creativecommons.org: https://creativecommons.org/licenses/
GitHub, Inc. (2018, 2 23). The Legal Side of Open Source. Retrieved from opensource.guide: https://opensource.guide/legal/
با ما همراه باشید:
آدرس کانال تلگرام: IranianJavaDevelopers@
آدرس اکانت توییتر: JavaCupIR@
آدرس صفحه اینستاگرام: javacup.ir
آدرس گروه لینکدین: Iranian Java Developers
تو ایران هم پیش میاد کسی درگیر این لایسنس ها و مباحث حقوقی شده باشه؟؟