
رخصة GNU العامة العامة (GPL) تُعد من أكثر تراخيص البرمجيات مفتوحة المصدر انتشاراً، وتشمل نسخاً شائعة مثل GPLv2 وGPLv3. تتيح لك استخدام الشيفرة المصدرية وتعديلها وتوزيعها، مع اشتراط بقاء أي أعمال مشتقة مفتوحة المصدر بموجب نفس شروط الترخيص.
في منظومة Web3، تؤثر GPL على عملاء البلوكشين ومستودعات العقود الذكية وواجهات التطبيقات اللامركزية (dApp) وسلاسل الأدوات. على سبيل المثال، يستخدم عميل Ethereum المعروف باسم Geth عائلة تراخيص GPL، ما يحدد ضوابط استخدامه وإعادة توزيعه.
في Web3، تحقق GPL هدفين رئيسيين: ضمان استمرارية المصدر المفتوح وتشكيل بيئة التعاون والمنافسة. على المشاريع التي تعتمد GPL إبقاء التفرعات مفتوحة المصدر، ما يعزز الشفافية وقابلية التدقيق.
تشجع GPL المطورين على مشاركة التحسينات وتقلل من تكرار العمل. أما لفرق المشاريع، فهي تؤثر بشكل مباشر على الاستراتيجيات التجارية—مثل تحديد إمكانية جعل بعض المكونات مغلقة المصدر، وتوقيت فتح المصدر، وكيفية إدارة العلامة التجارية والعمليات. كثيراً ما تبدأ المشاريع بترخيص أكثر تقييداً ثم تنتقل إلى GPL-3.0 في تاريخ محدد (مثلاً في 2023)، ما يتيح تفرعات أكثر توافقاً وابتكارات ثانوية.
جوهر GPL يكمن في بند "حقوق النشر العكسي" (copyleft): إذا استخدمت أو عدلت شيفرة مرخصة بـGPL ووزعت تعديلاتك، يجب عليك نشر الشيفرة المصدرية تحت نفس الترخيص مع الاحتفاظ بحقوق النشر وإخلاء المسؤولية للمؤلف الأصلي.
تشير "الأعمال المشتقة" إلى التطويرات المبنية على الشيفرة الأصلية. فعلى سبيل المثال، إذا أضفت منطق التوجيه والرسوم إلى عقد تبادل لامركزي وأطلقت نسختك الخاصة، فهذا يُعد عملاً مشتقاً. إذا وزعت نسخاً أو ملفات ثنائية، تصبح ملزماً بتوفير الشيفرة المصدرية ومعلومات الترخيص.
تتضمن GPL أيضاً بند "عدم الضمان" حيث تُقدم الشيفرة "كما هي". وتضيف GPLv3 بنوداً تتعلق بالبراءات ومنع التحايل (مثل DRM)، ما يقلل من المخاطر القانونية.
الميزة الجوهرية في GPL هي حقوق النشر العكسي—فهي تلزم بقاء التوزيعات التالية مفتوحة المصدر تحت نفس الترخيص. أما تراخيص MIT وApache-2.0 فهي أكثر مرونة: تسمح بالاستخدام في منتجات تجارية مغلقة المصدر بشرط الاحتفاظ بإشعارات حقوق النشر والترخيص.
من حيث التوافق، تُعتبر Apache-2.0 وGPLv3 متوافقتان غالباً، لكن قد تظهر تعارضات مع "GPLv2 فقط". يجب أن يتناسب اختيار الترخيص مع أهداف فريقك: اختر MIT/Apache لمرونة تجارية أكبر؛ أو GPL لضمان بقاء مساهمات المجتمع مفتوحة المصدر. ووفق تقارير عامة مثل GitHub Octoverse 2023، تهيمن تراخيص MIT وApache وعائلة GPL على الاستخدام السائد.
في ملفات Solidity، يُنصح بتحديد معرف SPDX بوضوح وإضافة ملف LICENSE في جذر المستودع يتوافق مع الإصدار المستخدم:
// SPDX-License-Identifier: GPL-3.0-or-later
أولاً، تأكد من أن المكتبات التي يعتمد عليها عقدك متوافقة مع GPL لتجنب خلط تراخيص غير متوافقة في عقد واحد. ثانياً، نسق ملفات LICENSE وNOTICE وبيانات حقوق النشر في المستودع قبل النشر. ثالثاً، انشر نصوص البناء وتعليمات إعادة تنفيذ التجارب لتسهيل تدقيق المجتمع وإعادة التطبيق.
خلال عمليات التدقيق في Gate، تتحقق الفرق عادةً من معرفات SPDX وتراخيص المستودعات لضمان سلسلة تبعيات خالية من التعارضات وتقليل مخاطر عدم الامتثال بعد الإطلاق.
اختيار GPL يعني أن التفرعات يجب أن تظل أيضاً مفتوحة المصدر، ما يسهل دخول المشاركين الجدد ويزيد من كفاءة التعاون في المنظومة. التسويق التجاري لا يقتصر على بيع برمجيات مغلقة المصدر؛ بل يشمل الخدمات المدارة، العلامة التجارية والعمليات، رموز الحوكمة، ودعم المنظومة—ما ينقل ميزة التنافس من "الشيفرة المملوكة" إلى تجربة المنتج وتأثير الشبكة.
في Web3، انتقلت بعض البروتوكولات الرائدة بإصدارات معينة إلى GPL-3.0 بعد فترة محددة، ما أدى إلى تفرعات متوافقة وتكرار للميزات. يعزز هذا النهج الابتكار والمنافسة ضمن إطار ترخيص واضح، لكنه يتطلب تخطيطاً مسبقاً للعلامة التجارية، نطاقات الواجهات، السيولة، وحوكمة المجتمع لتجنب التشتت السريع عبر التفرعات.
AGPL (Affero General Public License) هي نسخة أقوى من حيث "الاستخدام عبر الشبكة": إذا تفاعل المستخدمون مع برنامجك عبر الشبكة، يجب عليك توفير الشيفرة المصدرية. هذا مهم بشكل خاص لواجهات Web3 وخدمات الفهرسة وبوابات البيانات. إذا كان واجهة dApp الخاصة بك تعتمد على مكونات AGPL وتم نشرها كخدمة عامة، يجب نشر الشيفرة المصدرية المقابلة أيضاً.
أما LGPL (Lesser General Public License) فهي مناسبة أكثر للمكتبات والمكونات؛ حيث تسمح بالربط مع برامج مغلقة المصدر بشرط أن تكون تعديلات مكتبة LGPL نفسها مفتوحة المصدر. التطبيق الرئيسي يمكن أن يبقى ملكية خاصة. بالنسبة للمحافظ أو إضافات العقد، تحقق LGPL توازناً بين إبقاء المكتبات مفتوحة المصدر والسماح للتطبيقات بأن تكون مغلقة المصدر.
الخطوة 1: تأكيد الإصدار والتوافق. حدد بوضوح GPLv2، GPLv3 أو "أو لاحقاً"، وتحقق من توافق التبعيات مع الإصدار المختار.
الخطوة 2: الاحتفاظ ببيانات حقوق النشر والترخيص. احتفظ بنسب المؤلف الأصلي ونص الترخيص في ملفات المصدر وREADME، وأضف NOTICE إذا لزم الأمر.
الخطوة 3: فتح مصدر الأعمال المشتقة. قدم للمستخدمين الشيفرة المصدرية الكاملة ونصوص البناء وتعليمات التثبيت ليتمكن الآخرون من إعادة تنفيذ عملك.
الخطوة 4: التصريح الصريح عن معرفات SPDX. أضف سطر SPDX في كل ملف مصدر رئيسي وضع ملف LICENSE في جذر المستودع لضمان الاتساق.
الخطوة 5: التمييز بين التوزيع والاستخدام. نشر الملفات الثنائية أو الصور أو البرمجيات المجمعة يؤدي إلى التزامات؛ أما البحث الداخلي فلا يفعل عادة. ما إذا كان رمز البايت على السلسلة يُعد "توزيعاً" يخضع للتفسير—استشر مستشارين قانونيين لمزيد من الوضوح.
الخطوة 6: توثيق قائمة مواد البرمجيات (SBOM). أدرج جميع التبعيات وتراخيصها لتسهيل التدقيق والمراجعة على منصات مثل Gate.
تشمل المخاطر الرئيسية تعارض التراخيص وعدم الوفاء بالالتزامات: استخدام تراخيص غير متوافقة معاً، عدم فتح مصدر الأعمال المشتقة، أو حذف معلومات حقوق النشر/إخلاء المسؤولية، ما قد يؤدي إلى إزالة الشيفرة (مثل DMCA)، أو إعاقة التعاون أو الإضرار بسمعة العلامة التجارية.
توصيات الامتثال: اختر التراخيص المتوافقة مع الأهداف التجارية منذ بداية المشروع؛ اعتمد استراتيجيات مركبة مثل AGPL للواجهات أو MIT/Apache للخدمات؛ حافظ على SBOM وقوائم التحقق من الامتثال؛ أجرِ مراجعات طرف ثالث قبل الإطلاق؛ واطلب المشورة القانونية في الحالات الحرجة. المشاريع التي تستهدف التوسع على منصات التداول يجب أن تضع الامتثال للترخيص ضمن أولوياتها لتجنب العراقيل التشغيلية لاحقاً.
تحمي GPL استمرارية المصدر المفتوح عبر بنود حقوق النشر العكسي، ما يجعلها مناسبة لمشاريع Web3 التي تهدف لإعادة تدفق تحسينات المجتمع إلى المنظومة. مقارنةً بتراخيص MIT/Apache، تركز بشكل أكبر على إبقاء الأعمال المشتقة مفتوحة المصدر؛ أما بالمقارنة مع AGPL/LGPL، فهي أكثر تركيزاً على سيناريوهات التوزيع المحلي. التنفيذ السليم لمعرفات SPDX وملفات LICENSE وSBOM، إلى جانب مراجعات الامتثال وخارطة طريق تجارية واضحة، يمكّن الفرق من تحقيق التوازن بين الانفتاح والجدوى التجارية.
لا. تشترط GPL أن تظل الأعمال المشتقة مفتوحة المصدر بموجب نفس الترخيص—وهو ما يُعرف بمبدأ "حقوق النشر العكسي". إذا كان مشروعك يتضمن شيفرة GPL، يجب أن يبقى المشروع بأكمله مفتوح المصدر. إذا كنت ترغب في تسويق برمجيات مغلقة المصدر، تحقق من تراخيص التبعيات مسبقاً أو احصل على إذن المؤلف الأصلي للترخيص المزدوج.
الاستخدام الخاص لا ينتهك GPL من الناحية النظرية؛ ولكن بمجرد التوزيع أو النشر (بما في ذلك الخدمات عبر الإنترنت)، يجب الامتثال لمتطلبات المصدر المفتوح. كثير من المطورين يغفلون عن هذا الالتزام ويواجهون مخاطر قانونية لاحقاً. من الأفضل تحديد استراتيجية الترخيص في وقت مبكر لتجنب تغييرات مكلفة لاحقاً.
إذا استخدمت داخلياً بدون توزيع، فلست ملزماً بنشر الشيفرة المصدرية. لكن إذا قدمت البرنامج المعدل للمستخدمين أو العملاء—أو عبر خدمات الشبكة—فيجب عليك أيضاً تزويدهم بالشيفرة المصدرية وملخص للتعديلات. هذا مهم بشكل خاص لمشاريع SaaS.
تعتمد قوة تطبيق GPL القانونية على الولاية القضائية؛ في Web3 تكون أقل قوة لأن عمليات النشر على البلوكشين يصعب تتبعها، ولا يمكن للعُقد أو المعدنين التحقق بسهولة من الالتزام بالترخيص. مع ذلك، قد يؤدي انتهاك GPL إلى رد فعل سلبي من المجتمع أو تفرعات تضر بالسمعة—حتى إذا كانت الإجراءات القانونية محدودة. يُوصى بالامتثال الاستباقي لحماية مصداقية مشروعك.
نعم—ويُعرف ذلك بالترخيص المزدوج أو المتعدد. غالباً ما تعتمد مجتمعات المصدر المفتوح هذا النموذج؛ مثلاً، تقديم نسخة مجانية/مفتوحة المصدر بموجب GPL ونسخة تجارية مرخصة (مقابل رسوم). يجب توضيح أي نسخة تستخدم أي ترخيص في توثيق المشروع لتجنب إرباك المستخدمين، مع الانتباه لاحتمال تعارض التراخيص المختلفة.


