Договор на разработку по. Договор на разработку программного обеспечения Договор на создание программного продукта образец

Потребность в заказной разработке возникает, как правило, при создании уникального программного обеспечения. Это значит, что на рынке нет готовых продуктов, которые бы подходили под нужды заказчика из-за его особых требований к характеристикам, возможностям и функционалу софта. В этом случае клиент инициирует разработку продукта под свои потребности «с нуля» и с этой целью начинает вести переговоры с разработчиком. Переговоры переходят в сотрудничество. Заключается договор о создании программного продукта.

Как минимизировать риски в процессе исполнения обязательств и сделать сотрудничество сторон максимально комфортным?

Юридические конструкции при создании договора на разработку программного обеспечения

Договор на создание программного продукта может быть сконструирован в двух вариантах:

• по модели договора подряда;
• по модели договора оказания услуг.

Выбор зависит от того, насколько ясно можно изначально зафиксировать характеристики и функциональные возможности будущего программного продукта.

Договор подряда

Если есть четкое понимание, что должно появиться на выходе, правильным выбором будет заключение договора подряда.

Здесь в первую очередь необходимо обратить особое внимание на формулировки, связанные с конечным результатом работы. Как правило, документом, описывающим конечный результат, является техническое задание, которое служит приложением к договору. В нем максимально подробно раскрываются технические характеристики и функционал программного продукта.

Существенным является условие о сроке выполнения работ. Если он в договоре отсутствует, документ может быть признан незаключенным. Поэтому важно установить начальный и конечный сроки выполнения работ.

В ситуации, когда разработка программного продукта представляет собой длительный процесс (а чаще всего так и бывает), разумно составить календарный план, сделав его частью договора. Именно так в большинстве случаев и поступают на практике.

Договор оказания услуг

Однако ситуация создания нового софта далека от идеальной. Заказчик не всегда может на старте четко и в полной мере сформулировать характеристики и функционал, которые он ожидает от будущего продукта. В процессе разработки претерпевают изменения как сам бизнес, так и внешние условия. Решения, которые изначально представлялись оптимальными, теряют свою актуальность. Поэтому вариант, когда обе стороны с самого начала одинаково ясно представляют себе будущий продукт и идут строго по плану, в жизни малореализуем.

И здесь имеет смысл обратить внимание на конструкцию договора оказания услуг. В документе отсутствуют заранее установленные требования к конечному результату. Это означает, что заказчик платит исполнителю за процесс создания софта, например, исходя из реального времени, которое он на это потратил. Как правило, это происходит в виде почасовой оплаты специалистов исполнителя.

Конечно, на первый взгляд заказчику невыгоден такой подход, ведь его больше всего интересует результат. Однако неоспоримым плюсом данной конструкции является ее гибкость. Заказчик никак не связан техническим заданием и может смело вносить любые изменения в функционал и характеристики. Среди минусов – проблемы с контролем временных затрат исполнителя и связанные с этим трудности по планированию бюджета на проект.

Можно ли как-то минимизировать финансовые риски? Одним из вариантов решения этой проблемы является установление предельной величины вознаграждения исполнителя.

Что обязательно должно быть в договоре на разработку программного обеспечения?

Предмет договора и стоимость услуг – вот те условия, которые обязательно должны содержаться в документе. Тогда договор с точки зрения закона будет считаться заключенным.

Предмет договора можно изложить в виде действий исполнителя по созданию продукта, обозначив общие характеристики, в которых заказчик уверен полностью. Таким образом, в договоре фиксируется общий вектор усилий исполнителя. Детали же будут восполняться в ходе выполнения проекта. Что касается цены, то, как упоминалось выше, она чаще всего указывается в виде ставок специалистов за фактически отработанное время.

Как это происходит на практике?

В действительности все складывается не так просто. Схема может быть следующей.

Стороны облекают свои договоренности по созданию продукта в договор подряда. В техническом задании говорится о том, что должно из себя представлять программное обеспечение. Составляется календарный план, в котором весь процесс разбивается на этапы с четкими сроками выполнения работ и их стоимостью.

При этом нередко дополнительно указываются ставки специалистов исполнителя. В предмете договора говорится о том, что исполнитель оказывает услуги (в противовес работам, которые подразумевают результат). Получается смесь договора подряда с договором оказания услуг, где фиксированная цена за создание программного продукта соседствует с почасовыми ставками специалистов исполнителя. Все это именуется схемой Time & Material (но к этому иностранному термину договор имеет очень опосредованное отношение).

Далее в процессе исполнения договора у заказчика неизменно начинают появляться новые требования к создаваемому продукту. Исполнитель же, имея перед собой техническое задание и календарный план, старается им следовать, ведь это важная часть договора, подписанного обеими сторонами. А вознаграждение разработчика зависит от исполнения обязательств по договору.

Стороны каждый раз вынуждены спорить и договариваться о подписании многочисленных дополнительных соглашений либо отступать от первоначальных характеристик продукта без подписания каких-либо документов, а значит, идти в разрез с заключенным договором.

Последний сценарий может создать массу проблем разработчику, например, в ситуации, когда выполненная работа заказчиком не принимается, так как не соответствует условиям договора. При этом корректировки со стороны заказчика, на которые ориентировался исполнитель, давались или устно, или неуполномоченным лицом. Либо же просто были неправильно поняты.

Какой можно сделать вывод?

Чтобы избежать подобных недоразумений при создании программного продукта, заказчику и исполнителю целесообразно заключить договор оказания услуг, который бы содержал ставки специалистов исполнителя и при необходимости фиксировал бы предельную величину вознаграждения по проекту. В результате проект получит достаточную гибкость, заказчик сможет вносить корректировки неограниченное число раз, а исполнитель не будет иметь возражений, так как ему оплачивается фактически отработанное время.

Как распределяются права на разработанное программное обеспечение?

Несмотря на кажущуюся простоту этого вопроса (кому же, как не заказчику, должны принадлежать права на созданный продукт?), нюансы есть и здесь.

По умолчанию исключительное право на продукт принадлежит заказчику. Так обстоит дело, если в договоре ничего по этому поводу не сказано. По закону стороны могут заранее договориться о том, что исключительное право останется за исполнителем. В практике создания заказных разработок это встречается нечасто.

Если в договоре не содержится обратное, подрядчик получает право использовать программный продукт на условиях простой неисключительной лицензии в течение всего срока действия исключительного права. Поэтому, если заказчик имеет другие планы по данному вопросу, имеет смысл прямо предусмотреть это в договоре.

Передача исключительного права на программное обеспечение

В заключение необходимо обратить внимание на распространенную юридическую ошибку, которая допускается при составлении договоров на создание программных продуктов либо в договорах подряда, где программный продукт является одним из результатов работы подрядчика (например, при создании технологического оборудования, в состав которого входит программное обеспечение).

Так, намереваясь закрепить за заказчиком исключительное право на программный продукт, составители пишут, что «подрядчик обязуется передать исключительное право». Иногда для этого даже предусматривается подписание отдельного акта. Это неправильно.

Исключительное право не передается, а возникает у заказчика в силу одного только факта создания программного продукта. Передача права означала бы, что до этого оно возникло у подрядчика, а это не так.

В результате стороны перегружают договор еще одним обязательством. А если в финале сотрудничества возникнут разногласия, к ним добавится еще один «камень преткновения»: заказчик выдвигает среди прочих требование о передаче исключительного права на программный продукт и хочет при этом подписать акт приема-передачи.

Однако исключительное право принадлежит заказчику в силу закона и не нуждается в передаче. В договоре можно просто продублировать факт принадлежности этого права, и тогда отпадет необходимость в дополнительных обязательствах и требованиях.

На практике нам часто приходится сталкиваться с различными договорами на создание программного обеспечения . Обычно для оформления заказа на разработку программных продуктов используются договор возмездного оказания услуг, договор подряда либо договор авторского заказа (авторский договор).

Какой из них верный и чем грозит ошибка при выборе договора?

Договор на услуги в принципе не подходит на данную роль, поскольку его предметом выступает осуществление определенной деятельности, а не создание ПО и передача на него прав. Услуги по определению реализуются и потребляются в процессе их оказания и не имеют материального выражения. Безусловно, в результате оказания услуг может создаваться в том числе программное обеспечение, но такая деятельность является вторичной и, соответственно, права заказчика на такое ПО не защищаются должным образом по договору возмездного оказания услуг.

В отличие от договора на услуги возможность использования для разработки программного обеспечения договора подряда прямо предусмотрена в ст.1296 ГК РФ. Предметом такого договора является выполнение по заданию заказчика определенных работ по созданию конкретного ПО. Результатом работ, в отличие от услуг, всегда выступает определенный материальный объект. В рассматриваемом случае таким результатом является программное обеспечение с необходимыми заказчику характеристиками.

Таким образом, договор подряда на создание ПО главным образом направлен на разработку такого ПО в строгом соответствии с требованиями заказчика, изложенными в технической документации, и его последующую передачу заказчику. Здесь исполнитель сориентирован именно на результат, а не осуществление имитацию деятельности. Помимо этого, т.к. договор подряда направлен на передачу разработанного ПО заказчику, одновременно с ним заказчику переходит исключительное право на заказное ПО, как результат интеллектуальной деятельности, если иное не предусмотрено соглашением сторон.

Договор авторского заказа также может использоваться для создания программного обеспечения. Однако в отличие от договора подряда на разработку ПО, авторский договор заключается непосредственно с автором, т.е. физическим лицом.

Поскольку автор как человек, творческим трудом которого создается программное обеспечение, традиционно считается более слабой стороной в сделке, нежели заказчик, законодательство предоставляет ему ряд преимуществ (см. ст.1288 – 1290 ГК РФ). В частности, по договору авторского заказа права на ПО не переходят автоматически к заказчику, а сохраняются у автора. Поэтому положения о передаче прав на ПО в полном объеме необходимо прямо включать в договор авторского заказа.

Однако это не означает, что в случае работы с программистом-фрилансером лучше заключать договор подряда. Напротив, такой договор может быть оспорен, т.к. в законе для оформления отношений с автором прямо предусмотрен иной договор, который изначально предоставляет заказчику меньше преимуществ.

Если раньше по данному поводу между юристами еще были споры, то с 01 сентября 2014 г. статью о договоре подряда на создание произведений специально дополнили пунктом 5, где прямо указано, что правила данной статьи не распространяются на договоры, в которых подрядчиком (исполнителем) является сам автор произведения.

Таким образом, при выборе конструкции договора необходимо обращать внимание на следующие моменты:
1) что является непосредственным предметом заказа, и
2) кто выступает на стороне исполнителя.

Если предмет заказа – конкретное программное обеспечение, договор на услуги не подходит, т.к. последний направлен на деятельность определенного рода, в которой результат имеет вторичную роль. Соответственно, остаются договор подряда на создание произведений и договор авторского заказа.

Если в качестве исполнителя нанимается физическое лицо (автор), в том числе в статусе индивидуального предпринимателя, отпадает договор подряда, т.к. закон прямо указывает на необходимость заключения в таком случае договора авторского заказа.

Какие риски несут стороны в случае ошибки при заключении договора?

В такой ситуации неблагоприятный последствия возникают, прежде всего, у заказчика, который полагался на то, что подписанный договор является окончательным и защищает его в полном объеме.

Однако при заключении договора на оказание услуг исполнитель, основываясь на законе, вправе потребовать произвести доплату за отчуждение прав на ПО, передаваемое заказчику. Аналогичным образом может поступить и автор при заключении с ним договора подряда вместо договора авторского заказа.

Поэтому будьте внимательны при выборе договора на разработку ПО, т.к. ошибка может вам стоить прав на такое ПО или дополнительных расходов.

2. Порядок сдачи-приемки программного обеспечения

Данный раздел Договора на заказную разработку ПО имеет важное значение для обеспечения соответствия результатов работ потребностям и ожиданиям Заказчика, а также соблюдения интересов Разработчика в части объемов выполнения работ и их окончательной стоимости.

2.1. Заказчик вправе ознакомиться у Разработчика с ходом работ на любом этапе создания Продукта.

Для обеспечения качества работ необходимо обеспечить контроль со стороны Заказчика.

2.2. Если во время создания Продукта возникает необходимость внести какие-либо изменения в задание или другие изменения в условия Договора, то такие изменения оформляются письменным соглашением Сторон.

Можно предусмотреть иной порядок согласования изменений, в том числе путем обмена письмами, в рамках планирования или приемки промежуточных результатов работ.

2.3. По завершении работ и/или отдельного этапа работ Разработчик предоставляет Заказчику исходный текст и объектный код Продукта (в том числе его части) на оптическом диске или посредством сети связи с сопутствующей технической документацией и руководствами по использованию.

Важный пункт для Разработчика в целях подтверждения сдачи промежуточных этапов работ и требования их оплаты. Для Заказчика также важно получать промежуточные результаты для проверки качества, тестирования, внесения необходимых изменений в ход работ.

2.4. Заказчик не позднее двух дней с момента извещения Разработчиком о готовности Продукта обязуется принять и протестировать представленный Разработчиком Продукт.

Пункт важен в первую очередь для Разработчика программного обеспечения.

2.5. После принятия Заказчиком решения о соответствии Продукта требования задания Стороны составляют акт сдачи-приемки выполненных работ. В случае мотивированного отказа Заказчика подписать акт сдачи-приемки Сторонами составляется двусторонний акт с указанием необходимых доработок и сроков их выполнения.

Здесь заложена модель приемки окончательных результатов работ в пользу Заказчика, т.к. он может мотивированно настоять на доработке переданного ему программного обеспечения. Однако это будет достаточно сложно сделать, в случае приемки промежуточных этапов без соответствующих оговорок (см. пункт выше).

Далее в разделе необходимо решить вопрос о правах на промежуточные и окончательные результаты разработок. Если не согласовать иное, Разработчик может создать массу промежуточных версий ПО с приоритетом по дате создания, воспользовавшись финансированием Заказчика. В таком случае Заказчик получит исключительное право только на окончательный результат, а за Разработчиком сохранятся права на массу клонов.

Также возможна ситуация с последующим использованием наработок. Поэтому в договоре на разработку ПО нужно решить вопрос о возможности или запрете использования Разработчиком полученных результатов работ в будущем для создания новых версий Продуктов для себя или третьих лиц.

Здесь же необходимо определить момент перехода исключительного права на созданное по договору программное обеспечение, т.к. это важно для целей бухгалтерского и налогового учета (особенно при осуществлении приемки промежуточных этапов работ).

3. Цена договора и порядок расчетов по договору на разработку ПО

Данный раздел договора имеет существенное значение для обеспечения качества и сроков выполнения работ, обоснования расходов Заказчика для целей налогообложения и обеспечения полной и своевременной оплаты работ в интересах Разработчика.

Возможна масса вариантов определения стоимости работ по созданию программного обеспечения :

. в твердой сумме

. в виде процентов с дохода от последующего использования

. на основе почасовых ставок сотрудников разработчика.

Порядок оплаты также имеет множество вариантов от 100% предоплаты, до оплаты в рассрочку по завершении определенных этапов работ или сдачи результатов в окончательном виде, или по итогам отчетного периода.

4. Ответственность сторон по договору на создание ПО

В разделе согласуются возможные санкции за нарушение сроков выполнения работ, их качество, сроки оплаты, нарушение исключительных прав третьих лиц и т.п.

5. Разрешение споров

Важный раздел договора, поскольку выполнение обязательств и действительность санкций напрямую зависит от возможности их принудительного исполнения.

6. Конфиденциальность

Существенный раздел, поскольку при подписании Договора и в ходе его выполнения стороны будут обмениваться различной информацией, которая имеет коммерческую ценность в силу ее неизвестности третьим лицам.

Вот 2 образца договора разработки мобильного приложения , которые мы используем на практике: договор на разработку программного обеспечения или договор авторского заказа . Какой образец договора на разработку мобильного приложения подходит в вашей ситуации? Как не ошибиться с выбором договора на создание приложения?

Отличия договоров на разработку мобильного приложения

Выбор договора производится с учетом того, какое лицо занимается разработкой мобильного приложения .

Если вы нанимаете для создания мобильного приложения организацию или индивидуального предпринимателя со штатом , то необходимо использовать договор заказной разработки программного обеспечения . Такой договор регулируется положениями ст.1296 ГК РФ. По умолчанию исключительное право на результаты работ по договору принадлежит заказчику. Хотя договором может быть предусмотрено предоставление заказчику лицензии на результаты интеллектуальной деятельности разработчика.

Иначе данный вопрос решается в законодательстве в случае, когда для разработки мобильного приложения привлекается физическое лицо . Это может быт и предприниматель, который выступает в качестве единственного разработчика (автора) по договору. В таком случае должен заключаться договор авторского заказа , который регулируется ст.1288-1290 ГК РФ.

В отличие от договора заказной разработки, создание мобильного приложения по договору авторского заказа не влечет автоматического перехода исключительного права на приложение заказчику . Для этого необходимо включать в договор прямую говорку об отчуждении прав заказчику и указывать размер вознаграждения за передачу прав отдельно от стоимости работ по созданию мобильного приложения. В противном случае исключительные права сохраняются в полном объеме за автором.

Помимо этого при заключении договора на разработку мобильного приложения с автором следует помнить, что законом жестко ограничена ответственность автора за нарушения . Автор не возмещает упущенную выгоду, в отличие от разработчика - организации. Ответственность по договору авторского заказа ограничена возмещением реального ущерба, причиненного заказчику.

Ниже представлен типовой образец документа. Документы разработаны без учета Ваших персональных потребностей и возможных правовых рисков. Если Вы хотите разработать функциональный и грамотный документ, договор или контракт любой сложности обращайтесь к профессионалам.

ДОГОВОР ЗАКАЗА
на разработку программного обеспечения
г. Москва "___"__________ 20__ г.
_____________________ именуемое в дальнейшем "Заказчик", в лице _____________, действующего на основании ___, с одной стороны, и ____________________________________, именуемый в дальнейшем "Исполнитель", с другой стороны, вместе именуемые "Стороны", заключили настоящий договор о нижеследующем.
1. ПРЕДМЕТ ДОГОВОРА
1.1. Исполнитель обязуется создать программное обеспечение (далее - "Программа"), соответствующее техническому заданию, являющемуся неотъемлемой частью настоящего договора (Приложение №1), и передать Заказчику исключительные права на использование Программы в соответствии с условиями настоящего договора, а Заказчик за создание Программы уплачивает Исполнителю вознаграждение.
1.2. Программа должна соответствовать условиям технического задания, предоставленного Заказчиком в рамках настоящего договора и утвержденного Исполнителем.
1.3. Исполнитель настоящим предоставляет Заказчику все имущественные права на использование Программы в соответствии с условиями настоящего Договора.
2. ПРАВА И ОБЯЗАННОСТИ СТОРОН
2.1. Исполнитель обязуется создать Программу в течение ________ с момента подписания настоящего Договора.
2.2. Исполнитель обязуется создать Программу своими силами и средствами.
2.3. Исполнитель обязан немедленно сообщить Заказчику и до получения от него указаний приостановить работы при обнаружении:
непригодности или недоброкачественности предоставленной информации или технической документации;
возможных неблагоприятных для Заказчика последствий выполнения его указаний о способе выполнения задания;
иных, не зависящих от Исполнителя обстоятельств, которые могут повлиять на качество работы или невозможность ее завершения в срок.
2.4. После завершения работ Исполнитель предоставляет экземпляр первоначального варианта Программы на утверждение Заказчику. Заказчик принимает первоначальный вариант Программы по акту предварительной приемки-передачи, подписываемому обеими сторонами.
Заказчик обязуется рассмотреть представленный вариант Программы и известить Исполнителя либо об одобрении работы, либо о необходимости внесения поправок и доработок с указанием требуемых исправлений.
При получении указания Заказчика о внесении поправок и доработок Исполнитель обязуется в установленные Заказчиком сроки внести требуемые исправления и повторно представить Программу Заказчику.
2.5. Исполнитель передает окончательный вариант Программы в виде дистрибутива на материальном носителе (CD-ROM или DVD-ROM дисках), к которой прилагается инструкция по установке и руководство пользователя. Исполнитель обязан обучить работе с Программой представителей Заказчика и оказывать бесплатную консультационную помощь в течение гарантийного срока, установленного пунктом 4.2. настоящего Договора.
2.6. При получении одобрения Заказчика и получения окончательного варианта Программы согласно п. 2.5. Договора, Стороны составляют акт приемки-передачи Программы.
2.7. Исключительное право на созданную Исполнителем Программу принадлежит Заказчику в полном объеме с момента передачи Программы Исполнителем. Заказчик вправе зарегистрировать Программу как ее правообладатель в органах, осуществляющих государственную регистрацию программ для ЭВМ и баз данных.
2.8. Действие полученных Заказчиком исключительных прав не ограничивается территориальными пределами.
2.9. Исполнитель не сохраняет за собой права использовать Программу самостоятельно или предоставлять аналогичные права на ее использование третьим лицам.
2.10. За создание Программы и получение исключительных прав на нее Заказчик выплачивает Исполнителю вознаграждение в порядке, предусмотренном разделом 3 настоящего Договора.
3. СУММА ВОЗНАГРАЖДЕНИЯ И ПОРЯДОК ВЫПЛАТЫ
3.1. Вознаграждение Исполнителя по настоящему договору составляет ___________
3.2. Оплата производится в следующем порядке:

3.3. Денежные средства, подлежащие уплате по настоящему договору, оплачиваются Заказчиком путем ____________________________________.
4. ГАРАНТИИ ПО ДОГОВОРУ
4.1. Исполнитель гарантирует, что:
- при создании Программы им не будут нарушены авторские, патентные и любые иные права третьих лиц;
- на момент подписания настоящего Договора Исполнитель не связан какими-либо обязательствами с третьими лицами в отношении имущественных прав на использование Программы.
4.2. На разработанную Программу Исполнитель устанавливает гарантийный срок __________ со дня подписания акта окончательной сдачи-приемки Программы. Исполнитель обязуется исправить выявленные в процессе эксплуатации Программы проблемы (недостатки) и устранить их, если они противоречат условиям технического задания Заказчика.
5. КОНФИДЕНЦИАЛЬНОСТЬ
5.1. Условия настоящего договора и заданий конфиденциальны и не подлежат разглашению.
6. ОТВЕТСТВЕННОСТЬ СТОРОН
6.1. Сторона, не исполнившая или ненадлежащим образом исполнившая обязательства по настоящему договору, обязана возместить другой стороне причиненные таким неисполнением убытки.
6.2. В случае несоответствия переданной Программы характеристикам, указанным в Техническом Задании Заказчик вправе потребовать по своему выбору:
- замены программным средством надлежащего качества;
- изменения размера вознаграждения;
- расторжения настоящего Договора с возмещением убытков.
6.3. В случае нарушения Исполнителем срока создания Программы, установленного п. 2.1 настоящего Договора, Исполнитель уплачивает Заказчику штраф в размере ___ за каждый ___ просрочки.
7. ФОРС-МАЖОР
7.1. Обстоятельства форс-мажорного характера (непредвиденные обстоятельства непреодолимой силы), за которые стороны не являются ответственными (стихийные бедствия, забастовки, войны, принятие государственными органами законов и подзаконных актов, препятствующих исполнению договора и другое), освобождают сторону, не выполнившую своих обязательств в связи с наступлением указанных обстоятельств, от ответственности за такое невыполнение на срок действия этих обстоятельств. Если эти обстоятельства будут длиться более трех месяцев, каждая из сторон будет иметь право отказаться от исполнения обязательств по настоящему договору.
8. РАЗРЕШЕНИЕ СПОРОВ
8.1. Все споры и разногласия, которые могут возникнуть между Сторонами по вопросам, не нашедшим своего разрешения в тексте данного договора, будут разрешаться путем переговоров на основе действующего законодательства РФ.
8.2. Неурегулированные в процессе переговоров споры разрешаются в Арбитражном су...