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

ملكية الكود المصدري
عبدالله سنكر
تدفع آخر دفعة، وتستلم التطبيق، وتحس إنه صار ملكك. بعد سنة تبي تطوّره مع مبرمج ثاني، وتكتشف إن حساب المتجر باسم المنفّذ القديم، والكود في مستودعه هو، والعقد ما يذكر الملكية بكلمة. عبدالله سنكر يشوف إن أغلب نزاعات ما بعد المشروع تبدأ من افتراضات ما انكتبت. هذي ست خرافات شائعة عن ملكية الكود، والحقيقة وراء كل وحدة. وقبل نبدأ: هذا شرح عام من منظور مبرمج، مو استشارة قانونية، والأنظمة تختلف من بلد لبلد.
الخرافة الأولى: «دفعت، إذن الكود ملكي تلقائياً»
الدفع مقابل الخدمة ما يعني دائماً نقل الملكية الفكرية. في أنظمة كثيرة، حقوق المؤلف على العمل تبدأ عند اللي أنشأه، ما لم يُتفق كتابياً على غير ذلك، والكود عمل مكتوب. يعني بدون بند واضح، ممكن تكون دفعت مقابل «استخدام» الكود مو مقابل ملكيته. الحل بسيط: بند صريح يقول إن حقوق الكود الخاص بالمشروع تنتقل لك عند سداد كامل المستحقات. والربط بالسداد عادل للطرفين: أنت تضمن الملكية، والمنفّذ يضمن حقه. وفكّر كمان في السيناريو الأصعب: لو انتهى التعاون في نص المشروع، وش تملك من الشغل اللي دفعت عليه؟ الصياغة الواضحة تقول إن كل مرحلة مدفوعة تنتقل حقوقها لك، بدل ما تعلق الملكية كلها على آخر دفعة ما بتصير.
الخرافة الثانية: «ملكية الكود تعني ملكية كل سطر فيه»
أي مشروع حديث يعتمد على مكتبات مفتوحة المصدر: حزم Flutter، ومكتبات npm في مشاريع Next.js، وغيرها. هذي المكتبات ما تصير ملكك، تستخدمها حسب رخصتها. والرخص مو كلها نفس الشي:
- رخص متساهلة مثل MIT و Apache 2.0: تسمح بالاستخدام التجاري والتعديل، بشرط الإبقاء على إشعار الحقوق والرخصة.
- رخص بشرط المشاركة مثل GPL: لو وزّعت برنامج مبني عليها، ممكن تلتزم بنشر كودك بنفس الرخصة. هذي تحتاج انتباه في المنتجات التجارية.
- مكتبات تجارية مدفوعة: لها اتفاقية ترخيص، وأحياناً الرخصة باسم المنفّذ مو باسمك.
اطلب قائمة بالمكتبات الأساسية ورخصها مع التسليم. طلب بسيط، ويكشف لك أي التزام مخفي قبل ما يصير مشكلة. ونفس المنطق ينطبق على غير الكود: الخطوط لها رخص، وبعض الخطوط المدفوعة رخصة الويب فيها غير رخصة تضمينها داخل تطبيق جوال. والصور من مواقع الصور المدفوعة مرخّصة لمن اشتراها، فإذا اشتراها المنفّذ باسمه، تأكد إن الترخيص يغطي استخدامك أنت تجارياً.
الخرافة الثالثة: «المنفّذ ما يحق له يستخدم أي شي من مشروعي»
المنفّذ المحترف عنده أدوات ومكوّنات عامة يستخدمها في كل مشاريعه: نظام تسجيل دخول، أو مكوّن جداول، أو إعدادات نشر جاهزة. هذي اللي يسمونها الملكية السابقة، وهي جزء من سبب إن شغله أسرع وأرخص. الطلب المعقول مو إنك تملكها، بل إنك تحصل على ترخيص دائم ومجاني لاستخدامها داخل مشروعك. أما منطق عملك الخاص، وتصميمك، وبيانات عملائك، فهذي لك بوضوح. التمييز هذا يحمي الطرفين: أنت ما تخاف إنه يبيع فكرتك، وهو ما يخسر أدواته.
الخرافة الرابعة: «إذا عندي الكود، عندي كل شي»
الكود بدون الحسابات مثل مفتاح بيت ما تملكه. المشروع الرقمي يعيش على حسابات كثيرة، وكل وحدة منها لازم تكون باسمك أو باسم منشأتك:
- الدومين، لأنه هويتك، واستعادته من شخص ثاني ممكن تكون متعبة.
- حساب مطوّر آبل وحساب Google Play Console. نقل تطبيق منشور بين حسابات ممكن، بس له شروط وإجراءات، والأسهل إنه ينشر من حسابك من أول يوم.
- الاستضافة وقاعدة البيانات ومشروع Firebase أو Supabase.
- بوابة الدفع وخدمة البريد والرسائل، لأن الفلوس والعملاء يمرون منها.
المنفّذ ياخذ صلاحية على حساباتك أثناء المشروع، وتسحبها بعد التسليم. هذا الترتيب الصحيح، مو العكس. وانتبه إن حساب مطوّر آبل للمنشآت يحتاج رقم D-U-N-S للمنشأة، وتجهيزه ياخذ وقت، فابدأ فيه بدري بدل ما يصير هو اللي يأخّر النشر ويخلّيك تقبل إن التطبيق ينزل من حساب المنفّذ «مؤقتاً». المؤقت في هالحالات غالباً يصير دائم.
الخرافة الخامسة: «يرسل لي الكود في الآخر»
ملف مضغوط يوصلك يوم التسليم أفضل من لا شي، بس ما يكفي. المستودع اللي على GitHub أو غيره يكون تحت حسابك أو منظمتك من البداية، والمنفّذ مضاف عليه كمساهم. بهالطريقة تشوف التقدم أول بأول، وعندك تاريخ كل تعديل، ولو تعثرت العلاقة لأي سبب، ما تبدأ من الصفر ولا تنتظر أحد يرسل لك شي.
الخرافة السادسة: «اتفاقية السرية تحمي ملكيتي»
اتفاقية عدم الإفصاح تمنع المنفّذ من كشف معلوماتك، بس ما تقول مين يملك الكود. هذا موضوع وذاك موضوع. تحتاج الاثنين: بند سرية للمعلومات والبيانات، وبند ملكية للكود والتصميم. ولا تكتفِ بإن واحد منهم «يغطي» الثاني.
وعشان تحوّل الخرافات الست إلى شي عملي، هذي خمس جمل تتأكد إن معناها موجود في عقدك، بأي صياغة كانت:
- حقوق الكود والتصميم الخاص بالمشروع تنتقل للعميل عند سداد كامل المستحقات.
- المكوّنات العامة السابقة للمنفّذ تبقى له، مع ترخيص دائم للعميل لاستخدامها في المشروع.
- المستودع والحسابات باسم العميل، ويتم تسليم كل صلاحيات الإدارة عند الانتهاء.
- قائمة بالمكتبات الأساسية ورخصها جزء من التسليم.
- بند سرية مستقل يغطي البيانات والمعلومات التجارية.
في منصة أزهل الرقمية، يمشي عبدالله عبدالرحيم بن سنكر الكندي على قاعدة إن العميل يملك مشروعه وحساباته من أول يوم، لأن الثقة اللي تعتمد على حسن النية بس تنكسر عند أول خلاف. وللمشاريع الكبيرة أو اللي فيها شركاء أو استثمار، خذ هالقائمة لمحامي يصيغها حسب نظام بلدك. الخرافات تكلّف أكثر بكثير من ساعة استشارة.
عندك فكرة؟ الاستشارة الأولى علينا
كلّم عبدالله مباشرة على واتساب — رسالتك توصل له هو، مو لرد آلي. نسمع فكرتك ونقول لك وش تحتاج وكم تكلّف، ببلاش.
مقالات ذات صلة
كل المقالات
ربط بوابة دفع
عبدالله عبدالرحيم سنكر
رحلة الدفع خطوة بخطوة: عبدالله عبدالرحيم سنكر يشرح ربط مدى و Apple Pay
عبدالله عبدالرحيم سنكر يشرح رحلة الدفع في التطبيقات السعودية خطوة بخطوة: مدى و Apple Pay وبوابة الدفع، والتحقق 3-D Secure، والـ webhook، والاسترداد والفاتورة.
اقرأ المقال
تقييم الذكاء الاصطناعي
عبدالله عبدالرحيم بن سنكر
تقييم مخرجات الذكاء الاصطناعي Evals مع عبدالله عبدالرحيم بن سنكر
عبدالله عبدالرحيم بن سنكر يشرح تقييمات Evals لأنظمة الذكاء الاصطناعي: من وين تجيب الحالات، وكيف تحكم على الجواب بالكود أو بنموذج مقيّم، وكيف تتأكد إن تعديلك حسّن النظام.
اقرأ المقال
تحليل المنافسين بالذكاء الاصطناعي
عبدالله سنكر
تحليل المنافسين بالذكاء الاصطناعي: عبدالله سنكر من جمع البيانات إلى القرار
عبدالله سنكر يشرح مراحل نظام آلي لتحليل المنافسين: وش تراقب، وكيف تجمع البيانات العامة بشكل نظامي، وليش النموذج يقرأ الفرق مو الصفحة، وكيف يتحول التقرير إلى قرار.
اقرأ المقال