Как основателям IT-стартапа оформить партнёрские отношения до создания общей компании

Приветствую! Меня зовут Евгений Рябов, я корпоративный и инвестиционный юрист, автор книги "Стартап и инвестор: правила игры", в прошлом основатель legal-tech стартапа. В этой статье я отвечу на один из самых популярных вопросов в стартап-среде — как грамотно оформить отношения сооснователей на самой ранней стадии (стадии, предшествующей созданию общей компании). 

Как часто происходит создание стартапа: человек, у которого есть идея, видение того, как её реализовать и чем конкретно реализация идеи может быть полезна обществу (целевой аудитории), находит человека, который своими руками может помочь эту идею воплотить в реальность. Они знакомятся, общаются, и если происходит партнёрский «матч», то они согласовывают порядок действий по тестированию гипотезы, созданию первой версии продукта (MVP) и приступают к реализации. Первый сооснователь (как правило, предприниматель) обычно формирует ТЗ, второй (как правило, технарь) ТЗ технически (физически) реализует.

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

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

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

Поскольку первую версию продукта своими собственными руками чаще всего создаёт сооснователь-технарь (если берём IT-стартап, такой основатель является программистом), то он и становится автором программного обеспечения (я сейчас сознательно допускаю, что такой основатель является фулстек-разработчиком и самостоятельно в одиночку поднимает MVP, что кстати, бывает нередко). А поскольку он является автором разработанного софта, то у другого сооснователя возникают непропорциональные риски, связанные с полным присвоением техническим основателем созданного в соответствии с ТЗ продукта, даже не смотря на то, что его идея изначально принадлежала сооснователю-предпринимателю и последним для обеспечения создания продукта были потрачены те или иные ресурсы. При этом, судебное разбирательство, особенно в российской юрисдикции, в данном конкретном кейсе может вообще ничем не помочь сооснователю-предпринимателю.

Выходом из этой ситуации (на этапе до создания компании) является заключение сооснователями партнёрского соглашения, которое включает в себя:

• договорённость о совместном создании проекта и внесении совместных вкладов в это дело;

• договорённость о создании в будущем компании (с определением долей партнёров), за которой будут закреплены все созданные к этому времени активы проекта;

• проект устава компании, которую партнёры договорились создать в будущем (заранее утверждённый проект устава очень важен, ибо если его не будет, то на стадии создании компании можно очень быстро скатиться в конфликт, обсуждая редакцию устава);

• проект корпоративного договора, который партнёры обязуются заключить при создании общей компании (заранее утверждённый проект корпоративного договора также очень важен, ибо если его не будет, то на стадии создании компании можно также очень быстро скатиться в конфликт, обсуждая редакцию корпоративного договора);

• обязанность партнёров немедленно предоставлять друг другу доступ к любым создаваемым в рамках реализации проекта объектам (активам);

• передачу каждым партнёром другому партнёру безвозмездной лицензии (права пользования) на все создаваемые в рамках реализации проекта активы;

• и прочее.

Ключевым в плане безопасности партнёрских отношений до создания общей компании является предпоследний пункт - предоставление партнёрами друг другу лицензий на создаваемые ими в проекте активы.

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

Статья 1288 Гражданского кодекса РФ позволяет партнёрам договориться о создании объекта интеллектуальной собственности (ОИС) в рамках договора авторского заказа и автоматической передаче лицензии на такой объект заказчику (партнёру, который физически не участвовал в создании ОИС). При этом создатель ОИС (автор) оставляет за собой исключительное право на ОИС.

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

Наличие у каждого из партнёров права коммерческого использования ОИС, юридически принадлежащего другому партнёру, снимает значительную часть рисков, связанных с присвоением одним из партнёров ключевых активов проекта. Даже если кто-то из партнёров впоследствии поведёт себя не адекватно договоренностям, то другой партнёр может, используя все созданные в рамках реализации проекта ОИС, реализовать аналогичный проект самостоятельно (с привлечением новых партнёров).

При этом, не стоит упускать из виду, что лицензия на ОИС должна предусматривать запрет на использование ОИС вне рамок проекта, если автор (собственник ОИС) не нарушил условия партнёрского соглашения. На случай нарушения такого запрета должен предусмотрен суровый штраф (плюс автор может обратиться в суд с требованием о запрете использования ОИС в связи с нарушением условий лицензии).

Резюме: обмен сооснователями лицензиями на все создаваемые ими в рамках реализации проекта ОИС нивелирует риски неудачного партнёрства.

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

На самой ранней стадии проекта при паритете партнёров, когда вопрос доверия является ключевым, очень желательно использовать так называемые  «зеркальные договоры» (зеркальные партнёрские договоры), которые предусматривают абсолютно равные юридические статусы бизнес-партнёров. Такие договоры предусматривают единую формулу с одной переменной, на место которой можно поставить фигуру любого из партнёров. Иными словами, каждый партнёр имеет те же самые (идентичные) права и обязанности (в том числе меры ответственности), что и другой партнёр. Такой подход значительно повышает доверие партнёров друг к другу и снижает стресс от неопределённости. Конечно, содержание вклада каждого партнёра в проект является чаще всего разным, но это не мешает формировать зеркальные договоры.

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

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

UPD: не понимаю зачем минусовать статью за "несоответствие тематике хабра", когда статей на даже менее релевантные темы на ресурсе полно? если будет ещё один минус, удалю статью (демотивирует такое отношение)

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

Почта

Телеграм