Необходимый минимальный контракт кейс на начальном этапе

в 12:43, , рубрики: закон, Законодательство и IT-бизнес, контракты. стартап, право. договора, метки: ,

Открывая новый стартап, каждый знает, что существуют “подводные камни”, о которых все подозревают, но мало кто задумается. Одним из таких “камней” является игнорирование или экономия на юридических аспектах, а ведь они по сути не менее важны, чем сама идея проекта и его реализация. 

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

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

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

Зачем мне готовить документы, если я могу скачать их в интеренете?

 
Многие начинающие стартаперы, редко сталкивались с необходимостью юридического оформления каждого своего шага. Если это выходцы из тех.социалистов, то почти все документы им уже предоставили юристы. Но когда открываешь свой проект, то рассчитывать стоить только на себя, у тебя нет за спиной юридического отдела и корпоративный юрист уже не подскажет.
 
Под термином контракт — кейс, в этой статье мы будем подразумевать необходимый минимум документов. Однако, чаще всего IT компании делятся на два типа, продуктовые и аутсорсовые. У них есть как общие, так и различные виды документов.
 
Объединяет, продуктовые и аутсорсовые компании, внутренние документы. К ним относятся договора с разработчиками, дизайнерами и любыми специалистами, связанными с созданием интеллектуального продукта. Имейте ввиду, что в мире принята презумпция авторства, то есть, результатом работы, владеет автор, а не компания на которую он работал. Поэтому, дабы не втягиваться в долгие судебные тяжбы, необходимо сразу прописать, что вся созданная интеллектуальная собственность (программный код, дизайн, контент и т.д. ) в рамках выполнения трудовых или договорных обязательств, безусловно и в полном объеме, переходят работодателю/заказчику. Это необходимо оформить как пункт в трудовом договоре или если вы работаете без оформления трудовых отношений, в отдельном документе. Но настоятельно рекомендую, не качайте шаблон из интернета, лучше потратить 50 долларов на создание драфта у юриста. Это позволит сэкономить вам кучу времени и нервов. 

Также не забываем об ещё одном важном документе — соглашение о не разглашении. Ведь в IT бизнесе огромную роль играет, кто первый запустится, если у вас идея на миллиард, то точно не стоить рисковать. Как показывает история Марка Цукенберга, даже миллиардеры воруют. На практике сам договор у меня занимает всего 8 страниц, но вот приложение с перечнем, что попадает под термин «конфиденциальной информации » более 10. Также с каждым сотрудником устанавливается индивидуальный размер ответственности, но в среднем это годовая зарплата сотрудника плюс компенсация прямых убытков и утраченной прибыли. Но все же в этом вопросе стоит знать меру. Больше чем у человека есть, он не заплатит и суд это понимает. И как бы вы не хотели, суд не пойдет на то, чтобы делать из человека бомжа.
 
Внешние договора — вообще заслуживают отдельной статьи, но мы постараемся лаконично и по сути описать их ниже. 
Поделим их условно на те, в которых мы оказываем услуги и там, где услуги оказывают нам. Основные драфты, которые должны у вас быть, это договора на  оказание  услуг.  Обратите внимание, на тот момент, что в случае, если вам пишут софт или делают какой-либо интеллектуальный продукт, то все права на него должны переходить именно к вам. А не просто право его использовать, это обязательно нужно отразить в тесте договора. Обязательно, как можно детальнее описывайте, что именно вы покупаете, вообще ТЗ должен быть как приложение. 

Если Вам пишут софт, то должен быть оговорен период на тест и выявления “багов”. В настоящее время исполнители не гнущяются срывать и затягивать. Для предупреждения этого прописывайте четкие временные рамки с конкретными датами. И тем более, если это поэтапная сдача проекта. Уточняйте каким образом передается результат работы ( на физическом носители или посредством онлайн-передачи), и мотивирующую часть: ответственность, штрафы, и т.д.  Но не переусердствуйте, так как явно завышенные штрафы, суд может порезать, как нарушение равенства сторон. 

Отдельно стоить упомянуть СЕО. 

Абсолютное большинство исполнителей в своих договорах на продвижение, указывают, что они не гарантирую результат. Поэтому настаивайте, на уточнении четких саксес-метрик, иначе можете лишиться денег и не получить результат.
В договорах по которым вы оказываете услуги, мы сейчас не об публичных офертах, о них напишем отдельную статью, главный акцент сделайте на обязанностях заказчика. К примеру, предоставлять информацию в указаный сроки и способ, утверждать дизайн, установив лимит на переделку и прочее. Всё, что вам необходимо от него, опишите, а также укажите, как именно заказчик должен вам передавать эту информацию. Помните и о ТЗ, оно должно быть полным и четким, никакого двоемыслия или недосказанности. В любых спорах — это будет ваш главный аргумент!
 
Чтобы не лить воду, подытожим. Первое, у вас под рукой должны быть трудовые договора и договора конфиденциальности, которые часто подписывают просто как с физическим лицом ещё на этапе собеседования, а также минимум два вида договора на оказание услуг, где вам оказывают или где оказываете вы. Второе, скупой платить дважды, если не деньгами, то временем и нервами, поэтому — закажите индивидуальные драфты и всегда настаивайте них. О причинах, я писал в предыдущей статьи. О дальнейших юридических нюансах с которыми сталкивается IT расскажем в следующих статьях.

Автор: swich_style

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js