Документи, які приватному інженеру слід підготувати заздалегідь для спільного бізнесу з компанією

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

1. Як індивідуальний інженер, він був залучений до розробки нової системи для компанії, яка не обов’язково має сильні IT-компетенції, з самого початку.
2. Ця система добре працює і приносить прибуток.
3. Інженер вимагає розподілу акцій або розподілу прибутку на основі продажів, але компанія відмовляється відповідати на ці вимоги.

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

Спірні питання щодо спільного бізнесу можна запобігти, якщо є договір

По-перше, якщо висловити висновок заздалегідь, запобігти таким ситуаціям насправді просто. Відповідь проста

Щоб бути готовим до таких обставин, вам просто потрібно заздалегідь укласти “договір про спільний бізнес”, який включає такі пункти.

Це те, що ви повинні зробити. У договорі про спільний бізнес можна встановити такі положення, наприклад:

• Авторські права на відповідну систему будуть спільними між вами та компанією
• ●% від прибутку буде розподілено вам
• Положення про передачу акцій

Вам просто потрібно розробити ці положення в оптимальному балансі та укласти їх заздалегідь.

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

• Які правові відносини існують, коли проблема виникає?
• Якими принципами керуватися при розробці договору про спільний бізнес заздалегідь?
• Однак, чому проблеми часто виникають, коли договір ще не укладено?

Про ці питання я розповім нижче по порядку.

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

На етапі, коли виникає вищезазначена проблема, максимальним “правом”, яке може стверджувати індивідуальний інженер проти компанії, є авторське право. Вихідний код програми є “твором”, що є об’єктом авторського права. І приналежність авторських прав на вихідний код визначається за такими правилами:

1. Як правило, вони належать тому, хто написав цей код.
2. Якщо той, хто написав код, працює на підприємстві або відповідає певним умовам, він стає “службовим твором”, і належить компанії.
3. Якщо в договорі встановлено приналежність авторських прав, слід дотримуватися цього положення.

Отже,

1. Як правило, вони належать індивідуальному інженеру, який написав код.
2. Індивідуальний інженер не є працівником компанії, тому службовий твір не створюється.
3. Приналежність визначається за договором, але “договір” не існує.

З цього можна зробити висновок, що авторські права належать індивідуальному інженеру. Однак, якщо цей конфлікт стане предметом судового розгляду, суд не обов’язково прийме таке рішення.

До речі, щодо питання, чи може бути укладено договір про розробку системи без договору, детально пояснено в наступній статті.

https://monolith.law/corporate/system-development-contract[ja]

У відсутності договору судове рішення може бути неоднозначним

Це не стосується проектів розробки систем, але у справі, що стосується дизайну монумента, встановленого на станції, виник спір про авторські права між індивідуальним дизайнером, який створив дизайн, та компанією, яка замовила його. Токійський вищий суд 31 травня 2004 року (Хейсей 16 рік) вирішив цю справу, враховуючи такі фактори:

• Договір не був укладений
• Монумент був спланований для встановлення на станції під керівництвом компанії з самого початку, і не передбачалося його використання в інших цілях
• Компанія сплатила гонорар індивідуальному дизайнеру

На цій основі суд визнав передачу авторських прав від індивідуального дизайнера до компанії.

Таким чином, у відсутності письмового договору, питання про те, чи були авторські права передані замовнику, вирішується шляхом вивчення різних обставин і пошуку розумної волі замовника та виконавця. Іншими словами, це стає досить “неоднозначним” рішенням, і немає чітких правил. Наприклад, питання “як виплачується винагорода за написання вихідного коду” зазвичай розглядається в контексті цього “неоднозначного” рішення наступним чином:

• Якщо платіж здійснюється у вигляді щомісячної плати → вважається винагородою за загальні послуги, включаючи обслуговування, а також, особливо якщо виконавець – фізична особа, вважається аналогом зарплати, що підтверджує передачу авторських прав замовнику
• Якщо оцінка проводиться кожен раз при оновленні версії → легко вважати це винагородою за створення цієї версії, що заперечує передачу авторських прав замовнику

Коли індивідуальний інженер виконує замовлення від компанії у формі “спільного підприємства”, винагорода часто виплачується у вигляді щомісячної плати, і в результаті, передача авторських прав компанії зазвичай підтверджується. Крім того, принаймні з боку індивідуального інженера, у відсутності письмових документів, важко стверджувати, що “авторські права явно належать мені”.

Детальніше про авторські права на вихідний код програми описано в наступній статті.

Які питання слід визначити в договорі про спільне підприємство

Основна причина такої ситуації – відсутність попереднього договору. Можливо, ви інтуїтивно думаєте, що “створення договору заздалегідь не є реалістичним”, але ми обговоримо це питання пізніше. Спочатку давайте обговоримо, яким має бути договір.

Визначення щодо авторських прав

Як видно з вищенаведеного, в договорі слід встановити положення щодо авторських прав. З точки зору індивідуального інженера, найбільшим ризиком при “розробці системи в рамках спільного підприємства між особою та компанією” є те, що він може бути “відкинутий” після того, як проект стане прибутковим.

Тобто, навіть якщо ви укладете договір, як буде згадано нижче, наприклад, “20% від прибутку буде виплачено індивідуальному інженеру”, якщо сам договір буде припинено, ви в кінцевому рахунку не зможете отримати прибуток. Щоб не припиняти договір, важливо мати “права” на своїй стороні, а найважливішим з цих “прав” є авторські права. Щодо авторських прав,

• Авторські права належать індивідуальному інженеру
• Авторські права є спільною власністю компанії та індивідуального інженера
• Авторські права належать компанії, але компанія не може їх використовувати або передавати без дозволу індивідуального інженера

Якщо ви встановите такі положення, з точки зору компанії, ситуація стане такою, що “якщо ви відкинете індивідуального інженера, ви не зможете продовжити бізнес”, тому ви зможете запобігти “відкиданню” вищезазначеним способом.

Для детального розуміння загальної картини IT-системи та авторських прав, дивіться статтю нижче.

https://monolith.law/corporate/internet-technology-system-copyright-problem[ja]

Визначення щодо винагороди

Також, звичайно, потрібно визначити винагороду. Це не обмежується лише такими випадками, але коли ви ведете бізнес разом, та сторона, яка не має прибутку, має перевагу в отриманні розподілу на основі продажів, а не прибутку. Тобто, наприклад,

• Компанія виплачує індивідуальному інженеру ●% прибутку від бізнесу, пов’язаного з цією системою
• Компанія виплачує індивідуальному інженеру ●% від продажів бізнесу, пов’язаного з цією системою

Ви повинні намагатися зробити це останнє. Індивідуальний інженер не може точно знати, скільки продажів відбувається в компанії, скільки витрат, а також чи є ці витрати дійсно “для цього бізнесу”. Отримання прибутку, оплата витрат, управління тим, що було отримано за ці витрати, наприклад, персоналом, – все це, в кінцевому рахунку, компанія. І в цьому контексті, продажі є найлегшими для розуміння. Тому вигідніше отримувати платежі, які можна просто розрахувати з легко розуміємих речей.

Визначення щодо передачі акцій

Крім того, ви також можете вимагати передачі акцій. Однак, ця стаття не вдається в деталі, але “індивідуальний інженер-зовнішній контрактник, який займається спільним підприємством”, вимагаючи багато акцій, наприклад, десятки відсотків, є практично складним. Якщо зовнішній учасник з такою позицією має значну кількість акцій, інвестиції від VC або IPO стають дуже складними в практиці. Ви повинні вести переговори в реалістичних межах, наприклад, 5%.

Чому договори не створюються заздалегідь?

Таким чином, відсутність договору, який включає майбутні платежі та інше для “спільного бізнесу” між індивідуальними інженерами та компаніями, є “невигідною” ситуацією для індивідуальних інженерів. Важливо створити договір заздалегідь, але багато людей, здається, вважають, що “незважаючи на це, створення та укладення договору заздалегідь є складним”.

Це, на мою думку, пов’язано з різницею в свідомості про “бізнес” між компанією та індивідуальними особами. Взагалі кажучи, спори щодо такого спільного бізнесу виникають в наступному хронологічному порядку:

1. Компанія та індивідуальний інженер доручають розробку системи для створення нового бізнесу. При цьому, наприклад, “щомісячна плата в розмірі 300 000 ієн” погоджується як плата для підтримки життя індивідуального інженера.
2. Даний бізнес стає прибутковим, і вищезазначена плата дещо збільшується.
3. Даний бізнес продовжує рости, приносячи компанії прибуток у декілька десятків мільйонів або навіть мільярдів ієн.
4. На цьому етапі, наприклад, “щомісячна плата в розмірі 500 000 ієн”, яку отримує індивідуальний інженер, стає незначною порівняно з прибутком, який отримує компанія, а також порівняно з вартістю, яку інша компанія могла б запропонувати за таку систему.
5. Відносини між індивідуальним інженером та компанією погіршуються.

З точки зору індивідуального інженера, безумовно, якщо вони не отримують щомісячну плату на етапі 1, це може вплинути на їх життя. І на етапі 4, безумовно, “щомісячна плата в розмірі 500 000 ієн”, як у вищезазначеному прикладі, є незначною порівняно з:

1. Прибутком, який отримує компанія
2. Вартістю системи, якщо б її створила інша компанія

Однак, просте порівняння цих двох факторів є економічно недоцільним. Це тому, що:

1. На етапі 1, компанія робить передбачувані інвестиції, сплачуючи зарплату індивідуальному інженеру та менеджеру з продажу, навіть не знаючи, чи принесе бізнес прибуток.
2. Якщо б інша компанія створила систему, вона мала б передбачити передачу авторських прав, тому не могла б бути мова про “розподіл прибутку на основі продажів”.

Щоб сказати жорстко, “якщо ви отримали плату за роботу на етапі, коли не відомо, чи стане бізнес прибутковим, у вас немає права вимагати розподілу прибутку, коли він стає прибутковим”. Вважається, що багато судових рішень в кінцевому підсумку приходять до такого ж висновку.

Підсумки

На етапі, коли абсолютно невідомо, чи принесе бізнес успіх, витрачати час на створення договору про спільне підприємство або звертатися до адвоката з відповідними витратами, безумовно, є “ризиком”. Якщо в кінцевому результаті цей бізнес зазнає невдачі, цей час та витрати стануть “витратами без результату”.

Однак, суть бізнесу полягає в тому, що ті, хто бере на себе “ризик”, в кінцевому результаті отримують прибуток, якщо все йде добре. Інженери-приватники, навіть на етапі, коли ще невідомо, чи стане бізнес прибутковим, витрачають час та гроші, як зазначено вище, і беруть на себе “ризик” до певної міри. Якщо в результаті цей бізнес принесе успіх, вони зможуть отримати кращі результати, ніж якби вони не взяли на себе цей “ризик”.

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

Інформація про створення та перегляд договорів нашим бюро

Юридичне бюро “Monolis” як юридична фірма, що спеціалізується на IT, Інтернеті та бізнесі, надає послуги зі створення та перегляду різноманітних договорів для наших корпоративних клієнтів та клієнтів-консультантів.

Детальніше дивіться на сторінці нижче.

https://monolith.law/contractcreation[ja]