شرح AGPL: الالتزامات عند النشر داخل الشركة

لقد وجدت شيفرة تحت AGPL تبدو مفيدة، لكنك غير متأكد مما تعنيه عند تشغيلها داخل شركتك. القلق العملي: هل سيُجبرك ذلك على نشر شيفرة خاصة، كشف أنظمة داخلية، أو افتعال مشكلة قانونية إن عدَّلت البرنامج واستخدمته خلف جدار الحماية؟ يقطع هذا الدليل العبارات القانونية ويبيّن، بمصطلحات تقنية، ما الذي تفرضه رخصة GNU Affero General Public License (AGPL) فعليًا على شركة تنشر هذه الشيفرة داخليًا.

نظرة سريعة: ما هي AGPL وكيف تختلف عن GPL

AGPL هي GNU GPL مع بند شبكة. تغطي GPLv3 توزيع الملفات الثنائية: إذا وزعت برنامجًا معدلًا، يجب أن تعرض الشيفرة المصدرية المطابقة. تضيف AGPLv3 القسم 13: إذا شغلت برنامج AGPL معدلًا وسمحّت للآخرين بالتفاعل معه عبر الشبكة، يجب أن يُمنح هؤلاء المستخدمون البعيدون أيضًا إمكانية الوصول إلى الشيفرة المصدرية لتلك النسخة المعدلة. باختصار: استخدام الشبكة يفعّل التزامات عرض الشيفرة المشابهة لما تفعله GPL عند التوزيع.

متى تنطبق AGPL داخل الشركة

السؤال المحوري هو من يُحتسب كمـُ«مستخدم» بموجب AGPL. الترخيص لا يميّز بين العملاء العموميين والموظفين: أي شخص يتفاعل مع البرنامج المشمول بـ AGPL عبر الشبكة هو مستخدم يحق له الحصول على الشيفرة. لذا هناك ثلاثة سيناريوهات داخلية نموذجية يجب تمييزها:

• نشر داخلي مخصص للموظفين فقط يمكن الوصول إليه خلف جدار حماية الشركة: تنطبق التزامات AGPL على هؤلاء المستخدمين-الموظفين — يجب أن توفر لهم الشيفرة المطابقة للإصدار الجاري وأي تعديلات.
• نشر بنمط SaaS أو خدمات موجهة للعملاء: إذا تفاعل عملاء خارجيون مع خدمتك، يجب عليك إتاحة الشيفرة لهؤلاء العملاء (النشر العام هو الطريقة الشائعة للامتثال).
• استخدام دون اتصال صارم (بدون واجهة شبكة): إذا شُغّل البرنامج محليًا على أجهزة دون تفاعل شبكي، فلا تُفعّل بند الشبكة في AGPL بخلاف المحفزات العادية لـ GPL المتعلقة بالتوزيع.

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

ما الذي يجب أن تقدمه فعليًا للمستخدمين

عندما تُفعّل AGPL، تكون الالتزامات العملية ملموسة. يجب أن تقدّم "الشيفرة المصدرية المطابقة الكاملة" للإصدار الدقيق من البرنامج الذي تشغله. هذا يتضمن عادة:

• شجرة الشيفرة الكاملة للبرنامج، بما في ذلك أي تعديلات قمت بها.
• سكربتات البناء، ملفات التهيئة، سكربتات التغليف، وأي تعليمات تركيب ونشر ضرورية لإعادة إنتاج الملف الثنائي الجاري.
• أي سكربتات أو شيفرة لازمة لتوليد أو جلب مكونات غير-المصدرية جزءًا من النظام المنشور (مثال: الشيفرة المستخدمة في بناء الحاوية).
• المحافَظات على إخطارات الترخيص، رؤوس حقوق النشر، وملفات AUTHORS/NOTICE كما في المشروع الأصلي.

يمكن تقديم العرض مباشرة إلى المستخدمين الذين يتفاعلون مع البرنامج. عمليًا، تفي المؤسسات بذلك عبر وضع رابط واضح المعنونة في واجهة التطبيق أو صفحة "حول" تشير إلى أرشيف tarball أو لقطة مستودع git وملف README قابل للقراءة يشرح خطوات البناء والنشر. لا تفرض AGPL صيغة URL معينة أو مزوّد استضافة محدد، لكن يجب أن تكون الشيفرة متاحة للمستخدمين المستحقين بصورة قابلة للاستخدام.

ما الذي لا يعنيه "توفير الشيفرة" (ومفاهيم خاطئة شائعة)

بعض الأمور التي لا تجبرك AGPL على فعلها تلقائيًا:

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

كيفية الامتثال — قائمة تحقق عملية لفرق الهندسة

عند نشر شيفرة AGPL (معدلة أو غير معدلة)، اتبع الخطوات التالية لتظل ملتزمًا وتتجنب المفاجآت:

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

مثال: رابط "الشيفرة" الأدنى المعروض في تذييل تطبيق
https://example.com/source/myapp-2026-11-01.tar.gz
Contents: myapp-2026-11-01/  (لقطة git)
  - src/  (الشيفرة الكاملة)
  - Dockerfile
  - build.sh
  - README.build.md  (تعليمات لإعادة إنتاج الحاوية)

دمج شيفرة AGPL مع وحدات ملكية — أخطاء شائعة

أحد أصعب الأسئلة العملية هو متى تصبح شيفرتك الملكية التي تتواصل مع برنامج AGPL خاضعة لـ AGPL. ينطبق الترخيص على البرنامج والأعمال المشتقة. لا توجد قاعدة فاصلة في الترخيص تقول لك "الربط بهذه الطريقة آمن". قواعد الهندسة المتعارف عليها هي:

• العمليات المنفصلة التي تتواصل عبر بروتوكولات شبكة معيارية ومحددة جيدًا (HTTP، gRPC، SMTP، إلخ) أقل احتمالًا أن تُعتبر برنامجًا موحدًا مدمجًا. إذا كان مكونك الملكي خدمة منفصلة تستخدم مكون AGPL عبر واجهة REST، يتعامل كثير من الممارسين مع ذلك كفصل آمن — لكن هذا غير مضمَّن ويعتمد على مدى الترابط والتصميم بين الجزئين.
• ربط مكتبة مباشرة داخل ملف ثنائي، استخدام واجهات برمجة داخلية في العملية نفسها، أو شحن توزيع أحادي مدمج هو أمر محفوف بالمخاطر: هذا الدمج يُرجّح أن يُعتبر عملًا مشتقًا ويُفعّل التزامات الشيفرة.
• الملحقات أو الوحدات التي تُحمَّل داخل عملية AGPL خطيرة إذا لم تكن مفصولة بوضوح؛ بعض المشاريع تستخدم حدود IPC مستقرة ومراجعة لتقليل المخاطر.

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

خيارات تجارية: الترخيص التجاري، الترخيص المزدوج، والخيارات التشغيلية

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

من منظور تشغيلي، لديك ثلاث مسارات واقعية عند مواجهة تبعية AGPL:

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

إذا كان منتجك خدمة وصول عن بُعد أو خدمة سطح مكتب عن بُعد، فكر فيما إذا كان المكوّن AGPL يؤثر على العميل فقط أم يؤثر أيضًا على شفرة الخادم/المرسل لديك. في كثير من عمليات النشر، يقلل استخدام خدمة ترحيل مُدارة من عبء التشغيل والامتثال لديك؛ Tenvo مرحّل مُدار نشغّله نحن (خوادم في ألمانيا) وهو توصيتنا الافتراضية للفرق التي تريد مرحّلًا مُدارًا بسيطًا دون عبء الاستضافة الذاتية. إذا تطلّب الامتثال بنية تحتية في الموقع (على سبيل المثال، مطلب مكتوب يمنع بنية تحتية لطرف ثالث)، فحينها تكون الاستضافة الذاتية هي الخيار الصحيح — ضع في اعتبارك الاستضافة الذاتية لـRustDesk، لكن احسب التكاليف المستمرة للصيانة وتجديد الشهادات وتخطيط التحوّل عند الفشل قبل اختيار ذلك المسار.

النشر الداخلي فقط مقابل النشر العام — التفرقة المهمة

توضيحيان أخيران يسبّبان الالتباس:

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

متى تكون الاستضافة الذاتية أو ترتيبات خاصة مطلوبة

الاستضافة الذاتية مناسبة عندما يمنع متطلب مكتوب الاعتماد على بنى طرف ثالث (قواعد الإقامة البيانية التنظيمية، شبكات مصنفة، أو التزامات تعاقدية). خلاف ذلك، فإن خيار الريلاي المدار/البنية المدارّة عادة ما يكون أقل تكلفة فعليًا عند حساب عبء الاستدعاء، تصحيح الثغرات، حفظ شهادات TLS، وخطط التعافي من العطل. نناقش هذه المقايضات بتفصيل أكبر في Self hosting hidden costs وفي مقالنا الأوسع عن Open source business model: why AGPL works for SaaS.

أمثلة عملية وأسئلة قصيرة متكررة

• س: إن عدّلت شيفرة AGPL واستخدمها فريق العمليات فقط، هل يجب أن أنشرها؟ ج: نعم — فريق العمليات هو من المستخدمين. اجعل الشيفرة متاحة داخليًا.
• س: إن قدمت خدمة مدعومة بـ AGPL للعملاء، هل يجب أن أنشرها علنًا؟ ج: يجب أن توفّر الشيفرة المطابقة لهؤلاء العملاء. النشر العام هو الطريقة القياسية للوفاء بالمتطلب.
• س: هل يمكنني إبقاء التهيئات والأسرار مغلقة؟ ج: الأسرار ليست "شيفرة مصدر" بموجب الترخيص. ارفع الأسرار من الأرشيفات المنشورة ودوّن المدخلات السرية المتوقعة بدلًا من تضمينها.
• س: هل يكفي الإشارة إلى المصدر الأصلي إن قمت بتعديلات محلية؟ ج: لا. يجب أن تقدّم الشيفرة للنسخة المحددة التي تشغّلها، بما في ذلك تغييراتك.

إن أردت مثالًا عمليًا لاستضافة مكدس سطح مكتب عن بُعد مفتوح المصدر وخطوات البناء الدقيقة للحفاظ على الامتثال، انظر دليلنا Self-hosted remote desktop ودليل Docker الخاص بـ RustDesk في RustDesk self-hosted setup للاقتباس في الآليات.

الامتثال لـ AGPL عملية منهجية: حدد المستخدمين، ثبت نسخة التشغيل، اجمع الشيفرة المصدرية المطابقة وتعليمات البناء، واجعلها قابلة للوصول لهؤلاء المستخدمين. الأجزاء الصعبة هي الحوكمة والعمارة: قرار فصل المكونات، التفاوض على التراخيص، أو قبول ظهور التعديلات للعامة.

إذا كنت تنشر بنية تحتية للوصول عن بُعد وتريد تجنب تشغيل مرحّل مخصص ونشره، فإن مرحّل Tenvo المُدار هو الخيار الافتراضي العملي: عملاء أصليون لأنظمة Windows وmacOS وLinux، وعميل متصفح في إصدار تجريبي عام، ومرحّل مُدار بخوادم في ألمانيا، وباقات من Free $0 إلى Lite $2.99 شهريًا وPro $7.99 شهريًا. يجب استخدام الاستضافة الذاتية فقط عندما يفرضها متطلب مكتوب: وإلا فغالبًا ما يكون الخيار المدار أقل تكلفة عند احتساب الاستدعاء، التصحيحات، حفظ المفاتيح ومتطلبات التعافي.

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

عندما تكون مستعدًا لتجربة ريلاي مدار وتقليل العبء التشغيلي، حمّل Tenvo وتعرّف على نموذج النشر والواجهة: Download Tenvo.