قرارداد توسعه نرم‌افزار صرفاً توافقی برای ساخت یک محصول با مبلغی مشخص نیست. اگر در قرارداد فقط نام پروژه، موضوع کلی و هزینه درج شود، بسیاری از مسائل مهم در طول همکاری بدون پاسخ می‌ماند. محدوده دقیق کار، مسئولیت هر طرف، زمان‌بندی، معیارهای تحویل و پذیرش، مالکیت کد منبع، نحوه دسترسی به مستندات، پشتیبانی و ضمانت اجرای تعهدات باید به‌روشنی تعیین شوند. تنظیم قرارداد نرم افزار با این جزئیات، امکان ارزیابی عملکرد و پیگیری حقوق طرفین را در صورت بروز اختلاف فراهم می‌کند.
برای شرکت‌های فناوری و تولیدی، ابهام در امکانات مورد انتظار می‌تواند به اختلاف درباره تکمیل یا ناقص بودن نرم‌افزار منجر شود. تأخیر در تحویل، نداشتن دسترسی کارفرما به کد منبع و نامشخص بودن حقوق برنامه‌نویس یا پیمانکار نیز از ریسک‌های رایج قرارداد پیمانکاری نرم افزار است. هرچه تعهدات و آثار عدم انجام آن‌ها دقیق‌تر نوشته شود، وابستگی به برداشت‌های متفاوت و مذاکرات فرسایشی کاهش می‌یابد.
بر اساس ماده ۱۰ قانون مدنی، قراردادهای خصوصی تا زمانی که مخالف صریح قانون نباشند معتبرند. همچنین مواد ۲۱۹ و ۲۲۰ قانون مدنی، طرفین را به مفاد قرارداد و آثار قانونی، عرفی و ناشی از مفاد آن ملتزم می‌دانند. بنابراین متن قرارداد باید متناسب با پروژه واقعی تنظیم شود. این مطلب اطلاع‌رسانی حقوقی عمومی است و جایگزین بررسی قرارداد یا مشاوره تخصصی درباره وضعیت واقعی طرفین نیست.
فهرست مطالب
تعریف دقیق پروژه، طرفین و تعهدات اجرایی
پیش از امضای قرارداد پیمانکاری نرم‌افزار، باید روشن باشد که دقیقاً چه چیزی قرار است ساخته شود، چه کسی مسئول هر تصمیم است و هر مرحله در چه زمانی باید به نتیجه برسد. ابهام در این سه موضوع معمولاً اختلاف درباره دامنه کار، تأخیر یا مسئولیت نقص خروجی را افزایش می‌دهد.
موضوع و محدوده دقیق نرم‌افزار
موضوع قرارداد را به نام کلی پروژه محدود نکنید. محصول، ماژول‌ها، قابلیت‌ها، فناوری‌های مورد استفاده، زیرساخت‌های لازم، نسخه‌های قابل تحویل و قالب هر خروجی باید مشخص شود. همچنین مواردی که عمداً خارج از تعهد مجری هستند، مانند پشتیبانی بلندمدت، تولید محتوای اختصاصی یا اتصال به سامانه‌های ثالث، صریحاً نوشته شوند. هر تغییر در دامنه نیز باید از مسیر تأیید کتبی عبور کند و اثر آن بر مبلغ، زمان و منابع پروژه ثبت شود.
نقش‌ها و مسئولیت‌های کارفرما و مجری
قرارداد باید مسئول ارائه نیازمندی‌ها، دسترسی‌ها و داده‌ها، شخص مجاز برای تأیید خروجی و شیوه گزارش‌دهی را تعیین کند. در شرکت نرم‌افزاری، رابطه کارفرما اصولاً با شرکت است، نه با هر برنامه‌نویس به‌صورت جداگانه. بنابراین باید مسئولیت شرکت، پیمانکار فرعی، مدیر پروژه و اعضای تیم در برابر کارفرما تفکیک شود. همکاری با برنامه‌نویس مستقل نیز با رابطه استخدامی یکسان نیست و متن قرارداد باید با واقعیت رابطه طرفین هماهنگ باشد. در تولید نرم‌افزار برای استخدام یا قرارداد، وضعیت حقوق مادی می‌تواند تحت تأثیر ماده ۶ قانون حمایت از حقوق پدیدآورندگان نرم‌افزارهای رایانه‌ای قرار گیرد، مگر آنکه توافق متفاوتی وجود داشته باشد.
زمان‌بندی، نقاط عطف و تغییرات پروژه
تاریخ شروع، مراحل اجرا، موعد هر خروجی و معیار عبور از هر نقطه عطف را جداگانه بنویسید. اگر انجام تعهدات به ارائه اطلاعات یا دسترسی از سوی کارفرما وابسته است، این وابستگی و آثار تأخیر آن مشخص شود. درخواست‌های تغییر نیز باید کتبی ثبت شوند تا زمان و تعهدات جدید قابل احراز باشند.
| بند قراردادی | ریسک ناشی از ابهام | اقدام پیشنهادی |
|---|---|---|
| موضوع و دامنه پروژه | اختلاف درباره خروجی‌های مورد انتظار | فهرست قابلیت‌ها، موارد خارج از تعهد و فرآیند تغییر را درج کنید. |
| نقش و مسئولیت طرفین | انتقال مسئولیت میان کارفرما، شرکت و برنامه‌نویس | مسئول تأیید، گزارش‌دهی و پاسخ‌گویی هر طرف را تعیین کنید. |
| زمان‌بندی و نقاط عطف | ادعای تأخیر یا تمدیدهای مورد اختلاف | موعدها، وابستگی‌ها و روش ثبت تغییرات را مکتوب کنید. |
مالکیت فکری، کد منبع و حقوق بهره‌برداری
در قرارداد توسعه نرم‌افزار، عبارت کلی «تمام حقوق متعلق به کارفرماست» به‌تنهایی برای مدیریت ریسک کافی نیست. باید روشن شود منظور از حق، مالکیت یا انتقال، دقیقاً کدام دارایی و کدام نوع اختیار است. کد منبع، مستندات فنی و حقوق مادی نرم‌افزار مفاهیم مرتبط اما جداگانه‌ای هستند.
مالکیت کد منبع و مستندات فنی
قرارداد باید کد منبع، طراحی رابط کاربری، ساختار پایگاه داده، اسکریپت‌ها، فایل‌های پیکربندی، مستندات تحلیل و طراحی، راهنمای نصب و راه‌اندازی و خروجی‌های میانی را به‌صورت مشخص شناسایی کند. همچنین باید زمان و شیوه تحویل تعیین شود. تحویل واقعی می‌تواند شامل انتقال مخزن کد، اطلاعات دسترسی، کلیدهای لازم، نسخه قابل استقرار و مستندات کافی برای ادامه توسعه باشد. صرف تحویل فایل اجرایی یا اعطای دسترسی موقت، معمولاً امکان نگهداری و توسعه مستقل نرم‌افزار را تضمین نمی‌کند.
وضعیت کدهای قبلی پیمانکار، کتابخانه‌های متن‌باز، ابزارهای دارای مجوز و اجزای متعلق به اشخاص ثالث نیز باید در پیوست قرارداد بیاید. در غیر این صورت، ممکن است کارفرما کدی را تحویل بگیرد که حق تغییر، واگذاری یا استفاده تجاری از آن محدود است.
انتقال حقوق مادی و حدود بهره‌برداری
مطابق قانون حمایت از حقوق پدیدآورندگان نرم‌افزارهای رایانه‌ای، حقوق مادی شامل استفاده، نشر، عرضه، اجرا، تکثیر و بهره‌برداری اقتصادی است و می‌تواند منتقل شود. بنابراین قرارداد باید مشخص کند کارفرما حق توسعه، تغییر، تکثیر، عرضه به مشتریان، واگذاری به شرکت‌های وابسته یا انتقال به اشخاص ثالث را دارد یا خیر.
مدت انتقال، قلمرو جغرافیایی، انحصاری یا غیرانحصاری بودن آن و هر محدودیت استفاده نیز باید صریح باشد. طبق ماده ۹ آیین‌نامه اجرایی، انتقال حقوق مادی می‌تواند برای مدت ۳۰ سال یا کمتر و با شرط یا بدون شرط انجام شود. ذکر نام پدیدآورنده نیز اصل است، مگر آنکه درباره آن توافق دیگری شده باشد.
حق معنوی پدیدآورنده و الزامات قانونی
حقوق معنوی با حقوق مادی یکسان نیست. ماده ۱ قانون، مدت حقوق مادی را ۳۰ سال و حقوق معنوی را نامحدود دانسته است. همچنین ماده ۴ آیین‌نامه، حق انتساب نرم‌افزار به پدیدآورنده را محدود به زمان و مکان نمی‌داند و آن را غیرقابل انتقال معرفی می‌کند. در مقابل، حقوق مادی قابل نقل‌وانتقال است. این تفکیک باید در بند انتساب، درج نام پدیدآورنده و اختیار تغییر یا توسعه نرم‌افزار منعکس شود.
نام، عنوان و نشانه ویژه نرم‌افزار نیز طبق ماده ۳ قانون حمایت می‌شود. قرارداد باید وضعیت استفاده از نام نرم‌افزار و برند آن را مشخص کند. همچنین پیش از استناد به ثبت یا تأییدیه فنی، باید وضعیت واقعی پروژه بررسی شود. مواد ۸ و ۹ قانون، تأییدیه فنی را پیش از ثبت نرم‌افزار مطرح می‌کنند و پیش از صدور آن، دعوای نقض حقوق مورد حمایت قابلیت استماع ندارد. ماده ۱۶ نیز دامنه حمایت را به موضوعاتی مرتبط می‌کند که برای نخستین‌بار در ایران تولید و توزیع شده‌اند. بنابراین، بررسی اجزای پروژه و سوابق تولید آن اهمیت دارد.
| نوع دارایی نرم‌افزاری | صاحب حق احتمالی | بند لازم در قرارداد |
|---|---|---|
| کد منبع و خروجی‌های میانی | پدیدآورنده یا کارفرما طبق قرارداد | زمان، شیوه تحویل و دسترسی فنی |
| مستندات، طراحی و پایگاه داده | ایجادکننده یا دارنده حقوق منتقل‌شده | انتقال، امکان تغییر و ادامه توسعه |
| کتابخانه‌ها و ابزارهای متن‌باز | دارنده مجوز یا شخص ثالث | ذکر مجوز و محدودیت‌های استفاده |
| نام، عنوان و نشانه نرم‌افزار | دارنده حق قانونی یا قراردادی | نحوه استفاده، تغییر و واگذاری برند |
محرمانگی، داده‌ها و امنیت اطلاعات
حفاظت از اطلاعات پروژه فقط با درج عبارت کلی «محرمانگی اطلاعات» تأمین نمی‌شود. در قرارداد باید مشخص شود چه اطلاعاتی محرمانه است، چه کسانی مجاز به دسترسی هستند و پیمانکار چگونه باید از اطلاعات نگهداری کند. این تعریف می‌تواند داده‌های مشتریان، اطلاعات تجاری، مستندات فنی، رمزهای عبور، کد منبع، اطلاعات کارکنان و داده‌هایی را دربرگیرد که برای توسعه یا آزمایش در اختیار پیمانکار قرار می‌گیرند.
تعریف اطلاعات محرمانه و دسترسی مجاز
مصادیق اطلاعات محرمانه، مانند فایل‌ها، حساب‌های کاربری، پایگاه‌های داده، اسناد محصول و اطلاعات مالی یا عملیاتی، باید تا حد امکان روشن نوشته شوند. در مقابل، اطلاعاتی که پیش‌تر عمومی بوده، بدون نقض قرارداد عمومی شده یا پیمانکار پیش از دریافت آن به‌طور مستقل در اختیار داشته است، می‌تواند در شمار استثناها قرار گیرد.
دسترسی نیز باید بر اساس نقش و نیاز کاری محدود شود، نه اینکه همه کارکنان یا پیمانکاران فرعی به کل محیط پروژه دسترسی داشته باشند. تعهدات کارکنان، پیمانکاران فرعی و اشخاص ثالث باید با تعهد اصلی پیمانکار هماهنگ شود. همچنین قرارداد باید مدت محرمانگی، روش نگهداری، نحوه اعلام رخداد امنیتی یا دسترسی غیرمجاز و الزام بازگرداندن یا حذف اطلاعات پس از پایان قرارداد را تعیین کند. ضمانت اجرای قرارداد باید روشن و متناسب باشد، اما دامنه تعهد نباید آن‌قدر مبهم تنظیم شود که تشخیص نقض آن دشوار شود.
تحویل، آزمون، پذیرش و پشتیبانی
معیارهای تحویل و پذیرش نرم‌افزار
در قرارداد توسعه نرم‌افزار، تحویل نباید صرفاً با ارسال یک فایل یا اعلام آماده‌بودن نسخه محقق تلقی شود. پیمانکار باید نسخه قابل‌آزمون را در محیط مشخص، همراه با اقلام تحویلی مانند کد منبع، مستندات فنی و کاربری، فایل‌های پیکربندی، اطلاعات استقرار، آموزش و دسترسی‌های مدیریتی ارائه کند. همچنین باید روشن باشد که کارفرما چه مدتی برای بررسی فرصت دارد و عدم انطباق را از چه طریق و با چه اطلاعاتی اعلام می‌کند.
پذیرش هر مرحله بهتر است به تست‌های پذیرش، نیازمندی‌های فنی و معیارهای تجاری قابل اثبات متصل باشد. عباراتی مانند «مورد تأیید کارفرما» یا «عملکرد مطلوب» بدون معیار سنجش، در زمان اختلاف راهنمای کافی ایجاد نمی‌کنند. در صورت اعلام ایراد، قرارداد باید مهلت اصلاح، نحوه ارائه نسخه اصلاح‌شده و فرآیند پذیرش مجدد را تعیین کند. آثار سکوت یا عدم اعلام نظر نیز باید صریح باشد و بدون توجه به ساختار پروژه، پذیرش خودکار فرض نشود.
| سطح خطا | نمونه اثر | مهلت اصلاح | اثر بر پذیرش |
|---|---|---|---|
| بحرانی | توقف سامانه یا از دسترس خارج شدن قابلیت اصلی | زمان مشخص و کوتاه طبق قرارداد | مانع پذیرش مرحله |
| عمده | اختلال جدی در یک قابلیت مهم | مهلت تعیین‌شده برای اصلاح | پذیرش منوط به اصلاح یا توافق مکتوب |
| جزئی | نقص محدود بدون اثر اساسی بر بهره‌برداری | در بازه نگهداری یا نسخه بعدی | معمولاً مانع پذیرش نیست، مگر خلاف آن توافق شود |
ارتباط میان پذیرش، پرداخت مرحله‌ای، انتقال حقوق مادی و تحویل نهایی نیز باید روشن و متناسب با پروژه تنظیم شود. برای نمونه، پرداخت هر مرحله می‌تواند به پذیرش همان مرحله و تحویل اقلام مشخص وابسته باشد، نه صرفاً گذشت زمان.
پشتیبانی، رفع خطا و نگهداری
قرارداد پشتیبانی نرم‌افزار باید مدت پشتیبانی، سطح خدمات، ساعات پاسخ‌گویی، زمان رفع هر سطح خطا، به‌روزرسانی و نگهداری را مشخص کند. پشتیبانی معمولاً برای حفظ عملکرد توافق‌شده است، نه ایجاد قابلیت‌های جدید. توسعه ویژگی تازه، تغییر اساسی در دامنه پروژه یا اصلاح ناشی از درخواست جدید کارفرما باید در قالب تغییر دامنه و توافق جداگانه بررسی شود.
پرداخت، تأخیر و ضمانت اجرای تعهدات
در قرارداد پیمانکاری نرم‌افزار، مبلغ قرارداد و زمان پرداخت باید به مراحل قابل سنجش، تحویل اقلام مشخص و پذیرش همان مرحله وابسته باشد. فاکتور، صورت‌وضعیت، مالیات و هزینه‌های مورد توافق نیز باید روشن شود. اگر بخشی از تحویل دارای ایراد باشد، قرارداد باید مشخص کند کارفرما حق دارد کل پرداخت را متوقف کند یا فقط مبلغ متناظر با بخش معیوب را تا زمان اصلاح نگه دارد.
وجه‌التزام و خسارت تأخیر در انجام تعهد
برای هر تعهد مهم، باید موضوع تعهد، موعد انجام، شیوه اعلام تخلف و اثر آن جداگانه تعیین شود. برای نمونه، تأخیر در تحویل نسخه قابل آزمون، عدم رفع خطای بحرانی در مهلت پشتیبانی، تحویل ندادن کد منبع یا استفاده غیرمجاز از دارایی فکری، ضمانت اجرای یکسانی ندارد.
خسارت، ناظر به زیانی است که از تخلف ایجاد شده و مطالبه آن به شرایط قرارداد، اثبات تخلف و رابطه میان تخلف و زیان بستگی دارد. در مقابل، وجه‌التزام مبلغی است که طرفین از پیش برای تخلف یا تأخیر تعیین می‌کنند. بر اساس ماده ۲۲۱ قانون مدنی، مسئولیت خسارت در صورت تخلف، به تصریح قراردادی، عرف یا حکم قانون وابسته است. مطابق ماده ۲۲۶، تعیین موعد یا مطالبه اجرای تعهد برای مطالبه خسارت اهمیت دارد. همچنین ماده ۲۳۰، در صورت تعیین وجه‌التزام، مبلغ توافق‌شده را مبنای محکومیت قرار می‌دهد. برای بررسی متن این مواد می‌توان به متن قانون مدنی مراجعه کرد.
وجه‌التزام مرحله‌ای، سقف مسئولیت، موارد معافیت، امکان تعلیق پرداخت یا خدمات و شرایط فسخ باید صریح باشد. تعلیق معمولاً برای فشار قراردادی و فرصت اصلاح تخلف به کار می‌رود، اما فسخ راهکاری شدیدتر است و باید برای تخلف‌های اساسی مانند عدم تحویل کد منبع یا نقض جدی محرمانگی پیش‌بینی شود.
| نوع تخلف | ضمانت اجرای پیشنهادی | نکته حقوقی |
|---|---|---|
| تأخیر در تحویل مرحله | وجه‌التزام روزانه یا مرحله‌ای | موعد و مبنای محاسبه باید دقیق باشد. |
| تحویل ناقص یا دارای ایراد | مهلت اصلاح، تعلیق پرداخت و خسارت | ایراد باید بر اساس معیار پذیرش قابل اثبات باشد. |
| عدم تحویل کد منبع | تعلیق پرداخت و حق فسخ در صورت استمرار | اقلام تحویلی و زمان انتقال باید مشخص شود. |
| نقض محرمانگی یا استفاده غیرمجاز از دارایی فکری | وجه‌التزام، جبران خسارت و فسخ در موارد اساسی | دامنه اطلاعات و مصادیق استفاده غیرمجاز را تعریف کنید. |
فسخ، حل اختلاف و اقدام پیش از امضا
چک‌لیست نهایی پیش از امضای قرارداد
پیش از امضای قرارداد توسعه نرم‌افزار، بندهای مربوط به دامنه پروژه، مسئولیت‌های طرفین، زمان‌بندی، مالکیت کد منبع، حقوق مادی و معنوی، محرمانگی اطلاعات، تحویل و پذیرش نرم‌افزار، پشتیبانی، پرداخت و ضمانت اجرای تعهدات را جداگانه بررسی کنید. هر عبارتی که معیار اجرایی، مهلت، مسئول مشخص یا شیوه اثبات ندارد، می‌تواند در زمان اختلاف مشکل‌ساز شود. پیوست‌های فنی، جدول زمان‌بندی، معیارهای پذیرش و وضعیت مالکیت فکری نیز باید پیش از امضا بررسی و جزء جدایی‌ناپذیر قرارداد شوند.
در بند پایان همکاری، موارد فسخ یا خاتمه، مهلت رفع تخلف، تکلیف پرداخت‌های انجام‌شده، تحویل کد منبع و سایر دارایی‌ها، بازگرداندن اطلاعات و ادامه تعهدات محرمانگی را روشن کنید. همچنین قانون حاکم، مرجع حل اختلاف، شیوه ابلاغ، امکان مذاکره یا سازوکار حل‌وفصل پیش از طرح دعوا و محل رسیدگی باید متناسب با وضعیت طرفین تعیین شود.
اعتبار و قابلیت اعمال هر بند به متن قرارداد، رابطه واقعی طرفین، نوع نرم‌افزار، نحوه تولید، نقش برنامه‌نویسان و اسناد قابل ارائه وابسته است. در پروژه‌های پیچیده، استفاده از خدمات تنظیم قرارداد نرم‌افزار و بررسی تخصصی پیوست‌ها پیش از امضا می‌تواند ابهام‌های پرهزینه را کاهش دهد. برای شروع مشاوره بدون مراجعه حضوری، امکان ثبت درخواست در سایت lawin.co یا سامانه آنلاین app.lawin.co وجود دارد. شرکت خدمات حقوقی لاوین، وابسته به گروه حقوقی داد و خرد، از طریق دپارتمان‌های تخصصی به تفکیک صنعت، خدمات مشاوره حقوقی تلفنی، آنلاین و حضوری، تنظیم قرارداد، بررسی اسناد و پذیرش وکالت و دفاع در مراجع قضایی را ارائه می‌کند و تضمین کیفیت خدمات بر عهده شرکت است.
دفتر تهران: نیاوران، خیابان عمار (میرانصاری)، نبش کوچه صابر، پلاک ۱۲، طبقه ۷
تلفن: ۰۲۱-۲۲۷۱۰۰۰۰
ساعات کار: شنبه تا چهارشنبه، ۹:۳۰ تا ۱۸:۰۰
پرسش‌های متداول درباره قرارداد توسعه نرم‌افزار
آیا قرارداد توسعه نرم‌افزار با برنامه‌نویس مستقل با قرارداد شرکت نرم‌افزاری تفاوت دارد؟
بله. در قرارداد با شرکت، مسئولیت اجرای پروژه، مدیریت تیم و عملکرد پیمانکاران فرعی معمولاً بر عهده شرکت است؛ اما در همکاری با برنامه‌نویس مستقل، مسئولیت‌ها مستقیماً متوجه همان شخص می‌شود. نوع رابطه، نحوه پرداخت، مالکیت خروجی، تعهدات محرمانگی و وضعیت استخدامی باید مطابق واقعیت همکاری تنظیم شود.
آیا استفاده از کتابخانه‌های متن‌باز در پروژه باید در قرارداد ذکر شود؟
بله. کتابخانه‌ها و ابزارهای متن‌باز ممکن است مجوزها و محدودیت‌های متفاوتی درباره تغییر، توزیع یا استفاده تجاری داشته باشند. پیمانکار باید فهرست اجزای شخص ثالث، نوع مجوز و تعهدات ناشی از آن را اعلام کند. همچنین قرارداد باید مسئولیت رعایت مجوزها و جبران خسارت ناشی از نقض آن‌ها را مشخص کند.
اگر کارفرما در مهلت تعیین‌شده درباره تحویل نرم‌افزار نظر ندهد، آیا پذیرش خودکار رخ می‌دهد؟
پذیرش خودکار فقط زمانی قابل استناد است که شرایط آن به‌صراحت در قرارداد تعیین شده باشد. قرارداد باید مهلت بررسی، شیوه اعلام ایراد، اطلاعات لازم برای رد خروجی و آثار سکوت کارفرما را مشخص کند. بهتر است پذیرش بر اساس معیارهای فنی و تجاری قابل سنجش انجام شود، نه صرفاً سکوت یا گذشت زمان.
درخواست قابلیت جدید در میانه پروژه چگونه باید ثبت شود؟
درخواست قابلیت جدید باید به‌عنوان تغییر دامنه، به‌صورت کتبی ثبت و از سوی اشخاص مجاز تأیید شود. شرح قابلیت، اثر آن بر زمان‌بندی، مبلغ، منابع، وابستگی‌های فنی و معیار پذیرش باید در یک الحاقیه یا صورت‌جلسه درج شود. اجرای تغییر بدون ثبت آثار آن، احتمال اختلاف درباره هزینه و موعد تحویل را افزایش می‌دهد.
آیا پرداخت کامل مبلغ قرارداد پیش از تحویل کد منبع منطقی است؟
این موضوع به ساختار پروژه و قدرت قراردادی طرفین بستگی دارد، اما پرداخت مرحله‌ای معمولاً امکان کنترل بیشتری ایجاد می‌کند. بهتر است پرداخت‌ها به تحویل اقلام مشخص، پذیرش هر مرحله و انتقال دسترسی‌های لازم وابسته شوند. قرارداد همچنین باید تکلیف پرداخت در صورت تحویل ناقص، وجود ایراد یا تأخیر در ارائه کد منبع را روشن کند.
