Давайте разбираться, какой договор мы обычно заключаем, какой может быть выгоднее заказчику, а какой программисту, какие последствия влечет не верная интерпретация договорных отношений
Кому это вообще надо?!
Если быстро и коротко – всем! Довольно обыденной является ситуация, когда для всех заказчиков используется один и тот же договор в независимости от задач, которые предполагается выполнять по нему. У кого-то это договор на выполнение работ, у кого-то договор на оказание услуг, реже договор о создании программы для ЭВМ, авторского заказа и т.п.
В чем возникают сложности?
Обычная ситуация, договор скопирован у крупной компании разработчика, которая имеет штат высококвалифицированных юристов и это логично, они же крупные игроки рынка. Удалено «лишнее», пройдена адаптация под задачи конкретного пользователя (в данном случае разработчика). Из плюсов: достался фактически бесплатно (временные затраты на удаление лишнего), делался он явно командой опытных юристов, ибо скопирован он у крупной компании и должен защищать интересы именно разработчиков.
НО на практике это почти всегда не работает, как разработчик создает новый продукт под конкретные задачи клиента, так и договор верстается с учетом целей и задач конкретного проекта. При копировании договора теряется связь между проектом, для которого он создавался и условиями договора.
Интересно, что заказчики, которые не специализируются на программном обеспечении и которые хотят получить разовую услугу, обычно наступают на те же грабли, скачивают где-то договор, в котором прописывают основные условия, а потом узнают, что фактически у них нет прав на продукт.
В данном случае попробуем, кратко, разобрать, что из себя представляет тот или иной договор и кому он может быть более полезен:
Договор возмездного оказания услуг
По данному договору заказчик поручает, а разработчик оказывает услуги, например, изучает исходный код, выявляет ошибки и готовит заключение с перечнем доработок. Важно, что при заключении договора на оказание услуг оплата производится не зависимо от достижения результата, т.е. оплачиваются старания (за исключением отдельных исключений), если результата нет, то заказчик все равно оплатит старания разработчика. Данный договор выгоднее прежде всего разработчикам, так как претензии по качеству услуг фактически невозможно предъявить: сделал как смог. Для заказчика это, наоборот, одна из худших форм при которой он фактически лишается права на предъявление претензий.
Договор подряда
По данному договору заказчик поручает выполнить определенную работу, а разработчик обязуется предоставить определенный результат. В данном случае значение имеет слова «работа», которое предполагает именно получение результата в итоге. Многие считают, что указание в договоре на «выполнение работ», не имеет никакого значения, однако, это не так В первую очередь исследуется буквальное содержание условий договора, а потом реальные цели сторон, если из поведения сторон нельзя будет определить, что они предполагали при заключении договора, суд применит терминологию и буквальное содержание условий.
Кроме того, что в договоре подряда заказчик вправе предъявлять претензии к результату работ, он еще имеет право контролировать ход их выполнения и давать обязательные для исполнения указания, что обычно не предполагается при заключении договора на оказание услуг. Данный договор в первую очередь интересен заказчикам, так как позволяет контролировать ход работ, предъявлять требования к результату и требовать от разработчика его достижения.
Договор на выполнение НИОКР
По договору на выполнение научно-исследовательских работ (НИОКР) разработчик обязуется провести согласованные в техническом задании научные исследования, а заказчик оплатить их. Договор на выполнение НИОКР предусматривает отличный от договора подряда порядок распределения рисков недостижения результата работ. Как было указано выше в договоре подряда данный риск ложится на плечи разработчика, нет согласованного результат – нет оплаты работ. При выполнении работ по договору НИОКР риск невозможности достижения результата, возникший вследствие обстоятельств, не зависящих от разработчика, лежит на заказчике. Данное условие позволяет разработчику избежать необоснованного привлечения к ответственности при недостижении запланированного в договоре результата.
Необходимо отметить, что договор на выполнение НИОКР обычно заключают государственные предприятия и учреждения, так как он является более удобным для них с точки зрения делового оборота и налогообложения.
Договор авторского заказа
Особенностью договора авторского заказа является создание непосредственно автором (коллективом авторов) конкретного результата (проекта) и передачу его заказчику в установленный таким договором срок. При этом исполнителем по данному договору может быть только физическое лицо (самозанятый, ИП), юридическое лицо не может быть автором и, следовательно, стороной договора. Обычно сюрпризом для заказчика становится право разработчика увеличить срок выполнения работ до ¼ от ранее согласованного срока, это право предоставлено разработчику законом в случае «необходимости и наличия уважительных причин», обычно заказчики узнают об этом и выражают искреннее недоумение и удивление.
Необходимо также отметить, что закон не урегулирует кому принадлежат результаты на выполненные автором работы. При отсутствии в договоре указания на распределение прав, у заказчика будут проблемы, связанные с использованием результата работ, при которых доказывать и обосновывать предполагаемый вид использования придется в суде.
Трудовой договор
Один из наиболее часто встречающихся случаев, когда проект создается коллективом разработчиков, которые связанны с заказчиком условиями трудового договора. При видимой простоте регулирования данный вид договора (трудовой) содержит в себе огромное количество рисков, связанных с возможностью сохранения права собственности на разработанный РИД за работником. Для перехода права на РИД работодатель не только должен доказать факт выполнения работ по заданию, но и доказать факт передачи РИД от работника, а также уплату согласованного вознаграждения, нарушение процедуры оформления передачи РИД становится причиной дорогостоящих судебных споров и потерей прав на РИД работодателем.
Для чего все это нужно?
Для разрешения будущего спора. Фраза «я сто раз так делал и ничего» ломается при первом конфликте, который передается на разрешение суда, результаты этого спора обычно сильно удивляют опытного пользователя шаблона договора из интернета;
Заключая договор с заказчиком / разработчиком, учитывайте особенности задачи, не занимайтесь простым копированием «хороших договоров» у крупных игроков рынка;
Хотите сэкономить время и силы, проработайте не только ТЗ, но и порядок общения с контрагентом, отражайте реальные способы коммуникации, которые вы планируете;
Даже если вы отлично закрыли контракт, получили желаемое ПО, при отсутствии в договоре авторского заказа, на оказание услуг и т.п. условий о переходе прав на РИД, результат коммерческого использования вас может сильно удивить;
Взяли разработчика на должность консультанта, не оформляли ему задания, акты передачи прав, не платили специально вознаграждение за РИД - продукт не ваш, а вот того консультанта, который по факту был разработчиком.
Выводы:
Необходимо подготавливать договор под конкретную задачу и не маскировать любой договор под услуги, подряд, что выгоднее той или иной стороне. Обращайте внимание на реальные задачи и уже от них разрабатывайте условия договора. От того, что в терминологии договора вы замените слова «услуги» на «работы», его содержание не изменится, смотрите есть ли требования к результату и детальная проработка порядка выполнения работ и контроль их со стороны заказчика.
С договором все было хорошо, пока мы не начали спорить…. (с).