Андрій Желтов ІТ контракти, Договір на розробку програмного забезпечення

Договір з розробником: 3 ключові розділи для замовника

Укладаючи договір з IT-спеціалістом, потрібно грамотно прописати всі умови, про які Ви домовилися (починаючи від детально визначеного предмету договору, закінчуючи електронними способами комунікації сторін).

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

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

Безумовно, такими положеннями виступають добре відомі Non-disclosure, Non-compete та Non-solicitation clauses, однак в цій статті ми хочемо поставити акценти на інших розділах, специфіку яких не слід ігнорувати.

Предмет послуг

Слід насамперед вказати, що поряд з строком і ціною предмет договору є однією з його так званих “істотних умов”. За законом без погодження істотних умов договір вважатиметься неукладеним. При розробці договору слід обов’язково звернути увагу, що в ньому (і) чітко прописаний скоуп послуг (який, у свою чергу, може деталізуватися при постановці ТЗ), (іі) встановлений строк договору (це один з важливих маркерів для визначення того, що між компанією та ІТ-спеціалістом немає трудових відносин), (ііі) визначена ціна послуг (вона може формуватися, зокрема, на основі моделей Fixed Price або Time & Material).

В рамках довгострокової роботи з девелопером оптимально не домовлятися про ТЗ в додатку до договору, а визначити, що таски формуються і деталізується в “системі” комунікації сторін (нею може бути, зокрема, Jira, Slack, Trello тощо). Слід прописати, що комунікація сторін через “систему” є невід’ємною складовою договору.

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

Інтелектуальна власність

Будь-яка передача розробленого ПЗ компанії на носіях інформації або шляхом завантаження на “хмару” не є автоматичною передачею прав на створені об’єкти інтелектуальної власності. Договір завжди має включати в себе розділ, присвячений передачі прав на IP.

Важливо: за законом у разі недодержання письмової (електронної) форми договору щодо розпоряджання майновими правами інтелектуальної власності такий договір є нікчемним.

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

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

Після того, як розроблений продукт вже було продано клієнту, ІТ-спеціаліст може подати позов до суду з метою припинення порушення клієнтом його прав на інтелектуальну власність (або ж взагалі подати DMCA-скаргу якщо продукт опубліковано на платформі, що хоститься в США). На жаль, з огляду на відсутність передачі прав, він може виграти спір, тим самим підставивши компанію перед її клієнтом.

Аби не допустити таких ситуацій, в договорі має грамотно прописуватися розділ, присвячений IP:

міститися деталізований обсяг прав, що передаються компанії (доцільно вказати кожне майнове право, що передається);
чітко визначити момент передачі прав (у випадку договору з девелопером найліпшим варіантом є момент створення об’єкта);
вказати, що права передаються не тільки на “deliverables”, а й на будь-який “work product” , створений в процесі надання послуг;
зобов’язати девелопера перед початком використання будь-яких бібліотек відкритого вихідного коду узгоджувати їх перелік з компанією та не допускати будь-яке порушення умов публічних ліцензій таких open-source матеріалів;
можливо прописати “Виконавець забороняє Замовнику вказувати його ім’я при публікації примірників створених Об’єктів”, якщо компанії важливо не вказувати імена своїх девелоперів при публікації продукту (такий вординг прямо дозволяється законодавством).

Якщо вже і сталася ситуація, що договір не містить розділу IP, компанія в разі судового спору з девелопером матиме довести, що укладений договір кваліфікується як “договір на створення творів на замовлення” (у випадку застосування права України як права договору). За ч. 4 ст. 440 Цивільного кодексу України майнові права інтелектуальної власності на твір, створений за замовленням, переходять до замовника з моменту створення твору у повному складі, якщо інше не передбачено договором чи законом.

Зверніть увагу, що законодавча норма такого змісту працює лише з 14 серпня 2021 року, а отже не поширюється на об’єкти, що були створені раніше.

Відповідальність сторін

Якщо не прописати штраф в договорі – його не вийде застосувати в разі спору. Винятками можуть слугувати ситуації, коли штраф визначається на рівні закону, однак українське законодавство не містить визначених договірних штрафів за порушення умов Intellectual property, Non-disclosure, Non-compete та Non-solicitation clauses.

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

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

Ділимося наступними нюансами правильного визначення штрафів:

вказати штраф об’єктивно співмірний можливим порушенням (за порушення умов щодо конфіденційності інформації слід вказати ту суму, яка відображає цінність інформації – наприклад, 15 000 USD);
збільшити строк позовної давності. За умовчанням є всього 1 рік на те, щоб звернутися до суду для стягнення штрафу з моменту, коли компанія дізналася про порушення своїх прав девелопером. Втім, цей строк можливо збільшити (наприклад, до 5 років);
збільшити строк нарахування пені в господарських відносинах. За умовчанням в договорі між суб’єктами господарювання (тобто, між ФОПами та юридичними особами) пеня нараховується всього 6 місяців з моменту прострочення. Втім, цей строк можливо збільшити (наприклад, до 5 років);
вказати, що штрафні санкції нараховуються понад суму збитків. Якщо це не прописати, то за умовчанням в господарських відносинах штраф зменшуватиметься на суму збитків.

За наявності таких дисклеймерів Ви матимете значно більші переваги в суді при стягненні штрафів.

В «Legal IT Group» мають великий досвід підготовки договорів для ІТ-компаній на різних рівнях (і з клієнтами, і з розробниками). Ми будемо раді допомогти Вашому запиту!