Создание любого ИТ-продукта начинается с юридического оформления отношений – с заключения договора и определения взаимных обязательств. Договор понадобится и при разработке мобильного приложения, и при создании сложной нейросети. Многие предприниматели очень рискуют, считая разработку софта обычной услугой, похожей на ремонт офиса или поставку канцелярии. Они скачивают стандартный шаблон договора подряда из сети, подписывают его и думают, что полностью защищены. Подход к договору на программную разработку должен быть другим. В этой статье разбираем, почему в сфере ИТ стандартный подход не работает.
Практикующий юрист разобрал 7 главных ошибок, которые совершает бизнес при заключении договора на разработку программного обеспечения.
Практикующий юрист разобрал 7 главных ошибок, которые совершает бизнес при заключении договора на разработку программного обеспечения.
Ошибка 1. Использование стандартного договора подряда
Главная причина, почему рушатся отношения ИТ-компаний и программистов, – это использование обычных договоров оказания услуг. В Гражданском кодексе предмет такого соглашения формулируется как «осуществление определенной деятельности». Но заказчику не нужен абстрактный процесс, ему нужен конкретный результат – работающий программный код.
Профессиональный договор на разработку ПО кардинально отличается от обычного оказания услуг. Его предмет – это не просто написание строчек кода, а создание и отчуждение исключительных прав на объект интеллектуальной собственности. Если в тексте документа не прописаны правила отчуждения этих прав, компания платит исполнителю только за его рабочее время, но юридически не становится владельцем софта. Перед началом работы над любым цифровым проектом критически важно выстроить правильный legal-каркас. Чтобы не допустить базовых ошибок на старте, изучите также наш материал оюридической обвязке сайта. Подготовим юридически грамотный договор с разработчиком для защиты вашего софта
УЗНАТЬ БОЛЬШЕ
Профессиональный договор на разработку ПО кардинально отличается от обычного оказания услуг. Его предмет – это не просто написание строчек кода, а создание и отчуждение исключительных прав на объект интеллектуальной собственности. Если в тексте документа не прописаны правила отчуждения этих прав, компания платит исполнителю только за его рабочее время, но юридически не становится владельцем софта. Перед началом работы над любым цифровым проектом критически важно выстроить правильный legal-каркас. Чтобы не допустить базовых ошибок на старте, изучите также наш материал о
УЗНАТЬ БОЛЬШЕ
Ошибка 2. Иллюзия автоматического перехода прав на код
Владелец может размышлять: «Я заплатил за работу деньги, значит, код принадлежит моему бизнесу». Это достаточно распространенное и опасное заблуждение в ИТ-сфере. По закону автором любого произведения (включая программный код) всегда является физическое лицо, которое его создало, – то есть конкретный программист.
Заказчик не получает права автоматически по факту оплаты за разработку. Чтобы авторские права на программный код перешли к компании, в договоре должно быть прямо и недвусмысленно прописано условие по поводу отчуждения исключительных прав в полном объеме. Если этого пункта в договоре нет, разработчик вправе запретить вам использовать софт, продать этот же код вашим конкурентам или потребовать компенсацию за нарушение его интеллектуальных прав.
Заказчик не получает права автоматически по факту оплаты за разработку. Чтобы авторские права на программный код перешли к компании, в договоре должно быть прямо и недвусмысленно прописано условие по поводу отчуждения исключительных прав в полном объеме. Если этого пункта в договоре нет, разработчик вправе запретить вам использовать софт, продать этот же код вашим конкурентам или потребовать компенсацию за нарушение его интеллектуальных прав.
Ошибка 3. Отсутствие в договоре «авторского вознаграждения»
Даже если в вашем контракте написано, что все права переходят к компании, договор можно легко оспорить в суде, если в нем не выделено авторское вознаграждение. Закон требует, чтобы плата за разработку и плата за передачу прав на результат этой работы были разделены.
Если исполнитель получает общую сумму за «услуги по программированию», его юрист в суде может заявить, что права на софт не были оплачены, так как цена передачи интеллектуальной собственности не была согласована сторонами.
Как правильно? В тексте договора или в приложении к нему должно быть четко указано: «Стоимость выполненных работ составляет [Х] рублей, в том числе авторское вознаграждение за отчуждение исключительных прав – [Y] рублей». Это условие исключает любые притязания разработчика на созданный продукт.
Если исполнитель получает общую сумму за «услуги по программированию», его юрист в суде может заявить, что права на софт не были оплачены, так как цена передачи интеллектуальной собственности не была согласована сторонами.
Как правильно? В тексте договора или в приложении к нему должно быть четко указано: «Стоимость выполненных работ составляет [Х] рублей, в том числе авторское вознаграждение за отчуждение исключительных прав – [Y] рублей». Это условие исключает любые притязания разработчика на созданный продукт.
Ошибка 4. Некорректное оформление служебных произведений
Если софт пишут штатные сотрудники, риски те же. Чтобы код стал собственностью работодателя, он должен быть оформлен как служебное произведение. Простого наличия трудового договора недостаточно.
Чтобы зафиксировать переход прав от штатного программиста, необходима строгая цепочка документов:
Чтобы зафиксировать переход прав от штатного программиста, необходима строгая цепочка документов:
- Действующая должностная инструкция, где прямо прописана обязанность разрабатывать ПО.
- Официальное служебное задание на конкретный спринт или фичу с четкими техническими требованиями.
- Подписанный сторонами якорный акт приема-передачи служебного произведения по итогам выполнения задания.
Ошибка 5. Формальный NDA и отсутствие коммерческой тайны
Каждая компания подписывает с разработчиками соглашение о конфиденциальности. Но в настоящее время в 90% случаев этот документ является пустышкой. Сам по себе NDA с разработчиком не работает, если в компании не введен официальный режим коммерческой тайны.
Чтобы привлечь исполнителя к ответственности за слив кода или базы данных персональных данных клиентов, бизнес обязан выполнить ряд действий в связи с требованиями законодательства РФ:
Чтобы привлечь исполнителя к ответственности за слив кода или базы данных персональных данных клиентов, бизнес обязан выполнить ряд действий в связи с требованиями законодательства РФ:
- Утвердить положение о коммерческой тайне внутри компании.
- Нанести на все конфиденциальные документы и файлы специальный гриф защиты.
- Вести реестр лиц, получивших доступ к информации.
Ошибка 6. Размытое техническое задание и приемка работ «на честном слове»
Необходимо учесть, что проблемы могут возникнуть в связи с отсутствием конкретики в формулировках ТЗ вроде «разработать удобный личный кабинет». Если не составить надлежащим образом описание опций, функций, элементов и свойств будущего сервиса, информационной системы, электронного продукта или другой программной разработки, в будущем это приведет к спорам. Настоящее, а не формальное техническое задание не терпит абстрактных понятий, ведь представление об «удобстве» у всех разное.Без четких деталей разработчик принимает решения на свое усмотрение. Заказчик ждет одну логику, а исполнитель видит этот вопрос иначе. В результате весь период работы превращается в бесконечные споры и изменения кода. Новый релиз постоянно откладывается, потому что клиент просто не согласен с тем, что получилось. Это превращается в настоящее испытание для всех заинтересованных сторон.Чтобы разработка шла гладко, каждое техническое условие нужно расписывать до мелочей. Такая подготовка документа займет больше времени, зато позволит предусмотреть риски и обеспечить исполнение с учетом реальных требований. Также важно зафиксировать и другой момент: имя и контакты конкретного человека, который утверждает каждый соответствующий этап и принимает финальное решение.Вторая сторона этой проблемы – отсутствие фиксации момента передачи. Договор должен четко определять порядок и срок тестирования готового продукта заказчиком. Если в течение установленных рабочих дней после получения софта заказчик не направил мотивированный отказ, продукт должен считаться принятым. Любые изменения в логике программы после этого момента должны оформляться как дополнительные услуги за отдельную стоимость.
Ошибка 7. Отсутствие досудебного порядка урегулирования
Когда возникают судебные споры по разработке ПО, отсутствие одной строчки в контракте может заморозить работу компании на месяцы. Если в тексте не прописан обязательный претензионный порядок, вы не сможете оперативно подать иск в суд.
В безопасном договоре юрист всегда фиксирует:
В безопасном договоре юрист всегда фиксирует:
- Четкий порядок расторжения соглашения в одностороннем порядке в случае, если исполнитель срывает сроки.
- Обязанность разработчика передать заказчику все исходные коды и доступы к репозиториям на основании части выполненных и оплаченных работ, даже если полный объем проекта еще не завершен.
Как выглядит безопасный договор с разработчиком
Безопасный, юридически чистый, договор должен быть заключен в строгом соответствии с действующим законодательством, иметь четкий предмет, детальное ТЗ, прописанные правила использования сторонних библиотек (Open Source) и прозрачные условия оплаты.
Качественное оформление документов и регулярный аудит отношений с исполнителями – главная инвестиция в безопасность цифровых активов вашего бизнеса.Хотите проверить текущий договор на ИТ-разработку на критические ошибки?
СВЯЗАТЬСЯ
Качественное оформление документов и регулярный аудит отношений с исполнителями – главная инвестиция в безопасность цифровых активов вашего бизнеса.Хотите проверить текущий договор на ИТ-разработку на критические ошибки?
СВЯЗАТЬСЯ
