EPL (Eclipse Public License) و GPL (GNU Public License) / LGPL (Lesser GPL) واستثناءات الترخيص؟[مغلق]

Question

تعتبر مؤسسة البرمجيات الحرة أن EPL و GPL غير متوافقين . بناءً على قراءتي لمنطقهم ، يبدو أن LGPL ستتأثر بالمثل - IANAL ، يرجى تصحيح لي إذا كانت هذه القراءة غير صحيحة. الآن ، هناك دليل لمالك حقوق الطبع والنشر لرمز GPL-ed لتوفير استثناءات تسمح بربط الشفرة بالمكتبات غير المتوافقة ، لكنها لا تزال تمنع الارتباط برمز GPL-ed من الآخرين (إذا كان الرمز مرتبطًا بالفعل بمكتبة EPL) ، والموقف مع ربط GPL- برنامج ed مقابل EPL و مكتبة LGPL أخرى يبدو غير واضح.

أود معرفة الإجابة على عدة أسئلة:

1. ما هو بالضبط القيد المفروض على ربط منتج GPL-ed بمكتبة EPL ومكتبة LGPL؟ هل هو غير مسموح به بدون إذن صريح من صاحب حقوق النشر LGPL ، كما هو الحال مع GPL ، أم أنه مسموح به؟
2. هل يكون الاستثناء الممنوح من قبل صاحب حقوق الطبع والنشر EPL كافيًا؟ اعتبر Trolltech (الآن جزء من Nokia) مثل هذا الاستثناء آمنًا ، عندما استخدم لترخيص مكتبة Qt باستخدام ترخيص Qt العام الخاص بها والذي لا يتوافق مع GPL ؛ ومن خلال مشروع KDE ، الذي ترتبط مكتباته بـ Qt ويتم إصداره بموجب LGPL ، بينما يتم إصدار تطبيقات KDE بشكل عام بموجب GPL. يرجع اعتراض إف إس إف إلى "الحقوق المتروكة الضعيفة" و "بند اختيار القانون" - يبدو الأول غير مرفوض ، إذا منح حامل ترخيص EPL استثناءً ، ولكن ما هو نوع الاستثناء الممنوح من قبل صاحب حقوق الطبع والنشر EPL الذي يرضي "اختيار" الشرط القانوني "اعتراض؟

Answer 1

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

أولاً ، دعنا نتناول أسئلتك المحددة

السؤال: ما هو بالضبط القيد المفروض على ربط منتج GPL-ed بمكتبة EPL ومكتبة LGPL؟ هل هو غير مسموح به بدون إذن صريح من مالك حقوق النشر LGPL ، كما هو الحال مع GPL ، أم أنه مسموح به؟

الإجابة: يتبع التحلل

• ربما يكون ربط رمز LGPL 2 & 3 بـ EPL 1.0 أمرًا مقبولاً.
  • المرجع: LGPL 2 ، القسم 5 : البرنامج الذي لا يحتوي على أي مشتق من أي جزء من المكتبة ، ولكنه مصمم للعمل مع المكتبة من خلال تجميعها أو ربطها بها ، يسمى "العمل الذي يستخدم المكتبة".
  • المرجع: LGPL 3 ، القسم 4 : يمكنك نقل ملف اعمل وفقًا لشروط من اختيارك والتي ، مجتمعة ، لا تقيد بشكل فعال تعديل أجزاء المكتبة الواردة في العمل المشترك ...
• ربما يكون ربط رمز LGPL 2 و 3 برمز GPL 2 و 3 مقبولاً. انظر المخطط هو إجابة @ 0A0D لفهم المجموعات المسموح بها على وجه التحديد.
• ربط شفرة GPL 2 و 3 بـ EPL 1.0 بالتأكيد غير مسموح به .
  • المرجع: راجع إجابة @ 0A0D.
• فيما يتعلق الإذن الصريح لصاحب حقوق الطبع والنشر : ربما يمكنك فعل أي شيء تريده إذا حصلت على إذن من جميع أصحاب حقوق الطبع والنشر. بالنظر إلى تعقيد هذا من الناحية القانونية واللوجستية ، ينبغي اعتباره شبه مستحيل.
  • مثال: يمكنك (بجهود بطولية) ، محاولة الحصول على إذن (بالمال؟) من جميع المساهمين في Linux kernel لمنحك ترخيصًا على غرار BSD للرمز يمكنك التعديل والإصدار كبرنامج غير مجاني (تجاري). مرة أخرى ، كما لوحظ سابقًا ، ممكن ، لكنه غير واقعي.

السؤال: هل سيكون الاستثناء الممنوح من قبل صاحب حقوق الطبع والنشر EPL كافيًا؟ اعتبر Trolltech (الآن جزء من Nokia) مثل هذا الاستثناء آمنًا ، عندما استخدم لترخيص مكتبة Qt باستخدام ترخيص Qt العام الخاص بها والذي لا يتوافق مع GPL ؛ ومن خلال مشروع KDE ، الذي ترتبط مكتباته بـ Qt ويتم إصداره بموجب LGPL ، بينما يتم إصدار تطبيقات KDE بشكل عام بموجب GPL. يرجع اعتراض إف إس إف إلى "الحقوق المتروكة الضعيفة" و "شرط اختيار القانون" - يبدو الأول غير مرفوض ، إذا منح حامل ترخيص EPL استثناءً ، ولكن ما هو نوع الاستثناء الممنوح من قبل صاحب حقوق الطبع والنشر EPL الذي يرضي "اختيار البند القانوني "اعتراض؟

الإجابة: يتبع التحلل

• هل سيكون الاستثناء الممنوح من قبل صاحب حقوق الطبع والنشر EPL كافيًا؟
  • كما هو مذكور أعلاه ، هذا ممكن ، لكن غير واقعي للغاية أن أصحاب حقوق الطبع والنشر لرمز EPL 1.0 يمنحون مثل هذا الاستثناء.
• فيما يتعلق بترولتيك والترخيص المتعدد ، تتمتع الأعمال المشتقة عمومًا بخيار تحديد الترخيص المطلوب تقديمه. وبالتالي ، في حالة Trolltech / QPL / GPL ، انسَ أمر QPL واستخدم GPL.
• فيما يتعلق بـ KDE / LGPL ، لست على دراية بإستراتيجية الترخيص الخاصة بهم ولا يمكنني التعليق. ومع ذلك ، من المؤكد أن لديهم محامين لمراجعتها. AFAIK: KDE هي مؤسسة غير ربحية مسجلة في ألمانيا وقد تلقت على الأرجح بعض النصائح القانونية المجانية بشأن هذه الأمور. حتى لو لا ، فإن كيدي قديمة بما يكفي ، إذا لم تكن ممتثلة ، لكان صاحب حقوق الطبع والنشر سيعترض بالتأكيد الآن. اقرأ المزيد هنا.

أخيرًا ، أواجه أيضًا مشكلة مماثلة كما أحاول

لدمج كود Java من Eclipse و OpenJDK.

• Eclipse يستخدم EPL 1.0.
• يستخدم OpenJDK GPL 2 w / Classpath Exception (راجع الجزء السفلي جدًا من Classpathاستثناء)
  • اقرأ المزيد حول استثناءات Classpath هنا

تقول قراءتي للتراخيص أن دمج هذه الأعمال مسموح به صراحة لأن Eclipse يستخدم مصطلح عمل مشتق في بيان عدم توافق GPL 2 و 3.علاوة على ذلك ، ينص استثناء Classpath على وجه التحديد على أن الارتباط بهذه المكتبة لا يؤدي إلى إنشاء عمل مشتق.

Answer 2

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

من موقع Eclipse يوضح ما يلي:

لا يتوافق EPL و GPL في أي مجموعة حيث تكون النتيجة يعتبر إما: (أ) أ "العمل المشتق" (الذي كسوف يفسر بما يتفق مع تعريف هذا المصطلح في الولايات المتحدة. قانون حقوق النشر) أو (ب) العمل "القائم على "كود GPL ، كما هي هذه العبارة المستخدمة في GPLv2 أو GPLv3 أو GPL التعليمات حسب الاقتضاء. علاوة على ذلك ، يمكنك لا تجمع بين كود EPL و GPL في أي السيناريو حيث شفرة المصدر تحت تلك التراخيص هي نفس التعليمات البرمجية المصدر وحدة.

بناء على موقف الأحرار مؤسسة البرمجيات ، لا يجوز لك الجمع بين كود EPL و GPL في أي ملف السيناريو حيث يوجد الارتباط بين الشفرة المتاحة تحت تلك التراخيص. ما ورد أعلاه ينطبق على كليهما الإصدار 2 من GPL والإصدار 3.

في رأيي ، ما لم يكن هناك استثناء - لا ينبغي دمج كود LGPL و EPL. في الواقع ، الكثير من البرامج مرخصة بشكل مزدوج بموجب LGPL و EPL.