Набір контрактів для компанії-резидента Дія Сіті
Коли команда готує вхід у Дія Сіті, увага нерідко на реєстрації, КВЕДах, середній винагороді і звіті про відповідність. Пакет договорів часом відкладають «на потім» – до першого спору про код, юридичної претензії від замовника або перевірки, чи справді компанія отримує кваліфікований дохід. І саме тоді з’ясовується, що для режиму Дія Сіті договір – це не шаблон із папки «типові документи». Це спосіб, у який компанія фіксує модель зайнятості, передає інтелектуальну власність, зберігає статус резидента.
Помилка в контракті коштує дорожче за правку формулювання.
Вона здатна перетворити відносини з гіг-спеціалістом на звичайний цивільно-правовий договір без гарантій Закону України «Про стимулювання розвитку цифрової економіки в Україні» від 15.07.2021 № 1667-IX, залишити код у гіг-спеціаліста, зробити умову неконкуренції нікчемною або зруйнувати аргумент у спорі з клієнтом
Нижче – перелік договорів, без яких резидентство працює лише наполовину. Його варто зібрати до старту режиму або одразу після внесення компанії до реєстру, до моменту коли сервіс почне працювати з командою, клієнтами та інвесторами.
Чому статуту і свідоцтва резидента недостатньо
Статус резидента дає право користуватися спеціальними конструкціями. Сам по собі він не створює відносин з гіг-спеціалістом, не передає майнові права на код і не робить заборону конкуренції обов’язковою для гіг-спеціаліста. Якщо компанія увійшла в реєстр, а з командою й далі працює «як раніше» – через ФОП, усні домовленості й NDA з минулого року – для режиму цього може бути недостатньо.
Правила Закону № 1667-IX однаково спільні для продуктової компанії, яка продає власний SaaS, аутсорсера з довгими MSA і стартапу, який щойно закрив перший раунд. Відрізняється не норма, а те, який договір у конкретній моделі тримає бізнес і де найдорожче помилитися. У продуктовій компанії головне – щоб код, дизайн і база користувачів не зависли на гіг-спеціалісті чи ФОП, а майнові права зібралися в юридичної особи, яка продає підписку. В аутсорсера й аутстафера на першому плані клієнтський контур: у MSA і SOW компанії не варто гарантувати замовнику більше, ніж вона вже має за договорами з командою (права на результат, реальні строки виконання тощо). У стартапі після раунду інвестор дивиться не лише на гіг-контракт. Йому важливо, чи опціон і частки були оформлені документами, і чи компанія взагалі може показати, що продукт належить їй, а не розпорошений між виконавцями.
Окремо варто пам’ятати: режим Дія Сіті – це не лише гіг-контракт. Закон № 1667-IX окремо описує трудовий контракт, договір про нерозголошення, договір про утримання від конкурентних дій, опціон і позику з альтернативним зобов’язанням. Команду резидент може збирати і трудовим договором чи контрактом, і гіг-контрактом. Різниця в правовому режимі: у штаті діє трудове законодавство, облік ; у гіг-моделі – спеціальні правила Закону № 1667-IX. Договір про нерозголошення тримає код, клієнтські дані, факт роботи із замовником тощо. Договір про неконкуренцію закриває інше: щоб член команди не пішов з тим самим досвідом до прямого конкурента. Позика з альтернативним зобов’язанням потрібна, коли компанія залучає інвестиції. Якщо з усього цього в пакеті стоїть лише один договір із виконавцем, компанія користується режимом наполовину. Вона платить за статусом, але не бере інструменти, заради яких статус і задумували.
Договори з командою: трудовий, гіг-контракт, ФОП
Перший шар пакета – модель зайнятості. До NDA, неконкуренції й клієнтського MSA треба зрозуміти простіше: на якій підставі в компанії взагалі з’являється член команди. Від відповіді залежить, яке законодавство на неї поширюється, чи входить вона в критерії резидента, хто платить податки.
Резидент Дія Сіті може поєднувати три контури:
| 1 | Трудовий договір або трудовий контракт за статтею 16 Закону № 1667-IX. |
| 2 | Гіг-контракт з фізичною особою за статтею 17. |
| 3 | Цивільно-правовий договір з ФОП. |
Помилка не в самому поєднанні. Помилка – коли в одному файлі змішані ознаки всіх трьох моделей, а в обліку, звітності людина рахується не туди.
Якщо спеціаліста оформлюють за трудовим договором або контрактом, на нього поширюється законодавство про працю. Компанія отримує звичний кадровий контур: прийняття, облік, відпустки, лікарняні, підстави звільнення тощо. Трудовий контракт у режимі Дія Сіті дозволяє гнучкіше прописати строк, оплату, підстави припинення і режим інтелектуальної власності, ніж «голий» прийом наказом. Це зручно для ключових ролей, де потрібна дисципліна штату. Але контракт не виводить людину з трудового права. Трудове законодавство не зникає. Якщо компанія хоче «майже як гіг, але в штаті», вона все одно має забезпечувати трудові гарантії.
Гіг-контракт – окрема конструкція. Його може укласти лише резидент Дія Сіті і лише з фізичною особою. Інша юридична особа, навіть із IT-КВЕДами, такого договору укласти не може. Стороною гіг-контракту не є ФОП як підприємець: людина підписує його від свого імені, а не як суб’єкт господарювання.
Цивільно-правовий договір не вважається гіг-контрактом, якщо в ньому прямо не зазначено про укладення саме гіг-контракту.
Це не стилістика преамбули. Без цієї фрази компанія втрачає спеціальні правила Закону № 1667-IX – від презумпції переходу майнових прав до можливості укласти оплатну неконкуренцію в логіці цього закону. Форма має бути письмовою або електронною. Усна домовленість, лист «працюємо з понеділка» чи доступ у репозиторій гіг-контрактом автоматично не стануть.
Податковий контур у цих моделях теж різний. Для гіг-спеціаліста компанія є податковим агентом: вона нараховує й утримує податки з винагороди. Для ФОП – ні: підприємець рахує свої податки сам. ФОП не входить до середньооблікової кількості «дев’яти осіб» і не береться до розрахунку середньої винагороди. Туди йдуть працівники та гіг-спеціалісти.
Про укладення гіг-контракту, як і про прийняття за трудовим договором, потрібно повідомити податковий орган до початку роботи. Є ще один сценарій, який у шаблоні часто забувають. Якщо компанію виключають із реєстру Дія Сіті, гіг-контракт через певний час припиняється і спеціальний режим до цих відносин більше не застосовується. Щоб працювати далі, сторонам потрібен уже звичайний цивільно-правовий або трудовий договір — без тих правил, на які вони розраховували в гіг-контурі.
Що має бути всередині гіг-контракту
Сам факт назви «гіг-контракт» не закриває зміст. У тексті визначають строк, права, обов’язки, відповідальність, винагороду, порядок постановки завдань, приймання результату і підстави припинення — з урахуванням особливостей закону. Якщо строк не прописано, контракт вважається безстроковим. Якщо сторони продовжують його виконувати після закінчення строку, він за замовчуванням продовжується на той самий строк і на тих самих умовах.
Соціальні гарантії розділу V Закону не є опцією. Гіг-спеціаліст має право на щорічну оплачувану перерву тривалістю не менше 17 робочих днів, на допомогу у зв’язку з тимчасовою непрацездатністю, на перерву у зв’язку з вагітністю та пологами. Ці гарантії можна деталізувати в договорі або у внутрішніх документах, на які договір посилається.
Внутрішні політики резидента можна включити до гіг-контракту шляхом посилання. Це зручно для регламенту безпеки, постановки завдань, правил користування обладнанням тощо. Але тоді спеціаліста треба повідомити про зміни заздалегідь — за загальним правилом, не пізніше ніж за 30 днів, якщо сторони не визначили інший строк. Умовна політика, яку оновили в Confluence і нікому не надіслали, у спорі виглядає слабко.
За загальним правилом, припинення гіг-контракту потребує повідомлення за 30 календарних днів.
Резидент може скоротити цей строк, замінивши його компенсацією не нижче денної винагороди за кожен скорочений день. Матеріальна відповідальність гіг-спеціаліста за шкоду майну резидента з його вини обмежена: утримання – не більше 20% місячної винагороди. Штраф за порушення конфіденційності чи неконкуренції – інша історія, її визначають окремо.
Договірний контур інтелектуальної власності
Особисті немайнові права на об’єкт, створений у зв’язку з виконанням гіг-контракту, залишаються за гіг-спеціалістом. Ім’я автора, право на недоторканність твору компанія «забрати» не може. Інша річ – майнові права: право використовувати код і дизайн, змінювати їх, давати ліцензію, продавати клієнту, ставити в продукт. За статтею 24 Закону № 1667-IX ці права належать резиденту як замовнику, якщо інше не передбачено гіг-контрактом. Це сильна презумпція. Вона працює саме в контурі відносин з гіг-спеціалістом й саме щодо об’єкта, створеного у зв’язку з виконанням цього контракту.
Презумпція не ширша за свій периметр.
Вона не замінює договір з дизайнером, який малює банери як звичайний фрилансер без гіг-контракту. Не покриває автоматично код, написаний до старту співпраці, навіть якщо спеціаліст потім поклав його в той самий репозиторій. Не працює автоматично в договорі з ФОП, якщо там стоїть зворотна формула «права залишаються у виконавця».
На практиці недостатньо одного речення «всі права належать компанії». Така фраза не відповідає на питання, які потім ставить клієнт або інвестор. Що саме вважається об’єктом, створеним у зв’язку з виконанням контракту: лише код, зданий за завданням у робочий репозиторій, чи також розробка, яку спеціаліст зробив у вільний час, але за внутрішнім ТЗ чи з матеріалами компанії? Як бути з попередніми напрацюваннями – бібліотекою, шаблоном, заготовкою, які людина принесла з собою? Чи входить у передачу право на модифікацію, субліцензію і передачу клієнту, афілійованим особам, правонаступнику? Що відбувається після припинення співпраці з репозиторіями, акаунтами, доменами, ключами, дизайн-файлами й доступами в хмару? Ці моменти доцільно окреслити в договорі.
Окремо варто узгодити правила щодо open source, сторонніх бібліотек і генеративних моделей. Презумпція статті 24 передає компанії майнові права на те, що гіг-спеціаліст створив сам у зв’язку з контрактом. Вона не скасовує ліцензію чужого коду, який він підключив без дозволу. Якщо в продукт зайшла бібліотека з GitHub, у цього коду вже є правовласник і свої умови. Компанія стає власницею доробки спеціаліста, але не отримує автоматично право використовувати чужий фрагмент як завгодно.
Те саме з генеративними моделями. Якщо спеціаліст згодував у публічний чат код клієнта, внутрішнє ТЗ чи фрагмент репозиторію, модель перестає бути просто інструментом. Матеріал уже вийшов за контур компанії. Його можуть використати для донавчання, він може з’явитися в відповіді іншому користувачу, його важко повернути. Презумпція статті 24 тут не допомагає: права на згенерований текст і так спірні, а обов’язок не розкривати клієнтський код нікуди не зникає.
Якщо цього немає в договорі з командою і в SOW із клієнтом, потім пояснювати замовнику «так було зручніше розробнику» може бути марно. Відповідає не коміт і не автор бібліотеки. Відповідає компанія, яка підписала клієнту гарантію, що права на результат чисті.
Договір про нерозголошення
Стаття 26 Закону № 1667-IX прямо дозволяє резиденту укладати договір про нерозголошення. Це один із небагатьох випадків, коли українське законодавство не залишає NDA в сірій зоні. Але дозвіл закону не рятує порожній шаблон на дві сторінки, де конфіденційною оголошено «всю інформацію компанії».
У спорі компанії потрібен не красивий заголовок, а визначення об’єкта: код, клієнтські дані, фінансова модель, воронка, невипущені фічі, зміст переговорів, сам факт роботи з конкретним замовником. Потрібні винятки – інформація з публічного доступу, самостійно створена без використання конфіденційної інформації компанії. Потрібен строк після закінчення співпраці. Потрібна заборона на портфоліо там, де демо розкриває архітектуру клієнта. І потрібна зрозуміла санкція, а не загальне «відшкодувати збитки» без методики.
NDA з командою і NDA з клієнтом мають бути узгоджені між собою.
Якщо клієнтський Mutual NDA забороняє розкривати навіть факт переговорів, а спеціаліст у LinkedIn пише, що «гордий будувати продукт для цього бренду», формально порушує вже компанія. Після виходу людини з команди в договорі має лишатися порядок повернення або знищення носіїв, доступів і копій.
Договір про утримання від вчинення конкурентних дій
Статті 27 і 28 Закону № 1667-IX дозволяють резиденту укласти з фахівцем договір про утримання від вчинення конкурентних дій. Це сильний інструмент, регламентації якого немає в трудовому законодавстві.
Умова неконкуренції є дійсною за оплатності. Компенсація має бути справедливою.
Відмова фахівця підписати такий договір сама по собі не дає права розірвати гіг-контракт: закон окремо захищає вільне волевиявлення.
Заборонені дії треба описати предметно, наприклад, конкретні відносини з особами, які ведуть аналогічну діяльність; власна конкуруюча діяльність як ФОП; участь у капіталі чи органах управління конкурента. Абстрактне «не працювати в ІТ рік по всьому світу» виглядає не як захист бізнесу, а як спроба вимкнути людині ринок праці.
На практиці тут часто збираються дві крайності, і обидві поки виглядають вразливими. Перша – написати, що плата за неконкуренцію «включена в щомісячну винагороду», і не виділити її ні в платежі, ні в розрахунку. Тоді важко показати, що обмеження взагалі оплачене окремо, а не просто назване в тексті. Друга – поставити символічну суму й широкий територіальний та часовий обхват. Тоді вже саме «справедливість» компенсації виглядає сумнівно: обмеження велике, зустрічне надання відносне.
Як саме це оцінить суд у конкретному спорі, заздалегідь сказати не можна. Поки безпечніше будувати конструкцію так, щоб її можна було пояснити: окремий платіж або окремо виділена частина винагороди з призначенням «компенсація за неконкуренцію», співмірні строк і територія. Санкцію за порушення цього договору варто писати окремо – не змішувати зі штрафом за NDA і з обмеженим утриманням за шкоду майну.
Клієнтські договори
Резидент Дія Сіті рідко працює в вакуумі. Зовнішній шар пакета – це MSA, SOW, order form, SLA, інколи окремий IP assignment на користь замовника тощо. Якщо внутрішні договори з командою не синхронізовані з тим, що компанія підписує клієнту, ризик вилазить не на онбордингу, а на due diligence перед великим контрактом або угодою з інвестором.
Клієнт хоче гарантію, що компанія володіє правами на результат або має право їх передати, і що в продукті немає чужого коду без ліцензії. Ці обіцянки в MSA можна дати лише, якщо той самий зміст уже стоїть у договорах із командою: ланцюг прав інтелектуальної власності, NDA під клієнтський периметр, правила субпідряду.
Окремо стоїть заборона переманювання. Це вже захист виконавця. Клієнт кілька місяців бачить розробника в Slack і на дейлі, далі може запропонувати йому ставку напряму. Якщо в MSA немає non-solicit на час проєкту і певний строк після, а в гіг-контракті спеціаліст не зв’язаний обов’язком не йти до цього замовника в обхід компанії, резидент не має чим утримати маржу. Аутстаф без права заміни виконавця, без NDA під контур замовника і без заборони прямого хантингу – це не гнучка модель.
Окремо варто зіставити обмеження відповідальності в клієнтському договорі й у договорах із командою.
Якщо MSA ставить стелю на рівні річної винагороди за SOW, компанія перед замовником може бути винна десятки тисяч доларів за зрив строку, дірку в безпеці чи претензію про права на код. Проблема особливо відчувається у випадку, якщо у гіг-контракті спеціаліст відповідає символічною сумою або взагалі лише в межах утримання за шкоду майну. Різниця між цими двома стелями не зникає. Її платить резидент.
Це нормально, якщо компанія так вирішила свідомо: залишила ризик на собі, закладає його в маржу. Однак це небезпечно як дефолт двох шаблонів, які ніхто не читав разом. Тоді в MSA написано одне, у гіг-контракті – інше, а в момент претензії з’ясовується, що з виконавця взяти майже нічого.
Корпоративні договори
Окремий шар пакета згадують пізно: коли треба оформити опціон або пояснити інвестору, на якій підставі спеціаліст претендує на частку. Закон № 1667-IX дає резиденту прямі конструкції для цього – опціон і позику з альтернативним зобов’язанням. Самі по собі вони ще не створюють частку.
Потрібен, зокрема, договір, з якого видно обсяг, строк, ціну або формулу і що саме отримає людина, якщо умова спрацює.
Усна обіцянка «відсоток після релізу» може виглядати як мотивація для команди. У спорі її значно важче перетворити на вимогу передати корпоративні права, ніж документ із зрозумілими параметрами.
До цього ж шару входять рішення учасників, договірні конструкції щодо розподілу часток і порядок їх відчуження, корпоративний договір тощо. Вони не замінюють гіг-контракт і не оформлюють щоденну роботу. Їхня роль інша: зафіксувати, кому належить компанія і на яких умовах хтось може зайти в капітал.
Як скласти пакет до старту режиму
Перед входом у Дія Сіті або перед переведенням команди на модель відносин з гіг-спеціалістом варто пройти шлях як нова компанія: карта ролей, вибір форми співпраці для кожної ролі, онбординг, перше завдання, перша виплата, зміна ставки, вихід спеціаліста, передача прав клієнту. На кожному кроці видно, який документ це закриває і чи витримає він перевірку клієнта, інвестора або податкової.
Так з’являється живий набір, а не стос шаблонів. У типового резидента він складається з кількох кіл. У центрі — договори з командою: трудовий договір або контракт, гіг-контракт, договір із ФОП там, де ця модель справді доречна. Навколо них – договір про нерозголошення, договір про утримання від вчинення конкурентних дій. Далі — клієнтські MSA. Зверху — статут, корпоративні рішення тощо. Якщо якогось кола немає, рветься не «папірець». Рветься ланцюг, яким компанія доводить, що режим, код і люди належать саме їй.
Комплаєнс не стоїть окремо від продукту. Від того, як названа сторона в шапці договору, залежить, чи працює певний договірний режим. Від того, як написаний розділ про інтелектуальну власність, залежить, чи є що продати замовнику. Від того, чи оплачена неконкуренція, залежить, чи залишиться обмеження живим після виходу людини. Тому пакет договорів варто збирати разом із юристом до старту, а не після першої скарги чи спору про код.
Компаніям, які стають резидентами Дія Сіті, підготовку контрактного контуру варто закладати так само рано, як підготовку розрахунку середньої винагороди.
Виправити гіг-контракт, NDA і ланцюг прав до онбордингу фахівця дешевше, ніж потім пояснювати, чому продукт «ніби наш», але в репозиторії інша історія. Універсального шаблону на всі продуктові, аутсорс- і аутстаф-моделі немає. Перед стартом є сенс залучити юристів, які вміють зіставити конкретну команду й конкретних клієнтів із рамкою Закону № 1667-IX і сказати, що саме треба змінити, щоб договори тримали режим, права і людей. З цими питаннями радо допоможе команда Legal IT Group.
