Разработка ПО на заказ: как компании правильно оформить отношения с разработчиками
— Чтобы избежать такой ситуации, недостаточно записать в договоре «разработать программное обеспечение» и согласовать цену, — говорит старший юрист юридической фирмы Art Legal Матвей Городник. — Нужно заранее определить, какой результат получит заказчик, какие права на него приобретет и сможет ли продолжить работу без первоначальной команды. Отдельного внимания заслуживает актуальный сегодня вопрос использования ИИ. Здесь к обычным договорным вопросам добавляются риски, связанные с происхождением кода и передачей информации внешним сервисам.
О чем статья?
Работающая программа, права на нее и исходники — это не одно и то же
При заказной разработке полезно разделять три результата: готовый продукт («работает ли программа так, как мы договорились?»), права на него («что нам юридически разрешено с ней делать?») и техническую возможность им управлять («сможем ли мы ее поддерживать и развивать без этого подрядчика?»).
Компьютерная программа охраняется авторским правом, в том числе в форме исходного текста и объектного кода. Обязательная регистрация для возникновения авторского права не требуется.
При оформлении прав принципиально различать два механизма:
-
уступка исключительного права означает его отчуждение заказчику в полном объеме;
-
лицензия дает право использовать программу в установленных пределах. Даже исключительная лицензия не равнозначна приобретению самого исключительного права.
Для бизнеса выбор зависит от задачи.
Если создается продукт для последующей продажи, привлечения инвестиций и самостоятельного развития, разумно добиваться исключительного права на специально разработанные элементы.
Если компания заказывает настройку готовой платформы, реалистичной моделью может быть лицензия на платформу и отдельное оформление прав на доработки.
Но ни один вариант не заменяет передачу технических материалов. Можно приобрести права и при этом не получить комплект, с которым другая команда сможет продолжить разработку. Поэтому вне зависимости от формулировок в договоре всегда надо задавать себе вопрос, что именно останется у компании, если завтра подрядчик перестанет отвечать.
Почему типовой договор может не сработать
1. Результат описан слишком абстрактно
Абстрактные формулировки типа «разработать удобную CRM» и «создать современный сайт» могут подойти для первичных переговоров, но не для приемки результата.
Представим, что заказчик ожидает автоматического расчета скидок, а разработчик предусмотрел только поле для ручного ввода. Обе стороны могут искренне считать свое понимание правильным.
Поэтому в техническом задании крайне рекомендуется описывать не только экраны и кнопки, но и конкретные действия пользователя, правила обработки данных, интеграции и проверяемый результат.
2. Цена согласована, а порядок ее изменения — нет
На практике заказчик очень часто просит добавить небольшую функцию. Иногда возникает ситуация, когда разработчик делает ее, а затем выставляет дополнительный счет, когда заказчик полагал, что это входит в общую стоимость.
Чтобы не выяснять стоимость изменений постфактум, полезно установить последовательность таких действий. Например, запрос заказчика, потом оценка влияния на цену и сроки, потом согласование уполномоченным лицом и только затем выполнение.
Отдельно стоит определить, кто вправе менять бюджет. Возможность сотрудника обсуждать интерфейс не должна автоматически означать право влиять на финансовые вопросы.
3. Демонстрацию принимают за полноценную приемку
Зачастую демонстрация приложения проводится самим разработчиком, после чего заказчику сразу же предлагается подписать акт.
Для приемки лучше заранее определить тестовую среду, проверяемые сценарии, срок испытаний и перечень недостатков, препятствующих принятию результата. Также заранее стоит определиться с разграничением ошибок и новых пожеланий, иначе любое исправление рискует превратиться в платную доработку.
Особенно внимательно следует читать условие о приемке при отсутствии возражений. Если договор предлагает считать результат принятым через несколько дней, нужно оценить, реально ли за это время провести проверку и кто в компании отвечает за ответ.
4. Чужой код считают бесплатным и ничем не ограниченным
Доступность кода в интернете сама по себе не дает права свободно включать его в коммерческий продукт.
У открытых лицензий есть условия. Например, предоставление исходного кода получателям распространяемого ПО, охватываемого этой лицензией. Конкретные последствия зависят от лицензии, состава продукта и способа использования компонентов.
Поэтому заказчику стоит запросить перечень сторонних компонентов с указанием версий и лицензий. Для компонентов, условия которых могут повлиять на продажу продукта или раскрытие его кода, желательно предусмотреть предварительное согласование.
5. Все технические ресурсы остаются у разработчика
При разработке приложения очень много не самых явных элементов может оказаться оформлено на исполнителя или вообще конкретного программиста. Например, репозиторий с кодом, облачный сервер, домен и учетная запись для публикации приложения.
Решать вопрос принадлежности и передачи этих ресурсов лучше до запуска. Для критичных элементов разумно использовать учетные записи компании-заказчика, предоставляя разработчику необходимые полномочия.
Как организовать работу над проектом
Уровень 1. Зафиксировать понятный объем разработки
Не каждому проекту требуется техническое задание на 100 страниц. Важнее, чтобы документы позволяли определить, что входит в работу, а что — нет.
Для небольшого проекта в принципе могут подойти спецификация, прототипы экранов и перечень пользовательских сценариев. А уже для сложного продукта можно рассматривать рамочный договор и согласуемые задания на отдельные этапы.
Уровень 2. Установить правила общения и согласования
Полезно закрепить рабочие адреса электронной почты, систему постановки задач, ответственных лиц и пределы их полномочий.
Например, технический специалист заказчика согласует детали реализации, руководитель проекта — завершение этапа, а директор — увеличение бюджета.
Уровень 3. Связать оплату с понятными обязательствами
При фиксированной цене целесообразно привязывать платежи к согласованным этапам и результатам.
При почасовой оплате следует определить ставки, правила учета времени, состав отчетов и бюджетные ограничения. Для заказчика особенно полезен предел расходов, превышение которого требует отдельного согласования.
Уровень 4. Получать материалы по ходу проекта
Исходники рекомендуется передавать не одним архивом в последний день, а регулярно (например, через согласованное хранилище кода).
В комплект результата стоит включить инструкции по сборке и запуску программы, описание настроек, структуру базы данных, сведения о зависимостях и иные необходимые технические документы.
В идеале надо стремиться к тому, чтобы другая техническая команда имела возможность развернуть продукт по переданным материалам, не обращаясь к первоначальному разработчику за пояснениями.
Что предусмотреть в договоре с разработчиком
При работе непосредственно с физическим лицом (автором) применяется конструкция договора о создании и использовании объекта авторского права. Она предполагает письменную форму, согласование создаваемого произведения, срока, вознаграждения за создание и порядка его выплаты, а также условий передачи права или предоставления использования. В этом кейсе необходимо помнить, что личные права автора нельзя купить, а условие об отказе от личных неимущественных прав ничтожно. Вместо такой формулировки следует урегулировать необходимые согласия на изменение произведения и порядок указания имени автора.
При работе с компанией-разработчиком договор может сочетать разные элементы: выполнение работ, оказание услуг, передачу исключительного права и лицензирование готовых компонентов.
Практически договор стоит проверить по следующим вопросам:
|
Вопрос |
Что рекомендуется зафиксировать |
|
Что создается? |
Состав программы, этапы, документация, дизайн и иные результаты, которые заказчик должен получить. |
|
За что платит заказчик? |
Стоимость разработки, порядок оплаты и вознаграждение за передачу или предоставление прав. |
|
Какие права передаются? |
Уступается исключительное право или предоставляется лицензия; на какие именно результаты распространяется соответствующее условие. |
|
Когда заказчик получает права? |
Конкретное событие: приемка этапа, оплата или иной согласованный момент. Права на промежуточные результаты при досрочном прекращении проекта. |
|
Как принимается результат? |
Комплект передачи, проверяемая версия, порядок испытаний, мотивированных замечаний и повторной приемки. |
|
Что происходит после запуска? |
Срок и порядок исправления недостатков; отличие гарантийных исправлений от платной поддержки и нового функционала. |
|
Как прекратить сотрудничество? |
Расчеты, передача незавершенного результата, документации и доступов, содействие новой команде. |
Отдельно стоит упомянуть также вопросы конфиденциальности и защиты персональных данных. Желательно определить, какие материалы разработчик получает, где вправе их хранить, кому передавать и может ли использовать проект в портфолио. Если разработчик обрабатывает персональные данные по поручению заказчика, одного NDA недостаточно. По законодательству в договоре необходимо определить цели обработки, действия с данными, обязанности по конфиденциальности и меры защиты.
Как оформить отношения со штатными программистами
Считать, что если сотрудник получает зарплату и работает на корпоративном ноутбуке, то любой написанный им код принадлежит компании, слишком рискованно.
Такой вывод слишком широкий. Для служебного произведения важна связь его создания с трудовыми обязанностями и заданием нанимателя. Исключительное право на служебное произведение по общему правилу переходит нанимателю с момента создания, если договором с автором не предусмотрено иное.
Поэтому компании желательно обеспечить понятную документальную цепочку. Обязанности по разработке должны быть закреплены в трудовых документах, задания должны выдаваться и сохраняться, а результаты должны быть соотнесены с конкретными задачами и версиями кода.
Причем речь здесь идет не о том, что обязательно нужно составлять отдельный бумажный акт на каждое изменение. Достаточно выстроить процесс, в котором трудовые документы, система задач и история разработки согласуются между собой.
Ранее созданные личные разработки сотрудника следует рассматривать отдельно. Например, если программист предлагает встроить в продукт собственный модуль, написанный до трудоустройства, разумно заранее оформить условия его использования, а не считать вопрос решенным выдачей зарплаты.
Есть и важный нюанс белорусского законодательства: если наниматель в течение пяти лет не начнет использовать служебное произведение и не передаст исключительное право другому лицу, право переходит к автору, если договором не установлено иное. Для долгосрочных и временно замороженных проектов это условие стоит проверить отдельно.
Что меняется при разработке с помощью ИИ
1. Вопросы возникновения исключительного права
Белорусское законодательство связывает авторство с творческим трудом физического лица. Поэтому для автоматически сгенерированного результата без творческого вклада человека нельзя уверенно обещать обычную авторско-правовую охрану. Условие пользовательского соглашения сервиса о принадлежности результата само по себе не заменяет предусмотренные законом основания охраны.
При этом использование ИИ как инструмента не означает, что вся программа лишается охраны. Принципиально различать человеческий творческий вклад и машинную генерацию. Иными словами, для значимых элементов продукта рекомендуется сохранять историю разработки, человеческих изменений и принятых решений. В этом случае, полагаем, защищенность продукта возрастает.
2. Конфиденциальность материалов при загрузке в ИИ-сервис
Нередкими в последние дни являются ситуации, когда, например, программист отправляет нейросети фрагмент базы клиентов, чтобы быстрее найти ошибку. При этом хоть заказчик и разрешил разработчику работать с этой базой, но это еще не означает согласие на ее передачу внешнему сервису.
Использование зарубежной облачной инфраструктуры для персональных данных может являться трансграничной передачей. Ее допустимость необходимо проверять с учетом законодательства о защите персональных данных, включая страну передачи и применимое основание.
Поэтому в договоре и (или) внутренних правилах желательно определить разрешенные инструменты и категории данных. Передачу клиентских баз, паролей, ключей доступа и конфиденциальных материалов в несогласованные сервисы разумно запретить.
3. Условия ИИ-сервиса нужно проверять до его использования
В идеальном варианте заказчику стоит согласовать не только сам инструмент, но и конкретный вариант его использования.
Рекомендуется проверить, допускается ли нужное коммерческое применение, какие условия установлены для входных материалов и результата, сохраняются ли переданные данные, используются ли они для обучения, какие ограничения действуют для выбранной учетной записи.
Для критичных частей программы можно предусмотреть учет использования ИИ (какие инструменты применялись, для каких задач и как результат был проверен).
4. Использование ИИ не должно становиться оправданием недостатков
Нейросети не заменяют проверку результата. Несмотря на очень высокий уровень разработки современных ИИ, нельзя исключать ошибки, уязвимости и совпадения с публичным кодом. Проверять и тестировать продукт все равно необходимо.
С разработчиком сразу стоит договориться о том, что использование ИИ не снижает согласованные требования к качеству, безопасности и соблюдению прав третьих лиц, равно как и о его обязанности устранить выявленные проблемы.
5. Нужно договориться, как ИИ влияет на расчеты
Крайне актуальным становится вопрос о том, как использование ИИ должно влиять на оплату разработчику.
При фиксированной цене в этом смысле проще, поскольку следует оценивать результат и соблюдение согласованных требований, а не количество вручную набранных строк.
Для почасовой оплаты ситуация сложнее. В идеальном варианте стоит отдельно определить учет фактического времени специалистов и расходы на ИИ-сервисы, чтобы автоматическая операция не отражалась в отчете так, будто сотрудник выполнял ее вручную условно весь рабочий день.
Отдельная ситуация, когда ИИ встроен в сам продукт. Например, приложение обращается к внешней модели для обработки запросов пользователей. Здесь сторонам важно согласовать стоимость таких обращений, владельца учетной записи, порядок передачи данных и действия при недоступности сервиса.
Что делать, если проект остановился или нужно сменить команду
Шаг 1. Сохранить доказательства
В пределах имеющегося доступа выгрузить актуальный код, историю изменений, задания, переписку, отчеты, документы о приемке и оплате. Отдельно зафиксировать, что работает, какие недостатки выявлены и какие материалы не переданы.
Шаг 2. Сопоставить результат с договором
Определить, какие обязательства уже выполнены, какие сроки нарушены, какие права приобретены и что должен передать разработчик.
Шаг 3. Направить конкретное требование
Перечислить несоответствия, договорные основания и требуемые действия (например, исправить ошибки, передать определенную версию исходников и предоставить документацию).
Шаг 4. Организовать передачу проекта
Проверить не только наличие архива с кодом, но и возможность сборки и запуска, передачу данных и настроек, а также доступы к инфраструктуре. Пароли и ключи после передачи следует заменить.
Шаг 5. Оформить завершение отношений
В соглашении о прекращении договора желательно зафиксировать окончательные расчеты, состав переданных результатов, сохраняющиеся права заказчика, обязанности по конфиденциальности и порядок дальнейшего использования либо удаления оставшихся у подрядчика материалов.
В качестве вывода можно резюмировать, что хорошо оформленная заказная разработка заканчивается не красивой демонстрацией, а тем, что у бизнеса есть согласованный результат с необходимыми правами и возможность продолжить работу с другой командой.
Фото: Envato Elements
