Договір з розробником B2B: ключові умови

Що насправді вирішує договір з розробником

Договір між замовником і розробником-ФОП або розробником-компанією вирішує три різні задачі, і плутанина між ними — головна причина, чому такі договори не працюють, коли потрібні.

1. Господарська задача — що саме буде зроблено, в які строки, за які гроші, як приймається результат і хто відповідає за недоліки.
2. Задача інтелектуальної власності — кому належать майнові права на створений код, документацію, дизайн і дані. Це не те саме, що оплата роботи: сплативши за розробку, ви не стаєте автоматично власником прав.
3. Задача правового режиму відносин — чи є ці відносини справді цивільно-правовими, чи вони за своїм змістом трудові, і які ризики виникають у другому випадку.

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

Головна пастка: стаття 430 ЦК і спільні права

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

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

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

Що це означає практично:

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

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

З урахуванням статті 16 Закону України «Про авторське право і суміжні права» № 2811-IX такими договорами, що змінюють це правило, можуть бути трудовий договір або цивільно-правовий договір, у тому числі окремий договір про розподіл майнових прав на службовий твір.

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

Яку договірну конструкцію обрати

Стаття 1107 ЦК перелічує види договорів щодо розпоряджання майновими правами інтелектуальної власності. Для IT релевантні такі:

На практиці робоча схема для замовника — це комбінація: договір про створення за замовленням, у якому прямо передбачено передання (відчуження) замовнику виключних майнових прав на все створене, з моментом переходу, прив’язаним до підписання акта або до оплати.

Окремо про одну норму статті 1112 ЦК, яка показує логіку закону. Оригінал твору образотворчого мистецтва, створеного за замовленням, переходить у власність замовника, при цьому майнові права інтелектуальної власності на цей твір залишаються за його автором, якщо інше не встановлено договором. Тобто закон послідовно розділяє носій і права: ви отримуєте річ, але не права на неї. Для коду це означає, що передача вихідників у ваш репозиторій сама собою не передає прав.

Істотні умови договору про створення за замовленням

Міністерство економіки називає обов’язковими (істотними) умовами договору про створення за замовленням і використання об’єкта авторського права і суміжних прав дві:

1. строк, протягом якого має бути створений об’єкт авторського права і (або) суміжних прав;
2. способи та умови використання об’єкта авторського права і (або) суміжних прав замовником.

Друга умова заслуговує особливої уваги. «Способи використання» — це не загальна фраза, а перелік. Майнові права суб’єкта авторського права охоплюють відтворення, розповсюдження, публічне сповіщення, переробку, адаптацію, здавання в найм, імпорт та інші способи. Якщо в договорі перелічено лише частину, права на решту способів до вас не переходять.

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

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

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

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

Предмет, акти і приймання результату

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

Предмет. Формулювання «розробка програмного забезпечення» в предметі договору не означає нічого. Робоча структура — рамковий договір плюс додатки: технічне завдання або беклог, перелік етапів, критерії готовності для кожного етапу. Технічне завдання має бути додатком до договору, підписаним обома сторонами, а не посиланням на документ у чужому хмарному сховищі, який можна змінити без вашого відома.

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

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

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

Гарантійний період і підтримка. Строк, протягом якого розробник виправляє дефекти безоплатно; що є дефектом, а що — новою функціональністю; строки реакції. Без цього будь-яке виправлення після підписання акта перетворюється на нову комерційну домовленість.

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

Код і контент, згенеровані штучним інтелектом

Це питання стало практичним, і українське право на нього вже відповідає. З 1 січня 2023 року, коли набрав чинності Закон України «Про авторське право і суміжні права» № 2811-IX, в українському праві з’явилося право особливого роду (sui generis) на неоригінальні об’єкти, згенеровані комп’ютерною програмою — стаття 33 цього Закону. Закон діє в редакції від 31 липня 2026 року за Законом № 4742-IX, а з 24 березня 2027 року набирає чинності наступна редакція за Законом № 4888-IX.

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

Ключові параметри цього права:

• Це не авторське право. Неоригінальні об’єкти не підпадають під дію авторського права, а охороняються правом особливого роду.
• Особисті немайнові права не виникають (частина третя статті 33). У згенерованого об’єкта немає автора.
• Обсяг майнових прав збігається з майновими правами суб’єкта авторського права на твір і визначається статтею 12 Закону (частина четверта статті 33).
• Строк — 25 років, що обчислюються з 1 січня року, наступного за роком, у якому згенеровано об’єкт (частина шоста статті 33).
• Дозвіл на використання надається за ліцензійним або субліцензійним договором у порядку статті 50 Закону.
• Коло суб’єктів визначене частиною другою статті 33 і охоплює, зокрема, творців комп’ютерної програми, володільців прав і ліцензій на програмне забезпечення та правомірних користувачів програми. Договором між сторонами суб’єкта цього права можна визначити прямо.

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

Що з цього має бути в договорі з розробником:

1. Розкриття. Обов’язок розробника повідомляти, які частини результату створено з використанням генеративних інструментів і яких саме.
2. Передання прав обох видів. Умова про передання має охоплювати не лише майнові авторські права, а й право особливого роду (sui generis) на неоригінальні об’єкти у складі результату. Договір, який говорить лише про авторські права, частину вашого продукту не покриває.
3. Сумісність ліцензій. Умови використання конкретного ШІ-сервісу можуть обмежувати комерційне використання результату або впливати на те, хто є суб’єктом права. Це перевіряється до початку робіт, а не після.
4. Відповідальність за чужі права. Гарантія розробника, що результат не порушує прав третіх осіб, має прямо охоплювати і згенерований контент.
5. Сторонній код. Окремо від ШІ — перелік використаних open source бібліотек із їхніми ліцензіями. Копілефт-ліцензія в одному модулі здатна змінити режим усього продукту.

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

NDA з розробником має вирішувати чотири питання, і типові шаблони зазвичай вирішують одне.

1. Що саме є конфіденційною інформацією. Не абстрактна «вся інформація», а перелік категорій: вихідний код, архітектура, бізнес-логіка, клієнтські дані, комерційні умови, плани розвитку, доступи. І водночас перелік винятків: загальнодоступна інформація, інформація, отримана законно від третіх осіб, інформація, розкриття якої вимагає закон.

2. Хто зобов’язаний. Якщо розробник — компанія, зобов’язання мусять поширюватися на її працівників і субпідрядників, із обов’язком забезпечити відповідні зобов’язання з їхнього боку. Якщо розробник — ФОП із командою, це формулюється так само.

3. Строк. Конфіденційність має діяти і після завершення договору. Строк «протягом дії договору» робить NDA безглуздим саме в той момент, коли він потрібен.

4. Наслідки порушення. Конкретна сума неустойки за порушення, а не лише посилання на відшкодування збитків. Доводити розмір збитків від розкриття комерційної інформації надзвичайно складно, тому саме зафіксована неустойка робить NDA дієвим.

Окремо — персональні дані. Якщо розробник отримує доступ до даних ваших користувачів, одного NDA недостатньо: потрібні окремі положення про обробку персональних даних із визначенням ролей сторін, цілей і підстав обробки, заходів безпеки, порядку повідомлення про інциденти і дій після завершення робіт. Якщо ваші користувачі є в ЄС, додається шар вимог GDPR — про нього у матеріалі GDPR для українського IT.

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

Ризик перекваліфікації відносин у трудові

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

У КЗпП України відсутні визначення поняття та ознак трудових відносин. Окремі з них можна вивести лише з поняття трудового договору, закріпленого в частині першій статті 21 Кодексу. Це констатує і аналітична довідка Головного науково-експертного управління Верховної Ради від вересня 2025 року.

Що є натомість:

• Позиція Держпраці. У листі Державної служби України з питань праці від 19 березня 2025 року № 429/2.3/2.1-ЗВ-25а викладено 12 ознак, які можуть свідчити про наявність трудових відносин, і сама служба вважає, що наявності хоча б однієї з них може бути достатньо, щоб говорити про трудові відносини. Серед них — особисте виконання роботи, підпорядкування правилам внутрішнього трудового розпорядку, встановлений час початку і закінчення робочого дня, виконання роботи на робочому місці та обладнанням замовника, регулярна однакова винагорода, наділення організаційно-розпорядчими повноваженнями.
• Рекомендація МОП № 198 (2006) щодо трудових відносин, яка формулює ознаки на міжнародному рівні: якщо правовідносини між сторонами, всупереч договору, мають ознаки трудових відносин, працівник та інспектор праці від його імені можуть подати позов до суду про встановлення наявності трудових відносин.
• Законопроєкт № 13507 від 18 липня 2025 року, який пропонує доповнити КЗпП статтею 3-1 «Ознаки наявності трудових відносин» і визнавати роботи чи послуги виконаними в межах трудових відносин за одночасної наявності семи і більше ознак, а також покласти на контролюючі органи обов’язок звертатися до суду для перекваліфікації. Станом на зараз це законопроєкт, а не чинна норма, і стверджувати протилежне не варто.

Отже сьогодні ризик визначається не формальним переліком у законі, а позицією інспектора і оцінкою суду. І ціна цього ризику висока. Фінансові санкції статті 265 КЗпП прив’язані до мінімальної заробітної плати, яка у 2026 році становить 8 647 грн:

Для роботодавців на єдиному податку першої — третьої груп за фактичний допуск без оформлення застосовується попередження. До штрафів додаються донарахування ПДФО, військового збору і ЄСВ за весь період відносин із пенею.

Як знизити ризик:

• описувати в договорі результат, а не процес і не трудові функції;
• не встановлювати графік роботи, обов’язкову присутність і підпорядкування внутрішнім правилам;
• платити за прийняті етапи чи обсяг, а не однакову суму двічі на місяць у дні виплати зарплати;
• не видавати розробнику атрибутів працівника: посади в структурі, табеля, відпусток, дисциплінарних стягнень;
• дозволяти розробнику використовувати власне обладнання і працювати з іншими замовниками;
• фіксувати реальні акти за реальні етапи, а не однакові акти «послуги надано» щомісяця.

Альтернатива, створена спеціально для IT, — гіг-контракт у межах режиму Дія City. Порівняння моделей — у матеріалі гіг-контракт проти ФОП, а податкові наслідки кожної — у оподаткуванні IT-компанії.

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