التوافق يعني 'هل يمكن الدمج والتوزيع معًا؟'
يعني توافق ترخيصين أنه يمكن الالتزام بشروط الترخيصين معًا عند دمج الشيفرتين المرخصتين بهما وتوزيعهما كبرنامج واحد. وإذا كان أحدهما يحظر شروط الآخر فهما غير متوافقين. فمثلًا يشترط GPL 'عدم فرض قيود إضافية'، لذا لا يمكن إدراج شيفرة ترخيص يتضمن شروطًا إضافية لا يسمح بها GPL في برنامج GPL.
للتوافق اتجاه
يمكن للشيفرة المتساهلة أن تدخل مشاريع الحقوق المتروكة، لكن العكس غير ممكن.
- شيفرة MIT ← مشروع GPL: ممكن. مع الإبقاء على إشعار MIT يمكن توزيع العمل المدمج بأكمله بترخيص GPL.
- شيفرة GPL ← مشروع MIT: يجب أن يتبع العمل المدمج بأكمله شروط GPL، فلا يمكن أن يبقى 'مشروع MIT'.
ولذلك يجب دائمًا قراءة جداول التوافق على أساس 'أي شيفرة ← في أي مشروع'.
تركيبات شائعة
Apache-2.0 وGPL
ترى FSF أن Apache-2.0 متوافق مع GPL-3.0 لكنه غير متوافق مع GPL-2.0. والسبب أن بندي إنهاء البراءات والتعويض في Apache-2.0 شرطان إضافيان غير موجودين في GPL-2.0. وقد صُمّم GPL-3.0 منذ البداية لحل هذه المشكلة. لذا يمكن لمشاريع GPL-2.0-or-later استخدام شيفرة Apache-2.0 إذا وزّعت العمل المدمج بترخيص GPL-3.0.
MPL-2.0 وتراخيص GNU
تعرّف المادة 1.12 من MPL-2.0 تراخيص GPL-2.0 وLGPL-2.1 وAGPL-3.0 وإصداراتها اللاحقة بوصفها 'Secondary License'، وتسمح المادة 3.3 بتوزيع Larger Work الذي يجمع شيفرة MPL مع هذه الشيفرات بترخيص GNU. ويُستثنى من ذلك ما أرفق به المؤلف الأصلي Exhibit B ('Incompatible With Secondary Licenses').
مكتبات LGPL والتطبيقات المغلقة
يمكن استخدام مكتبات LGPL في التطبيقات المغلقة. لكن في المقابل يجب أن يتمكن المستخدم من استبدال المكتبة بنسخة معدّلة (والربط الديناميكي أسهل الطرق)، ويجب تقديم مصدر جزء المكتبة وإشعار الترخيص. أما إذا نسخت شيفرة LGPL وخلطتها بمصدر التطبيق فيختلف الأمر، ويجب أن يتبع العمل المدمج شروط LGPL/GPL.
GPL-3.0 وAGPL-3.0
يسمح الترخيصان صراحةً بالدمج عبر المادة 13 في كل منهما. وفي العمل المدمج يستمر جزء GPL في اتباع شروط GPL، وجزء AGPL في اتباع شروط AGPL بما فيها شرط توفير المصدر عبر الشبكة.
EPL-2.0 وGPL
EPL-2.0 غير متوافق مع GPL افتراضيًا، لكن إذا حدّد المؤلف الأصلي GPL أو غيره بوصفه Secondary License عبر Exhibit A يصبح الدمج ممكنًا.
| الشيفرة المستوردة | تطبيق مغلق | مشروع MIT | GPL-2.0-only | GPL-3.0 |
|---|---|---|---|---|
| MIT·BSD·ISC | ممكن (إشعار) | ممكن | ممكن | ممكن |
| Apache-2.0 | ممكن (إشعار·NOTICE) | ممكن | غير ممكن | ممكن |
| MPL-2.0 | بشروط (نشر الملفات) | بشروط | بشروط (Secondary) | بشروط (Secondary) |
| LGPL-3.0 | بشروط (الربط) | بشروط (الربط) | غير ممكن | ممكن |
| GPL-3.0 | غير ممكن | غير ممكن | غير ممكن | ممكن |
إلى أي حد يمتد 'الدمج'؟
تنشأ مشكلة التوافق عندما تُدمج الشيفرة في برنامج واحد. ترى FSF أن الربط في ملف تنفيذي واحد أو مشاركة بنى بيانات داخلية معقدة يجعلهما برنامجًا واحدًا، أما التواصل المعتاد بين برامج منفصلة عبر الأنابيب والمقابس ومعاملات سطر الأوامر فيُعدّ عادةً 'تجميعًا (aggregate)' لبرامج منفصلة. لكن هذا الحد لم تحسمه أحكام قضائية، فالتفسيرات متباينة. ومجرد وضع عدة برامج معًا في توزيعة واحدة ليس دمجًا.
الخطوات العملية
- استخرج قائمة الاعتماديات (بميزة تقارير التراخيص في مدير الحزم أو بأدوات SBOM).
- نظّم ترخيص كل اعتمادية بمعرّف SPDX.
- تحقّق مبدئيًا من تركيبتها مع ترخيص مشروعك عبر مدقق التوافق.
- في التركيبات 'المشروطة' تحقّق من الشروط (الإشعار، طريقة الربط، وجود Secondary License) في النص الأصلي.
- إذا وُجدت تركيبة غير ممكنة فغيّر الاعتمادية أو افصل البرنامج أو عدّل ترخيصك.
هذا المقال معلومات عامة وليس استشارة قانونية. استشر مختصًا في القرارات المهمة.
المصادر
- GNU License FAQ (compatibility matrix, MereAggregation) — https://www.gnu.org/licenses/gpl-faq.html
- FSF, Various Licenses and Comments about Them — https://www.gnu.org/licenses/license-list.html
- Apache Software Foundation, GPL Compatibility — https://www.apache.org/licenses/GPL-compatibility.html
- Mozilla, MPL 2.0 FAQ — https://www.mozilla.org/en-US/MPL/2.0/FAQ/
- Eclipse Foundation, EPL 2.0 FAQ — https://www.eclipse.org/legal/epl-2.0/faq/