المكونات الإضافية الخاصة ببرامج GPL:ماذا عن اللغات المترجمة؟[مغلق]

Question

أقوم بتطوير تطبيق مرخص بـ GPL في Python وأحتاج إلى معرفة ما إذا كانت GPL تسمح لبرنامجي باستخدام المكونات الإضافية الخاصة.هذا هو ما يجب أن يقوله FSF حول القضية:

إذا كان البرنامج الذي تم إصداره بموجب GPL يستخدم مكونات إضافية، فما هي متطلبات تراخيص المكونات الإضافية؟

يعتمد ذلك على كيفية استدعاء البرنامج للمكونات الإضافية الخاصة به.إذا كان البرنامج يستخدم fork وexec لاستدعاء المكونات الإضافية، فإن المكونات الإضافية هي برامج منفصلة، ​​وبالتالي فإن ترخيص البرنامج الرئيسي لا يتطلب أي متطلبات لها.

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

إذا كان البرنامج يربط المكونات الإضافية ديناميكيًا، ولكن الاتصال بينها يقتصر على استدعاء الوظيفة "الرئيسية" للمكون الإضافي مع بعض الخيارات وانتظار عودته، فهذه حالة حدودية.

لا ينطبق التمييز بين fork/exec والارتباط الديناميكي، إلى جانب كونه نوعًا من الاصطناعي، على اللغات المفسرة:ماذا عن البرنامج المساعد Python/Perl/Ruby، الذي يتم تحميله عبر import أو execfile?

(يحرر:أفهم سبب التمييز بين fork/exec والارتباط الديناميكي، ولكن يبدو أن الشخص الذي يريد الامتثال لـ GPL ولكنه يتعارض مع "الروح" - لا أفعل - يمكنه فقط استخدام fork/exec والتواصل بين العمليات من أجل افعل أي شيء تقريبًا).

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

Answer 1

إنه يميز بين fork/exec والربط الديناميكي، إلى جانب كونه نوعًا من الاصطناعي،

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

من ناحية أخرى، إذا كانت التعليمات البرمجية تعتمد بشكل كبير على عمل GPL، مثل استدعاء واجهات برمجة التطبيقات (APIs) على نطاق واسع، أو التكامل المحكم لبنية البيانات، فمن المرجح أن تعتبر الأشياء عملاً مشتقًا.أي أن "المكون الإضافي" لا يمكن أن يوجد بمفرده بدون منتج GPL، والمنتج المثبت عليه هذا المكون الإضافي هو في الأساس عمل مشتق من منتج GPLed.

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

هل هذا أكثر منطقية؟

Answer 2

@ دانيال

لا ينطبق التمييز بين fork/exec والارتباط الديناميكي، إلى جانب كونه نوعًا من الاصطناعي، على اللغات المفسرة:ماذا عن البرنامج المساعد Python/Perl/Ruby، الذي يتم تحميله عبر ملف الاستيراد أو execfile؟

لست متأكدا من هذا التمييز يكون صناعي.بعد التحميل الديناميكي، يشارك كود البرنامج الإضافي سياق التنفيذ مع كود GPLed.بعد شوكة/exec لا يحدث ذلك.

على أية حال سأخمن ذلك importيؤدي ing إلى تشغيل التعليمات البرمجية الجديدة في نفس سياق التنفيذ مثل بت GPLed، ويجب أن تعاملها مثل حالة الارتباط الديناميكي.لا؟

Answer 3

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