مبانی مجوز های متن باز

فهرست

1. چکیده
2. مقدمه
3. انواع مجوزها
   1. مجوزهای سهل‌گیرانه (Permissive Licenses)
   2. مجوزهای میانی (Copyleft ضعیف)
   3. کپی‌لفت (Copyleft)
4. سازگاری و تغییر مجوز (Re-licensing)
   1. مجوزهای سهل‌گیرانه (Permissive licenses)
   2. مجوزهای میانی (کپی‌لفت ضعیف)
   3. کپی‌لفت (Copyleft)
   4. مجوزدهی دوگانه (Dual licensing)
5. ترکیب کدهای دارای مجوزهای متفاوت
6. انتخاب مجوز
   1. مجوزهای سهل‌گیرانه (Permissive licenses)
   2. مجوزهای میانی (کپی‌لفت ضعیف)
   3. کپی‌لفت
7. سایر منابع خوب
8. منابع

نسخه‌ی انگلیسی این مطلب را میتوانید از وبسایت شخصی نویسنده مطالعه کنید.(opensource licensing 101)

چکیده ¶

مقدمه ¶

مجوز (License) نرم‌افزار شما، وظایف و محدودیت‌های قانونی‌تان را در موارد زیر تعیین می‌کند:

• آنچه می‌توانید با نرم‌افزار خود انجام دهید
• نحوه توزیع آن
• نحوه مدیریت و صدور مجوز برای آثار مشتق‌شده (آثاری که بر پایه نرم‌افزار شما ساخته شده‌اند)
• نحوه استفاده از آن در پروژه‌های دیگر
• اینکه چه پروژه‌های دیگری را می‌توانید در پروژه خود به کار ببرید
• و غیره.

هنگام انتخاب مجوز برای محصول خود باید بسیار دقت کنید، زیرا این انتخاب می‌تواند بر موارد زیر تأثیر بگذارد:

• نحوه استفاده از آن
• نحوه توزیع آن
• ماهیت آن (نرم‌افزار انحصاری، نرم‌افزار با کد منبع در دسترس، یا نرم‌افزار آزاد و متن‌باز - FOSS)

توجه کنید که این یک مسئله حقوقی است؛ نمی‌توانید صرفاً با خواندن یک مطلب کوتاه، کار را تمام‌شده بدانید. عجله نکنید، راهنماهای معتبر (مانند آنچه در fsf.org آمده است) را مطالعه کنید، از یک وکیل متخصص در این حوزه کمک بگیرید و مهم‌تر از همه، متن دقیق مجوزهایی را که مد نظر دارید بخوانید (می‌دانم که کاری بسیار خسته‌کننده است، اما انجام آن ضروری است).

انواع مجوزها ¶

مجوزهای سهل‌گیرانه (Permissive Licenses) ¶

این مجوزها که به آن‌ها «سهل‌گیرانه» می‌گویند، در اصطلاح ریچارد استالمن و «بنیاد نرم‌افزار آزاد» (FSF)،اینطور شناخته می‌شوند:

ما به آن‌ها «مجوزهای توسری خور» (Pushover licenses) می‌گوییم، زیرا وقتی کاربری سعی می‌کند آزادی دیگران را سلب کند، این مجوزها نمی‌توانند در برابر او «نه» بگویند.

• این مجوزها تقریباً هر کاری را مجاز می‌دانند. شما می‌توانید به هر شکلی که می‌خواهید از کد استفاده کنید و هر کاری که مایلید با آن انجام دهید، بدون اینکه هیچ‌گونه تعهد یا الزامی داشته باشید.

• نمونه‌ها:

• مجوز MIT

• مجوز Apache 2.0

• مجوز BSD

مجوزهای میانی (Copyleft ضعیف) ¶

مجوزهای میانی آن دسته از مجوزهایی هستند که الزامات اساسی و مهمی برای بازنشر (توزیع مجدد) دارند، اما در دسته مجوزهای «کپی‌لفت» (Copyleft) قرار نمی‌گیرند.¹

• معمولاً به این معناست که شما می‌توانید محصول را بدون هیچ‌گونه تغییری (به همان شکل اصلی) برای هر منظوری، حتی در نرم‌افزارهای انحصاری (مالکانه)، به کار ببرید. اما اگر تغییری در آن ایجاد کنید، باید «اثر اصلاح‌شده» را تحت همان مجوز منتشر نمایید.
• نمونه‌ها:
• LGPL (GNU Lesser General Public License)
• EPL (Eclipse Public License)
• MPL (Mozilla Public License)

کپی‌لفت (Copyleft) ¶

کپی‌لفت روشی کلی برای آزاد کردن یک برنامه (یا هر اثر دیگر) است (به معنای «آزادی»، نه «رایگان بودن» یا قیمت صفر)؛ به طوری که تمام نسخه‌های اصلاح‌شده و توسعه‌یافته‌ی آن برنامه نیز باید آزاد باشند.²

• هر اثر مشتق‌شده از اثری که تحت کپی‌لفت است، و یا هر اثری که مستقیماً از آن اثرِ تحت کپی‌لفت استفاده می‌کند، باید خود نیز تحت همان شرایط کپی‌لفت منتشر شود.
• تعریف و دامنهٔ واژهٔ «استفاده» (Uses) به نوع مجوز بستگی دارد؛ اما برای نمونه، در اینجا نحوهٔ تعریف آن در نسخهٔ ۳ مجوز GPL (GPLv3) آمده است (به مجوز GPLv3 مراجعه کنید):
  • «پیوند دادن» (Linking)
  • استفاده از برنامه (برای مثال: import foo)
  • «اصلاح کردن» (Modifying)
  • «اثر تحت پوشش» (Covered work).
• نمونه‌های مجوز کپی‌لفت:
  • GPL (مجوز عمومی همگانی گنو - GNU General Public License)
  • AGPL (مجوز عمومی همگانی آفرو - Affero General Public License)

سازگاری و تغییر مجوز (Re-licensing) ¶

مجوزهای سهل‌گیرانه (Permissive licenses) ¶

به‌طور کلی، این مجوزها هم با یکدیگر و هم با سایر مجوزها سازگار هستند، زیرا هیچ‌چیز را ممنوع نمی‌کنند و تقریباً همه چیز را مجاز می‌دانند (البته استثنائاتی نیز وجود دارد¹).

در ترکیبی از برنامه‌ها که تحت مجوزهای سهل‌گیرانه هستند، هر بخش همچنان تابع مجوزی است که با آن عرضه شده بود. زمانی که کدها به قدری با هم ادغام شوند که دیگر نتوان بخش‌های مختلف را از یکدیگر تشخیص داد، آن کدِ ادغام‌شده باید شامل تمام مجوزهایِ بخش‌های تشکیل‌دهنده‌اش باشد. از آنجایی که همه مجوزها به هر حال سهل‌گیرانه هستند، این امر هیچ مشکل عملی ایجاد نمی‌کند، جز اینکه لیست مجوزها طولانی می‌شود.³

• معمولاً می‌توانید مشتقات نرم‌افزارهای دارای مجوز سهل‌گیرانه را به هر مجوزی تغییر دهید.

مجوزهای میانی (کپی‌لفت ضعیف) ¶

مجوزهای میانی معمولاً با هیچ مجوز کپی‌لفتی سازگار نیستند زیرا الزامات آنها اجازه نمی‌دهد که برنامه ترکیبی تحت مجوز کپی‌لفت باشد.¹

• مثال‌ها
  • LGPL (مجوز عمومی عمومی کوچک‌تر گنو)

    مجوز عمومی عمومی کوچک‌تر گنو، نسخه ۳، در واقع همان مجوز عمومی عمومی گنو نسخه ۳ به علاوه برخی مجوزهای اضافی اضافه شده است. نسخه ۳ GPL (بخش ۷) می‌گوید که شما همیشه می‌توانید مجوزهای اضافه شده را حذف کنید و با انجام این کار، شما همان کد را تحت GNU GPL نسخه ۳ معمولی دریافت می‌کنید.

    • اگر برنامه‌ای اجازه‌ی استفاده تحت GNU LGPL نسخه ۳ یا بالاتر را می‌دهد، می‌توانید آن را به GPL نسخه ۳ یا بالاتر تغییر مجوز دهید¹
    • می‌تواند تحت مجوز GPL دوباره مجوزدهی شود، بنابراین سازگار هستند.
    • اجازه پیوند(linking) با ماژول‌های غیر آزاد را می‌دهد.

کپی‌لفت (Copyleft) ¶

• مستلزم آن است که هرگونه استفاده‌ی مجدد، در برنامه‌هایی صورت گیرد که تحت همان مجوز منتشر شده‌اند.
  در نتیجه اگر از یک کتابخانه یا قطعه‌کدی با مجوز «کپی‌لفت» استفاده کنید، باید کل نرم‌افزار خود را تحت همان مجوز کپی‌لفت منتشر نمایید.
  در نتیجه شما نمی‌توانید از نرم‌افزارهایی که دارای چنین مجوزهایی هستند، در نرم‌افزارهای انحصاری (مالکانه) استفاده کنید.
  در نتیجه نرم‌افزاری که تحت مجوز کپی‌لفت باشد، همواره به عنوان نرم‌افزاری آزاد با مجوز کپی‌لفت باقی خواهد ماند.

به‌طور کلی، دو مجوز کپی‌لفتِ متفاوت، ناگزیر با یکدیگر ناسازگارند، مگر آنکه دارای مفاد صریحی برای سازگاری باشند. این مسئله ناشی از اشتباه در جزئیات نیست، بلکه در ذاتِ مفهوم کپی‌لفت نهفته است.¹

• «نسخه‌های اصلاح‌شده و توسعه‌یافته باید تحت همان مجوز باشند.»
  در نتیجه اگر مجوز «الف» (برای برنامه «پ») مقرر کند که برنامه‌های توسعه‌یافته باید تحت مجوز «الف» باشند، و مجوز «ب» (برای برنامه «ق») مقرر کند که برنامه‌های توسعه‌یافته باید تحت مجوز «ب» باشند،
  در نتیجه آنگاه مجوزِ برنامه‌ی ترکیبی (که شامل کدی از «پ» و کدی از «ق» است) باید هم‌زمان هم «الف» باشد و هم «ب». ¹
  در نتیجه این دو مجوز با یکدیگر ناسازگاریِ حل‌نشدنی دارند.
• بنابراین، حتی نسخه‌های GPL v2 و GPL v3 نیز با یکدیگر ناسازگارند. این موضوع در دنیای نرم‌افزار امری رایج است و راهکارهایی برای مدیریت آن وجود دارد. نمی‌توان انتظار داشت که تمام مجوزها با یکدیگر سازگار باشند.

  • [گنو:] برای پرهیز از مشکل ناسازگاری ناشی از نسخه‌های مختلفِ مجوزهای کپی‌لفت، دو رویکرد وجود دارد.¹

    • رویکرد بنیاد نرم‌افزارهای آزاد (FSF) این است که از توسعه‌دهندگان می‌خواهد برنامه‌های خود را تحت مجوزی منتشر کنند که عبارت «GNU GPL نسخه N یا هر نسخهٔ بعدی» را در بر داشته باشد. بدین ترتیب، آثار مشتق‌شده و خودِ نرم‌افزار، تنها به نسخهٔ N محدود نمی‌مانند و می‌توانند به نسخه‌های جدیدترِ مجوز ارتقا یابند.
    • رویکرد دیگر این است که در متنِ هر نسخه از مجوز، به‌صراحت اجازهٔ ارتقا به نسخه‌های بعدی داده شود.
    • مجوزهای گنو (GNU) به پدیدآورندگان این اختیار را می‌دهند که تصمیم بگیرند آیا اجازهٔ ارتقا به نسخه‌های آیندهٔ مجوز را می‌دهند یا خیر.

    • برنامه‌هایی مانند لینوکس، که تنها یک نسخه از مجوز GNU GPL را می‌پذیرند و ارتقای مجوز را رد می‌کنند، موجب ناسازگاری عملی می‌شوند.¹

  • برخی از مجوزهای «کپی‌لفت» (copyleft) اجازه می‌دهند که با استفاده از یک بند صریح برای تغییر مجوز (relicensing)، کد تحت مجوز کپی‌لفت دیگری قرار گیرد؛ این امر امکان ترکیب مجوزهای مختلف کپی‌لفت را فراهم می‌کند.¹
    • برای مثال EPLv2 که اجازه‌ی تغییر به یک مجوز ثانویه (مثلا LGPL v3) را میدهد
  • «دو مجوزی» یا «چند مجوزی» کردن پروژه های نیز یک امر ممکن است. ( dual-licensing & multi-licensing)
    • پروژه تحت مجوز های الف و ب منتشر شده و کاربر میتواند انتخاب کند که تحت کدام پروانه میخواهد از این برنامه استفاده کند
  • اجازه صریح برای تغییر مجوز، با «سازگاری» (compatibility) یکسان نیست (اگرچه تغییر مجوزِ یک کد می‌تواند آن را با کدهای دیگر سازگار کند) و این رابطه متقارن هم نمی‌باشد. برای نمونه، مجوز CeCILL اجازه صریح می‌دهد که کد تحت مجوز GNU GPL درآید، اما GNU GPL اجازه نمی‌دهد که کد تحت مجوز CeCILL قرار گیرد.

مجوزدهی دوگانه (Dual licensing) ¶

به این معناست که یک برنامه واحد، امکان انتخاب میان دو یا چند مجوز مختلف را فراهم می‌کند.¹

• برای مثال، نسخه‌های قدیمی‌تر زبان Perl دارای مجوزدهی دوگانه تحت «مجوز هنری» (Artistic License) و «مجوز GPL» بودند.

  این بدان معنا بود که هر کاربر می‌توانست انتخاب کند که از Perl استفاده کرده و آن را تحت یکی از این دو مجوز (یا هر دو به صورت انتخابی/جداگانه، همان‌طور که در خودِ نسخه منتشرشده‌ی Perl آمده بود) توزیع مجدد نماید.
  یک ترکیب انتخابی (disjunction) از مجوزها، با مجموعه‌ای از مجوزهای دیگر سازگار است، اگر دست‌کم یکی از گزینه‌های موجود در آن ترکیب، با آن مجموعه سازگار باشد.¹

• مراقب باشید که مجوز نرم افزار شما، عملا برابر ضعیف ترینِ مجوز های موجود خواهد بود. مثلا اگر نرم افزاری تحت GPL و MIT منتشر شده، عملا قدرت کپی‌لفت خود را از دست داده و مجوز آن MIT تلقی میشود.

ترکیب کدهای دارای مجوزهای متفاوت ¶

هنگامی که مجموعه‌ای از مجوزها با یکدیگر سازگار باشند، بدین معناست که می‌توانید به‌طور قانونی چندین برنامه را — که هر کدام تحت یکی از آن مجوزها منتشر شده‌اند — با هم ترکیب یا ادغام کنید.³

• اگر مجوزها اجازه ندهند که برنامه تحت مجوز دیگری (مجوز جدیدی) قرار گیرد (که اکثر مجوزهای «کپی‌لفت» [copyleft] چنین اجازه‌ای نمی‌دهند)، آنگاه مجوزِ برنامهٔ ترکیبی شامل مجوزهای تمام اجزای تشکیل‌دهنده‌ی آن خواهد بود (که البته این اجزا باید با یکدیگر سازگار باشند).
• به تعاریفِ عباراتی نظیر «ترکیب کد»، «اثر مشتق‌شده» (Derivative)، «اثر اصلاح‌شده» (Modified work) و غیره دقت کنید. این اصطلاحات در مجوزهای مختلف، معانی متفاوتی دارند.
• برای نمونه:
• در مجوز GPL:

  «اثر ترکیبی» (Combined Work) به اثری گفته می‌شود که از طریق ترکیب یا پیوند دادن (Linking) یک «برنامه کاربردی» (Application) با یک «کتابخانه» (Library) پدید آمده باشد. آن نسخهٔ خاص از کتابخانه که در ایجاد اثر ترکیبی به کار رفته است، «نسخهٔ پیوند‌داده‌شده» (Linked Version) نامیده می‌شود.⁴

• در مجوز EPL نسخه ۲:

  «آثار اصلاح‌شده» (Modified Works) به هر اثری — چه به صورت کد منبع (Source Code) و چه به اشکال دیگر — گفته می‌شود که حاصلِ افزودن، حذف کردن یا تغییر دادنِ محتوای «برنامه» (Program) باشد. برای شفافیت بیشتر، این تعریف شامل هر فایل جدیدی (در قالب کد منبع) که حاوی بخشی از محتوای برنامه باشد نیز می‌شود. با این حال، آثار اصلاح‌شده شامل مواردی نمی‌شوند که صرفاً حاوی اعلان‌ها (declarations)، رابط‌ها (interfaces)، انواع (types)، کلاس‌ها، ساختارها یا فایل‌هایی از برنامه باشند که هدف از آن‌ها تنها برقراری پیوند (linking)، اتصال نامی (binding by name) یا ایجاد زیرکلاس (subclassing) از برنامه یا آثار اصلاح‌شدهٔ آن است.⁵

انتخاب مجوز ¶

این مطلب در وب‌سایت gnu.org راهنمای بسیار خوبی است؛ اما در اینجا خلاصه‌ای از آن ارائه شده است:

مجوزهای سهل‌گیرانه (Permissive licenses) ¶

• برای اکثر برنامه‌های کوچک، استفاده از مجوزهای «کپی‌لفت» (copyleft) ارزشِ زحمتش را ندارد. ما عدد ۳۰۰ خط کد را به عنوان معیار در نظر می‌گیریم: زمانی که کد منبع یک بسته نرم‌افزاری کوتاه‌تر از این مقدار باشد، مزایای حاصل از «کپی‌لفت» (copyleft) معمولاً آن‌قدر ناچیز است که زحمتِ اطمینان از همراه بودنِ متن مجوز با نرم‌افزار را توجیه نمی‌کند.⁶

• کتابخانه‌ها: اگر قصد دارید توسعه‌دهندگان نرم‌افزارهای انحصاری (مالکانه) را متقاعد کنید که از کتابخانه شما — که فرمت‌های آزاد را پیاده‌سازی می‌کند — استفاده کنند، باید این کار را برایشان آسان سازید؛ بدین منظور، کتابخانه را تحت یک «مجوز سهل‌گیرانه» (permissive license) منتشر کنید.⁶

مجوز MIT امروزه یک مجوز سهل‌گیرانه بسیار رایج است و یکی از پرکاربردترین مجوزها برای پروژه‌های متن‌باز (open source) محسوب می‌شود.

توصیه می‌کنم برای پروژه‌های خود از مجوزهای سهل‌گیرانه استفاده نکنید، مگر آنکه دلایل موجهی برای این کار داشته باشید. این مجوزها آزادی را از کاربران شما سلب می‌کنند و سودجویی از تلاش داوطلبان را بسیار آسان می‌سازند؛ چرا که شرکت‌های بزرگ و نرم‌افزارهای انحصاری می‌توانند حاصل کار داوطلبان را بردارند و هرگز هیچ‌گونه مشارکت با ارزش یا متناسبی در به پروژه نداشته باشند. در نتیجه، کاربران مجبور می‌شوند بابت چیز هایی هزینه بپردازند که در غیر این صورت می‌توانستند به صورت رایگان (هم از نظر قیمت و هم از نظر آزادی) در اختیار داشته باشند. به همین دلیل است که شرکت‌های بزرگ به‌شدت ترویج‌کننده مجوزهای سهل‌گیرانه هستند.

به‌طور خلاصه، مجوز سهل‌گیرانه برای این کاربری ها مناسب است:

• برنامه‌های کوچک (معمولاً کمتر از ۳۰۰ خط کد).
• کتابخانه‌هایی که قرار است عمدتاً در نرم‌افزارهای انحصاری استفاده شوند (مانند پیاده‌سازی فرمت‌های آزاد، ایجاد سازگاری و غیره).
• اگر برای «آزادی نرم‌افزار» ارزش قائل هستید، صرفاً به سراغ مجوز MIT یا سایر مجوزهای بسیار سهل‌گیرانه نروید، مگر آنکه دلیل موجهی برای این کار داشته باشید. پروژه های بسیاری هستند که از مجوز های سهل‌گیرانه استفاده میکنند و با قدرت پیش میروند (برای مثال PostgreSQL).

در میان مجوزهای «ضعیف» (یا سهل‌گیرانه)، مجوز Apache 2.0 بهترین گزینه است؛ بنابراین اگر به هر دلیلی قصد دارید از یک مجوز ضعیف استفاده کنید، توصیه ما انتخاب همین مجوز است.⁶

مجوزهای میانی (کپی‌لفت ضعیف) ¶

به توصیه‌ی FSF:⁷

رایج ترین حالت [برای استفاده‌ی این مجوز] وقتی است که قابلیت هایی که یک کتابخانه‌ی آزاد ارائه میدهد، به راحتی برای نرم‌افزار های اختصاصی از طریق کتابخانه‌های دیگر در دسترس هستند (بدون قابلیت یا مزیت منحصر به فرد).
در این حالت، این کتابخانه نمیتواند مزیت بخصوصی برای نرم‌افزار آزاد فراهم کند. در نتیجه، بهتر است که از LGPL (کپی‌لفت ضعیف) برای این کتابخانه استفاده کنند.

هنگامی که یک کتابخانه قابلیت منحصر به فرد قابل توجهی ارائه می‌دهد، انتشار آن تحت مجوز کپی‌لفت، یا نرم‌افزار اختصاصی را مجبور می‌کند که به FOSS بپیوندد یا از آن استفاده نکند، که مزیتی و اهرم قدرتی برای FOSS است.

همچنین اضافه می‌کنم، وقتی شما در حال توسعه نرم‌افزاری برای یک شرکت هستید تا از آن در نرم‌افزارهای اختصاصی استفاده کند، و از روی حسن نیت یا دلایل دیگر تصمیم می‌گیرید آن را به صورت نرم‌افزار آزاد و متن‌باز (FOSS) درآورید، می‌توانید از مجوزهای کپی‌لفت ضعیف استفاده کنید، بنابراین شرکت شما می‌تواند از نرم‌افزار در محصولات اختصاصی خود استفاده کند، اما نرم‌افزار همچنان FOSS باقی می‌ماند و هرگونه تغییر (مشتق) در کد باید تحت همان مجوز منتشر شود.
این امر آزادی نرم‌افزار را در حال پیشرفت نگه می‌دارد، در حالی که اجازه می‌دهد از آن به صورت کلمه به کلمه در سایر محصولات استفاده شود.
البته، شما می‌توانید محصول خود را با کپی‌رایت برای خود و شرکت خود مجوز دهید تا هرطور که میخواهید از آن استفاده کنید، امّا به نظر من، به نوعی خلاف روح FOSS است، هرچند که باز هم از هیچ بهتر است.

با مجوزهای کپی‌لفت ضعیف خوب، شما کسب و کار های بیشتری را برای استفاده از محصول خود جذب می‌کنید و می‌توانید مدل مالی بهتری از حامیان مالی و موارد مشابه برای محصول خود نسبت به نرم‌افزار کپی‌لفت ایجاد کنید. اما اگر آنها بخواهند آن را تغییر دهند، باید کار خود را متن‌باز کنند و مشارکت کنند.
من فکر می‌کنم این یک حد وسط عالی است.

به طور خلاصه، هنگامی مجوز میانی را انتخاب کنید که:

• برنامه/کتابخانه‌ای که قابلیت یا مزیت منحصر به فردی نسبت به رقبای انحصاری ندارد
• برنامه/کتابخانه‌ای که می‌خواهید آزاد نگه داشته شود اما در عین حال به راحتی در نرم‌افزار اختصاصی قابل استفاده باشد

FSF انتخاب LGPL را برای مجوز کپی‌لفت ضعیف توصیه میکند ، زیرا با سایر مجوزهای GPL سازگار است. مجوزهای ضعیف کپی‌لفت دیگری مانند EPL نسخه ۲ نیز وجود دارند. تحقیق کنید و ببینید چه چیزی با نیازهای شما مطابقت دارد.

کپی‌لفت ¶

توسعه‌دهندگان نرم‌افزار انحصاری از مزیت پول برخوردارند؛ توسعه‌دهندگان نرم‌افزار آزاد باید برای یکدیگر مزیت ایجاد کنند.
استفاده از مجوز GPL برای یک کتابخانه، به توسعه‌دهندگان نرم‌افزار آزاد نسبت به توسعه‌دهندگان نرم‌افزار انحصاری مزیت می‌دهد: کتابخانه‌ای که می‌توانند از آن استفاده کنند، در حالی که توسعه‌دهندگان انحصاری نمی‌توانند از آن استفاده کنند.⁷

وقتی یک کتابخانه قابلیت منحصر به فرد قابل توجهی ارائه می‌دهد، انتشار آن تحت مجوز کپی‌لفت، نرم‌افزارهای اختصاصی را مجبور می‌کند که به سمت نرم‌افزارهای آزاد (FOSS) بروند یا از آن استفاده نکنند.

اگر مجموعه‌ای از کتابخانه‌های قدرتمند تحت پوشش GPL را جمع‌آوری کنیم که هیچ مشابهی برای نرم‌افزارهای اختصاصی ندارند، طیف وسیعی از ماژول‌های مفید را برای استفاده به عنوان بلوک‌های سازنده در برنامه‌های آزاد جدید فراهم می‌کنند. این یک مزیت قابل توجه برای توسعه بیشتر نرم‌افزارهای آزاد خواهد بود و برخی پروژه‌ها تصمیم خواهند گرفت که نرم‌افزار را آزاد کنند تا از این کتابخانه‌ها استفاده کنند.⁷

به طور خلاصه، هنگامی مجوز کپی‌لفت را انتخاب کنید که:

• اگر محصول شما منحصر به فرد، ارزشمند و دارای مزایایی نسبت به سایر محصولات است
• کپی‌لفت بودن بخش مهمی از عملکرد و یا هویت آن است

مجوز کپی‌لفت پیشنهادی “GPLV3 یا بالاتر” است

طرفداری از کپی‌لفت ¶

تصور کنید اگر لینوکس، بلِندِر، گیمپ، ffmpeg، ابزارهای هسته گنو (cat، cp، tee و غیره)، gcc، وردپرس، openJDK، GNU R (زبان R)، VLC، ClamAV و غیره از کپی‌لفت استفاده نمی‌کردند. درنتیجه شرکت‌های بزرگ خیلی راحت‌تر از آنها پیشی می‌گرفتند و هیچ‌کس مجبور نبود تغییرات و بهبود های خود را به پروژه‌ها بازگرداند. به نظر من نتیجه اش این میشد که حالا ما بیشتر نرم‌افزارهایی که واقعاً خوب و ارزشمند هستند را، به خصوص نرم‌افزار متن‌باز رایگان و آزاد، نداشتیم (واقعاً چند نرم‌افزار خوب غیر FOSS داریم؟) و حالا باید بجای این چیزهایی که الان با حفظ آزادی، حریم شخصی، امنیت و مشارکت جمعی در اختیارمان هستند، برای نسخه‌های انحصاری همین نرم افزار ها که این ویژگی ها را هم نداشتند، هزینه‌های گزاف میدادیم.
صد البته که رایگان بودن نرم‌افزار های آزاد به این معنا نیست که فقط مصرف کننده باشیم. وضیفه‌ی هر مصرف کننده ای مشارکت در این تلاش انسانی جمعی است. چه از طریق حمایت مالی، مشارکت فنی، ایده پردازی، پشتیبانی و…

ما این را دیده‌ایم و ثابت شده است که شرکت‌هایی مانند مایکروسافت، متا، گوگل و سایر، از آزادی کاربر متنفرند و سعی می‌کنند آزادی را از کاربران بگیرند، حق محاسبات عمومی(General computing) و حقوق آنها را نسبت به حریم شخصی و سخت‌افزار خودشان از بین ببرند.
یکی از آخرین نمونه‌ها، تلاش‌های گوگل در سال‌های اخیر برای قفل کردن هرچه بیشتر اندروید و خلاص شدن تدریجی از بخش‌های GPL کد آنها است (اندروید مبتنی بر هسته لینوکس است). اساساً بی‌فایده کردن AOSP.
حالا هر توسعه دهنده صرفا باید از طریق پرداخت به گوگل و احراز هویت نرم افزار خود را منتشر کند و کاربر حق ندارد نرم افزاری دلخواه، بدون اجازه‌ی گوگل بر روی سخت افزار خودش، که مالک آن است، نصب کند. این فقط ساده ترین مثال بود.

همواره FOSS برای حفظ آزادی، حریم شخصی، امنیت و جلوگیری از بلعیده شدن توسط حرص و طمع، یک سنگر ایمن برای بشر بوده. بنابراین اگر ایده خوبی دارید که برای عموم مفید است، لطفاً به خاطر انسانیت و آزادی، انتخاب یک مجوز کپی‌لفت، یا حداقل مجوز کپی‌لفت ضعیف را برای آن در نظر بگیرید.
نرم‌افزار های انحصاری نیز جایگاه خودشان را دارند و الزاما بد نیستند. مثلا برای نرم افزار هایی که مخاطب آنها صرفا کسب و کار ها و شرکت ها هستند، و کاربری آموزشی، فردی یا گروهی ندارند — مثلا خانواده‌ی تیمار — استفاده از مجوز های انحصاری برای ایجاد کسب و کار مستحکم تر کاملا منطقی است. اما یادمان نرود که اگر نرم افزار‌های آزاد نبودند، هیچ نرم‌افزار انحصاری نمیتوانست ساخته شود. چراکه آنها اجزای سازنده‌ و سنگ بنای نرم‌افزار های انحصاری هستند.

ماهم در شرکت اندیشه پردازان سرآمد، به آزادی نرم‌افزار علاقه‌مند و پایبندیم و فرهنگ نرم‌افزار آزاد را در شرکت خود ترویج میدهیم، پروژه های آزاد میسازیم و در پروژه‌های موجود مشارکت میکنیم.

سایر منابع خوب ¶

• https://www.mend.io/blog/top-open-source-licenses-explained/
• https://www.mend.io/blog/why-open-source-license-management-matters/
• https://isitreallyfoss.com/
• https://www.tldrlegal.com/

منابع ¶