من يملك Source Code بعد تطوير التطبيق؟ وما الذي يجب أن تستلمه من شركة البرمجة؟

الملكية والاستلام التقني

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

الإجابة المباشرة: من يملك Source Code بعد تطوير التطبيق؟

في السعودية، البرمجيات تدخل ضمن المصنفات التي يحميها نظام حماية حقوق المؤلف ولائحته التنفيذية.[2] وقد أطلقت الهيئة السعودية للملكية الفكرية بالتعاون مع هيئة الاتصالات والفضاء والتقنية دليلًا استرشاديًا لحماية حقوق المؤلف في البرمجيات، يشمل برامج الحاسب وقواعد البيانات والمنصات الرقمية والتطبيقات، ويتناول انتقال المصنفات التقنية وتنظيم العلاقات التعاقدية واتفاقيات الترخيص وضوابط تسجيل المصنفات التقنية.[1]

لكن تحديد من يملك الحقوق المالية في برنامج طُوِّر لصالح عميل لا يُحسم بمجرد الدفع أو استلام الملفات. الحقوق المالية يمكن نقلها كلها أو بعضها، والتصرف فيها يحتاج اتفاقًا مكتوبًا يحدد نطاق الحق والغرض منه. وما لم يُتنازل عنه صراحةً يبقى محل نزاع لاحق.

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

أربع طبقات يجب ألا تخلط بينها

ماذا يعني «Source Code» داخل العقد؟

عبارة «سيتم تسليم Source Code» وحدها غامضة في مشروع متعدد المكونات. الأفضل أن تحدد قائمة التسليمات ما يدخل بالاسم:

العقد: ما الذي يجب أن يحسمه قبل بدء التطوير؟

الدليل الاسترشادي للبرمجيات لا يكتفي بفكرة «الترخيص» عمومًا، بل يتناول تنظيم العلاقات التعاقدية واتفاقيات الترخيص وانتقال المصنفات التقنية.[1] ترجمة ذلك إلى بنود يجب حسمها مسبقًا:

جدول الملكية: لا تترك أي أصل بلا مسؤول واضح

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

المستودع: لا تستلم ملفًا مضغوطًا وتعتبر المهمة انتهت

منصات Git توفّر آليات رسمية لنقل المستودع إلى مستخدم أو مؤسسة أخرى؛ فعند نقل مستودع على GitHub تنتقل معه المشكلات وطلبات السحب والويكي والنجوم والمتابعون، ويستطيع المالك الجديد إدارة محتوياته وإعداداته مباشرة.[3] أي أن الاستلام يمكن أن يشمل نقل التحكم في مساحة التطوير نفسها، لا مجرد تنزيل الملفات.

هل يمكن إعادة بناء النسخة المنشورة؟

إذا كان المنتج يعتمد على Pipeline آلية، فملفات هذه الـPipeline وإعداداتها جزء عملي من التسليم لا إضافة اختيارية.

كذلك يجب حفظ إصدارات الـRuntime والاعتماديات بطريقة تسمح بإعادة البناء. مثالًا، توضح وثائق npm أن ملف package-lock.json يصف الشجرة الدقيقة التي وُلِّدت، بحيث تستطيع عمليات التثبيت اللاحقة توليد شجرة مطابقة بغض النظر عن تحديثات الاعتماديات الوسيطة.[4]

الاختبارات: ما وُجد منها يجب ألا يضيع في الطريق

ليس كل مشروع يحتوي على النوع نفسه من الاختبارات. لكن ما نُفِّذ منها ضمن نطاق العمل يجب أن يصل إليك:

وجود أو غياب كل نوع يعتمد على نطاق المشروع. لا تستخدم القائمة كادعاء بأن كل مشروع يجب أن يحتوي عليها جميعًا.

الأسرار: لا تحوّل الاستلام إلى تسريب

توصي وثائق GitHub بألا تُكتب الأسرار داخل الكود إطلاقًا، وباستخدام متغيرات البيئة أو أدوات إدارة الأسرار، وبعدم إرسالها عبر البريد أو الرسائل الفورية، وبتحديد صلاحيات انتهاء لها وتدويرها دوريًا. وتضيف أن أي سرّ انكشف ولو للحظة يُعتبر مخترَقًا ويجب إبطاله فورًا واستبداله.[5]

الاستلام الجيد إذن ليس إرسال ملف .env على واتساب، بل تنظيم:

النسخ الاحتياطي: وجوده لا يكفي بدون استعادة مُختبَرة

تنص إرشادات AWS على أن استراتيجية النسخ الاحتياطي يجب أن تتضمن اختبار النسخ، وأن الاستراتيجية لا تكون فعّالة إذا تعذّر استرجاع البيانات المنسوخة، وتوصي باختبار القدرة على تحديد نقاط الاستعادة واستردادها بانتظام.[6]

متاجر التطبيقات: الملكية ليست اسم مستخدم وكلمة مرور

لدى Apple عملية رسمية لنقل ملكية التطبيق إلى مطوّر آخر دون إزالته من المتجر؛ يحتفظ التطبيق أثناء النقل وبعده بمراجعاته وتقييماته، ويستمر المستخدمون في تلقّي التحديثات، ويحتفظ بمعرّف الحزمة (Bundle ID) الذي لا يمكن تغييره بعد رفع أول Build. ويشترط أن يكون التطبيق قد صدرت له نسخة واحدة على الأقل على المتجر، وألا يكون في حالة مراجعة أو انتظار إصدار.[7]

وGoogle Play كذلك يوفّر عملية نقل رسمية بين حسابات المطورين، تنتقل معها بيانات المستخدمين وإحصاءات التنزيل والتقييمات والمراجعات وبيانات المتجر، بينما لا تنتقل تقارير الأرباح والمدفوعات.[8]

الدومين والحسابات الحرجة

لا تكتب في محضر الاستلام «الدومين موجود» فقط. سجّل من يملك الحساب الذي يدير الأصل نفسه.

سجل الخدمات الخارجية: الفواتير التي تظهر بعد خروج المورّد

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

هل ستعرف أن Production تعطّل بعد خروج الفريق؟

راجع ما يستخدمه المنتج فعليًا، ولا تضف أدوات لمجرد استكمال قائمة:

الحد الأدنى من التوثيق

كلمة «Documentation» في العقد ليست كافية. حدّد المستوى المتفق عليه. قد يشمل بحسب النطاق:

سجل المشكلات المعروفة والدين التقني

لا تجعل الفريق الجديد يكتشف بعد الاستلام ما كان الفريق السابق يعرفه بالفعل. اطلب سجلًا عمليًا يوضح — إن وُجدت عناصر معروفة:

اختبار القبول التقني قبل التوقيع

بدل سؤال «هل استلمنا الملفات؟»، اختبر المشروع كسلسلة تشغيل فعلية:

قائمة تحقق قبل التوقيع على العقد

قائمة تحقق يوم الاستلام

أسئلة متكررة

الخلاصة

الملكية ليست سؤالًا واحدًا. هي أربعة أسئلة تُحسم في مكانين مختلفين: العقد، ومحضر الاستلام.

العقد يحدد ما تملكه. الاستلام يحدد ما تستطيع فعله بما تملكه. والفجوة بينهما هي المكان الذي تعلق فيه أغلب المشاريع بعد انتهاء العلاقة مع المورّد.