شيفرة GitHub في منتج تجاري: التراخيص وما ينبغي التحقق منه
Markdownالتراخيص المتساهلة MIT وApache وBSD، وتراخيص الحقوق المتروكة GPL/AGPL، وغياب ملف LICENSE، والتحقق من مصدر الشيفرة التي يضيفها الذكاء الاصطناعي.
قراءة المقال كاملًا
أنت تبني منتجًا وتعثر على جزء جاهز على GitHub: مكتبة أو قالبًا أو مشروعًا كاملًا يفعل ما تحتاج إليه بالضبط. يقترح Claude إدراجه في مشروعك. ثم تتوقف لتفكر: تبدو الشيفرة متاحة للعامة، لكن هل يمكنك استخدامها فعلًا، ناهيك عن بيع منتج يتضمنها؟ وهل يمكن أن يلاحقك مؤلفها لاحقًا؟
سأشرح الأمر بالترتيب: لماذا لا يُعد وجود شيفرة مفتوحة على GitHub إذنًا باستخدامها، وما التراخيص التي تتيح لك استخدام الشيفرة وبيع منتج، وأي شروط حقوق متروكة قد تتطلب المصدر المقابل لعمل مشمول، وكيف تتحقق من الترخيص في دقيقة قبل استخدام الشيفرة. لن أقول «الأمر يعتمد على الحالة».
تجد في الوثائق معلومات عملية عن استخدام Ailoot.
تنبيه
هذه المادة مرجعية، ولست محاميًا. أشرح أدناه شروط التراخيص الشائعة وقواعدها، مع روابط إلى المصادر الأولية، لكن تحقق من حالتك الخاصة بالرجوع إلى نص الترخيص، واستشر محاميًا إذا كان المنتج كبيرًا وتجاريًا. أنت من يتخذ القرار.
هل صحيح أنه يمكنك استخدام الشيفرة مجانًا إذا كانت على GitHub؟
الفكرة الرئيسية
لا. إتاحة الشيفرة للاطلاع لا تعني أنه مسموح لك استخدامها في عملك. افتراضيًا، تخضع جميع الشيفرات لحقوق الطبع والنشر، ولا يجوز لك استخدامها ما لم يمنحك المؤلف إذنًا منفصلًا. إن نشر الشيفرة على GitHub وحده يتيح للآخرين الاطلاع على المستودع وإنشاء نسخة منه داخل GitHub. أما حق إدراج الشيفرة في منتجك فيأتي من الترخيص الذي أرفقه المؤلف بالمستودع. GitHub نفسه لا يمنح هذا الحق.
أكبر فخ هنا هو كلمة «مفتوحة». يمكنك رؤية الشيفرة المصدرية، فتظن أن عدم إخفائها يعني السماح لك باستخدامها. هذا المنطق خاطئ. «متاحة للقراءة» و«مرخّصة للاستخدام» أمران مختلفان.
افتراضيًا، يخضع أي عمل إبداعي، بما في ذلك الشيفرة، لحقوق الطبع والنشر منذ لحظة إنشائه. وما لم يمنح المؤلف إذنًا صريحًا، فلا يجوز لك استخدامه. وهذا ما توضحه GitHub في صفحة مرجع التراخيص الخاصة بها.
عندما تنشئ عملًا إبداعيًا (والشيفرة عمل إبداعي أيضًا)، فإنه يخضع افتراضيًا لحقوق طبع ونشر حصرية. وما لم تُرفق ترخيصًا ينص على خلاف ذلك، فلا يجوز لأي شخص آخر نسخ عملك أو توزيعه أو تعديله دون المخاطرة بمطالبة قانونية أو دعوى قضائية.
الطبقة الثانية هي GitHub نفسه. يظن الناس أنهم، بما أنهم وافقوا على قواعد GitHub عند نشر الشيفرة، يستطيعون أيضًا استخدام شيفرات الآخرين الموجودة هناك. لكن القواعد تقول العكس تمامًا. فعندما يجعل المؤلف المستودع عامًا، لا يسمح للآخرين إلا بالاطلاع عليه وإنشاء fork له، أي إنشاء نسخة داخل GitHub نفسه. وهذا لا يجيز استخدام الشيفرة في عملك.
عندما تجعل مستودعًا عامًا، تمنح المستخدمين الآخرين ترخيصًا غير حصري وساريًا في جميع أنحاء العالم لاستخدام موادك وعرضها وإعادة إنتاجها (من خلال fork) عبر الخدمة، ضمن ميزات GitHub. ويمكنك منح حقوق إضافية بإرفاق ترخيص.
الكلمات المهمة في الجملة الأخيرة هي: «ضمن ميزات GitHub» و«تأتي الحقوق الإضافية من ترخيص». يظل fork داخل GitHub. وبمجرد أن تريد استخدام الشيفرة في منتجك، فضلًا عن بيعه، تحتاج إلى ترخيص منفصل من المؤلف. من دون ترخيص، لا حق لك، حتى لو كانت الشيفرة أمامك مكشوفة تمامًا.
ما الذي يحدد ما إذا كان بإمكانك استخدام شيفرة شخص آخر؟
الفكرة الرئيسية
إنه ملف الترخيص في المستودع، ويُسمّى عادةً LICENSE أو LICENSE.md. وهو الإذن الذي يمنحه المؤلف، ويحدد ما يمكنك وما لا يمكنك فعله بالشيفرة. يجيب الترخيص عن ثلاثة أسئلة: هل يمكنك استخدام الشيفرة في منتج تجاري؟ وهل يمكنك تعديلها؟ وهل يمكنك إبقاء شيفرتك المصدرية مغلقة؟ تختلف الإجابات باختلاف التراخيص، لذا أول ما ينبغي التحقق منه هو هذا الملف؛ وبعد ذلك فقط افتح الشيفرة نفسها.
الأمر كله يتوقف على ملف واحد. يحتوي المستودع الذي تتم صيانته كما ينبغي على ملف ترخيص، يُسمّى عادةً LICENSE، وأحيانًا LICENSE.md، أو يشار إلى الترخيص مباشرةً في README. هذا هو إذن المؤلف الذي يحدد الشروط التي يجوز لك بموجبها استخدام الشيفرة. وعادةً ما تعرض GitHub اسم الترخيص في الشريط الجانبي لصفحة المستودع قبل أن تفتح الملف نفسه.
لتجنب الضياع في الصياغات القانونية، من المفيد قراءة الترخيص من خلال ثلاثة أسئلة تتعلق بحالتك:
- هل يمكنك استخدام هذه الشيفرة في منتج تجاري يدفع الناس مقابله؟
- هل يمكنك تعديل الشيفرة لتلبية احتياجاتك؟
- هل يجب أن تفتح شيفرة منتجك المصدرية بعد ذلك، أم يمكنك إبقاءها مغلقة؟
ترجع معظم الفروق بين التراخيص إلى اختلاف الإجابات عن السؤال الثالث. أما عن السؤالين الأولين، فكثيرًا ما تجيب التراخيص المفتوحة الشائعة بـ«نعم»: استخدم الشيفرة وعدّلها وبِعها. لكن موضع تعثر الناس هو ما إذا كان الترخيص سيُلزمهم بفتح شيفرتهم. والآن سنستعرض الأنواع الرئيسية من خلال هذه الأسئلة الثلاثة.
ما التراخيص التي تتيح لك استخدام الشيفرة وبيع منتج؟
الفكرة الرئيسية
أيسر التراخيص لمنتج تجاري هي التراخيص المتساهلة: MIT وApache 2.0 وBSD. فهي تسمح بكل شيء تقريبًا: استخدام الشيفرة وتعديلها وبيع المنتج وإبقاء شيفرتك المصدرية مغلقة. وهناك التزام واحد: الاحتفاظ بنص الترخيص والإسناد. كما يحمي Apache 2.0 من مطالبات براءات الاختراع، ويُلزمك بتمييز الملفات التي عدّلتها. إذا كانت شيفرة شخص آخر تحمل أحد هذه التراخيص، فيمكنك استخدامها بأمان في منتج تجاري.
لنبدأ بالخبر السار. الخيار الأفضل لمن يبني منتجًا لبيعه هو مجموعة من التراخيص تُسمّى التراخيص المتساهلة. توجد عدة تراخيص منها، لكن أشهر ثلاثة هي MIT وApache 2.0 وBSD. تجيب هذه التراخيص الثلاثة بـ«نعم» عن السؤالين الأولين، وتتيح لك إبقاء شيفرتك المصدرية مغلقة.
أكثرها شيوعًا وبساطة هو MIT. إذ يتسع نصه في فقرة واحدة.
يُمنح بموجب هذا الإذن مجانًا لأي شخص يحصل على نسخة من هذا البرنامج، لاستخدامه دون قيود، بما في ذلك حقوق الاستخدام والنسخ والتعديل والدمج والنشر والتوزيع والترخيص من الباطن وبيع النسخ، شريطة تضمين إشعار حقوق الطبع والنشر أعلاه وإشعار الإذن هذا في جميع النسخ.
بعبارات أبسط، يتيح لك MIT فعل أي شيء تقريبًا بالشيفرة، بما في ذلك بيع المنتج وإبقاء شيفرتك المصدرية مغلقة. والالتزام الوحيد هو تضمين نص الترخيص وسطر الإسناد. ومن أمثلة المشاريع المنشورة بموجب MIT: Babel و.NET وRails، لذا يكاد يكون مؤكدًا أنك استخدمت بالفعل شيفرة تحمل هذا الترخيص.
يعمل Apache 2.0 بطريقة مشابهة، لكنه يضيف نقطتين مهمتين. الأولى حماية صريحة من مطالبات براءات الاختراع: يتعهد مؤلفو الشيفرة بألا يقاضوك بشأن براءات الاختراع المتعلقة بهذه الشيفرة. والثانية بضعة متطلبات رسمية إضافية للاستخدام.
يجوز لك إعادة إنتاج نسخ من العمل أو الأعمال المشتقة وتوزيعها بأي وسيط، مع التعديلات أو بدونها، شريطة تقديم نسخة من هذا الترخيص إلى المستلمين، وتمييز الملفات المعدّلة، والإبقاء على إشعارات حقوق الطبع والنشر وبراءات الاختراع، وتضمين نسخة مقروءة من ملف NOTICE إن وُجد.
يشبه BSD، بنسختيه ذواتي البندين والثلاثة بنود، ترخيص MIT إلى حد كبير: استخدمه وعدّله وبِعه مع الاحتفاظ بإشعار حقوق الطبع والنشر. أدرجت التراخيص الثلاثة في جدول لتتمكن من رؤية الفروق بنظرة سريعة.
| الترخيص | بيع المنتج | إبقاء الشيفرة المصدرية مغلقة | ما يجب فعله | الحماية من براءات الاختراع |
|---|---|---|---|---|
| MIT | نعم | نعم | الاحتفاظ بإشعار حقوق الطبع والنشر ونص الترخيص | لا يتضمن بندًا |
| Apache 2.0 | نعم | نعم | إشعار حقوق الطبع والنشر، وملف NOTICE، وتمييز التعديلات | نعم |
| BSD (بندان وثلاثة بنود) | نعم | نعم | الاحتفاظ بإشعار حقوق الطبع والنشر | لا |
كيفية تطبيق ذلك على حالتك: إذا وجدت MIT أو Apache 2.0 أو BSD على شيفرة شخص آخر، فيمكنك الاطمئنان: يمكنك استخدامها في منتج تجاري وتعديلها وإبقاء شيفرتك المصدرية مغلقة. عليك فقط ألا تزيل ملف الترخيص والإسناد من الجزء الذي أخذته.
كيف تنطبق التزامات المصدر في GPL وAGPL؟
الفكرة الرئيسية
تسمح GPL وAGPL بالاستخدام التجاري. تنشأ التزامات المصدر في GPL عند نقل عمل مشمول؛ وليس تشغيل خادم عادي دون تسليم نسخة هذا المحفز. تضيف AGPLv3 مطلب عرض المصدر للمستخدمين المتفاعلين عن بعد مع نسخة معدلة. حدد العمل المركب المشمول؛ فالمكونات المستقلة لا تصبح كلها جزءًا منه تلقائيًا.
تحافظ الحقوق المتروكة على ترخيص العمل المشمول ومشتقاته عند انطباق الشروط. يتطلب توزيع نسخ مصدر أو كود كائن لعمل مشمول أو مشتق مركب وفق GPLv3 الالتزام بالترخيص والمصدر المقابل. لا يشمل ذلك تلقائيًا كل برنامج مستقل في المنتج أو الخادم نفسه.
في مثال خدمة الويب، لا تقتضي استضافة مكتبة GPL على خادمك دون تسليم المستخدمين نسخًا نشر الخدمة كلها بحد ذاتها. قد يفعّل توزيع تطبيق مركب مشمول على العملاء التزامات GPL؛ افحص التكامل والترخيص قبل تحديد المصدر المرافق. والعميل المسلّم للمتصفح مسألة توزيع مستقلة.
تضيف AGPLv3 شرط شبكة: إذا عدلت البرنامج وتفاعل المستخدمون مع النسخة عن بعد، فيجب أن تعرض لهم مصدرها المقابل بوضوح. هذا أدق من القول إن استضافة أي مكون AGPL تفتح كل جزء مستقل من الخدمة.
للمنتج الملكي، افحص العمل المشمول وطريقة جمع المكونات وتوزيع النسخ وانطباق تفاعل شبكة AGPL. اختر بديلًا متساهلًا متوافقًا أو احصل على إذن منفصل إذا لم تستطع استيفاء الالتزامات. الاستخدام التجاري مسموح؛ والمسألة هي الالتزام بالترخيص والتكامل الفعليين.
ماذا تفعل إذا لم يكن في المستودع ملف ترخيص على الإطلاق؟
الفكرة الرئيسية
غياب ملف الترخيص يعني أنه لا يجوز لك استخدام الشيفرة. وهذا لا يعني «أنها مجانية»؛ بل على العكس، تظل الشيفرة من دون ترخيص خاضعة لحقوق المؤلف كاملة، وليس لديك حق استخدامها أو نسخها أو تعديلها. ولا يفيدك الإذن بالاطلاع عليها وإنشاء fork لها داخل GitHub، إذ لا يمنحك حق إدراجها في منتجك. إذا كنت تحتاج إليها فعلًا، فالطريق السليم الوحيد هو مراسلة المؤلف وطلب الإذن، أو الانتظار حتى يضيف ترخيصًا.
من الأخطاء الشائعة افتراض أن غياب الترخيص يعني عدم وجود قيود وأن بإمكانك استخدام الشيفرة بحرية. العكس هو الصحيح. غياب الترخيص ليس إذنًا؛ بل يعني افتراضيًا عدم وجود إذن. وتظل الشيفرة غير المرخّصة خاضعة لحقوق المؤلف كاملة، ولا يجوز لك المساس بها.
تنطبق القاعدة التي بدأنا بها مجددًا: تخضع الشيفرة افتراضيًا لحقوق الطبع والنشر، ولا يجوز لك نسخها أو تعديلها أو توزيعها من دون إذن صريح. ولا تزيل إمكانية الاطلاع عليها وإنشاء fork لها داخل GitHub هذا الحاجز، فهي لا تمنحك حق استخدام الشيفرة في منتجك.
ما ينبغي فعله عمليًا إذا لم تكن للشيفرة رخصة وكنت تحتاج إليها فعلًا:
- راسل المؤلف. اسأله مباشرةً، إما في قسم المناقشات بالمستودع أو عبر البريد الإلكتروني، عما إذا كان بإمكانك استخدام الشيفرة وبأي شروط. أحيانًا ينسى المؤلف ببساطة إضافة ترخيص، وقد يضيفه إذا طلبت ذلك.
- ابحث عن بديل. لكل مهمة تقريبًا مستودع مشابه ثانٍ وثالث وعاشر، وستجد بينها مستودعًا يحمل ترخيص MIT أو Apache مناسبًا.
- لا تستخدمها. إذا لم تحصل على إذن ولم تجد بديلًا، فالشيفرة ليست ملكًا لك، ولا يمكنك إدراجها في منتج تنوي بيعه. تنتهي فكرة «من سيكتشف ذلك؟» نهاية سيئة عندما يبدأ المنتج بتحقيق المال وجذب الانتباه.
ماذا لو أضاف Claude نفسه شيفرة شخص آخر إلى المشروع؟
الفكرة الرئيسية
هذه حالة منفصلة، ومن المهم عدم الخلط بينها وبين نسخ مستودع مباشرةً. عندما تأخذ بنفسك شيفرة من مستودع محدد، عليك الالتزام بترخيصها. أما عندما ينشئ Claude أو ذكاء اصطناعي آخر شيفرة استجابةً لطلبك، فعادةً ما ينتج نصًا خاصًا به ومصاغًا للمهمة بدلًا من نسخ ملف شخص آخر، وعندئذ يتحول السؤال إلى الحقوق في الشيفرة المُنشأة. لكن إذا أعاد الذكاء الاصطناعي بوضوح إنتاج جزء معروف من شيفرة شخص آخر مرخّصة، تظل شروط الترخيص سارية. ومن المفيد التحقق من المصدر في الحالتين.
هناك جانب ثانٍ هنا، ومن السهل الخلط بينه وبين الأول. يختلف الأمر عندما تزور مستودعًا وتنسخ منه ملفًا؛ ففي هذه الحالة تصبح كل الالتزامات المتعلقة بالترخيص التي ذكرناها أعلاه واجبة عليك مباشرةً. ويختلف عندما يكتب Claude شيفرة لك استجابةً لطلب.
في الحالات المعتادة، ينشئ الذكاء الاصطناعي نصًا خاصًا به ومصاغًا لمهمتك بدلًا من نسخ ملف شخص آخر. عندها ينتقل السؤال إلى مجال مختلف: من يملك الشيفرة المُنشأة، وهل يمكنك بيعها؟ هذا موضوع واسع بحد ذاته، وقد تناولته في مقال عن من يملك الشيفرة التي يكتبها الذكاء الاصطناعي.
لكن هناك استثناء ينبغي أخذه في الحسبان. أحيانًا ينتج الذكاء الاصطناعي جزءًا معروفًا من شيفرة شخص آخر كلمة بكلمة تقريبًا، مثل دالة كاملة من مكتبة مشهورة. في هذه الحالة، يظل ترخيص المكتبة ساريًا، بصرف النظر عمن ضغط المفاتيح فعليًا. لذلك ينبغي التحقق من كتل الشيفرة الكبيرة الجاهزة التي أدرجها Claude كاملةً كما لو أنك نسختها بنفسك.
كيفية التحقق من الترخيص قبل استخدام الشيفرة: خطوات ينبغي اتباعها
الفكرة الرئيسية
الخطوات هي: افتح صفحة المستودع وتحقق من اسم الترخيص في الشريط الجانبي، وافتح ملف LICENSE نفسه، وحدد النوع: متساهل (MIT وApache وBSD) أم حقوق متروكة (GPL وAGPL)، ثم قارن ذلك بحالتك وقرر ما إذا كنت ستستخدم الشيفرة أو تبحث عن بديل. إذا لم يكن هناك ترخيص، فلا تستخدم الشيفرة. يستغرق التحقق بضع دقائق، وينبغي إجراؤه قبل إدخال الشيفرة في مشروعك، لا بعد ذلك.
لنحوّل كل ما سبق إلى قائمة تحقق قصيرة لفحص أي شيفرة من طرف ثالث قبل إدخالها في مشروعك. اتبع الخطوات من الأعلى إلى الأسفل.
اعثر على اسم الترخيص في صفحة المستودع
افتح المستودع على GitHub. يظهر اسم الترخيص عادةً في العمود الأيمن أو أسفل قائمة الملفات، مثل “MIT License” أو “Apache-2.0” أو “GPL-3.0”. إذا كان الحقل فارغًا ولم يوجد ملف ترخيص، فهذه إشارة تحذير بالفعل؛ عُد إلى الأمر في الخطوة الأخيرة.
افتح ملف الترخيص نفسه
ابحث في قائمة الملفات عن LICENSE أو LICENSE.md أو COPYING وافتحه. تأكد من أن الاسم يطابق ما يظهر في الشريط الجانبي، ومن أن الترخيص ينطبق على الشيفرة التي تستخدمها لا على جزء منفصل من المستودع فقط.
حدد النوع: متساهل أم حقوق متروكة
تراخيص MIT وApache 2.0 وBSD متساهلة؛ ويمكنك استخدام الشيفرة في منتج تجاري مغلق المصدر. أما GPL وAGPL فحقوق متروكة؛ افحص العمل المشمول والتوزيع وشرط شبكة AGPL قبل تحديد التزامات المصدر. لا يحدد الاسم وحده المكونات المستقلة المشمولة.
قارن الترخيص بحالتك
أجب عن ثلاثة أسئلة: هل تبيع المنتج؟ هل تعدّل الشيفرة؟ وهل تريد إبقاء الشيفرة المصدرية مغلقة؟ تناسب MIT وApache وBSD منتجًا مغلق المصدر معروضًا للبيع. مع GPL وAGPL، حدد العمل المشمول أو المركب المطلوب مصدره المقابل ومتى ينشأ الالتزام، وقيّم إمكان استيفاء الشروط.
غياب الترخيص يعني عدم الاستخدام
إذا لم يوجد ملف ترخيص ولم يذكر README شيئًا عن الإذن، فلا يجوز لك استخدام الشيفرة. راسل المؤلف واطلب الإذن أو ابحث عن بديل مكافئ يحمل ترخيصًا مناسبًا. «متاحة للعامة» لا تعني وجود إذن.
يبدو هذا التحقق مملًا إلى أن يكبر منتجك ويبدأ بتحقيق المال ويسألك أحدهم عن شيفرة الطرف الثالث الموجودة فيه. كلفة دقيقتين في البداية أقل من التعامل مع نزاع لاحقًا. وتناولت في مقال منفصل ما ينبغي فعله بمنتجك بعد ذلك حتى لا يتوقف بعد الإطلاق: بنيت منتجًا باستخدام الذكاء الاصطناعي؛ ماذا بعد؟.
الأسئلة الشائعة
هل يمكنك بيع منتج يتضمن شيفرة شخص آخر من GitHub؟
نعم، إذا كانت الشيفرة تحمل ترخيصًا متساهلًا مثل MIT أو Apache 2.0 أو BSD. فهي تسمح لك باستخدام الشيفرة في منتج تجاري وبيعه وإبقاء شيفرتك المصدرية مغلقة، ولا تشترط إلا الاحتفاظ بنص الترخيص والإسناد. تسمح GPL وAGPL بالتجارة أيضًا، لكن واجبات المصدر تتوقف على العمل المشمول ومحفز التوزيع أو شبكة AGPL المنطبق. أما من دون ملف ترخيص فلا يجوز لك استخدام الشيفرة مطلقًا.
ماذا يعني ألا يكون لمستودع GitHub ترخيص؟
يعني أنه لا يجوز لك استخدام الشيفرة. فغياب الترخيص يعني افتراضيًا غياب الإذن، ولا يعني أنها «مجانية». تظل الشيفرة خاضعة لحقوق المؤلف كاملة. ولا تمنحك إمكانية الاطلاع على المستودع وإنشاء fork له داخل GitHub حق استخدام الشيفرة في منتجك. إذا كنت تحتاج إليها، فراسل المؤلف واطلب الإذن أو ابحث عن بديل يحمل ترخيصًا مفتوحًا.
ما الفرق بين MIT وGPL بالنسبة إلى منتجي؟
يتيح لك MIT استخدام الشيفرة وتعديلها وبيع المنتج وإبقاء شيفرتك المصدرية مغلقة؛ والالتزام الوحيد هو الاحتفاظ بنص الترخيص. يسمح GPL بالتجارة أيضًا، لكن نقل عمل مشمول مركب أو مشتق يتطلب المصدر المقابل والترخيص نفسه وفق شروطه. الاستضافة دون نقل نسخة مختلفة؛ ولا تُشمل المكونات المستقلة تلقائيًا.
هل عليّ فعل أي شيء إذا استخدمت شيفرة بموجب ترخيص MIT؟
نعم، أمر واحد بسيط: احتفظ بنص ترخيص MIT وسطر الإسناد الخاص بالشيفرة التي استخدمتها في مشروعك. وعادةً ما يكون ذلك ملف LICENSE نفسه المرفق بالأصل. لا يفرض MIT أي شيء آخر؛ فيمكنك تعديل الشيفرة وبيع المنتج وإبقاء شيفرتك المصدرية مغلقة.
ماذا لو أضاف Claude نفسه شيفرة شخص آخر بدلًا مني؟
عليك التحقق من المصدر على أي حال. عادةً ما ينتج الذكاء الاصطناعي نصًا خاصًا بمهمتك، وعندئذ يتحول السؤال إلى الحقوق في الشيفرة المُنشأة، وهذا موضوع منفصل. لكن إذا أعاد الذكاء الاصطناعي إنتاج جزء معروف من شيفرة شخص آخر من مكتبة مشهورة كلمة بكلمة تقريبًا، يظل ترخيص تلك المكتبة ساريًا. تحقّق من كتل الشيفرة الكبيرة الجاهزة التي أُدرجت كاملةً كما تتحقق من شيفرة نسختها بنفسك ولصقتها.
المصادر
المزيد من التفاصيل
أسئلة شائعة
هل تجبرني استضافة مكتبة GPL على نشر خدمة الويب كاملة؟
الاستضافة وحدها دون نقل نسخ ليست محفز توزيع GPL. عند توزيع تطبيق مركب أو مشتق مشمول، قد تنطبق التزامات المصدر على ذلك العمل؛ ولا تُشمل المكونات المستقلة تلقائيًا.
أي شرط إضافي تفرض AGPLv3 على خدمة ويب؟
يجب أن يعرض برنامج AGPL معدل يدعم تفاعل الشبكة البعيد مصدره المقابل لأولئك المستخدمين. افحص البرنامج المشمول والتكامل بدل افتراض غياب الالتزام أو وجوب فتح كل خدمة مستقلة.