توضیحات
رویای داشتن یک برنامه اختصاصی روی گوشیهای هوشمند، اغلب با کابوس «مالکیت کدهای منبع» (سورس کد) به پایان میرسد. برنامهنویسان تمایل دارند فقط نسخه اجرایی برنامه را تحویل دهند و کدهای اصلی را نزد خود نگه دارند تا کارفرما برای هر تغییر کوچکی در آینده، محتاج آنها باشد. در قرارداد ساخت نرمافزار، باید به صراحت قید شود که مالکیت تمام و کمال کدهای منبع، مستندات فنی و طرحهای گرافیکی متعلق به کارفرماست و پیمانکار حق استفاده مجدد از آنها را برای مشتریان دیگر ندارد. گلوگاه فنی دیگر، «تضمین انتشار» در فروشگاههای نرمافزاری رسمی است؛ اگر برنامه توسط بازارهای جهانی یا داخلی به دلایل فنی یا امنیتی رد شود، مسئولیت اصلاح و دریافت تاییدیه با کیست؟ قرارداد باید پرداخت مرحله نهایی (حسن انجام کار) را منوط به انتشار موفقیتآمیز و کارکرد صحیح برنامه روی طیف مشخصی از گوشیها (قدیمی و جدید) کند تا کارفرما صاحب نرمافزاری بلااستفاده نشود.
دانلود نمونه قرارداد طراحی اپلیکیشن
این قرارداد بین طراح اپلیکیشن و شخصی که می خواهد اپلیکیشنی برای او طراحی و ساخته شود منعقد خواهد شد. در این قرارداد طراح واقعی اپلیکیشن پیمانکار تلقی می شود و درخواست کننده ساخت اپلیکیشن کارفرما خواهد بود. کارفرما و پیمانکار با انعقاد نمونه قرارداد توسعه اپلیکیشن موبایل، متعهد می شوند که با توجه به موضوع قرارداد با یکدیگر همکاری کرده و مسئولیت هایی را که بر عهده گرفته اند انجام دهند. در ادامه این مقاله قرارداد طراحی اپلیکیشن موبایل را به تفصیل توضیح خواهیم داد.
اهمیت قرارداد طراحی اپلیکیشن
- تعیین دقیق پروژه: قرارداد به طور دقیق مشخص میکند که چه ویژگیها و عملکردهایی باید در اپلیکیشن گنجانده شود.
- تعریف زمانبندی: تاریخ شروع و پایان پروژه، مراحل مختلف توسعه و زمان تحویل نهایی اپلیکیشن در قرارداد مشخص میشود.
- تعیین هزینهها: هزینههای توسعه، پشتیبانی و نگهداری اپلیکیشن به صورت واضح در قرارداد ذکر میشود.
- تعیین مالکیت: مالکیت معنوی اپلیکیشن (مانند کپیرایت، حق اختراع) و کدهای منبع آن در قرارداد مشخص میشود.
- حل اختلافات: روش حل اختلافات احتمالی بین طرفین در قرارداد ذکر میشود.
نکات مهم در قرارداد طراحی اپلیکیشن
- تعریف دقیق محصول: ویژگیها، عملکردها، پلتفرمهای هدف (اندروید، iOS، وب) و طراحی رابط کاربری اپلیکیشن باید به طور دقیق مشخص شود.
- زمانبندی پروژه: جدول زمانی پروژه با ذکر تاریخ شروع و پایان هر مرحله باید در قرارداد گنجانده شود.
- هزینهها: هزینههای توسعه، پشتیبانی، نگهداری و هر هزینه اضافی دیگری باید به صورت شفاف مشخص شود.
- پرداختها: نحوه پرداخت هزینهها (یکجا، اقساطی و…) و زمان پرداخت هر قسط باید مشخص شود.
- مالکیت معنوی: مالکیت معنوی اپلیکیشن و کدهای منبع آن باید به طور واضح مشخص شود.
- محرمانگی: اطلاعات محرمانه هر یک از طرفین باید محافظت شود.
- شرایط فسخ قرارداد: شرایط فسخ قرارداد توسط هر یک از طرفین باید مشخص شود.
- مسئولیتها: مسئولیت هر یک از طرفین در قبال بروز مشکلات یا تأخیر در پروژه باید مشخص شود.
- تست و تحویل: مراحل تست و تحویل اپلیکیشن و معیارهای پذیرش آن باید مشخص شود.
- پشتیبانی: مدت زمان و نوع پشتیبانی پس از تحویل اپلیکیشن باید مشخص شود.
در جدول زیر، موارد مهم از نمونه قرارداد طراحی اپلیکیشن ذکر شده است:
| عنوان | توضیحات |
|---|---|
| تعریف پروژه | شامل ویژگیها، پلتفرمها و عملکردهای اپلیکیشن |
| زمانبندی | تاریخ شروع، پایان و فازهای مختلف پروژه |
| هزینهها | مبلغ توسعه، پشتیبانی و نحوه پرداخت |
| مالکیت معنوی | حقوق مرتبط با کد منبع و اپلیکیشن |
| حل اختلافات | روشها و فرآیندهای حل اختلاف |
| محرمانگی و عدم رقابت | تعهدات مرتبط با محرمانگی و عدم رقابت |
| فسخ قرارداد و جریمه | شرایط فسخ قرارداد و جریمه تأخیر |
نکات حقوقی در قرارداد طراحی اپلیکیشن موبایل
قبل از امضای قالب قرارداد اپلیکیشن موبایل و شروع همکاری، داشتن اطلاعات دقیق از ویژگی ها و جنبه های حقوقی این قرارداد حائز اهمیت است. نمونه ای از قرارداد اپلیکیشن موبایل، قرارداد قرارداد است و به مجموعه ای از قراردادهای تعریف شده تعلق دارد. این بدان معناست که هیچ تعریف دقیق یا قوانین و مقررات خاصی برای این گونه قراردادها وجود ندارد. با این حال، این موافقتنامه توسط قانون مدنی اداره می شود و باید با قوانین کلی آن قانون مطابقت داشته باشد. نمونه قرارداد توسعه اپلیکیشن موبایل با رعایت مواد 10، 190، 219 و ماده 220 قانون مدنی تنظیم می شود. این بدان معناست که قرارداد بر اساس اراده و توافق طرفین تنظیم می شود; از شروط اعتبار قرارداد پیروی می کند و مفاد قرارداد با قانون مدنی مغایرت ندارد. بنابراین و با رعایت دقیق این موارد، قراردادی که بین طرفین منعقد می شود معتبر و معتبر خواهد بود.
قرارداد طراحی اپلیکیشن موبایل یک قرارداد ضروری است. یعنی طرفین این قرارداد اختیار فسخ ندارند و نمی توانند اعلام کنند که در انجام موضوع قرارداد کوتاهی کرده اند. البته اگرچه قرارداد باید شامل مالک و پیمانکار باشد، اما در مواردی امکان فسخ قرارداد وجود دارد. برای مثال می توانید با مراجعه به شرایطی که برای فسخ در قانون مدنی قید شده است قرارداد خود را فسخ کنید و یا اینکه می توان بندهای فسخ قرارداد قرارداد توسعه اپلیکیشن موبایل را در نظر گرفت. تعریف شروط به این معناست که در صورت وقوع، طرفین حق فسخ قرارداد را دارند. در اکثر موارد این شرایط برای طرفین بسیار مهم است.
محرمانه بودن و عدم رقابت در مدل قرارداد برای طراحی اپلیکیشن موبایل
مهمترین مسئله در سفارش ساخت و ایجاد اپلیکیشن موبایل ترس از افشای اطلاعات شخصی و ایده اصلی اپلیکیشن است. کسانی که می خواهند اپلیکیشن های خود را طراحی کنند می ترسند که اسرار و ایده های تجاری شان فاش شود و شخصی که کار طراحی اپلیکیشن را انجام می دهد، نقاط قوت و ضعف آن را تجزیه و تحلیل کرده و با آن ها رقابت کند. برای جلوگیری از این مشکل، توصیه میکنیم هر کسی که میخواهد برنامه کاربردی خود را داشته باشد، یک توافقنامه محرمانه و یک توافقنامه غیررقابتی با مهندس طراح و توسعهدهنده برنامه آماده کند.
با امضای این قرارداد می توانید با سهولت بیشتری همکاری کنید و دیگر نگران اطلاعات و ایده های خود نباشید.
مالکیت اپلیکیشن موبایل را تعریف کنید!
در متن نمونه قرارداد طراحی اپلیکیشن موبایل، مالکیت نهایی اپلیکیشن و سورس کد آن را توضیح دهید. در مورد این موضوع صریح باشید و در متن قرارداد به صراحت قید کنید که محصول نهایی یا برنامه طراحی شده به طور کامل توسط کارفرما و متعلق به کارفرما خواهد بود. همچنین میتوانید تعیین کنید که طراح و توسعهدهنده برنامه نتواند از طراحی، کد منبع، محتوای خصوصی و غیره برنامه استفاده کند.
با روشن شدن این موضوع خیالتان از بابت استفاده از طراح راحت خواهد بود و در صورت اعتراض می توانید از متن قرارداد برای حفظ حقوق قانونی خود استفاده کنید.
توضیحات فنی دقیق در قالب قرارداد طراحی اپلیکیشن موبایل
نکته بسیار مهم در رابطه با توافق قرارداد با طراح اپلیکیشن، توضیحات فنی است که به طراح داده می شود. توصیه می کنیم تمام مواردی را که باید در هنگام طراحی و توسعه برنامه خود در نظر گرفته شود، به وضوح مشخص و توضیح دهید.
این به شما فرصتی می دهد تا انتظارات خود را بیان کنید و مهندس طراح دقیقاً می داند که چگونه پروژه مورد نظر شما را انجام دهد. با مراجعه به این اطلاعات به شما کمک می کند تا سفارش خود را در پایان قرارداد بررسی کنید و درخواست ارسال شده توسط طراح را برای سنجش کیفیت نهایی پروژه بررسی کنید. همچنین در صورتی که آخرین درخواست مغایر با مشخصات سفارش شما باشد، می توانید بر اساس قرارداد ادعای خسارت کرده یا از پذیرش درخواست خودداری کنید.
شما می توانید تمام مشخصات، اطلاعات و تمام مواد لازم را برای مرتبط کردن این برنامه با قرارداد اضافه کنید. پیمانکار باید از طریق فایل ضمیمه درخواست شما را طبق سفارشی که شما مشخص کرده اید طراحی و تحویل دهد.
خسارت تاخیر نمونه قرارداد طراحی اپلیکیشن موبایل
پیمانکار توضیح داد که با توجه به مدت زمانی که قرارداد کامل تلقی می شود باید درخواست نهایی به کارفرما ارائه شود. در اینجا اگر پیمانکار در ساخت و طراحی اپلیکیشن به تعویق بیفتد و یا در زمان وعده داده شده درخواست را به کارفرما تحویل ندهد، کارفرما ناراضی و حتی متضرر می شود. به همین دلیل توصیه می کنیم بند تاخیر پرداخت را در قرارداد خود در نظر بگیرید. بدین ترتیب به ازای هر روز تاخیر در تحویل درخواست، مبلغ معینی به عنوان خسارت در نظر گرفته می شود.
بنابراین اگر پیمانکار درخواست را در موعد مقرر ارائه نکند، موظف به پرداخت مبلغی خسارت به ازای هر روز تاخیر خواهد بود.
مبلغ کارمزد قرارداد طراحی اپلیکیشن موبایل
مبلغ کمیسیون مبلغی است که برای ساخت و طراحی اپلیکیشن موبایل به پیمانکار پرداخت می شود. این مبلغ با توافق و نظر طرفین تعیین خواهد شد. بنابراین لازم است قبل از انعقاد قرارداد، طرفین در مورد مبلغ قرارداد به توافق برسند و حق الزحمه را تعیین کنند. علاوه بر تعیین میزان کارمزد، می توانید روش پرداخت را نیز تعیین کنید. به عنوان مثال می توانید هزینه های مرحله ای و اقساطی را در نظر بگیرید و تاریخ پرداخت مشخصی را مشخص کنید.
بر اساس تجربههای عمومی از قراردادهای طراحی اپلیکیشن، یکی از مهمترین نکات در چنین توافقنامههایی تعیین شفاف محدوده پروژه و انتظارات از ابتدا است. بسیاری از مشکلات و اختلافات بین کارفرما و پیمانکار به دلیل عدم شفافیت در تعریف وظایف و خروجیهای مورد انتظار پیش میآید. نکته دیگر در این نوع قراردادها، زمانبندی دقیق و مشخص کردن نحوه پرداختها متناسب با پیشرفت کار است. از سوی دیگر، اهمیت مالکیت معنوی و حفاظت از کد منبع برای جلوگیری از مشکلات قانونی آینده نیز غیرقابل انکار است.
تحلیل اشتباهات رایج در قرارداد طراحی اپلیکیشن
| اشتباه رایج | توضیح حقوقی | راهکار عملی |
| ۱. فقدان “سند محدوده پروژه” (SOW) دقیق | این مرگبارترین اشتباه در قراردادهای نرمافزاری است. استفاده از عبارات کلی مانند “طراحی یک اپلیکیشن فروشگاهی” بدون پیوست فنی، قرارداد را از نظر حقوقی بیارزش میکند. “مورد معامله” که از ارکان اصلی صحت قرارداد است، مبهم باقی میماند. این امر منجر به پدیدهای به نام “Scope Creep” یا “خزش محدوده” میشود؛ کارفرما مدام ویژگیهای جدیدی را انتظار دارد و توسعهدهنده نیز با تحویل حداقلها، ادعای انجام تعهد میکند. حل چنین اختلافی در دادگاه تقریباً غیرممکن است. | الزام به تهیه و امضای “پیوست مشخصات فنی و کاربردی” (SOW): این سند، قلب تپنده قرارداد شماست و باید پیش از امضای قرارداد نهایی شود. این پیوست باید شامل موارد زیر باشد: – شرح کامل ویژگیها (Features): لیست تمام قابلیتهای اپلیکیشن به تفکیک بخشهای مختلف (مثلاً: ثبتنام کاربر، پروفایل، جستجو، سبد خرید، پرداخت). – وایرفریمها (Wireframes) و طراحی UI/UX: ارائه طرحهای اولیه و نهایی تمام صفحات اپلیکیشن. – پلتفرمهای هدف: مشخص کردن اینکه اپلیکیشن برای چه سیستمعاملهایی (iOS, Android) و چه نسخههایی توسعه مییابد. – مشخصات فنی: تعیین تکنولوژیهای مورد استفاده (زبان برنامهنویسی، پایگاه داده و…). |
| ۲. ابهام در “مالکیت سورس کد” و حقوق فکری | طبق قوانین مالکیت فکری، پدیدآورنده اثر (توسعهدهنده) مالک آن است، مگر آنکه صراحتاً حقوق خود را واگذار کند. اگر در قرارداد به طور شفاف ذکر نشود، توسعهدهنده میتواند ادعا کند که تنها “مجوز استفاده” از اپلیکیشن را به شما فروخته و مالکیت سورس کدها همچنان در اختیار اوست. این یعنی شما در آینده برای توسعه، فروش یا حتی نگهداری اپلیکیشن توسط تیمی دیگر، کاملاً به توسعهدهنده اولیه وابسته خواهید بود. | درج “بند انتقال قطعی و کامل مالکیت فکری”: یک بند صریح و قاطع در قرارداد بگنجانید که بیان کند: “پس از پرداخت کامل و نهایی مبلغ قرارداد، کلیه حقوق مادی (از جمله حق ویرایش، توسعه، فروش، تکثیر) و معنوی (تا جایی که قانون اجازه میدهد) مرتبط با پروژه، شامل سورس کدها، فایلهای طراحی، دیتابیس، مستندات و هر آنچه در جریان پروژه تولید شده است، به صورت قطعی، انحصاری، دائمی و بدون محدودیت مکانی به کارفرما منتقل میگردد و توسعهدهنده هیچگونه حق یا ادعایی نسبت به آن نخواهد داشت.” |
| ۳. برنامه پرداخت مبتنی بر زمان به جای پیشرفت پروژه | پرداخت مبلغ به صورت ماهانه یا درصدهای ثابت زمانی، بدون گره زدن آن به خروجیهای ملموس، ریسک بزرگی برای کارفرماست. این روش هیچ اهرمی برای اطمینان از پیشرفت واقعی پروژه به شما نمیدهد. توسعهدهنده ممکن است زمان زیادی صرف کند اما خروجی قابل قبولی ارائه ندهد، در حالی که پرداختها را دریافت کرده است. | تنظیم “جدول پرداخت مبتنی بر تحویل مایلاستون (Milestone)”: مبلغ کل قرارداد را به فازهای مختلف تقسیم کرده و پرداخت هر فاز را منوط به “تحویل موفق و پذیرش نهایی” یک بخش از پروژه کنید. برای مثال: – فاز ۱ (۲۰٪): تحویل و تأیید نهایی طراحی UI/UX. – فاز ۲ (۳۰٪): تحویل نسخه قابل تست فرانتاند (Front-End). – فاز ۳ (۳۰٪): تحویل نسخه بتای کاملاً کاربردی با بکاند (Back-End) یکپارچه. – فاز ۴ (۲۰٪): پس از رفع باگهای نهایی، پذیرش کامل و انتشار در فروشگاههای اپلیکیشن. |
| ۴. عدم پیشبینی دوره “گارانتی” و “پشتیبانی” | تعهدات توسعهدهنده با تحویل نهایی اپلیکیشن به پایان میرسد. اگر در قرارداد پیشبینی نشده باشد، هرگونه باگ یا ایرادی که پس از تحویل کشف شود، مسئولیت رفع آن با شما خواهد بود. همچنین با آمدن نسخههای جدید سیستمعاملها (iOS/Android)، اپلیکیشن شما ممکن است دچار اختلال شود. | افزودن “بند گارانتی (رفع خطا)” و “قرارداد پشتیبانی”: – دوره گارانتی: یک دوره زمانی مشخص (مثلاً ۳ الی ۶ ماه پس از تحویل نهایی) را به عنوان دوره گارانتی تعیین کنید. “در این دوره، توسعهدهنده موظف است هرگونه باگ یا خطایی را که ناشی از کدهای تحویل داده شده توسط او باشد، بدون دریافت هزینه اضافی برطرف نماید.” – قرارداد پشتیبانی (اختیاری): برای پس از دوره گارانتی، یک قرارداد جداگانه یا بندی در همین قرارداد برای پشتیبانی فنی، بهروزرسانیها و توسعههای جزئی با نرخ ساعتی یا ماهانه مشخص، پیشبینی کنید. |
| ۵. فقدان فرآیند مشخص برای “تست و پذیرش” | بدون وجود یک فرآیند شفاف، مرحله تحویل پروژه میتواند به یک چرخه بیپایان از اصلاحات و ایرادگیری تبدیل شود. کارفرما ممکن است به صورت سلیقهای از پذیرش محصول خودداری کند و توسعهدهنده نیز ممکن است ادعا کند که محصول مطابق قرارداد آماده است. | تعریف “فرآیند و معیارهای تست و پذیرش (UAT)”: یک بند مشخص برای این فرآیند ایجاد کنید که شامل موارد زیر باشد: – دوره زمانی تست: کارفرما برای هر مایلاستون تحویلی، چند روز کاری فرصت تست دارد (مثلاً ۵ روز). – نحوه گزارش خطا: خطاها باید به صورت مکتوب و از طریق یک ابزار مشخص (مانند ایمیل یا نرمافزار مدیریت پروژه) گزارش شوند. – معیار پذیرش: معیار نهایی پذیرش، “انطباق کامل عملکرد محصول تحویلی با تمام ویژگیهای مندرج در پیوست مشخصات فنی (SOW)” است، نه سلایق شخصی. |
| ۶. غفلت از “قرارداد عدم افشا” (NDA) | ایده اپلیکیشن و اطلاعات کسبوکار شما، یک دارایی ارزشمند است. در صورت عدم وجود یک توافقنامه محرمانگی، توسعهدهنده هیچ تعهد قانونی برای حفظ اسرار شما ندارد و میتواند از ایده یا اطلاعات شما به نفع خود یا دیگران استفاده کند. | درج “بند حفظ محرمانگی اطلاعات” یا امضای NDA مجزا: پیش از به اشتراک گذاشتن هرگونه اطلاعات حساس، یک قرارداد عدم افشای اطلاعات (NDA) امضا کنید یا یک بند محرمانگی بسیار قوی در قرارداد اصلی بگنجانید. این بند باید توسعهدهنده و تیم او را ملزم کند که کلیه اطلاعات فنی، مالی و تجاری کارفرما را در طول پروژه و تا چند سال پس از آن محرمانه نگه داشته و برای هیچ شخص ثالثی فاش نکنند. |
نکات حقوقی و توصیههای کاربردی در تنظیم قرارداد
تنظیم یک قرارداد طراحی اپلیکیشن کارآمد، نیازمند توجه به نکات حقوقی و کاربردی خاصی است که میتواند از بروز بسیاری از مشکلات جلوگیری کرده و به موفقیت پروژه کمک کند.
اهمیت شفافیت و پرهیز از کلیگویی
یکی از اصول بنیادین در نگارش قرارداد، شفافیت و وضوح است. از بهکار بردن عبارات مبهم، کلی و چندپهلو که امکان تفاسیر مختلف را فراهم میکند، باید جداً پرهیز کرد. تمامی تعهدات، انتظارات، مشخصات فنی، زمانبندیها و شرایط پرداخت باید به صورت صریح، دقیق و با جزئیات کامل بیان شوند. استفاده از زبان ساده و قابل فهم برای هر دو طرف، حتی اگر یکی از آنها دانش حقوقی کمتری داشته باشد، ارجحیت دارد. همانطور که اشاره شد، بسیاری از قراردادها به دلیل عدم شفافیت در شرح وظایف و تعهدات طرفین با مشکلات حقوقی مواجه میشوند. هرچه قرارداد شفافتر باشد، احتمال بروز اختلاف نظر و سوءتفاهم در آینده کمتر خواهد بود.
استفاده از پیوستها برای جزئیات فنی
همانطور که در بخش موضوع قرارداد نیز اشاره شد، توصیه اکید بر این است که جزئیات فنی پیچیده، فهرست کامل ویژگیها و قابلیتهای اپلیکیشن، و سایر موارد فنی تخصصی، در یک یا چند سند پیوست جداگانه تدوین و به قرارداد اصلی ضمیمه شوند. در متن اصلی قرارداد باید به این پیوستها به روشنی ارجاع داده شود و تصریح گردد که جزء لاینفک قرارداد محسوب میشوند. این رویکرد باعث میشود متن اصلی قرارداد که حاوی مفاد حقوقی و تجاری کلیدی است، مختصرتر، خواناتر و قابل فهمتر باقی بماند. همچنین، مدیریت و در صورت لزوم، اصلاح یا بهروزرسانی پیوستهای فنی (با رعایت تشریفات مربوط به الحاقیه قرارداد) توسط تیمهای فنی آسانتر خواهد بود، بدون آنکه نیازی به تغییرات گسترده در متن اصلی قرارداد باشد.
ضرورت مشاوره با متخصصین حقوقی
اگرچه ممکن است نمونه قراردادهای آماده برای طراحی اپلیکیشن در دسترس باشند ، اما اکیداً توصیه میشود که پیش از امضای نهایی هرگونه قرارداد، بهویژه برای پروژههای مهم، پیچیده یا حساس از نظر مالکیت معنوی، با یک وکیل یا مشاور حقوقی متخصص در زمینه قراردادهای فناوری اطلاعات مشورت شود. یک متخصص حقوقی میتواند به شما در موارد زیر کمک کند:
- اطمینان از اینکه قرارداد تمامی جوانب قانونی لازم را پوشش میدهد و با قوانین جاری کشور مطابقت دارد.
- شناسایی ریسکها و نقاط ضعف احتمالی در پیشنویس قرارداد و ارائه راهحل برای کاهش آنها.
- تنظیم بندهای قرارداد به گونهای که منافع شما را به بهترین شکل ممکن حفظ کند.
- تطبیق دادن نمونههای عمومی قرارداد با نیازها و شرایط خاص پروژه شما.
- توضیح مفاد پیچیده حقوقی به زبان ساده.
کاربر مهمان –
آیا در قرارداد طراحی اپلیکیشن باید به موضوع مالکیت فکری و حقوق مربوط به کدها و نرمافزارها توجه کنم؟ اگر بله، چگونه میتوانم این موضوع را در قرارداد لحاظ کنم؟
فول فایل –
بله، موضوع مالکیت فکری و حقوق مربوط به کدها و نرمافزارها از اهمیت بالایی برخوردار است و باید در قرارداد به وضوح مشخص شود. شما باید در قرارداد تعیین کنید که مالکیت کدها و نرمافزارهای تولید شده به چه کسی تعلق دارد و تحت چه شرایطی میتوان از آنها استفاده کرد. همچنین، باید مشخص شود که آیا شرکت طراحی حق استفاده مجدد از کدها را دارد یا خیر. این موضوع میتواند از بروز اختلافات آینده جلوگیری کند و حقوق شما را به عنوان کارفرما حفظ نماید.