يقوم مكتب MKB Juristen بصياغة المستندات القانونية المخصصة
من الأفضل عدم تجميع أو نسخ العقود والشروط والأحكام المهمة، وغيرها من المستندات القانونية بنفسك. نحن نساعد رواد الأعمال ذوي الميزانية المحدودة من خلال حلول قانونية مصممة خصيصًا لهم، وتكاليف واضحة مسبقًا، وشروحات عملية.
- العقود المخصصة، والشروط والأحكام، والوثائق القانونية
- مناسب للميزانية وواضح بشأن التكاليف مقدماً
- اطلب استشارة مجانية أو عرض سعر بدون أي التزام
صياغة الشروط والأحكام العامة لشركة برمجيات تعني وضع القواعد المتعلقة بالتطوير والتسليم والقبول والملكية الفكرية والصيانة والأعمال الإضافية والمسؤولية والدفع. على عكس خدمة البرمجيات كخدمة (SaaS)، فإن هذا الأمر يتمحور حول عملية التطوير وملكية الكود، وليس حول الوصول إلى منصة إلكترونية. فيما يلي، لكل قسم، نوضح ما يجب تضمينه، والقواعد القانونية المطبقة، والأخطاء الشائعة التي يقع فيها مطورو البرمجيات.
الإجابة المختصرة
- الملكية الفكرية والترخيص: تنظيم من يحصل على حقوق شفرة المصدر وبموجب أي ترخيص يستخدم العميل البرنامج.
- التطوير والتسليم: أسلوب العمل، والمراحل الرئيسية، وتواريخ التسليم، وتعريف "الانتهاء".
- القبول: فترة الاختبار، والمعايير، ومتى يُعتبر البرنامج مقبولاً.
- عمل إضافي: كيفية ترتيب الطلبات الخارجة عن نطاق العمل وإصدار فواتيرها.
- المسؤولية واتفاقية مستوى الخدمة: الحد الأقصى، الأضرار المستثناة، الصيانة، وأوقات الاستجابة.
- الدفع: إصدار الفواتير لكل مرحلة، والأقساط، وحق التعليق.
الملكية الفكرية والترخيص
هذا هو الجزء الأهم والأكثر استهانةً. منشئ الكود المصدري يمتلك حقوق الملكية الفكرية من حيث المبدأ (المادة 1 من قانون حقوق المؤلف). بالنسبة للمطور، هذا يعني أنه ما لم يُتفق على خلاف ذلك، فإنه يظل مالك الكود - حتى لو دفع العميل ثمنه.
اختر بوعي بين النموذجين:
- الترخيص. تحتفظ بحقوق الملكية الفكرية وتمنح العميل حق الاستخدام. الميزة: يمكنك إعادة استخدام (أجزاء من) الكود لعملاء آخرين. حدد نطاق الترخيص: حصري أم لا، قابل للتحويل أم لا، ولمن يُستخدم.
- نقل الحقوق. يرغب العميل في الحصول على الحقوق الكاملة. هذا ممكن، لكن نقل حقوق التأليف والنشر يتطلب سندًا (المادة 2، الفقرة 2 من قانون حقوق التأليف والنشر) - جملة واحدة في الشروط والأحكام لا تكفي دائمًا. عمومًا، يُطلب سعر أعلى مقابل ذلك.
لا تنس المكونات مفتوحة المصدر: اذكر أن البرنامج قد يحتوي على مكتبات تابعة لجهات خارجية بشروط ترخيص خاصة بها.
التطوير والتسليم والقبول
تطوير البرمجيات عملية تتضمن لحظات يُعتبر فيها شيء ما "مكتملاً". وبدون سياسة قبول واضحة، يبقى من غير الواضح متى تم التسليم، وبالتالي متى يُمكن إصدار الفاتورة. الوثيقة:
- المنهجية والمعالم الرئيسية. التسليم على مراحل (على سبيل المثال، لكل وحدة أو دورة تطوير) مع تحديد مواعيد تسليم واضحة.
- اختبار القبول. يقوم العميل بالاختبار وفقًا لمعايير متفق عليها مسبقًا خلال فترة زمنية محددة (على سبيل المثال، 10 أيام عمل).
- القبول الصوري. إذا لم يستجب العميل خلال المهلة المحددة، أو لم يستخدم البرنامج استخدامًا فعليًا، يُعتبر ذلك قبولًا. وبدون هذا البند، يبقى العميل "غير راضٍ" إلى أجل غير مسمى.
- إصلاح العيوب. فقط أوجه القصور التي تؤثر على الوظائف المتفق عليها تمنع القبول - أما النقاط التجميلية فلا تمنع ذلك.
أعمال إضافية
تتطور معظم مشاريع البرمجيات أثناء التطوير. يطرح العميل متطلبات جديدة، ويتغير نطاق المشروع. وبدون بندٍ يُعنى بالأعمال الإضافية، ستُنفذ هذه الأعمال مجانًا أو ستنشأ نزاعات حول الفاتورة. لذا، يُنصح بالاتفاق على ما يلي:
- يُعتبر هذا العمل الذي يقع خارج نطاق المهمة الأصلية عملاً إضافياً.
- يتم تأكيد هذا العمل الإضافي كتابياً (أو عبر البريد الإلكتروني) مسبقاً.
- بأي معدل أو طريقة يتم احتساب العمل الإضافي بالساعة؟.
- قد يؤدي هذا العمل الإضافي إلى تغيير مواعيد التسليم الأصلية.
المسؤولية والضمان
يحتوي البرنامج على أخطاء، وهذه حقيقة تقنية، وليست خرقًا للعقد. مع ذلك، قد يتسبب وجود خلل برمجي في إلحاق الضرر بالعميل. قلل من هذا الخطر:
- الحد الأقصى. تحديد المسؤولية، على سبيل المثال، بقيمة العقد أو قيمة الفاتورة خلال الفترة الأخيرة.
- لا يشمل ذلك الأضرار اللاحقة. ولا يشمل الأضرار غير المباشرة: خسارة الأرباح، خسارة الإيرادات، فقدان البيانات، الإضرار بالسمعة.
- فترة الضمان. نقدم خدمة إصلاح مجانية للعيوب التي تندرج ضمن الوظائف المتفق عليها لفترة محددة.
- الحدود. يرجى الملاحظة: لا يمكنك استبعاد المسؤولية عن النية أو التهور المتعمد (المادة 6:233 من القانون المدني الألماني).
الصيانة، اتفاقية مستوى الخدمة، والدفع
إذا كانت شركتك تقدم خدمات الصيانة أيضاً، فيجب تضمين إطار عمل اتفاقية مستوى الخدمة (SLA) في الشروط والأحكام أو في اتفاقية صيانة منفصلة:
- أوقات الاستجابة حسب الأولوية (على سبيل المثال، الفشل الحرج في غضون 4 ساعات).
- فترات التوافر والصيانة.
- ما الذي يندرج وما الذي لا يندرج تحت الصيانة (التحديثات مقابل الوظائف الجديدة).
- التكاليف: اشتراك صيانة ثابت أو بالساعة.
لأغراض الدفع: قم بإصدار فاتورة لكل مرحلة أو معلم، وحدد مدة الدفع (على سبيل المثال، 14 يومًا)، وقم بتضمين حق التعليق - في حالة عدم الدفع، يمكنك إيقاف العمل وتقييد الوصول إلى البرامج المسلمة حتى يتم استلام الدفع.
مثال عملي
يقوم مطور برامج ببناء نظام تخطيط مخصص لشركة تركيبات. في منتصف المشروع، يرغب العميل في إضافة روابط إلى نظامين خارجيين. ولأن الشروط والأحكام تتضمن بندًا خاصًا بالأعمال الإضافية، يتم تقديم عرض سعر وفاتورة منفصلة، ويتم تعديل تاريخ التسليم تبعًا لذلك. عند التسليم، يختبر العميل النظام لمدة عشرة أيام عمل؛ وبعد الموافقة - أو عند التشغيل - يُعتبر النظام مقبولًا، وتُصدر الفاتورة النهائية. تبقى حقوق الملكية الفكرية للمطور، ويحصل العميل على ترخيص استخدام. يمنع وجود مجموعة واحدة من الشروط والأحكام ثلاثة تعارضات محتملة في هذه الحالة.
توصية صادقة
صمّم الشروط والأحكام بما يتناسب مع مشروعك. إذا كنت تُطوّر حلولًا مُخصصة، فإنّ بنود الملكية الفكرية والقبول وأحكام العمل الإضافي تُشكّل جوهر النظام - لا تنسخ شروط وأحكام برامج SaaS التي تُغطي الاشتراكات. تكمن أكبر المخاطر في المسؤولية غير المحدودة وغياب آلية قبول فعّالة.
متى لا تحتاج إلى محامٍ؟ بالنسبة للمهام البسيطة والمتكررة وذات المخاطر المنخفضة، يكفي استخدام نموذج جاهز، شريطة تعديله ليناسب أساليب عملك وإرساله مع عرض السعر. أما عندما تكبر المهام، أو تعيد استخدام التعليمات البرمجية، أو يفرض العملاء شروطهم وأحكامهم الخاصة، يُنصح بالاستعانة بمراجعة قانونية، إذ قد يكون لبند واحد غير مُصاغ بشكل جيد يتعلق بالملكية الفكرية أو المسؤولية تكلفة باهظة.
اقرأ المزيد وقم بالترتيب: ما هي الشروط والأحكام العامة لشركة برمجيات، وقمت بصياغتها: التكاليف والعملية ، والشروط والأحكام العامة لشركة برمجيات.
الأسئلة الشائعة
تتضمن الأحكام المتعلقة بالملكية الفكرية وترخيص شفرة المصدر، والتطوير والتسليم، والقبول، والأعمال الإضافية، والصيانة، واتفاقية مستوى الخدمة، والمسؤولية المحدودة، والدفع لكل مرحلة. أما بالنسبة للأعمال المخصصة، فتُعدّ أحكام الملكية الفكرية والقبول والأعمال الإضافية هي الأهم.
ما لم يُتفق على خلاف ذلك، يحتفظ المطور بحقوق الملكية الفكرية (المادة 1 من قانون حقوق المؤلف)، حتى لو دفع العميل. اختر بحكمة: الترخيص (حيث تحتفظ أنت بحقوق الملكية الفكرية، ويحصل العميل على حق الاستخدام) أو التنازل (حيث يحصل العميل على جميع الحقوق بموجب سند، المادة 2 الفقرة 2 من قانون حقوق المؤلف). دوّن اختيارك في الشروط والأحكام.
اتفاقية تحدد كيفية اختبار العميل للبرنامج والمدة الزمنية اللازمة لذلك، ومتى يُعتبر البرنامج مقبولاً. تتضمن الاتفاقية بند قبول افتراضي: إذا لم يستجب العميل خلال المدة المحددة أو لم يبدأ باستخدام البرنامج، يُعتبر البرنامج مقبولاً. وإلا، فلن تتمكن من تسليم البرنامج وإصدار الفاتورة بشكل نهائي.
اشترط أن الطلبات الخارجة عن نطاق المهمة الأصلية تُعتبر عملاً إضافياً، وأن هذا العمل الإضافي يجب تأكيده كتابياً مسبقاً، مع توضيح الأجر المُحتسب، وأنه قد يؤدي إلى تغيير مواعيد التسليم. بدون هذا الشرط، فإنك تُجري فعلياً توسيعاً لنطاق العمل مجاناً.
يجب تحديد المسؤولية، على سبيل المثال، بقيمة العقد، واستبعاد الأضرار غير المباشرة (كفقدان الأرباح أو البيانات)، وتقديم فترة ضمان لإصلاح العيوب مجانًا. ملاحظة: لا يجوز استبعاد المسؤولية عن القصد أو الإهمال الجسيم (المادة 6:233 من القانون المدني الألماني).
إذا كنتَ تُقدّم خدمات الصيانة، نعم. يجب أن تشمل هذه الشروط أوقات الاستجابة حسب الأولوية، ومدى التوافر، وفترات الصيانة، ونطاقها (التحديثات مقابل الوظائف الجديدة). يُمكن تضمين ذلك في بنود وشروط الخدمة نفسها، أو في اتفاقية صيانة منفصلة تُشير إليها بنود وشروط الخدمة.
لا. تتعلق شروط وأحكام برامج SaaS بالوصول إلى خدمة قائمة (الاشتراك، ووقت التشغيل، والإلغاء) وتغفل جوهر عملية التطوير: ملكية شفرة المصدر، والقبول، والعمل الإضافي. أما بالنسبة للتطوير المخصص، فأنت بحاجة إلى شروط وأحكام مصممة خصيصًا لعملية التطوير.
