من يملك الكود؟ دليل حقوق الملكية الفكرية لمؤسسي الشركات الناشئة

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

من يملك الكود افتراضياً، قبل وجود أي عقد؟

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

هل يجعل الدفع مقابل العمل الأمر تلقائياً 'عملاً مقابل أجر'؟

لا، ليس تلقائياً. مفهوم 'العمل مقابل أجر' (work for hire) مصطلح قانوني محدد، وقواعده تختلف كثيراً بين الأنظمة القانونية. في الولايات المتحدة مثلاً، ينطبق بوضوح على الموظفين، لكنه بالنسبة للمتعاقدين المستقلين ينحصر في قائمة ضيقة من فئات الأعمال المطلوبة تحديداً، وفقط عندما يوقّع الطرفان اتفاقاً مكتوباً يصف العمل صراحة بأنه 'work made for hire' قبل بدء العمل. غالباً ما تقع البرمجيات خارج هذه القائمة الضيقة أصلاً. كثير من الأنظمة القانونية الأخرى لا تعترف بهذا المفهوم بالشكل نفسه إطلاقاً، وتعتمد بدلاً منه على قواعد عامة لحقوق النشر والتنازل عنها. والخلاصة العملية واحدة في كل مكان: لا تعتمد على عبارة 'عمل مقابل أجر'، ولا على سداد الفاتورة. اعتمد على بند مكتوب وصريح.

ما البند الذي يجب على المؤسس تأكيده قبل بدء العمل؟

البند المطلوب هو بند التنازل عن الملكية الفكرية (IP assignment clause) — نص صريح ينقل جميع الحقوق والملكية والمصلحة في الكود والتصاميم والمخرجات المرتبطة به من المطوّر أو الوكالة إلى المؤسس أو شركته، عادة عند سداد كامل المبلغ. البند الجيد يحدد بوضوح ما الذي يتم التنازل عنه (الكود المصدري، الكود التنفيذي، التوثيق، التصاميم)، وينص على أن التنازل نهائي لا رجعة فيه، ويوضح موقف الأدوات أو المكتبات الجاهزة التي يستخدمها المطوّر ولا يملك حق التنازل عنها بالكامل. يجب الاتفاق على هذا البند وتوقيعه قبل بدء التطوير، لا التفاوض عليه بعد اكتمال المنتج حين تتغير موازين القوة. جملة غامضة مثل 'العميل يملك المنتج النهائي' ليست بديلاً عن بند تنازل صريح — اسأل مباشرة: هل تنتقل الملكية الفكرية، ومتى بالضبط؟

ماذا يتطلب امتلاك الكود فعلياً على أرض الواقع؟

الملكية القانونية تكاد تكون بلا معنى إن لم تصل يدك إلى ما تملكه. المؤسس الذي يملك كامل الحقوق الفكرية على الورق لكن دون وصول إلى المستودع البرمجي أو حساب الاستضافة أو خط النشر يبقى معتمداً بالكامل على المطوّر الذي بناه. امتلاك الكود عملياً يعني أن يكون لديك وصول بصلاحيات مدير كاملة إلى مستودع الكود المصدري، وبيئتي الإنتاج والاختبار، وإعدادات النطاق (DNS)، وأي خدمات خارجية يعتمد عليها التطبيق. وعد المطوّر بـ'إرسالها إن احتجت' ليس وصولاً — إنه اعتماد ما زلت تحمله. تأكد من الوصول مبكراً، لا في اللحظة التي تنتهي فيها العلاقة وقد يصبح التعاون أصعب.

كيف يبدو تسليم مشروع سليم؟

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

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