أعتزم استخدام Discourse في موقعي الإلكتروني المستقبلي (شكرًا لكم على هذا البرنامج الرائع).
في حال قمت بإجراء بعض التعديلات (ليس بالضرورة كإضافة)، هل يتطلب ذلك أن تكون تعديلاتي مرخصة برخصة GPL؟
وبالمثل بالنسبة للإضافات: هل ستكون جميع الإضافات مرخصة برخصة GPL؟
كل من قام بذلك قد ندم بشدة. تريد أن تجري تعديلاتك في الإضافات والقوالب.
يمكنك استخدام إضافات وقوالب غير موزعة علنًا.
شكرًا لك.
ماذا عن الحالة التي يقوم فيها المطور بإنشاء تطبيق ويب أكبر يتضمن discourse كجزء منه، على سبيل المثال:
أدرك أن النقاشات هنا لا تُعتبر نصيحة قانونية، لكنني أقدر أي ملاحظات أولية.
أعتقد أن نقطة جاي لم تكن قانونية. تريد الاحتفاظ بالقدرة على ترقية Discourse وإعادة نشره من الصفر بنقرة واحدة. يجب أن تكون جميع التعديلات التقنية على شكل إضافات أو مكونات سمة. توجد بالفعل واجهة برمجة تطبيقات (API)، ودعم لتسجيل الدخول الموحد (SSO)، وOAuth، وويب هوك، ويمكنك دائمًا اختيار استضافة عنصر Discourse على نطاق فرعي ضمن نفس النطاق. استخدم هذه الميزات للدمج مع برمجيات إضافية. فكر في البديل: كابوس دمج التغييرات الأساسية يدويًا والتعامل مع عمليات هجرة مخصصة. مزعج، محفوف بالمخاطر، ومكلف للغاية!!!
تسمح لك الإضافات بتعديل البرمجيات الأساسية على نطاق واسع وبطرق عديدة. تقنيًا، الإمكانات غير محدودة. العمل بهذه الطريقة يجبرك على دمج التغييرات بالطريقة الصحيحة، مما يؤدي إلى حل أكثر متانة وموثوقية يمكنه الاستفادة من كل الجهد الشاق الذي يبذله الفريق الأساسي في تطوير ميزات وسلامة التطبيق الرئيسي.
حسناً، ضع في اعتبارك أنه مع تطبيق وسائل التواصل الاجتماعي الخاص بك، يمكنك استخدام إضافة لتسهيل الاتصال بمنصة Discourse الخاصة بك.
هناك بالفعل مجموعة متنوعة من الإضافات المُنشأة لاستخدام خدمات مثل:
وغيرها. والمشكلة في التعديل أو إنشاء نسخة مشتقة (Fork) هي أنك قد تواجه مشكلات أمنية وأخطاء برمجية (Bugs) يتعين عليك أنت وفريقك إصلاحها بأنفسكم.
لقد جعل فريق Discourse المنصة قابلة للتخصيص بشكل كبير من خلال الإضافات، والقوالب (Themes) ومكونات القوالب، بالإضافة إلى استخدام CSS والأوامر النصية (Scripts).
أوصي أكثر باستكشاف ما تقدمه Discourse لمعرفة كيف يمكنها أن تناسب احتياجاتك دون الحاجة إلى تعديلات مباشرة جذرية.
هناك حتى إضافة للدردشة الاجتماعية تُسمى Babblechat.
كان ردي تقنيًا. ما لم تكن تخطط لامتلاك فريق من عدة أشخاص لا يفعلون شيئًا سوى دمج التغييرات الجديدة، فستحتاج إلى تطوير إضافات لحل مشكلتك. في هذه الحالة، تصبح مخاوفك القانونية غير ذات صلة.
لست متأكدًا مما إذا كان الأمر ذا أهمية من أي جانب. فالمشكلة الأساسية هي أنه إذا قمت بتفرع (fork) نظام Discourse، فلن نتمكن من تقديم أي دعم على الإطلاق.
الطرق المدعومة الوحيدة للتوسع هي الإضافات (plugins)، والقوالب (themes)، واستخدام الخطافات (hooks) في ملف container.yml. لا يوجد حد لما يمكن تحقيقه بهذه الطرق، لذا فإن التفرع لا معنى له على الإطلاق.
شكرًا لكم جميعًا على المساهمات. لقد وجدت هذه المقالة التي تحتوي على نقاش جيد. يجب أن يكون كود جانب العميل مرخصًا بموجب رخصة GPL، لكن ليس كود جانب الخادم.
أعتقد أنك قد تكون قد فاتك النقطة؟ إذا قمت بإنشاء مكون إضافي على GitHub ووضعه في مستودع خاص، فستتمتع بالتحكم الكامل في تعديل Discourse (وإن كان عبر نهج المكونات الإضافية) وستمتلك ملكية كاملة وتحكم كامل في هذه التغييرات. لن يراها أي شخص آخر، ولا داعي للقلق بشأن أي آثار قانونية حسب علمي. كل هذا مع الاستفادة من تغييرات النواة المدعومة. يمنحك المكون الإضافي القدرة على تغيير الواجهة الأمامية والخلفية. أما التفرع عن Discourse وتعديله فسيصبح فوضويًا للغاية وبسرعة، بغض النظر عن الوضع القانوني، لذا لا يُنصح بذلك.
قد يكون من الأفضل لروبرت تزويده بروابط لإعدادات مخصصة للغاية من Discourse لتعزيز فهمه، أو لبعض الإضافات والقوالب الأكثر قوة.