Договір з ФОП розробником та дизайнером. Підводні камені

Договір – основа співпраці. Проте часом за типовими договірними положеннями ховаються підводні камені. У цій статті ми подивимося на контракт одразу з двох сторін: ФОПа та компанії-замовника. Проаналізуємо, де принципово відрізняються їхні інтереси та як досягти компромісу.

Правильно формулюємо предмет

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

Передусім необхідно перевірити, що предмет договору відповідає КВЕДам виконавця.

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

Зазначаємо про перехід прав інтелектуальної власності

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

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

Ключовими моментами, які потрібно визначити у договорі щодо прав інтелектуальної власності є:

• обсяг прав, що передаються, та
• момент переходу цих прав.

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

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

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

Для додаткового «страхування» замовника прописується пункт про те, що додатковим підтвердженням переходу прав інтелектуальної власності є виставлення виконавцем рахунку та його оплата замовником. Часом це може бути також підписання актів приймання-передачі наданих послуг.

Уважно читаємо умови щодо відповідальності за договором

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

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

Не варто погоджуватися на штрафи «на всі гроші світу» з думкою про те, що така ситуація все рівно не трапиться або що замовник не зможе її довести.

Поширеним пунктом є наступний: «Виконавець самостійно несе відповідальність у разі порушення ним прав інтелектуальної власності третіх осіб». Цим замовник захищає себе, якщо, наприклад, дизайнер вкрав чужі картинки і видав їх за свої, а замовник використав їх у кінцевому продуктів й отримав скаргу від правовласника.

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

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

Ризик визнання відносин трудовими

При розробці договору на послуги з ФОП слід бути обачним, аби положення не вказували на трудові відносини, якщо фактична природа є наданням саме послуг.

«Приховані» трудові відносини можуть дорого обійтися замовнику, адже в такому разі на нього можуть накласти високий штраф.

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

Перелік таких ознак трудових відносин може відрізнятися залежно від законодавства, що застосовується. Тож додатково перевірте, чи не містить ваш договір ризикових пунктів. Більше про ознаки трудових відносин у договорах між ІТ ФОП та замовником можете дізнатися на нашому вебінарі.

Конфіденційність

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

Ризики використання ШІ – це окрема тема, сьогодні зосереджуємося на іншому. Та все ж потрібно згадати, про безпековий ризик. ШІ теоретично може використовувати введені дані для подальшого навчання, а отже, потенційно може розкрити їх іншому користувачеві. Це сталося, коли співробітники компанії Samsung випадково злили комерційну таємницю через ChatGPT. Саме тому доцільно у договорах також прописувати обмеження про заборону виконавцю вводити конфіденційну інформацію в програми зі штучним інтелектом.

Неконкуренція

Останній можливий підводний камінь на сьогодні – неконкуренція. Часом вона прописана прямо, але іноді замаскована під конфіденційність. Тому потрібно уважно читати положення і те, що залишається «між рядками», аби не погодитися на заборону здійснювати свою професійну діяльність ще протягом 100 років після припинення співпраці.

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

Підсумуємо

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