الخلاصة السريعة
أخطر بند في عقود البرمجة هو البند الغائب لا المكتوب. أهم ثلاثة: ملكية الشيفرة المصدرية بنصّ صريح — لأن غياب النصّ يعني عادةً بقاء الحقوق مع من كتبها لا مع من دفع؛ والحسابات باسم من — النطاق والاستضافة وحساب المتجر؛ ومعايير القبول — كيف نعرف أن التسليم «تمّ» بلا خلاف. هذا المقال شرح عملي لصاحب المشروع، وليس استشارة قانونية — استعن بمحامٍ للصياغة النهائية.
البنود الاثنا عشر
| # | البند | ما يحميك منه |
|---|---|---|
| 1 | نطاق العمل المكتوب — بقائمة بما سيُنفَّذ وما لن يُنفَّذ | «ظننت أنها ضمن السعر» — أكثر خلاف يتكرّر |
| 2 | ملكية الشيفرة المصدرية بنقل حقوق صريح لك | اكتشاف أنك تملك تطبيقاً ولا تملك كوده |
| 3 | الحسابات باسمك: النطاق، الاستضافة، المتجر، القاعدة | أن يصير منتجك رهينة عند أي خلاف |
| 4 | الدفعات مرتبطة بتسليمات لا بالتواريخ وحدها | الدفع مقابل وقت مضى بلا نتيجة |
| 5 | معايير القبول — كيف يُختبر التسليم ومن يوافق | «خلصنا» مقابل «لم تخلصوا» بلا مرجع |
| 6 | مدة الضمان بعد الإطلاق وما يشمله | الدفع مرّتين لإصلاح عطل أصلي |
| 7 | آلية طلبات التغيير وسعرها | تضخّم النطاق الصامت من الطرفين |
| 8 | التسليم والتوثيق: ما الذي يُسلَّم حرفياً | تسليم «تطبيق» بلا ما يشغّله |
| 9 | السرّية وحماية بيانات عملائك | تسرّب بيانات لا تعرف مسؤوليته |
| 10 | حق ذكر المشروع في أعمال المنفّذ — أو منعه | مفاجأة بظهور مشروعك علناً قبل إطلاقه |
| 11 | الإنهاء المبكر: ماذا يحدث للمدفوع والمنجَز | خسارة كل شيء عند التوقّف |
| 12 | تسوية الخلاف ومرجعيته | خلاف بلا مسار واضح |
البند الأهم: ملكية الكود
كثير من أصحاب المشاريع يفترضون أن الدفع يعني التملّك تلقائياً. هذا افتراض خطر. القاعدة العامة في حقوق المؤلف أن الحقوق تنشأ لمن أنشأ العمل، وانتقالها للعميل يحتاج نصّاً صريحاً في العقد. بلا هذا النصّ قد تجد نفسك تملك نسخة تعمل ولا تملك حق تعديلها أو نقلها لمطوّر آخر.
والملكية أوسع من «الكود» بكلمة واحدة. اذكرها صراحةً:
- الشيفرة المصدرية وسجلّ التغييرات في مستودع تملكه.
- ملفات التصميم القابلة للتعديل، لا الصور المصدَّرة فقط.
- حسابات المتاجر والنطاق والاستضافة وقاعدة البيانات.
- المفاتيح والأسرار، مع التزام بتدويرها عند التسليم.
- حق التعديل والاشتقاق ونقل العمل لطرف آخر بلا إذن.
استثناء عادل يجب أن تقبله: المنفّذ قد يحتفظ بحق استخدام مكوّناته العامة التي بناها قبلك ويستخدمها مع غيرك. هذا مشروع ومعقول — المهم أن يُذكر بوضوح، وألا يشمل ما بُني خصيصاً لك.
الدفعات: اربطها بالتسليم لا بالتاريخ
| الدفعة | مقابل ماذا | نسبة معتادة |
|---|---|---|
| الأولى | بدء العمل ونطاق مكتوب معتمد | 25 – 30٪ |
| الثانية | تصميم معتمد قابل للتجربة | 20 – 25٪ |
| الثالثة | نسخة تجريبية تعمل تجرّبها بنفسك | 25 – 30٪ |
| الأخيرة | الإطلاق والتسليم الكامل والتوثيق | 20 – 25٪ |
الدفعة الأخيرة بعد التسليم لا قبله. ودفع 100٪ مقدماً ليس ثقة بل مخاطرة بلا مقابل.
معايير القبول — البند الذي ينهي أغلب الخلافات
«تم التسليم» جملة تحتمل تفسيرين. اجعلها قابلة للقياس: التطبيق يعمل على أجهزة محدّدة بأسمائها، والوظائف المذكورة في النطاق تُنفَّذ بنجاح في اختبار يحضره الطرفان، ومدّة مراجعة محدّدة (خمسة أيام مثلاً) تُبلَّغ فيها الملاحظات وإلا اعتُبر التسليم مقبولاً. هذه الفقرة الأخيرة تحمي الطرفين معاً — تحميك من تسليم ناقص، وتحمي المنفّذ من مراجعة بلا نهاية.
نعمل بعقد ونطاق مكتوب في كل مشروع، وتفصيل ذلك في الأنظمة الإدارية المخصّصة وشركة برمجة في الرياض. ولو كنت في مرحلة اختيار المنفّذ أصلاً، فالمقارنة بين الشركة والمستقل في مقال منفصل.
تنبيه: هذا شرح عملي لأصحاب المشاريع وليس استشارة قانونية. اعرض الصياغة النهائية على محامٍ، خصوصاً في بنود الملكية والمسؤولية وتسوية الخلاف.
