Права на цифровую систему для бизнеса: какие части договора стоит проверить перед расставанием с подрядчиком?

Если ваш подрядчик завтра исчезнет, сможете ли вы за неделю передать проект другой команде? Большинство заказчиков, которым задают этот вопрос, отвечают уверенно: «Конечно, у нас же всё оплачено». А потом выясняется, что оплата и владение — совсем не одно и то же.

Вот история, которую в разных вариантах рассказывают многие руководители: владелец сети магазинов шесть лет работал с одной студией: она сделала сайт, личный кабинет покупателя и мобильное приложение. Когда обслуживание стало дорожать, а сроки — растягиваться, он решил сменить исполнителя. Новая команда попросила доступ к хранилищу исходного кода.

Оказалось, что оно создано на учётной записи старой студии. Доменное имя сайта было оформлено на сотрудника, который давно уволился, приложение значилось в магазине приложений от имени студии, а в договоре стояла фраза «результат работ передаётся заказчику», и ни слова о том, кому принадлежат права на саму программу.

Переезд, который планировали на месяц, занял почти полгода и стоил как половина первоначальной разработки. Чтобы с вами такого не случилось, разберёмся, из чего на самом деле состоит владение программой и что стоит проверить, пока отношения с подрядчиком хорошие.

Три вида «владения», которые легко перепутать

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

Владение программой тоже складывается из трёх слоёв.

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

Потерять можно любой слой, и последствия у каждого свои. Без прав вы не можете законно развивать продукт. Без доступов не можете до него добраться. Без знаний можете и добраться, и развивать, но дорого и медленно, потому что любой новый исполнитель начнёт с долгих «раскопок».

Разбираемся в правах

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

Здесь есть тонкость, о которой редко думают. Автор программы — не студия, а конкретные люди: штатные программисты, дизайнеры, а часто и сторонние исполнители, которых студия привлекла на время. Чтобы передать вам права, студия сама должна сначала получить их от каждого из них. Такую последовательность называют цепочкой прав. Если в ней есть разрыв, например с внештатным разработчиком договорились на словах, студия не сможет передать вам больше, чем имеет сама.

Поэтому к вопросу «Передадите ли вы нам права?» полезно добавить второй: «А у вас они есть на весь код, включая тот, что писали не штатные сотрудники?»

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

Разницу проще всего увидеть на примере. Если право передано вам, вы можете завтра отдать код другой студии, продать продукт вместе с бизнесом или запустить его в другой стране. Если вам дали лицензию, каждое из этих действий потребует отдельного разрешения подрядчика, и он вправе назначить за него цену. Часто лицензия перечисляет способы использования, например «на сайте». Тогда мобильное приложение на основе того же кода может оказаться за её рамками, ведь всё, что в договоре прямо не названо, в ряде правовых систем считается непереданным.

И то и другое законно. Беда начинается, когда заказчик уверен, что купил квартиру, а на деле снял её. Чаще всего подвох прячется в оговорках: права могут переходить только после полной оплаты всех этапов, включая спорные, лицензия может оказаться неисключительной, и тогда подрядчик вправе продать то же самое вашему конкуренту. Её могут ограничить сроком, территорией или числом пользователей, а права на «готовые наработки» подрядчика, как правило, остаются у него.

Вот как расшифровываются фразы, которые встречаются в договорах чаще всего. Строка «результат работ передаётся заказчику» не говорит, что вам передаётся право на программу: возможно, вы получаете лишь её рабочую копию, поэтому стоит вписать прямо исключительное право на программу, исходный код и документацию.

Условие «права переходят после полной оплаты» означает, что пока есть неоплаченный этап или спор о нём, владелец — подрядчик, так что уточните, какие платежи считаются решающими. «Неисключительная лицензия» позволяет подрядчику выдать такую же вашим конкурентам. «Лицензия на три года» или «на 500 пользователей» вернёт вас за стол переговоров, когда срок закончится или аудитория вырастет.

Отдельного разговора заслуживают те самые «готовые наработки». Студии редко пишут всё с нуля: у многих есть собственные заготовки и внутренние библиотеки, которые ускоряют работу и делают её дешевле, и в этом нет ничего плохого. Важно понимать, что именно остаётся за подрядчиком и можете ли вы пользоваться этими частями после расставания.

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

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

После такой проверки у вас должны быть ясные ответы на пять вопросов:

• Что именно передаётся: программа, исходный код, документация, оформление, базы данных?
• Это право или лицензия, исключительная она или нет?
• С какого момента и при каких условиях это происходит?
• На какой срок, в какой стране и для каких способов использования?
• Что с наработками исполнителя и чужими компонентами?

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

Чужие кирпичики внутри вашей программы

О втором слое прав заказчики почти не знают. Современная программа на большую часть собрана из чужих готовых частей: библиотек с открытым исходным кодом, платных компонентов, готовых модулей. Это как строить дом из покупных блоков, и это разумно: никто не печёт кирпичи сам.

Что здесь считается «чужим»? Не только библиотеки кода. Это ещё платные компоненты (например, готовый модуль оплаты или карт), шаблоны оформления, шрифты, иконки, фотографии и подключаемые облачные услуги. Всё это можно не заметить, потому что снаружи программа выглядит единым целым. Но у каждого элемента есть свой автор, а значит, и свои условия.

У каждого такого блока своя лицензия: одни разрешают почти всё, другие требуют, чтобы вы открыли исходный код всего своего продукта, третьи запрещают коммерческое использование. Если подрядчик взял компонент с неподходящими условиями, об этом обычно узнают в самый неудобный момент: при продаже бизнеса, проверке инвесторов или споре с правообладателем.

Условия бывают очень разными, и полезно знать хотя бы четыре основных типа.

• Свободные лицензии с простыми условиями разрешают использовать код в коммерческих продуктах, менять и распространять его, но обычно требуют сохранить указание автора и текст лицензии, о чём часто забывают.
• Лицензии с обязательным открытием кода бесплатны, зато при распространении программы могут потребовать открыть и исходный код вашей собственной части, что не подходит закрытым продуктам.
• Платные лицензии и лицензии с ограничениями ставят лимиты по числу пользователей, серверов или сроку, а подписку приходится продлевать, и оформлена она может быть на подрядчика.
• Лицензии только для некоммерческого использования запрещают такой код в продукте, который приносит деньги.

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

Попросите перечень сторонних компонентов с указанием лицензий. У грамотной команды он есть или собирается за несколько часов. Если вам отвечают «а зачем вам это», это повод насторожиться.

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

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

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

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

Доступы: у кого на самом деле ключи

Это самая «земная» часть и самый частый источник беспорядка. Пройдитесь по всему, что нужно программе для жизни, и для каждого пункта выясните, на кого он оформлен:

• Хранилище исходного кода. Оно должно быть создано на вашу организацию, а подрядчику выданы права участника, иначе у вас нет самой программы.
• Серверы и облачные услуги. Договор и оплата должны быть на вашей компании, а не на карте сотрудника подрядчика.
• Домен и сертификаты защиты соединения. Они должны быть вашими, а письма о продлении приходить на рабочую почту; владельца домена легко проверить в открытой справке о нём.
• Магазины мобильных приложений. Учётная запись разработчика должна принадлежать вам: иначе перенос займёт недели, и всё это время приложение нельзя обновлять.
• Платёжные системы, рассылки, внешние сервисы. Их остановка означает потерянные платежи и письма.
• Пароли и ключи шифрования. Они должны лежать в общем защищённом хранилище, куда есть доступ и у вас, иначе данные могут стать нечитаемыми.
• Базы данных и резервные копии. Копии должны быть у вас или на вашей учётной записи, а восстановление из них хотя бы раз проверено на тестовом сервере.

Типичные сюжеты звучат так.

Домен на уволившегося: доменное имя оформили на сотрудника студии, он ушёл. Продлить имя некому, а срок истекает. Сайт может пропасть вместе с адресом, который вы годами печатали на упаковке.

Приложение «чужое»: приложение опубликовано от имени компании подрядчика. Перенос в вашу учётную запись возможен, но занимает недели, а всё это время обновления выпускать нельзя.

Сервер на личной карте: серверы оплачиваются с карты разработчика. Карта заблокировалась, и сайт лёг посреди распродажи.

Коды подтверждения уходят не вам: для входа в важные кабинеты используется почтовый ящик разработчика. Забыли пароль или решили сменить доступ, а код приходит человеку, который давно с вами не работает.

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

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

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

И напоследок совет, который кажется чрезмерным, пока не пригодится: храните аварийный набор доступов в запечатанном виде у двух доверенных людей компании: например, в сейфе у руководителя и у юриста. Открывать его придётся редко, но в день, когда это понадобится, вы будете рады, что он есть.

Знания: что остаётся в головах

Допустим, права у вас, ключи тоже. Новая команда открывает хранилище кода, и ей становится не по себе: непонятно, как запускать, где настройки, почему здесь «временное решение» трёхлетней давности. Без описания устройства системы каждый новый исполнитель тратит недели, и оплачиваете их вы.

Что должно быть записано? Прежде всего схема устройства: из каких частей состоит система и как они связаны. Затем порядок развёртывания, то есть как с нуля поднять рабочую копию. Далее список внешних подключений вроде платёжных систем, почты и учётных сервисов, а также особенности и «костыли»: всё, что сделано нестандартно, и почему. И, наконец, порядок обновления, чтобы новые версии выходили без аварий.

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

Как расставаться по-хорошему

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

1. 1. Не объявляйте о расставании сразу. Сначала убедитесь, что доступы и копии кода у вас в руках.
2. 2. Запросите полную выгрузку: исходный код, базы данных, описание системы и перечень учётных записей.
3. 3. Проверьте, что всё работает. Поручите новой команде или независимому специалисту собрать и запустить программу только из переданных материалов. Если не получается, значит, чего-то не хватает.
4. 4. Смените все пароли и ключи, чтобы доступы остались только у тех, кому они нужны.
5. 5. Проведите совместные «учения». Пусть прежний исполнитель покажет новой команде, как запускать и обновлять систему. Это самый быстрый способ закрыть пробелы в знаниях.
6. 6. Подпишите акт передачи с перечнем всего переданного.

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

Десять вопросов, пока вы ещё дружите

Хороший договор и порядок в доступах нужны не из недоверия. Они нужны для спокойствия обеих сторон: подрядчик знает, за что отвечает, а вы знаете, чем владеете. Задайте своей команде эти вопросы сегодня, а не в день ссоры.

1. 1. На каком основании и с какого момента ко мне переходят права?
2. 2. Передаётся право целиком или даётся лицензия?
3. 3. Какие готовые наработки остаются у вас?
4. 4. Какие сторонние компоненты вы используете и на каких условиях?
5. 5. На кого оформлены сервер, домен и учётные записи?
6. 6. Где хранится исходный код и кто имеет к нему доступ?
7. 7. Как часто делаются резервные копии и кто может их восстановить?
8. 8. Есть ли описание устройства системы и кто его обновляет?
9. 9. Что произойдёт при расторжении договора и в какие сроки вы передадите дела?
10. 10. Кто, кроме вас, сможет разобраться в проекте?

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

Разработка ПО от 66 Бит

Всего за 10 минут вы разобрались в сложной юридической теме и получили знания, которые способны сохранить ваш бюджет и репутацию. Самое сложное в разработке цифровых систем для бизнеса – выбор добросовестного подрядчика. Именно поэтому мы советуем вам обратиться в 66 Бит!

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