توضيح رخصة الاستخدام المستدام بخصوص الاستخدام كواجهة خلفية للتكامل

مرحبا للجميع،

لقد أرسلنا بريدًا إلكترونيًا إلى license@n8n.io قبل 10 أيام لكننا لم نتلق ردًا، لذا أسأل هنا على أمل أن يتمكن شخص ما من المساعدة.

نحن شركة يابانية توفر حلول chatbot والمساعد الصوتي كخدمة SaaS متعددة المستأجرين. نقيم حاليًا instance ذاتي الاستضافة من n8n كخادم خلفي داخلي للتكاملات اختيارية مع جهات خارجية.

لتقديم المزيد من التفاصيل، سيتم استخدام instance n8n فقط كبنية تحتية للتكامل الداخلي. سيتفاعل المستأجرون ومستخدمونهم النهائيون فقط مع chatbot الخاص بنا أو المساعد الصوتي. لن يحصلوا على حسابات n8n ولن يكون لديهم وصول إلى واجهة n8n أو API أو سير العمل أو واجهة بيانات الاعتماد. ستقوم مجموعة صغيرة من موظفينا بتصميم والحفاظ على سير العمل، والذي سيستدعيه مساعدونا بالذكاء الاصطناعي من خلال webhooks واستدعاءات الأدوات.

ستتم إضافة إمكانية التكامل ضمن اشتراكنا القياسي في خدمة SaaS. لن يتم بيعها كوصول إلى n8n أو كمنتج أتمتة سير عمل منفصل. ستستمر خدمات chatbot والمساعد الصوتي الأساسية لدينا في العمل بدون n8n.

للحصول على مثال حالة استخدام فعلي، قد يسأل المستخدم النهائي مساعد صوتي المستأجر عن طلب. قد يستدعي ذكاؤنا الاصطناعي سير عمل n8n الذي يتم الحفاظ عليه بشكل داخلي كأداة وتمرير معلومات مثل معرّفات المستأجر والطلب. يمكن لسير العمل استرجاع المعلومات من حساب HubSpot الخاص بالمستأجر، أو تنفيذ إجراء مثل تحديث السجل، ثم إرجاع النتيجة إلى تطبيقنا.

سيقوم المستأجرون بتفويض تكاملاتهم الخارجية من خلال تدفق إعداد OAuth أو بيانات الاعتماد ضمن خدمة SaaS الخاصة بنا. لم نقرر بعد حيث يجب تخزين تلك بيانات الاعتماد. أحد الخيارات هو تخزين واستخدام بيانات الاعتماد الخاصة بالجهات الخارجية ذات الصلة بأمان ضمن n8n، لكننا نعتقد أن هذا غير مسموح به. يتمثل الأسلوب البديل في الاحتفاظ ببيانات اعتماد الجهات الخارجية في خزنة أو خدمة وكيل يتم تشغيلها بواسطتنا. في هذا النموذج الثاني، سيستدعي n8n خدمتنا الداخلية مع السياق التجاري الضروري، بينما ستتعامل خدمتنا مع التفويض والاتصال بواجهة برمجة التطبيقات الخارجية، مع الاحتفاظ ببيانات اعتماد واجهة برمجة التطبيقات الخارجية خارج n8n.

من خلال المنتدى، أجابت إجابات جان في N8n كخادم خلفي SaaS — ما المقدار الذي تسمح به الترخيص؟ على معظم حالتنا، لكن تباينًا واحدًا لم يتم معالجته هناك، لذا أردت تأكيده.

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

شكرًا لك على وقتك، وعلى كل العمل الذي تبذله في مشروع رائع!

مرحبا @u-karakulak، في أثناء انتظارك للرد، إليك بعض الأشياء التي قد تساعدك:

الموارد المقترحة

تم المطابقة تلقائياً مع سؤالك.

المستندات:

المنتدى:

@jan، @achamm، @Piotr_Sikora - لقد ساعدتم مع مشاكل مشابهة من قبل، هل يمكنكم إلقاء نظرة؟

تم الاقتراح تلقائياً بواسطة روبوت مجتمع n8n. إنه مشروع تجريبي - يرجى مشاركة ملاحظاتك هنا.

مرحباً @u-karakulak

هذا رأيي في حالة الاستخدام الخاصة بك. إنه غير ملزم قانونياً. ستحتاج لا تزال إلى التحقق مع license@n8n.io.

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

ومع ذلك، حالة الاستخدام هذه غير مسموحة بموجب رخصة n8n Sustainable Use License (SUL) القياسية. العامل الحاسم للامتثال لـ SUL ليس ما إذا كان المستخدم النهائي يرى واجهة n8n، بل من الذي يتم معالجة بيانات ومصادقات الخاص به. لأن سير العمل سيقوم بتنفيذ الإجراءات باستخدام بيانات اعتماد جهات خارجية خاصة بـ مستأجريك للوصول إلى حساباتهم المحددة، فإنه يقع خارج نطاق السماح بـ “الأغراض التجارية الداخلية” للرخصة المجانية.

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

للمتابعة بشكل قانوني وسليم معمارياً، لديك ثلاث مسارات قابلة للتطبيق:

(1) شراء رخصة n8n Embed License التجارية، التي تم تصميمها بوضوح للتضمين في SaaS متعدد المستأجرين وإدارة بيانات اعتماد العميل
(2) إعادة تصميم التكامل بحيث يقوم n8n بالمصادقة فقط باستخدام بيانات اعتماد شركتك الرئيسية الخاصة أو حسابات الخدمة، وليس حسابات خاصة بمستأجرين أو
(3) الانتقال إلى نموذج نشر لامركزي حيث يتم استضافة نسخ معزولة من n8n على البنية الأساسية الخاصة بكل مستأجر، مما يبقي دورك بصرامة كمستشار صيانة.

مرحبا @u-karakulak
الخط الفاصل هو ما إذا كان n8n نفسه يستخدم بيانات اعتماد المستأجر للوصول إلى حساب المستأجر، وليس ما إذا كان أي شخص يرى واجهة مستخدم n8n. خيارك الأول، الاحتفاظ بيانات اعتماد HubSpot للمستأجر في n8n، هو الحالة بالضبط التي تحددها الوثائق على أنها غير مسموحة. خيارك الثاني شيء مختلف: إذا كانت خدمة الخزان الخاصة بك تحتفظ بالبيانات الاعتمادية وتقوم باستدعاء HubSpot، وكان n8n يمرر فقط السياق التجاري إلى تلك الخدمة ويحصل على نتيجة بدلاً من ذلك، فإن n8n لا يعمل أبداً على بيانات اعتماد المستأجر ويبقى داخل الترخيص.
انظر إلى هذا:

ما يدفعه إلى Embed هو تمرير رمز المستأجر إلى n8n في وقت التشغيل والسماح لعقدة n8n بإجراء المكالمة المصرح بها، بغض النظر عن المكان الذي تم تخزين هذا الرمز فيه. لذا احتفظ بكل استدعاء API من جهة خارجية داخل الخادم الوكيل واحتفظ بـ n8n على استدعاءات HTTP داخلية عادية له.
تنص الوثائق أيضاً على أن الاستخدام الخلفي، سير العمل الذي يعمل خلف الكواليس مع المستخدمين النهائيين الذين لا يرون n8n أبداً، يتم تغطيته في جميع الخطط المدفوعة بموجب الترخيص القياسي بدون اتفاقية منفصلة، وأن OEM مطلوب فقط عندما يعمل المستخدمون لديك في محرر n8n مباشرة.

خلفية عن المكان الذي ينتهي فيه SUL ويبدأ Embed:

@kjooleng @Anshul_Namdev
شكراً لكما على الرسائل السريعة والمشروحة جيداً!

آسف، صياغتي لم تكن واضحة. الخيار الأول، حيث يتم تخزين بيانات الاعتماد داخل n8n، هو الخيار الذي نفترض بالفعل أنه غير مسموح به.

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

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

أقدّر إجاباتكما كثيراً وسأتابع مع license@n8n.io للتأكيد النهائي.

وبالإضافة إلى ذلك، إذا احتجنا إلى اتفاقية تجارية لهذا، هل هو Embed تحديداً، أم يمكن لخطة مدفوعة قياسية مثل Business أن تغطيها؟

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

بافتراض أن عملائك لا يرون n8n أبداً ويتفاعلون فقط مع منصتك الخاصة، فستحتاج إلى ترخيص عمل/مؤسسي.
الترخيص المدمج مطلوب فقط إذا قمت بـ “إعادة تسمية العلامة التجارية” لـ n8n.

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

عندما تكتب إلى license@n8n.io، أرسل مخطط العمارة الفعلي بدلاً من وصف نثري. ستحصل على إجابة أقل تحفظاً، وتريد تلك الإجابة مكتوبة قبل أن تصبح حاملة للحمل بالنسبة لتسعيرك.