{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

Договор с разработчиком 2024: на что обратить внимание

Статья будет полезна как заказчикам, так и разработчикам ПО: рассмотрим важнейшие проблемы и специфические особенности. Приведем примеры из наших недавних кейсов.

Материал подготовил адвокат Антон Филогин.

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

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

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

Как Заказчику защитить свои права на программу, а Разработчику передать их?

Это закономерный вопрос. Часто Заказчик сам не понимает какой документ необходимо составить, чтобы получить права на ПО (и это нормально, он же не юрист). Наши клиенты приходили порой с запросами на подготовку: договора оказания услуг, договора выполнения работ, соглашения о неразглашении информации и т.д.

Все это не подойдет.

Правильный путь: составление договора авторского заказа между Заказчиком и Разработчиком (ст. 1288 ГК РФ).

1. Передача исключительных прав на ПО

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

Более того, если исключительные права будут принадлежать Разработчику, а Заказчик будет пользоваться, то программист вправе потребовать компенсации за нарушение его авторских прав. Потери могут быть весьма солидными (размер компенсации составляет от 10 тыс. до 5 млн руб.), а также риск потери самого нематериального актива.

Поэтому составление договоров услуг, работ и т.д. совершенно не подходит для таких ситуаций.

2. Способ передачи программного обеспечения Заказчику.

Казалось бы простой вопрос, согласно закону заказ может быть передан на материальном носителе (как это пишут в большинстве шаблонов), т.е. флешке, диске и т.д.

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

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

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

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

В общем, вещь неочевидная, но важная.

3. Защита информации и конфиденциальность

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

Откровенно говоря, с юридической точки зрения вопрос очень непростой.

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

Во многих договорах мы встречали такой раздел:

Самое смешное, что в большинстве случаев никто это не обеспечивает какой-либо ответственностью в договоре. Разгласил информацию, и что? Ничего.

У кого-то появляется раздел "Гарантии", а кто-то просто пишет, что Разработчик обязан будет возместить убытки за разглашение.

В общем, все это в целом неэффективно и абсолютно не работает в виду следующего.

Допустим укажете, что Разработчик должен возместить убытки - замучаетесь доказывать это раз, во-вторых, ответственность ограничено только суммой реального ущерба, упущенная выгода не взыскивается (п. 2 ст. 1290 ГК РФ). А основными вашими убытками будет как раз упущенная выгода.

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

Есть несколько вариантов решения проблемы. Тут стоит подумать о таких инструментах как возмещение потерь (ст. 406.1. ГК РФ), а также заверения (ст. 431.2. ГК РФ), не путать с гарантиями.

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

4. Срок исполнения договора

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

Однако срок определить необходимо, или ваш договор не заключен (п. 1 ст. 1289 ГК РФ).

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

5. Техническое задание

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

По идее это должно выглядеть так: изначально Заказчик и Разработчик согласовывают ТЗ со всей спецификой IT-отрасли, потом садятся с командой юристов и приводят его в какой-то человеческий вид. На это уходит много времени, это дорого, но это единственный вариант.

Я, например, встречал такие фразы: "формирование/обновление пар с расчетом на мультичейн". Сам уже не помню, что это значит.

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

Заключение

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

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

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

Заказчики - обращайте внимание на подводные камни при заключении договора с Разработчиком.

Разработчики - смотрите, чтобы Заказчик не навесил на вас такие обязательства, которые вы не сможете потом выполнить.

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

Надеюсь материал оказался полезным, пишите комментарии, звоните, делитесь статьей с друзьями. Успехов!

0
Комментарии
-3 комментариев
Раскрывать всегда