Кому принадлежит продукт, в который вы вкладываете

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

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

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

После переделок я смотрю на всю историю прав

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

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

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

Придумать игру и получить права на написанную для неё программу — разные вещи. ВОИС объясняет, что авторское право защищает форму выражения, включая компьютерные программы, но не саму идею. Поэтому мне недостаточно услышать, что концепцию придумал основатель. Мне нужно выяснить, какие части разработки компания вправе использовать и менять на основании договоров и закона.

Договор должен относиться к тому продукту, который работает

Я бы попросил сопоставить существенные части приложения с договорами и документами передачи результата. У меня перед глазами должен оказаться понятный перечень: собственный код, графика, интерфейс, материалы, созданные на заказ. Напротив каждой позиции — основание использования. Это помогает заметить, когда общее обещание передать результат в договоре никак не связано с тем, что действительно было сделано.

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

В рекомендациях Cooley для молодых компаний отдельно рассматриваются соглашения о правах с сотрудниками, включая основателей, и договоры с подрядчиками. Авторы также указывают на различия законодательства. Основатель тоже мог писать программу до оформления отношений с компанией. Мне нужно понять, как передана его работа, равно как и работа остальных сотрудников. Рекомендации Cooley относятся к американским компаниям; юрист проверит подходящие условия по законам, которым подчинены наши документы.

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

Доступ к исходникам помогает продолжать разработку

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

Я предложил бы показать сборку приложения из переданных материалов. Инженер получает комплект материалов и показывает работающую сборку, которую можно установить и запустить. Если без помощи прежнего подрядчика это не получается, становится понятно, какие материалы ещё нужны. Юрист при этом разбирает право на изменение программы. Я могу увидеть, что приложение собирается, и всё ещё должен выяснить, вправе ли компания его менять и распространять.

В Diaverse уже более 150 000 установок. Я думаю и о том, что будет с уже выпущенной игрой при смене исполнителя. Я чувствую ответственность перед людьми, пришедшими в игру. Исправление может понадобиться и тогда, когда прежний разработчик уже ушёл, а новый ещё не получил все материалы. Поэтому на месте инвестора я интересовался бы передачей материалов для исправлений ещё до того, как возникнет необходимость срочно искать другого специалиста.

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

Сторонний код может быть нормальной частью продукта

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

Open Source Initiative поясняет, что открытое программное обеспечение допускает коммерческое использование. У некоторых лицензий есть условие: при передаче программы другим людям нужно предоставить её на той же лицензии. Это называют copyleft. Я не делаю из наличия открытого кода вывод, что компания должна раскрыть всё приложение. Здесь специалисту нужно сопоставить конкретную лицензию, способ соединения компонентов и то, как продукт передаётся пользователю.

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

Сколько денег останется после замены компонента

Вот условный пример, не показатели Diaverse. Компания планирует привлечь $200 000 на развитие приложения. Выясняется, что для выбранного способа распространения ключевой компонент нужно заменить. Инженер оценивает замену в $40 000, а работа займёт 2 месяца с дополнительными расходами компании $15 000 в месяц. Допустим, других последствий в нашем расчёте нет.

Сначала считаю расходы за время замены: 2 × $15 000 = $30 000. Прибавляю саму разработку: $30 000 + $40 000 = $70 000. Из привлечённых $200 000 остаётся $130 000 на первоначально намеченное развитие. Значит, ещё до начала этого развития компания направит 35% вложения на замену компонента и расходы за время этой работы.

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

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

Что я обсуждаю перед первым внешним раундом

С первым внешним раундом $300K я хочу быстрее развивать Diaverse и расширять продажи в других странах. Для этого компания должна располагать правами на приложение. На встрече со мной можно обсудить документы по сделке и поставить вопросы о разработке; правовую проверку я предлагаю вести со специалистами инвестора.

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

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

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