تراخيص المكتبات والخدمات الخارجية في تطبيقك: من يدفع ومن يملك ومن يجدد
تطبيقك يقوم على مكتبات ومكونات وخطوط لا تملكها، ولكل منها ترخيص بشروط: إشعارات، أو نشر كود، أو اشتراك ينتهي. هذه قائمة تحقق لمدير التقنية والمشتريات تحدد ما تسأل عنه وتراقبه وتستلمه، ومن يدفع ويجدد.
تطبيقك مبني على مكونات لا تملكها: مكتبات مفتوحة المصدر، ومكونات وخطوط مدفوعة، وخدمات خارجية. تراخيص الطرف الثالث في التطبيق تحدد ثلاثة أشياء: ما يجب أن تلتزم به حين توزع التطبيق (إشعارات حقوق، أو نشر كود في بعض التراخيص)، ومن يدفع ويجدد، وباسم من الرخصة. القاعدة العملية: لا يدخل مكون بترخيص مقيِّد أو مدفوع دون موافقة مكتوبة منك، وكل رخصة مدفوعة تُشترى باسم منشأتك، وتستلم عند التسليم سجلًا بكل المكونات وتراخيصها ومواعيد تجديدها، وتعرف مسبقًا ماذا تفعل إن تغيّر ترخيص مكتبة تعتمد عليها.
حين تسأل شركة التطوير «من يملك التطبيق؟» تكون الإجابة غالبًا «أنت، والكود في مستودعك». هذا صحيح للكود المكتوب لمشروعك، لكنه لا يشمل مئات المكونات التي يقوم عليها ذلك الكود. مكتبة الرسوم البيانية، وحزمة تسجيل الدخول، والخط العربي في الواجهة، ومكوّن قراءة المستندات، كلها لها أصحاب وشروط. بعضها لا يطلب منك إلا إبقاء إشعار حقوق، وبعضها يطلب نشر كودك إن وزعت نسخة معدلة، وبعضها يتوقف عن العمل حين ينتهي اشتراك لم يخبرك أحد به. هذه قائمة تحقق لمدير التقنية والمشتريات: ما تسأل عنه قبل التعاقد، وما تراقبه أثناء التطوير، وما تستلمه عند التسليم.
هذه المقالة توعية تجارية وتقنية بطبيعة التراخيص وأثرها على مشروعك، لا تفسير قانوني لنص أي ترخيص. حين يتعلق القرار بمكون بترخيص مقيِّد في منتج تجاري، راجع نص الترخيص نفسه مع مستشار قانوني.
ثلاث فئات من المكونات التي تستخدمها ولا تملكها
قبل الحديث عن أنواع التراخيص، افصل المكونات إلى ثلاث فئات، لأن لكل فئة سؤالًا مختلفًا:
| الفئة | أمثلة في تطبيق أعمال | السؤال الأساسي | أين يظهر الخطر |
|---|---|---|---|
| مكتبات مفتوحة المصدر | حزم Flutter أو Android أو iOS، وإطار الخادم، وقاعدة البيانات، ومكتبات التشفير والتاريخ | ما الذي يشترطه الترخيص حين توزع التطبيق أو تشغل الخادم؟ | ترخيص يفرض نشر الكود، أو يتغير في إصدار لاحق |
| مكونات وأصول مدفوعة | خط عربي تجاري، ومجموعة أيقونات، ومكونات واجهة، ومكتبة تقارير أو قراءة مستندات، وصور | من اشترى الرخصة، وباسم من، وبأي نطاق استخدام؟ | رخصة باسم المطور، أو لنطاق لا يشمل التطبيق، أو اشتراك ينتهي |
| خدمات خارجية بشروط استخدام | الخرائط، والرسائل، والدفع، والإشعارات، ونماذج الذكاء الاصطناعي | باسم من الحساب، ومن يدفع الاستهلاك؟ | حساب باسم طرف آخر، أو تسعير يتغير |
الفئة الثالثة موضوع مقالة حسابات الخدمات الخارجية في تطبيقك، وملكية الكود المكتوب لك موضوع مقالة من يملك الكود المصدري للتطبيق. هنا نركز على الفئتين الأولى والثانية: ما يدخل في كودك أو واجهتك وله ترخيص من غيرك.
تراخيص المصادر المفتوحة: ما تشترطه كل عائلة حين تنشر تطبيقك
«مفتوح المصدر» لا يعني «بلا شروط». التراخيص تتوزع على عائلات، ولكل عائلة أثر مختلف على تطبيق تجاري. القراءة التالية عامة للتوجيه، والنص الملزم هو نص الترخيص نفسه كما تنشره مبادرة المصادر المفتوحة (OSI):
| العائلة | أمثلة | ما تشترطه عادة | ما تفعله في مشروعك |
|---|---|---|---|
| متساهلة | MIT، BSD، Apache-2.0 | إبقاء إشعار الحقوق ونص الترخيص مع التوزيع؛ وApache-2.0 يضيف ملف NOTICE إن وجد والإشارة إلى الملفات المعدلة | ✓ مقبولة غالبًا: اعرض الإشعارات داخل التطبيق |
| حماية ضعيفة | LGPL، MPL-2.0 | نشر تعديلاتك على المكتبة نفسها أو ملفاتها، لا كل كودك، مع شروط في طريقة الربط أحيانًا | جزئي: تحتاج موافقة ومراجعة لطريقة الاستخدام |
| حماية قوية | GPL | إن وزعت عملًا مشتقًا منها، يُوزع بالترخيص نفسه مع كوده المصدري | ✗ تجنبها في كود التطبيق الموزع إلا بقرار واعٍ |
| حماية شبكية | AGPL | كالسابقة، ويمتد الالتزام إلى من يتفاعل مع نسختك المعدلة عبر الشبكة | ✗ حساسة على الخادم إن عدّلت المكون |
| «متاحة المصدر» غير معتمدة من OSI | تراخيص بشروط تجارية أو قيود على تقديمه كخدمة | قيود على الاستخدام التجاري أو السحابي بحسب النص | اقرأ النص: قد يناسبك وقد لا يناسبك |
نقطتان تهمان تطبيقات الجوال تحديدًا. الأولى: التطبيق الموزع على المتاجر «توزيع»، فالتراخيص المتساهلة نفسها تطلب إشعارات الحقوق. أدوات البناء تساعدك: أداة Flutter تجمع ملفات الترخيص من كل الحزم المستخدمة في ملف واحد يمكن عرضه في صفحة تراخيص داخل التطبيق، وتوفر Google لتطبيقات Android أداة لجمع إشعارات المصادر المفتوحة وعرضها وتذكر أن عرضها مسؤولية المطور. اطلب أن تكون صفحة التراخيص جزءًا من التطبيق لا فكرة لاحقة. والثانية: ترخيص AGPL يخص الخادم أكثر من الجوال، فمكون بهذا الترخيص تعدّله وتشغله في خادمك قد يفرض عليك إتاحة كود نسختك المعدلة لمستخدميه، كما ينص نص الترخيص في بند التفاعل عبر الشبكة.
المكونات المدفوعة: من يدفع، ومن يملك، ومن يجدد
المكونات المدفوعة أوضح في التكلفة وأخطر في التفاصيل. المشكلات المتكررة ليست في السعر، بل في أربعة أسئلة لم يطرحها أحد عند الشراء:
- باسم من الرخصة؟
- شركة التطوير اشترت مكوّن التقارير بحسابها لأنها تملك رخصة سابقة. عند انتهاء العقد لا تنتقل الرخصة إليك، والفريق الجديد لا يستطيع البناء قبل أن تشتري رخصة أخرى، وقد يكون الإصدار المستخدم لم يعد يُباع.
- ما نطاق الاستخدام؟
- بعض الرخص لكل مطور يعمل على الكود، وبعضها لكل تطبيق، وبعضها لعدد مستخدمين أو أجهزة. رخصة خط لسطح المكتب لا تعني بالضرورة حق تضمينه في تطبيق يُوزع لآلاف المستخدمين؛ نوع الرخصة يُقرأ لا يُفترض.
- هل هي دائمة أم اشتراك؟
- الرخصة الدائمة تعطيك حق الاستخدام للإصدار الذي اشتريته، وقد يكون التحديث مدفوعًا. الاشتراك يعني تكلفة سنوية، وبعض المكونات تتحقق من مفتاح الترخيص عند التشغيل، فتتعطل ميزة في تطبيقك حين ينتهي الاشتراك.
- من يتابع التجديد؟
- إن لم يكن التجديد في تقويم شخص محدد في منشأتك، فسيُكتشف انتهاؤه من شكوى عميل.
الحل التعاقدي بسيط: أي مكون مدفوع يُعرض عليك قبل استخدامه بسعره ونطاقه وبديله المجاني إن وجد، ويُشترى باسم منشأتك أو بحساب يُنقل إليها. قد يُصاغ البند هكذا:
«لا يُدخل المزود في التطبيق أي مكون أو مكتبة أو أصل تصميمي بترخيص مدفوع، أو بترخيص يفرض إتاحة الكود المصدري للتطبيق أو لخادمه، أو بترخيص يقيد الاستخدام التجاري، إلا بعد موافقة المنشأة الكتابية المسبقة على اسم المكون وترخيصه وتكلفته وجهة الشراء. وتُشترى التراخيص المدفوعة باسم المنشأة، ويُسلم المزود سجلًا محدثًا بكل مكونات الطرف الثالث وتراخيصها مع كل إصدار.»
صياغة توضيحية تُراجع مع مستشارك وتوضع مع بقية بنود العقد، كما في مقالة بنود عقد تطوير التطبيق.
قائمة تحقق تراخيص الطرف الثالث في التطبيق: قبل التعاقد وأثناءه وعند التسليم
قبل التعاقد
- اسأل عن المكونات المدفوعة التي يتوقع المزود استخدامها، ومن يشتريها، وتكلفتها على مدة سنتين على الأقل.
- اسأل إن كان المزود يستخدم أدوات أو قوالب داخلية خاصة به، وبأي ترخيص تبقى معك بعد انتهاء العقد.
- أدخل في العقد شرط الموافقة المسبقة على المكونات المدفوعة والمقيِّدة، وشرط تسليم سجل التراخيص.
- حدد من يدفع ويجدد: مزود التطوير أم منشأتك مباشرة، وافصل ذلك في عرض السعر.
- اتفق على طريقة عرض إشعارات المصادر المفتوحة داخل التطبيق.
أثناء التطوير
- كل مكتبة جديدة تُضاف تمر بمراجعة لترخيصها ضمن مراجعة الكود، لا بعد التسليم.
- فحص آلي لتراخيص الاعتماديات في خط البناء ينبّه عند ظهور ترخيص من العائلات المقيِّدة.
- مفاتيح الرخص المدفوعة في خزنة أسرار تملكها المنشأة، لا في الكود ولا في جهاز المطور.
- تسجيل كل شراء لمكون أو خط أو أصل: الفاتورة، واسم الحساب، ونطاق الرخصة.
- مراجعة سجل التراخيص في نهاية كل مرحلة، مع مخرجاتها.
عند التسليم
- سجل كامل بالمكونات وإصداراتها وتراخيصها، يطابق ملفات الاعتماديات في المستودع.
- صفحة التراخيص داخل التطبيق تعمل وتعرض الإشعارات المطلوبة.
- كل رخصة مدفوعة باسم المنشأة أو منقولة إليها، مع بيانات الدخول إلى حساب المورد.
- مواعيد التجديد في تقويم شخص محدد في منشأتك.
- بيان بأي مكون بترخيص غير متساهل، وسبب اختياره، وبديله.
هذه البنود جزء من قائمة الاستلام الأشمل في مقالة قائمة استلام تطبيق من شركة البرمجة.
سجل التراخيص: النموذج الذي تستلمه
السجل ليس ملفًا شكليًا؛ هو ما يجيب عن أسئلة التدقيق، وما يحتاجه أي فريق يستلم التطبيق بعدك. هذا الحد الأدنى من أعمدته:
| العمود | مثال لما يُكتب | لماذا تحتاجه |
|---|---|---|
| المكون والإصدار | اسم الحزمة ورقم إصدارها المستخدم فعلًا | الترخيص قد يختلف من إصدار لآخر |
| مكانه | تطبيق الجوال، أو الخادم، أو لوحة التحكم | أثر الترخيص يختلف بين ما يُوزع وما يعمل على الخادم |
| الترخيص | معرّف موحد مثل MIT أو Apache-2.0، أو «تجاري» | يسهل الفحص الآلي والمراجعة |
| مدفوع؟ ونوع الرخصة | دائمة أم اشتراك، لكل مطور أم لكل تطبيق | يحدد التكلفة المستمرة ومن يحتاج رخصة عند تغيير الفريق |
| باسم من، ومن يدفع | المنشأة، أو المزود مؤقتًا مع موعد النقل | يحدد ما تفقده إن انتهت العلاقة |
| التجديد | التاريخ ومن يتابعه | يمنع تعطل ميزة بانتهاء اشتراك |
| الالتزام المطلوب | إشعار في صفحة التراخيص، أو ملف NOTICE، أو غير ذلك | يثبت أنك تفي بشروط الترخيص |
| البديل | مكون بديل أو «لا يوجد» | يسرّع القرار إن تغير الترخيص أو السعر |
في المشاريع الأكبر أو التي تمر بمراجعات أمنية، اطلب إضافة إلى الجدول «قائمة مكونات البرمجيات» (SBOM) تُولَّد آليًا من ملفات الاعتماديات بصيغة معيارية مثل SPDX، وهي معيار دولي (ISO/IEC 5962:2021)، أو CycloneDX. القائمة الآلية تغطي المكتبات، والجدول اليدوي يغطي ما لا تراه الأدوات: الخطوط، والأيقونات، والأصول، والرخص المدفوعة.
حين يتغير ترخيص مكتبة يعتمد عليها تطبيقك
الترخيص ليس ثابتًا إلى الأبد. أصحاب المشروع قد يغيرونه في الإصدارات القادمة، والإصدارات التي صدرت سابقًا تبقى عادة بترخيصها الأصلي. مثال معروف: أعلنت Redis، وهي قاعدة بيانات تُستخدم كثيرًا للتخزين المؤقت في خوادم التطبيقات، في مارس 2024 الانتقال إلى ترخيص «متاح المصدر» غير معتمد من OSI، ثم أضافت ترخيص AGPLv3 خيارًا بدءًا من Redis 8 في مايو 2025، كما تذكر مدونتها الرسمية، وتذكر أن مزودي سحابة كبارًا صاروا يطورون نسخة متفرعة خاصة بهم بعد التغيير الأول. من كان يعتمد عليها احتاج إلى قرار، لا إلى ذعر:
- لاحدّث السجل، وتابع الإصدارات كالمعتاد
- نعمهل تحتاج إلى الإصدارات الجديدة قريبًا (أمن أو مزايا)؟
- لاثبّت آخر إصدار بالترخيص القديم مؤقتًا، وضع موعدًا لقرار نهائي
- نعمهل يوجد تفرع نشط أو بديل بترخيص مناسب؟
- نعمخطط للانتقال إليه باختبار كامل
- لاالتزم بالترخيص الجديد أو اشترِ رخصة تجارية، بعد مراجعة قانونية
- نعم
- لا
العزل هو الدرس المعماري هنا: المكون الذي يُستدعى من مكان واحد في الكود يُستبدل في أيام، والمكون المنتشر في كل ملف يُستبدل في أشهر. هذا من القرارات التي تُكتب أسبابها وبدائلها في وثيقة المعمارية، ومتابعة تحديثات المكتبات وثغراتها جزء مما يشمله عقد الصيانة والدعم بعد الإطلاق.
أخطاء شائعة في تراخيص مكونات التطبيق
- افتراض أن «مجاني» يعني «بلا شروط»: أغلب التراخيص المجانية تطلب على الأقل إشعار الحقوق، وبعضها يطلب أكثر بكثير.
- رخص مدفوعة باسم المطور: تكتشف ذلك حين يطلب الفريق الجديد شراء كل شيء من جديد.
- مراجعة التراخيص عند التسليم فقط: حين تكتشف مكونًا مقيِّدًا في آخر المشروع، يكون استبداله إعادة عمل لا اختيارًا.
- تجاهل الخطوط والأيقونات والصور: لأنها ليست «كودًا»، لا تظهر في أدوات الفحص، وهي من أكثر ما يُستخدم دون رخصة مناسبة.
- مفتاح ترخيص مكتوب في الكود: يتسرب مع أي نسخة من المستودع، ويصعب تدويره.
- لا أحد يملك التجديد: كل طرف يظن أن الآخر سيجدد.
- التثبيت الدائم على إصدار قديم لتجنب ترخيص جديد: يوفر اليوم ويراكم ثغرات لا تُصلح.
ما تطلبه من شركة التطوير، وما تجهزه قبل التواصل
اطلب من شركة التطوير كتابة:
- قائمة بالمكونات المدفوعة المتوقعة وتكلفتها ومن يشتريها، ضمن عرض السعر.
- التزامًا بالموافقة المسبقة على أي مكون مدفوع أو بترخيص مقيِّد.
- سجل تراخيص محدثًا مع كل مرحلة، وقائمة SBOM إن كان مشروعك يمر بمراجعة أمنية.
- صفحة تراخيص داخل التطبيق تعرض الإشعارات المطلوبة.
- بيانًا بأي أداة أو قالب داخلي خاص بالشركة يدخل في الكود، وشروط بقائه معك.
وجهّز من طرفك:
- سياسة منشأتك من التراخيص إن وجدت (عائلات مقبولة وأخرى تحتاج موافقة).
- الأصول التي تملكها سابقًا: خطوط الهوية التجارية ورخصها، والأيقونات، والصور.
- الشخص الذي سيعتمد المكونات المدفوعة، والشخص الذي سيتابع التجديدات.
- متطلبات الجهة أو العميل الذي ستخدمه، إن كان يطلب قائمة مكونات أو مراجعة أمنية.
في كل نماذج التعاقد لدينا تبقى الملكية الفكرية للكود وحسابات المتاجر والاستضافة باسم منشأتك. والمكونات التي لا يملكها أحد منا هي ما تحكمه هذه القائمة، فاطرحها في أول اجتماع تقني لمشروعك.
الخلاصة: اعرف ما لا تملكه قبل أن تحتاجه
ملكيتك للكود المكتوب لمشروعك لا تكتمل إن كانت المكونات التي يقوم عليها مجهولة التراخيص أو مسجلة باسم غيرك. ثلاث قواعد تكفي أغلب المشاريع: موافقة مسبقة على كل مكون مدفوع أو مقيِّد، وشراء الرخص باسم منشأتك، وسجل تراخيص يُحدّث مع كل مرحلة ويُسلّم مع الكود. أضف إليها عزل المكونات الحساسة في المعمارية، ومتابعة التحديثات بعد الإطلاق، وسيصبح تغيير ترخيص مكتبة قرارًا هادئًا لا أزمة.
إن كان تطبيقك قائمًا ولا تعرف ما بداخله من مكونات وتراخيص، فالخطوة التالية جرد الاعتماديات والأصول وإعداد السجل قبل أي تطوير جديد أو تغيير في المزود.
أسئلة شائعة
نعم في أغلب الحالات، خاصة بالتراخيص المتساهلة مثل MIT وBSD وApache-2.0، بشرط الالتزام بما تطلبه كإبقاء إشعارات الحقوق وعرضها. التراخيص ذات الحماية القوية مثل GPL وAGPL تحتاج قرارًا واعيًا ومراجعة، لأنها قد تفرض إتاحة الكود في حالات معينة.
يعتمد على شروط الرخصة، وكثير منها لا يُنقل تلقائيًا. اطلب نقل الرخصة إلى منشأتك إن سمح المورد، أو شراء رخصة باسمك قبل انتهاء العلاقة، واشترط في العقود القادمة أن تُشترى الرخص المدفوعة باسم المنشأة من البداية.
لأن توزيع التطبيق على المتاجر توزيع للمكتبات المضمنة فيه، والتراخيص المتساهلة نفسها تطلب إرفاق إشعارات الحقوق. أدوات Flutter وAndroid تجمع هذه الإشعارات آليًا ويمكن عرضها في صفحة داخل الإعدادات، فهي جهد صغير يثبت التزامك.
تحقق أولًا إن كان التغيير يمس طريقة استخدامك فعلًا. إن كان كذلك، فالتثبيت على آخر إصدار بالترخيص القديم حل مؤقت، ثم تنتقل إلى تفرع أو بديل مناسب، أو تلتزم بالترخيص الجديد أو تشتري رخصة تجارية بعد مراجعة قانونية.
نعم، ولكل خط شروطه. بعض الخطوط بتراخيص مفتوحة تسمح بتضمينها، والخطوط التجارية قد تفرق بين رخصة الاستخدام على سطح المكتب ورخصة تضمينها في تطبيق يُوزع. اقرأ نوع الرخصة قبل التصميم، واحفظ الفاتورة والرخصة باسم منشأتك.
خدمات وصفحات مرتبطة
اقرأ أيضًا
راجع مكونات تطبيقك وتراخيصها مع مهندس
في اجتماع تقني نناقش المكونات التي يحتاجها مشروعك أو يستخدمها تطبيقك القائم، وتراخيصها، ومن يشتريها، وكيف تُسجل وتُسلّم.