لماذا تُمنح شيفرة واحدة عدة تراخيص؟
يمكن لصاحب الحقوق أن يمنح الشيفرة نفسها بعدة شروط في آن واحد. ويكفي المتلقي أن يختار أحدها ويلتزم بشروطه. والغرض من ذلك أمران رئيسيان.
- توسيع التوافق — لتتلاءم الشيفرة جيدًا مع منظومات مختلفة.
- نموذج العمل — لنشرها مفتوحة المصدر مع بيع ترخيص تجاري منفصل.
النوع 1: ترخيصان متساهلان معًا — MIT OR Apache-2.0
هذا هو النهج الذي تتبعه لغة Rust ومعظم حزم Rust. يختار المستخدم ما يناسبه من MIT أو Apache-2.0.
- إذا اختار Apache-2.0 يحصل على منح صريح للبراءات.
- إذا اختار MIT يمكنه إدراجها حتى في مشاريع GPL-2.0-only (بسبب موقف FSF بأن Apache-2.0 غير متوافق مع GPL-2.0).
فهو يجمع الميزتين معًا، ولذلك يحظى بشعبية لدى مؤلفي المكتبات. والعرف أن يوضع في المستودع ملفان: LICENSE-MIT وLICENSE-APACHE.
النوع 2: حقوق متروكة + ترخيص تجاري — 'إما GPL وإما أن تدفع'
تُنشر الشيفرة بترخيص GPL أو AGPL، ويُباع ترخيص تجاري بعقد منفصل للشركات التي لا تريد تحمّل التزام نشر المصدر. ومن الأمثلة البارزة MySQL (GPL + ترخيص Oracle التجاري) وQt (LGPL-3.0/GPL + ترخيص تجاري).
لا يعمل هذا النموذج إلا إذا كان صاحب الحقوق يملك حقوق الشيفرة كلها. فالشيفرة التي قدّمها مساهمون خارجيون بترخيص GPL فقط لا يحق لصاحب الحقوق بيعها بترخيص تجاري.
CLA وDCO
- CLA (اتفاقية ترخيص المساهم): عقد يمنح فيه المساهم الجهة المشغّلة للمشروع حقًا واسعًا (يشمل إعادة الترخيص) في استخدام مساهمته أو ينقل إليها حقوق النشر. وهي ضرورية فعليًا للترخيص المزدوج التجاري. وهناك صيغ مثل ICLA لمؤسسة Apache تمنح صلاحية إعادة الترخيص فقط وتُبقي حقوق النشر للمساهم.
- DCO (Developer Certificate of Origin): أسلوب يؤكد فيه المساهم في كل إيداع أنه 'يملك حق تقديم هذه الشيفرة بترخيص هذا المشروع' (بإضافة سطر
Signed-off-by:عبرgit commit -s). وتستخدمه نواة لينكس. ولا تمنح DCO صلاحية إعادة الترخيص، لذا فهي غير كافية للترخيص المزدوج التجاري.
الكتابة بتعبيرات SPDX
تُكتب العلاقة بين عدة تراخيص بتعبيرات تراخيص SPDX.
| التعبير | المعنى | مثال |
|---|---|---|
A OR B | اختر أحدهما واتبعه (مزدوج اختياري) | MIT OR Apache-2.0 |
A AND B | يجب اتباع الاثنين معًا (عند اختلاط أجزاء مختلفة) | MIT AND BSD-3-Clause |
A WITH استثناء | إرفاق بند استثناء بالترخيص | GPL-2.0-only WITH Linux-syscall-note |
| الأقواس | تحديد ترتيب الربط | (MIT OR Apache-2.0) AND Unicode-3.0 |
الخلط بين OR وAND يقلب المعنى تمامًا. إذا كان للمستخدم أن يختار فهو OR، وإذا وجب الالتزام بالكل فهو AND.
نقاط ينبغي الانتباه إليها
- الحقوق الممنوحة سابقًا تبقى قائمة: حتى إذا أبقيت لاحقًا على الترخيص التجاري وحده، يظل الإذن الممنوح للإصدارات التي وُزّعت مفتوحة المصدر ساريًا عادةً.
- يختلف عن 'النواة المفتوحة': نموذج نشر النواة مفتوحة المصدر وبيع الميزات الإضافية بترخيص تجاري مغلق ليس ترخيصًا مزدوجًا. الترخيص المزدوج هو منح ترخيصين للشيفرة نفسها.
- لا تخلط بينه وبين تراخيص المصدر المرئي: تزايدت حالات التحول إلى تراخيص مثل BUSL وSSPL يكون فيها المصدر مرئيًا لكنها ليست مفتوحة المصدر وفق معايير OSI. وهذه استراتيجية مختلفة عن الترخيص المزدوج.
- دقّق ملفات الإشعار: في النوع الاختياري قدّم النص الكامل لكل ترخيص، واذكر بوضوح في README أن 'الاختيار بين الاثنين'.
مثال على التطبيق
لتطبيق ترخيص مزدوج على طريقة Rust نزّل ملفي MIT وApache-2.0 كلًّا على حدة من المولّد واحفظهما باسم LICENSE-MIT وLICENSE-APACHE، ثم اكتب في البيانات الوصفية license = "MIT OR Apache-2.0". وفي ترويسة كل ملف استخدم SPDX-License-Identifier: MIT OR Apache-2.0.
هذا المقال معلومات عامة وليس استشارة قانونية. استشر مختصًا في القرارات المهمة.
المصادر
- SPDX Specification, License Expressions — https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
- Rust API Guidelines, Licensing — https://rust-lang.github.io/api-guidelines/necessities.html
- Developer Certificate of Origin — https://developercertificate.org/
- Apache ICLA — https://www.apache.org/licenses/contributor-agreements.html