GPL مقابل MIT وApache: ماذا يطلب منك كل ترخيص؟

GPL مقابل MIT مقابل Apache: ما الذي يطلبه منك كل ترخيص

تجيب تراخيص GPL وMIT وApache 2.0 عن السؤال نفسه بطرق مختلفة: ما الذي تدين به للآخرين عندما توزّع البرنامج؟ يطلب ترخيص MIT إشعار حقوق الطبع والنشر فقط. أما Apache 2.0 فيطلب ذلك الإشعار، إضافةً إلى اتفاق بشأن براءات الاختراع بين جميع من يتعاملون مع الشيفرة. ويطلب GPL منك نشر الشيفرة المصدرية لما بنيته فوق البرنامج، بموجب الترخيص نفسه الذي حصلت عليه.

قد يبدو هذا سؤالاً للمحامين إلى أن يغيّر مشروع تشغّله ترخيصه وينقسم إلى مشروعين. عندها يصبح السؤال تشغيلياً. سيكون عليك الاختيار بين مستودعي حزم، وستجد مكتبات عميلة تتوقف عن التواصل فيما بينها. يتناول هذا الدليل التراخيص وآليات عملها، لا الحركة التي أوجدتها؛ لذلك تنتهي كل فقرة عند النقطة التي تمسّك مباشرة: أنت الشخص الذي يتعين عليه تنفيذ الترقية.

لماذا وُجدت GPL: طابعة لم يُسمح لأحد بإصلاحها

في نحو عام 1980، تلقّى مختبر الذكاء الاصطناعي في MIT طابعة ليزر Xerox 9700. كان المختبر قد عدّل برنامج طابعة سابقة لكي تُعلمك عند انحشار مهمة الطباعة. أما الطابعة الجديدة، فلم يتوفر كودها المصدري، ورُفض طلب الحصول عليه بسبب اتفاقية عدم إفصاح. تعامل Richard Stallman، وكان حينها مبرمجاً في المختبر، مع ذلك الرفض باعتباره الحالة العامة لا مجرد يوم سيئ، وأعلن مشروع GNU في 27 سبتمبر 1983.

يُبنى Copyleft على قانون حقوق الطبع والنشر، وليس في مواجهته. افتراضياً، لا يحق لك نسخ كود شخص آخر إطلاقاً. تمنحك GPL هذا الحق بشرط: إذا منحت البرنامج لشخص آخر، فيجب أن تمنحه الكود المصدري أيضاً، وبالشروط نفسها، لكي يتمكن من فعل ما لم يستطع المختبر فعله. ويمكن إنفاذ هذا الشرط لأنك لم تكن تملك الإذن أصلاً من دون الترخيص.

كتب Stallman ترخيصاً لـGNU Emacs أولاً، ثم عمّمه ليصبح GPL version 1 في 25 فبراير 1989. تبعته GPL version 2 في يونيو 1991، وما زالت هذه الرخصة مستخدمة مع معظم برامج النظام التي تشغّلها. وظهرت Lesser GPL للمكتبات، بحيث يمكن لبرنامج مرخّص بأي ترخيص ربط مكتبة Copyleft من دون أن يخضع ذلك البرنامج لـGPL.

تحدد نقطة واحدة كيفية تأثير GPL في من يستضيف خدماته بنفسه. يبدأ الالتزام عند التوزيع، وليس عند الاستخدام. يمكنك تعديل برنامج GPL وتشغيله على خادمك الخاص وتقديم خدمة عامة به، من دون أن تدين لأحد بشيء، لأنك لم تسلّم نسخة منه إلى أي شخص. وهذه الفجوة هي سبب وجود AGPL.

التقليد المتساهل: BSD ثم MIT

اتبعت Berkeley مساراً مختلفاً. أصدرت Computer Systems Research Group أعمالها المتعلقة بـUnix بموجب ترخيص اشترط الإبقاء على إشعار حقوق الطبع والنشر، وأخلى المسؤولية عن جميع الضمانات. احتوى الإصدار الأصلي على أربعة بنود. وكان البند الرابع، المعروف ببند الإعلانات، يشترط الإشارة إلى الجامعة في جميع المواد الإعلانية التي تذكر ميزات البرنامج. هذا الشرط لا يتوسع عملياً. أحصى Stallman 75 إشارة منفصلة في إصدار عام 1997 من NetBSD. وسحبت UC Berkeley هذا البند في 22 July 1999، في رسالة من William Hoskins من Office of Technology Licensing التابعة لها.

المتبقي هو ترخيص BSD ذي 3 بنود. ويضيف حظراً على استخدام أسماء المساهمين لتأييد منتجك. وهناك الإصدار ذو البندين، الذي يحذف هذا الشرط أيضاً. صدر نص ترخيص MIT من MIT في 1980s، وكان يغطي X Window System. وعملياً، يؤدي الغرض نفسه الذي يؤديه BSD ذو البندين.

كانت الدوافع مختلفة. أرادت جامعة ممولة من المال العام أن تُستخدم أعمالها في كل مكان، بما في ذلك لدى الشركات. وأراد مشروع GNU إنشاء مشاع برمجي لا يمكن إغلاقه. كلا الموقفين صادق، ولكل منهما حالة فشل. يمكن تحويل الشيفرة المتساهلة إلى ملكية خاصة، ولا تحصل على شيء في المقابل. وقد ترفض الشركات الشيفرة الخاضعة لـcopyleft لأن محاميها لا يقبلون هذا الشرط.

هناك درس ثانٍ من Berkeley، وهو الدرس الذي يعود إليه هذا المنشور باستمرار. رفعت AT&T's Unix System Laboratories دعوى على Berkeley Software Design في 1992 بسبب شيفرة BSD، وانتهت القضية بتسوية في أوائل 1994. لمدة عامين، لم يكن أحد متأكداً من إمكانية بناء البرمجيات بأمان على BSD. وتباطأ اعتماده بينما نما Linux. يوقف عدم اليقين القانوني الاعتماد أسرع مما تفعل ميزة مفقودة.

لماذا أضاف Apache 2.0 منح ترخيص براءات الاختراع

كان أول ترخيص لمجموعة Apache نسخة مشتقة من BSD ذات 4 بنود، وكانت تتضمن المشكلة نفسها المتعلقة بالإعلانات. أزالت النسخة 1.1 هذا البند في عام 2000. أما النسخة 2.0، التي نُشرت في يناير 2004، فكانت إعادة صياغة كاملة وليست مجرد تصحيح.

الإضافة المهمة تتعلق ببراءات الاختراع. لا تتناول MIT وBSD براءات الاختراع إطلاقاً. يمكن للمساهم أن يمنحك إذناً واضحاً بحقوق الطبع والنشر الخاصة بشفرته، وأن يحتفظ في الوقت نفسه ببراءة اختراع تشمل ما تفعله الشفرة، ثم يقاضي الأشخاص الذين يستخدمونها. يعالج Apache 2.0 هذه الثغرة: يمنح كل مساهم ترخيصاً لبراءة اختراع يغطي مساهمته، ومن يقاضي مدعياً أن العمل ينتهك براءات اختراعه يفقد ترخيص براءات الاختراع الخاص به لهذا العمل. التهديد متبادل، لذلك لا يلجأ أحد إلى هذا الإجراء عملياً.

أما بقية النسخة 2.0 فتتعلق بالإدارة، ولهذا تفضّلها الشركات. يوجد ملف NOTICE محدد، فتكون الإشارة إلى أصحاب الحقوق في مكان واحد بدلاً من توزيعها في أنحاء شجرة المصدر. ويمكن تطبيق الترخيص بالإحالة إليه بدلاً من نسخه في كل ملف مصدر. وتخضع المساهمات لشروط صريحة. وتُستبعد العلامات التجارية. عند إجراء مراجعة قانونية لتبعية مرخّصة بموجب Apache 2.0، يجد المراجع أن كل سؤال يريد طرحه قد أُجيب عنه في النص مسبقاً، لذلك تصبح الموافقة إجراءً روتينياً، وهذا يعبّر عن معظم معنى «الافتراضي المؤسسي».

ما الذي غيّرته GPLv3، ولماذا بقي Linux على GPLv2

أطلقت TiVo مسجلاً للفيديو يعمل بنظام Linux ونشرت مصدر النواة، تماماً كما تتطلب GPLv2. ثم تحققت الأجهزة من توقيع تشفيري أثناء الإقلاع، ورفضت تشغيل نواة لا تتعرف إليها. كان بإمكانك قراءة المصدر وتعديله وتجميعه. لكن لم يكن بإمكانك تشغيله على الجهاز الذي أُخذ منه. استُوفي نص الرخصة، لكن أُحبط غرضها. واكتسبت هذه الممارسة اسم tivoisation.

تجيب GPL version 3، التي نُشرت في 29 June 2007، عن ذلك مباشرة. عند نقل الملف الثنائي داخل جهاز استهلاكي، يجب عليك أيضاً توفير "معلومات التثبيت": المفاتيح أو التعليمات اللازمة لتثبيت نسخة معدلة وتشغيلها. أضافت Version 3 أيضاً منحاً صريحاً لبراءات الاختراع، وشروطاً صيغت استجابة لاتفاق براءات الاختراع بين Microsoft وNovell في November 2006، وتوافقاً باتجاه واحد مع Apache 2.0.

لم يتبع Linux ذلك. فالنواة مرخّصة بموجب GPL version 2 فقط، ولا تتضمن عبارة "or any later version" التي تتيح الانتقال إلى إصدار لاحق، ويذكر ملفها COPYING ذلك صراحة. اعترض Linus Torvalds علناً على شروط مكافحة tivoisation المتعلقة بالأجهزة الموقعة. لكن العائق العملي أكبر من مجرد الخلاف: للنواة آلاف أصحاب حقوق الطبع والنشر، ولذلك لا يمكن لأي جهة جمع الأذونات التي تتطلبها إعادة الترخيص، حتى لو أراد الجميع ذلك. هذه الحقيقة وحدها هي أقوى حماية يمكن أن يحظى بها مشروع، ومن المفيد تذكرها عند النظر في مشروع تملكه شركة واحدة.

أما الرخصة الأخرى التي ظهرت في 2007 فهي الأهم لك. توسّع GNU Affero GPL version 3، التي نُشرت في November من العام نفسه، الالتزام بتوفير المصدر ليشمل من يتفاعلون مع البرنامج عبر شبكة. إذا شغّلت خدمة AGPL معدلة للعامة، فأنت ملزم بتوفير المصدر لهؤلاء المستخدمين. لهذا السبب تستخدم نسبة كبيرة من برمجيات الويب ذاتية الاستضافة AGPL. Nextcloud مثال على ذلك، وإذا كنت تقارن البدائل ذاتية الاستضافة لـ Nextcloud، فإن سطر الرخصة في مستودع كل مرشح يخبرك عن سنواته الخمس المقبلة أكثر مما تخبرك قائمة ميزاته.

ما التراخيص التي يمكنك جمعها فعلياً؟

تسير التوافقية في اتجاه واحد، من التراخيص المتساهلة نحو تراخيص الحقوق المتروكة.

• يمكن أن يندرج كود MIT وBSD في أي منتج، بما في ذلك المنتج المغلق.
• يمكن تضمين كود Apache 2.0 في مشروع GPLv3، ويصبح العمل المدمج خاضعاً لـGPLv3.
• لا يمكن تضمين كود Apache 2.0 في مشروع يقتصر على GPLv2. إذ تُعد شروط إنهاء حقوق براءة الاختراع والتعويض شروطاً إضافية لا تسمح GPLv2 بإضافتها. وتنشر كل من FSF وASF هذا الاستنتاج.
• لا يمكنك نقل كود خاضع لـGPL إلى ترخيص متساهل. لا يستطيع فعل ذلك إلا أصحاب حقوق الطبع والنشر، وهذا يعيدك إلى سؤال من هم هؤلاء أصحاب الحقوق.

عصر إعادة الترخيص: SSPL وBUSL وما ليستا إياه

كان الدافع تجارياً. تمتلك شركة حقوق الطبع والنشر لمنتج ما، ثم يبيعه مزود سحابي كخدمة مُدارة على نطاق واسع ولا يساهم إلا بالقليل في المقابل، فتغيّر الشركة الترخيص لإيقاف ذلك. اتخذت Redis Labs أول خطوة واضحة في أغسطس 2018، بإضافة Commons Clause إلى Apache 2.0 لعدة وحدات. ثم تبعتها MongoDB في 16 أكتوبر 2018، بالانتقال من AGPLv3 إلى Server Side Public License.

إن SSPL هي AGPL مع إعادة صياغة قسم واحد منها. إذا عرضت البرنامج على أطراف ثالثة كخدمة، فيجب أن تنشر الشيفرة المصدرية لكل ما تستخدمه لتقديمها، بما في ذلك برامج الإدارة والتنسيق المحيطة بها. لا يوجد حد واضح لهذا الالتزام، ولم تختبره أي محكمة. لم تعتمد OSI هذا الترخيص قط، وسحبت MongoDB طلبها في مارس 2019. وكانت Debian قد أعلنت بالفعل في ديسمبر 2018 أن برامج SSPL لا مكان لها في أرشيفها، ثم قررت Fedora في يناير 2019 أن الترخيص غير حر. بعد ذلك أزالت Red Hat MongoDB من Fedora ومن Red Hat Enterprise Linux. هذه هي النتيجة العملية لإعادة الترخيص: تتوقف التوزيعة عن حزم البرنامج، فتأتي ترقياتك الآن من مستودع مورّد وفق جدول المورّد.

إن Business Source License آلية مختلفة. وقد جاء من مؤسسي MariaDB، ويعود الإصدار 1.1 إلى 2017. وهو ليس ترخيصاً متبادلاً، وليس مفتوح المصدر. تكون الشيفرة المصدرية عامة، ويكون الاستخدام مجانياً باستثناء الاستخدام الذي يستثنيه المورّد، وهو عادةً تشغيل خدمة مستضافة منافسة. كما يتحول كل إصدار تلقائياً إلى ترخيص حقيقي مفتوح المصدر في تاريخ تغيير لا يتجاوز أربع سنوات من تاريخ ذلك الإصدار. ويجب أن يكون الترخيص الذي يتحول إليه متوافقاً مع GPLv2. نقلت HashiCorp Terraform ومنتجاتها الأخرى إلى BUSL 1.1 في 10 أغسطس 2023. وتستخدمه Outline أيضاً، وهذا مهم إذا كنت تختار من بدائل Notion المستضافة ذاتياً: يُسمح بتشغيله لفريقك، ولا يُسمح ببناء خدمة عليه.

لا يُعد أي من الترخيصين مخادعاً. فكلاهما يوضح صراحةً أن الشيفرة المصدرية متاحة. ولا يُعد أي منهما مفتوح المصدر وفق تعريف OSI، ويقع أثر هذا الفرق عليك أنت، لا على مزود الخدمة السحابية الذي استهدفه الترخيص.

OpenSearch: ما تكلفة تفرّع الترخيص على المشغّل

أعلنت Elastic في 14 January 2021 أن Elasticsearch وKibana سيتخلّيان عن Apache 2.0 لصالح خيار من SSPL أو Elastic License، بدءاً من الإصدار 7.11. وكان الإصدار 7.10.2 آخر إصدار بترخيص Apache 2.0. وبعد نحو أسبوع، أعلنت AWS أنها ستنشئ تفرّعاً بترخيص Apache 2.0 لكليهما وستحافظ عليه. سُمّي التفرّع OpenSearch في 12 April 2021، وأُعيدت تسمية Kibana إلى OpenSearch Dashboards. أصبح OpenSearch 1.0 متاحاً عموماً في 12 July 2021، وقد بُني من Elasticsearch 7.10.2 وKibana 7.10.2.

انظر إلى التكلفة التي تحمّلها مشغّلو العناقيد. تغيّرت أسماء الحزم والمستودعات. وتحولت كل إشارة إلى Kibana في دليل التشغيل إلى OpenSearch Dashboards. وانتقلت أسماء الإضافات. ثم وصل الانقسام إلى شيفرة التطبيقات: بدءاً من الإصدار 7.13 من مكتبات العميل الرسمية لدى Elastic، يتحقق العميل مما اتصل به ويرفض المتابعة إذا لم يكن Elasticsearch، ويبلّغ بأن الخادم منتج غير معروف. وصل قرار ترخيص اتخذته شركة لا تعمل لديها إلى شكل استدعاء فاشل داخل تطبيقك أنت.

ثم اتخذت القصة منعطفين إضافيين. أضافت Elastic ترخيص AGPLv3 كخيار ثالث في 29 August 2024، ولذلك أصبح Elasticsearch الحالي مرة أخرى برنامجاً مفتوح المصدر معتمداً من OSI. وفي 16 September 2024، نقلت AWS OpenSearch إلى OpenSearch Software Foundation، التي تستضيفها Linux Foundation، فحصل التفرّع على جهة حوكمة لا تتبع شركة واحدة. وبعد مرور خمس سنوات على الانقسام، أصبح كلا المشروعين مفتوح المصدر، وكلاهما يخضع للصيانة، ووصل OpenSearch إلى سلسلة 3.x اعتباراً من August 2026.

الخلاصة هي الدرس. عاد الترخيص، وبقي التفرّع. عندما يصبح للنظام البيئي نسختان من كل شيء، لا تؤدي إعادة الأوراق إلى دمجهما من جديد.

الرقم الذي يحدد مقدار الضرر الناتج عن إعادة الترخيص هو الفاصل بين الإعلان وإصدار مستقر لتفرّع يمكنك نشره فعلياً.

[
  {
    "label": "Elasticsearch to OpenSearch 1.0",
    "gap_to_stable_fork": 179
  },
  {
    "label": "Terraform to OpenTofu 1.6.0",
    "gap_to_stable_fork": 153
  },
  {
    "label": "Redis to Valkey 7.2.5",
    "gap_to_stable_fork": 27
  }
]

يُحسب كل فاصل من الإعلان العلني للمورّد إلى أول إصدار مستقر للتفرّع، باستخدام التواريخ الواردة أدناه. استغرق OpenSearch 1.0 مدة 179 يوماً، لأن التفرّع كان يحتاج إلى إعادة تسمية وإعادة بناء، ولم يكن هناك تفرّع أقدم يمكن النسخ منه. واستغرق OpenTofu مدة 153 يوماً. أما Valkey فاستغرق 27 يوماً، لأنه تفرّع من Redis 7.2.4 وأبقى البروتوكول والتنسيق على القرص متطابقين. الاتجاه هو الجزء المفيد: يصل التفرّع الموثوق الآن خلال أسابيع، مع مؤسسة ومشرفين مدفوعي الأجر منذ اليوم الأول.

Valkey وOpenTofu: النمط نفسه، لكن بوتيرة أسرع

نقلت Redis Ltd ترخيص Redis من BSD ذي البنود الثلاثة إلى خيار بين RSALv2 وSSPLv1 في 20 March 2024. وبعد 8 أيام، أعلنت Linux Foundation عن Valkey، الذي تفرّع من Redis 7.2.4 واستمر بترخيص BSD ذي البنود الثلاثة. صدر Valkey 7.2.5 في 16 April 2024 مع البروتوكول نفسه وملفات البيانات نفسها، لذلك اقتصرت عملية الترحيل لدى معظم المشغّلين على تغيير اسم الحزمة. ثم أضافت Redis ترخيص AGPLv3 كخيار ثالث في Redis 8 في May 2025، ما أعاده إلى وضع البرمجيات مفتوحة المصدر وفق تعريف OSI، بينما يواصل Valkey العمل وفق حوكمته الخاصة. ويتطابق هذا المسار بدرجة كبيرة مع Elasticsearch.

مرّت Terraform بالمسار نفسه مع فصل إضافي. تفرّعت OpenTofu من آخر إصدار بترخيص Mozilla Public License 2.0، وانضمّت إلى Linux Foundation في September 2023، وأصدرت 1.6.0 في 10 January 2024. في 3 April 2024، أرسل محامو HashiCorp إلى المشروع خطاباً يطالبه بوقف الاستخدام، مدّعين أن شيفرة من إصدار Terraform المرخّص بموجب BUSL نُسخت إلى التفرّع. نشرت OpenTofu رداً مفصلاً في 11 April 2024 ونفت ذلك، وأرجعت الشيفرة محل النزاع إلى السجل التاريخي المرخّص بموجب MPL، الذي يشترك فيه المشروعان. ولم يحدث شيء آخر علناً بعد ذلك. الخطر الحقيقي في تلك الحادثة هو ما ينبغي تذكّره: يمكن لاتهام وحده أن يجمّد الاعتماد لمدة ربع سنة، وهو الأثر نفسه الذي أحدثته دعوى Berkeley قبل 30 عاماً.

لا يبدأ كل تفرّع بسبب ترخيص. تفرّعت Forgejo من Gitea في 2022 بعد انتقال تطوير Gitea إلى شركة، وكان ذلك خلافاً حول الحوكمة لا حول الترخيص. حافظت Forgejo على ترخيص MIT طوال سلسلة إصداراتها 8، ثم غيّرت ترخيصها إلى GPLv3 أو أي إصدار لاحق بدءاً من الإصدار 9.0 في 2024، حتى لا يمكن إعادة دمج عملها في منتج خاضع لسيطرة تجارية. إذا كنت تقيّم خيارات خوادم Git ذاتية الاستضافة، فإن هذا الزوج هو أوضح مثال قائم على قاعدة شيفرة واحدة وفلسفتين مختلفتين.

الاختبار الذي يجب إجراؤه قبل اعتماد أي مشروع

أجب عن أربعة أسئلة قبل التثبيت الأول، لا بعده.

1. من يملك حقوق النشر؟ يتطلب إعادة الترخيص إذناً من كل صاحب حقوق نشر، لذلك لا يمكن عملياً إعادة ترخيص مشروع يضم مئات المساهمين المستقلين ولا يتضمن نقل حقوقهم. أما المشروع الذي تملك شركة واحدة جميع حقوقه، فيمكن إعادة ترخيصه بقرار من مجلس الإدارة.
2. هل توجد CLA، وما الحقوق التي تمنحها؟ تتيح اتفاقية ترخيص المساهم للشركة إعادة ترخيص مساهمتك بأي شروط تختارها، وهي الآلية المحددة وراء كل عمليات إعادة الترخيص المذكورة أعلاه. أما DCO (شهادة منشأ المطوّر)، وهي سطر الإقرار الذي اعتمده Linux kernel في 2004، فلا تنقل أي حقوق على الإطلاق. وتكون CLA التي تحتفظ بها مؤسسة أكثر أماناً من تلك التي تحتفظ بها شركة، لأن الشركة قد تُباع.
3. من يملك العلامة التجارية؟ احتفظت Elastic باسم Elasticsearch، لذلك اضطر المشروع المتشعب إلى تغيير اسمه، وكان يجب إعادة كتابة كل runbook يذكر Kibana.
4. ما تكلفة إعادة الترخيص عليك تحديداً؟ احسب تكلفة تنسيق البيانات، ومكتبات العميل، وإعادة كتابة الإعدادات، وتحقق مما إذا كان يوجد مشروع متشعب متوافق بالفعل.

يجيب أمران عن جزء من هذه الأسئلة خلال ثوانٍ.

head -n 12 /usr/share/doc/bash/copyright
git log --oneline -- LICENSE COPYING LICENSE.md

تتضمن كل حزمة Debian وUbuntu ملفاً في المسار /usr/share/doc/<package>/copyright، ويسجل هذا الملف ترخيص الإصدار الذي ثبّتَّه، لا الترخيص الذي يستخدمه المشروع اليوم. بالنسبة إلى bash في Ubuntu 24.04، يذكر الملف GNU General Public License الإصدار 3. شغّل الأمر الثاني داخل نسخة مسحوبة من المستودع المصدر لتحصل على سجل تغييرات ملف الترخيص نفسه. يجدر بك قراءة أي commit أُضيف إليه خلال آخر عامين قبل أن تبني أي شيء على المشروع. إذا لم يطبع الأمر شيئاً، فقد سمّى المستودع ملف الترخيص باسم آخر، لذا اعرض محتويات الدليل الجذري وابحث عنه.

لا يحميك أي ترخيص من كل النتائج المحتملة، كما أن الاختيار وفقاً للأيديولوجيا هو ما يؤدي إلى المفاجآت. فضّل المشاريع التي تتوزع حقوق نشرها بين جهات كثيرة أو تملكها مؤسسة، واحتفظ ببياناتك بتنسيق يمكنك تصديره. ثم حدّد المشروع المتشعب الذي ستنتقل إليه، واكتب اسمه قبل أن تحتاج إليه. لا يستغرق تطبيق هذا الفحص على كل مرشح أكثر من ساعة، وهو ما يحدد الفرق بين الترقية والترحيل عندما تقرر ما الذي تستضيفه ذاتياً في 2026.

FAQ

هل ترخيص MIT هو نفسه ترخيص BSD؟

عملياً، يتطابق ترخيص MIT مع ترخيص BSD ذي البندين: احتفظ بإشعار حقوق الطبع والنشر وإخلاء مسؤولية الضمان، ثم استخدم الكود كما تشاء، بما في ذلك إنشاء منتج مغلق المصدر. يضيف ترخيص BSD ذي البنود الثلاثة شرطاً واحداً، وهو حظر استخدام أسماء المساهمين للترويج لمنتجك دون إذن. أما الإصدار الأقدم ذو البنود الأربعة، فكان يفرض أيضاً إقراراً في المواد الإعلانية. وقد سحبت UC Berkeley هذا البند في 22 July 1999، لذلك يكاد لا يظهر في أي ترخيص حالي.

هل يمكنني وضع كود Apache 2.0 في مشروع يستخدم GPLv2؟

لا. يضيف Apache 2.0 شروطاً لا يسمح GPLv2 بإضافتها، وأهمها بند إنهاء حقوق براءات الاختراع. لذلك لا يمكن لعمل مدمج أن يستوفي كلا الترخيصين في الوقت نفسه. تنشر كل من FSF وASF هذا الاستنتاج. أما الاتجاه العكسي فهو ممكن: يمكن تضمين كود Apache 2.0 في مشروع يستخدم GPLv3، وتكون النتيجة مرخّصة بموجب GPLv3. ولهذا أيضاً لا يمكن دمج كود Apache 2.0 في Linux kernel، الذي يستخدم GPL version 2 فقط.

هل SSPL ترخيص مفتوح المصدر؟

لا، ولهذا الجواب تبعات عملية. لم تعتمد OSI هذا الترخيص قط، وسحبت MongoDB طلبها في March 2019. قالت Debian في December 2018 إن برمجيات SSPL لا تنتمي إلى أرشيفها، وقررت Fedora في January 2019 أن الترخيص غير حر. بعد ذلك أزالت Red Hat حزمة MongoDB من Fedora وRed Hat Enterprise Linux. وهذا يعني بالنسبة إليك أن الحزمة التي كانت توزيعتك تتولى صيانتها أصبحت تأتي من مستودع المورّد، وفق جدول دعم المورّد. ويُعد Business Source License أيضاً متاحاً للمصدر وليس مفتوح المصدر، مع أن كل إصدار يتحول إلى ترخيص مفتوح المصدر خلال أربع سنوات.

هل ينطبق تغيير الترخيص على الإصدار الذي أشغّله بالفعل؟

لا. لا يمكن سحب الترخيص الممنوح مع إصدار من النسخ المنشورة بالفعل، وهذا تحديداً ما يجعل إنشاء التفرعات ممكناً. بُني OpenSearch من Elasticsearch 7.10.2، وهو آخر إصدار نشرته Elastic بموجب Apache 2.0. ما تخسره هو المستقبل، لأن الإصلاح الأمني التالي سيصل بموجب الشروط الجديدة. يتيح لك تثبيت آخر إصدار مرخّص بترخيص متساهل كسب بضعة أشهر، لكنه ليس خطة.