«Мы за это заплатили, значит, оно принадлежит нам» — таково распространённое предположение. Верно ли это, полностью зависит от содержания договора, а при отсутствии соответствующего пункта законодательство многих юрисдикций по умолчанию благоприятствует разработчику.
Что должно охватывать право собственности
Договор, надлежащим образом регулирующий этот вопрос, отдельно охватывает четыре аспекта:
- Индивидуальный исходный код, написанный специально для этого проекта.
- Дизайн-материалы — экраны, значки, иллюстрации и редактируемые исходные файлы, а не только экспортированные изображения.
- Данные — всё, что хранит приложение и что должно недвусмысленно принадлежать клиенту.
- Документацию — спецификацию, заметки по архитектуре, инструкции по развёртыванию.
Ищите пункт, согласно которому право собственности на индивидуально разработанные материалы переходит к клиенту после окончательной оплаты. Важны две детали: переход должен происходить именно после оплаты, а не при наступлении какого-либо более позднего события, и должно быть прямо указано, что он включает исходные файлы дизайна, о которых часто забывают и которые впоследствии бывает сложно получить.
Чем вы не можете владеть
Некоторые компоненты лицензируются, а не передаются в собственность, и это нормально:
- Библиотеки с открытым исходным кодом. Их используют многие современные приложения. Они поставляются с собственными лицензиями, большинство из которых свободно разрешает коммерческое использование. Важно, чтобы лицензии соответствовали вашему сценарию использования — запросить их список вполне разумно.
- Коммерческие компоненты — платная библиотека для построения графиков, лицензированный шрифт, приобретённый шаблон. На них могут распространяться лицензии на проект, разработчика или развёртывание, и лицензию необходимо передать вам либо приобрести повторно.
- Ранее существовавший код фреймворка разработчика. Многие агентства повторно используют внутренние инструменты в разных проектах. Это законно и обычно выгодно, но вам должна быть предоставлена бессрочная лицензия, а вопрос не должен оставаться неопределённым — иначе часть вашего приложения принадлежит кому-то ещё.
Стоковые изображения — постоянная проблема. Изображения, лицензированные для макета, иногда не лицензированы для использования в рабочем продукте, и обнаружить это после запуска дорого. Стоит потратить пять минут и спросить, откуда взято каждое изображение.
Пакет передачи проекта
Проверка передачи проста: сможет ли компетентный разработчик, который никогда не видел этот проект, принять его? Для этого необходимы:
- Полный репозиторий с историей изменений, переданный в аккаунт, который контролирует клиент. История коммитов важна — именно благодаря ей новый разработчик понимает, почему всё устроено так, как устроено.
- Инструкции по развёртыванию, достаточно подробные для восстановления окружения с нуля.
- Конфигурация окружения — какие настройки существуют, за что они отвечают и какие из них являются секретами.
- Все учётные данные аккаунтов — хостинга, домена, базы данных, сторонних сервисов, магазинов — переданные в собственность клиента.
- Схема базы данных и соответствующие скрипты миграции.
- Перечень сторонних сервисов с указанием назначения каждого из них и его стоимости.
- Исходные файлы дизайна.
- Известные проблемы и отложенные задачи, честно зафиксированные в документации.
Последний пункт стоит запросить отдельно. В каждом проекте есть известные компромиссы, и разработчик, готовый задокументировать их, предоставляет клиенту действительно ценную информацию.
Проверка работоспособности передачи
Наиболее надёжная проверка — попросить независимого специалиста развернуть приложение только на основании пакета передачи в новом окружении, не задавая исходному разработчику никаких вопросов. Если это удаётся, передача действительно состоялась.
Провести такую проверку, пока отношения остаются хорошими, намного проще, чем после их завершения. Разумно привязать к этому небольшую часть окончательного платежа.
Эскроу
Если разработчик сохраняет код у себя — что иногда бывает при использовании платформенных решений или подписочных моделей, — эскроу исходного кода предусматривает передачу копии третьей стороне с последующим предоставлением её клиенту при наступлении оговорённых условий, например прекращении деятельности разработчика.
Это стоит денег и требует дополнительного администрирования, поэтому такой подход в основном оправдан, когда приложение критично для бизнеса, а разработчик — небольшая компания. Для большинства небольших проектов простая передача прав собственности в сочетании с проверенной передачей проекта даёт больше результата при меньших затратах.
Урегулируйте всё до начала работ
- Кому принадлежит индивидуальный код и с какого момента.
- Включены ли исходные файлы дизайна.
- Как лицензируется ранее существовавший код разработчика.
- Что данные недвусмысленно принадлежат клиенту и предоставляются в экспортируемом формате.
- Что входит в пакет передачи проекта.
- Что аккаунты с самого начала создаются на имя клиента.
Связанные услуги Manboo
- Разработка приложений на Flutter для MVP под iOS и Android.
- Разработка бизнес-программного обеспечения для CRM, систем бронирования, управления запасами и рабочих процессов.
- Разработка административных панелей для операционных дашбордов и управления серверной частью.
- Интеграция AI API, когда ваш продукт готов к интеллектуальному поиску, чату или автоматизации.
- Запросить оценку объёма работ и стоимости проекта, когда вы готовы спланировать первую версию.