رخصة الاستخدام العام

ما هي رخصة GNU العامة العمومية (GPL)؟

رخصة GNU العامة العمومية (المعروفة اختصارًا بـ "GPL") هي واحدة من أشهر رخص البرمجيات مفتوحة المصدر. تشترط هذه الرخصة أنه عند استخدام الشيفرة أو تعديلها أو توزيعها، يجب أن تبقى الشيفرة المصدرية مفتوحة ومتاحة بموجب نفس شروط الرخصة. وتُعد GPL من أكثر الرخص تأثيرًا في منظومة البرمجيات مفتوحة المصدر.

رخصة البرمجيات مفتوحة المصدر تحدد الشروط التي يسمح فيها المؤلف للآخرين باستخدام وتعديل شيفرته—كما لو أنك تشارك وصفة وتسمح بتحسينها. تفرض GPL أن أي نسخة محسنة من "الوصفة" يجب أن تكون متاحة للجميع وتخضع لنفس القواعد. هذا الالتزام التبادلي يضمن استفادة المجتمع باستمرار من التحسينات الجديدة.

ما هي المبادئ الأساسية لرخصة GPL؟

تعتمد GPL في جوهرها على مفهوم "حقوق النشر التبادلية" (copyleft)، والذي يعني أنه عند استخدامك أو تعديلك لشيفرة مفتوحة من الآخرين، يجب أن يكون أي توزيع لتعديلاتك أيضًا مفتوحًا، مع الاحتفاظ بإشعارات حقوق النشر الأصلية ونص الرخصة.

تشمل المبادئ الأساسية:

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

يستخدم نواة Linux رخصة GPL-2.0 منذ سنوات (حتى 2025)، ليكون من أبرز أمثلة تبني GPL.

كيف تؤثر GPL على تطوير Web3؟

تحدد GPL ما إذا كان يمكنك توزيع البرمجيات التي تعتمد على شيفرة مفتوحة المصدر بشكل مغلق المصدر، أو إذا كان يجب عليك فتح الشيفرة عند توزيع مشروعك. في Web3، قد تُطبق التزامات GPL على عملاء العقد (node clients)، المحافظ، الواجهات الأمامية، والعقود الذكية.

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

على السلسلة، تعزز ممارسات المصدر المفتوح القابلية للتدقيق والأمان. العديد من الفرق تختار نشر الشيفرة الحيوية لبناء الثقة مع تقييم توافق الرخصة مع استراتيجية المنتج بعناية.

كيف تُطبق GPL على العقود الذكية؟

عادةً ما تُكتب العقود الذكية بلغة Solidity، مع تحديد الرخصة أعلى الملفات عبر معرف الرخصة SPDX (مثل "SPDX-License-Identifier: GPL-3.0-or-later"). تفرض متطلبات الترخيص التبادلي في GPL عدة اعتبارات للعقود الذكية:

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

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

ثالثًا، الممارسة الشائعة: العديد من الفرق تفضل رخصًا أكثر تسامحًا مثل MIT أو Apache للعقود الأساسية لتقليل الالتزامات. عند استخدام GPL، قدم الشيفرة المصدرية بالكامل، وإشعارات حقوق النشر، وتعليمات البناء في المستودع لتعزيز التدقيق وإعادة الاستخدام.

كيف تختلف GPL عن رخصتي MIT وApache؟

الاختلاف الأساسي بين GPL وMIT وApache هو قوة متطلبات الترخيص التبادلي.

• MIT: كأنك تشارك وصفة مع ذكر المصدر—رخصة متسامحة جدًا ولا تشترط أن تستخدم الأعمال المشتقة نفس الرخصة. مناسبة للمنتجات مغلقة المصدر أو الترخيص المزدوج.
• Apache-2.0: مشابهة لـ MIT لكنها تتضمن منحًا صريحًا للبراءات وإخلاء مسؤولية—تلبي احتياجات المؤسسات.
• GPL: تفرض الترخيص التبادلي، وهي مثالية للمشاريع التي تسعى لمشاركة التحسينات مع المجتمع باستمرار؛ لكنها أكثر تقييدًا للتوزيع مغلق المصدر.

الخلاصة: اختر GPL لتعظيم التعاون المفتوح ووجوب مشاركة التحسينات؛ اختر MIT أو Apache لمزيد من المرونة بين النماذج المفتوحة والمغلقة المصدر.

كيف تلتزم برخصة GPL في مشروعك؟

الخطوة 1: ضع ملف LICENSE (النص الكامل لرخصة GPL) في الدليل الجذري لمستودعك، واذكر تفاصيل الترخيص في ملف README.

الخطوة 2: أضف ترويسة معرف الرخصة SPDX (مثل "SPDX-License-Identifier: GPL-3.0-or-later") أعلى كل ملف مصدر ليتمكن نظام الأدوات من تحديد الرخصة.

الخطوة 3: احتفظ بإشعارات حقوق النشر والرخصة الأصلية؛ ووضح تعديلاتك الخاصة مع التاريخ والمؤلف وملخص التغيير.

الخطوة 4: وفر وسيلة للحصول على الشيفرة المصدرية لأي ملفات تنفيذية موزعة—مثلاً، نشر الشيفرة المصدرية، ونصوص البناء، وتوثيق التبعيات لضمان إمكانية إعادة البناء.

الخطوة 5: راجع تبعيات الطرف الثالث لتوافق الرخص؛ إذا لزم الأمر، استخدم LGPL (المناسب أكثر للمكتبات) بدلاً منها.

الخطوة 6: أجرِ مراجعة التزام قبل الإطلاق؛ واطلب استشارة قانونية إذا كان هناك استخدام تجاري لتقليل المخاطر.

ما هي الفروق بين إصدارات GPL؟

الإصدارات الرئيسية هي v2 وv3:

• v2 (مثل نواة Linux): أقدم وأشهر إصدار؛ لا يتناول قضايا البراءات الحديثة أو قفل الأجهزة.
• v3: يعزز منح البراءات، ويضيف بنود مكافحة Tivoization (منع الأجهزة من حجب النسخ المعدلة) وشروط تتعلق بإدارة الحقوق الرقمية—مناسب أكثر لسيناريوهات التوزيع الحديثة.

"أو أحدث" مقابل "فقط": اختيار "GPL-3.0-or-later" يسمح بتبني الإصدارات المستقبلية لمزيد من المرونة؛ أما "فقط" فيثبت الإصدار لإدارة التوافق بشكل أفضل.

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

هل يمكن استخدام GPL لأغراض تجارية؟

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

• الترخيص المزدوج: فتح الشيفرة الأساسية بموجب GPL مع تقديم نسخة مرخصة تجاريًا لعملاء المؤسسات.
• نموذج الخدمة: تحقيق الدخل من خلال الاستضافة أو الدعم أو التدقيق أو خدمات التكامل مع الحفاظ على التوافق مع متطلبات المصدر المفتوح (مع الانتباه إلى التزامات AGPL الخاصة باستخدام الشبكة).
• فصل المكونات: عزل المكونات التي يجب مشاركتها عن منطق الأعمال الخاص؛ واستخدام LGPL أو بدائل احتكارية للمكتبات لتقليل الالتزامات التبادلية.

ما هي المخاطر والمفاهيم الخاطئة الشائعة حول GPL؟

تشمل المفاهيم الخاطئة الشائعة:

• "لا يمكن استخدام GPL تجاريًا"—خطأ. يسمح بالاستخدام التجاري لكنه يفرض التزامات المصدر المفتوح عند توزيع الأعمال المشتقة.
• "لا حاجة للالتزام إذا لم يكن هناك توزيع"—غير مكتمل. ما إذا كان النشر يمثل توزيعًا يعتمد على السياق؛ قد يُعتبر النشر على السلسلة أو التقديم عبر الشبكة توزيعًا عامًا.
• "يمكن مزج GPL مع MIT/Apache بحرية"—توخ الحذر. قد تتطلب العلاقات الاشتقاقية اعتماد GPL بالكامل؛ تجنب مزج الرخص غير المتوافقة.
• "الاستخدام البسيط يجنّب الالتزامات"—طريقة دمجك للشيفرة (وراثة، ربط ثابت/ديناميكي) قد تنشئ أعمالًا مشتقة؛ المراجعة ضرورية للامتثال.

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

توصيات وملخص لاختيار GPL

إذا كان هدفك تعزيز التعاون المجتمعي، وضمان مساهمة التحسينات، والحفاظ على القابلية للتدقيق، فإن GPL خيار قوي. إذا كنت بحاجة لحرية أكبر للنماذج مغلقة المصدر أو الترخيص المزدوج، توفر MIT أو Apache مرونة أوسع. احرص على توحيد وتتبع الترخيص للعقود الذكية والواجهات الأمامية—أدرج ملفات LICENSE وترويسات SPDX في المستودعات وقياسيًا طرق توزيع الشيفرة المصدرية. انتبه لاختلاف الإصدارات وتوافق التبعيات وما إذا كان سيناريوك يشكل توزيعًا أو اشتقاقًا. أجرِ دائمًا مراجعات الامتثال واطلب استشارة قانونية قبل إطلاق مشروع تجاري. مع استراتيجية ترخيص واضحة، يمكنك تحقيق تعاون موثوق وامتثال تنظيمي في منظومة Web3.

الأسئلة الشائعة

هل يمكنني استخدام شيفرة مرخصة تحت GPL مباشرة في مشاريع تجارية؟

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

ما هي المخاطر القانونية إذا أشرت إلى عقد ذكي مرخص تحت GPL في مشروع Web3 الخاص بي؟

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

لماذا يقال إن GPL "تلوث" مشروعي؟

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

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

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

ماذا يحدث إذا استخدمت شيفرة مرخصة تحت GPL وMIT في مشروع واحد؟

يجب الالتزام بكلتا الرخصتين—وهذا قد يكون معقدًا. تفرض GPL فتح جميع الأعمال المشتقة؛ بينما تسمح MIT بالاستخدام مغلق المصدر—وهذه الشروط متعارضة. عمليًا، يجب أن يتبع مشروعك الرخصة "الأكثر تقييدًا" (GPL) لضمان التوافق. تجنب مزج الرخص متى أمكن أو افصل الوحدات بوضوح حسب نوع الرخصة لتقليل تحديات الامتثال.