Soft Development Agreement для IT компанії у Польщі: на що варто звернути увагу?
Ми вже писали про те, що таке договір про розробку програмного забезпечення, навіщо він потрібен та які небезпеки можуть вас підстерігати, коли ви не дуже до нього уважні. Це все загалом. У той же час будь-який договір буде різнитися окремими пунктами з аналогічними договорами в інших юрисдикціях. Коли ви недооцінюєте їх значення при виборі права зовнішньоекономічного договору, десь у світі задоволено потирає руки хитрий юрист контрагента.
Що потрібно взяти до уваги, якщо право вашого договору про розробку ПЗ – польське?
1. Що таке договір про розробку програмного забезпечення у розумінні польського права
У праві Польської Республіки договір про розробку програмного забезпечення є видом договору про виконання робіт (по-польськи – umowa o dzieło) та регулюється Розділом 15 Книги 3 Цивільного кодексу. Більшість умов договору про виконання робіт, як його не назви, подібні у будь-якій юрисдикції. Проте, окремі особливості все ж існують.
Важливо, щоб договір про виконання робіт (а у нашому випадку – договір про розробку програмного забезпечення) не мав яскравих ознак трудового договору, натомість характеризувався:
- відсутністю чітко визначеного місця виконання завдань;
- свободою у виборі конкретного часу виконання завдань (однак протягом періоду, що визначений у договорі);
- відсутністю підпорядкування виконавця замовнику.
2.Визначення
Найперший момент – це однакове розуміння понять, які використовуються у договорі. Визначення (definitions) часто недооцінюють та пропускають, адже, на перший погляд, вони не дуже потрібні. Однак, часто значення понять тлумачаться по-різному окремими людьми, не кажучи вже про те розуміння, яке вкладають у них носії різних мов. Для попередження проблем, які потенційно можуть виникнути з питань тлумачення, ключові для договору слова варто пояснити. Трюк нескладний, але здатний урятувати від багатьох непорозумінь у майбутньому. Важливо також дотримуватися дисципліни при складанні договору та додатків до нього, а саме – використовувати створені визначення.
3. Предмет
Предмет договору про розробку ПЗ більш-менш однаково виглядатиме для договорів у різних юрисдикціях. Особливості ж у польському праві стосуються не стільки власне предмета, скільки процесу узгодження його сторонами.
Потрібно розуміти, що для будь-якого «польського» договору важливим моментом є так звана співпраця між сторонами. «Співпраця» означає, що ви та ваш контрагент на момент укладання договору повинні чітко усвідомлювати та однаково розуміти його мету. Відсутність такої співпраці, що унеможливлює досягнення узгодженого результату, згідно з цивільним правом Польщі (ст. 640 польського ЦК), є підставою для виконавця відмовитися від виконання своїх обов’язків за договором (для цього виконавець повинен встановити строк, протягом якого замовник може скоригувати ситуацію, і тільки після непродуктивного спливу цього строку у нього з’являється право розірвати договір). Тому дуже бажано, щоб договору про розробку ПЗ передував аналіз потреб замовника, що міститиме специфікацію програмних вимог, тобто опис її функціональності, технічні та функціональні рішення програми, вимоги користувачів тощо.
Аналіз потреб замовника важливий також для «формування» самого предмету. Як правило, у власне тексті договору предмет прописується більш узагальнено, а більш широкий та детальний його опис (тобто технічна специфікація), включаючи, наприклад, функції та конкретні параметри програмного забезпечення, міститься в окремому додатку.
Функції майбутнього програмного забезпечення варто прописати обов’язково. Обмеживши технічне завдання списком конкретних робіт, ми ризикуємо пропустити і не вписати фактично необхідні роботи в опис, внаслідок чого виконавець може відмовитися виконувати їх за договором. Щоб уникнути конфліктів, обом сторонам повинна бути зрозуміла мета, задля якої створюється ПЗ.
Варто також пам’ятати, що відповідно до договору, виконавець може не тільки виконати програмне забезпечення, але й, наприклад, навчати замовника його використовувати. Такі послуги можуть здаватися «побічними» та такими, що розуміються самі собою, однак виконавець цілком вправі відмовитися від їх надання, якщо договір їх не міститиме.
4. Графік виконання
Графік виконання ПЗ встановлюється у вигляді строків для окремих етапів. Етап виконання роботи – це окрема сходинка, що передбачає певні завдання, що повинні бути виконані, та строк, протягом якого їх потрібно завершити. Розподіл роботи на етапи дає можливість замовнику контролювати процес виконання, що є важливим моментом для масштабних проектів. Це також має значення у випадку, якщо виконавець так сильно затримається у роботі, що стане малоймовірно, що він зможе закінчити роботу до узгодженої дати. У такому випадку замовник може не ризикувати та відмовитися від договору, не встановлюючи додатковий термін, до закінчення всього періоду реалізації.
5. Оплата
З оплатою у договорі за польським правом все звично – вона може бути як фіксованою (наприклад, всю програму повністю або погодинно), так і попередньо розрахованою (у випадку, коли весь об’єм робіт неможливо знати наперед).
Окрім визначення розміру винагороди (wynagrodzenie), у договорі варто вказати момент, коли виконавець повинен її отримати. Наприклад, це може бути момент здачі робіт, а у випадку виконання великих проектів, де винагороду сторони визначили окремо для кожного етапу – момент завершення такого окремого етапу. 
Найчастіше замовникові надається визначений договором строк для оплати після завершення виконавцем роботи, але така умова впроваджується лише за бажанням сторін.
Потрібно також домовитися про спосіб визначення винагороди – чи буде вона фіксованою або сплаченою відповідно до погодинної ставки (time and material), тощо.
6. Майнові права інтелектуальної власності
Автори комп’ютерних програм часто надають свої програми за ліцензією. Пояснюється це тим, що використання їхніх програм часом повторюється. Універсальність деяких програм означає, що їхні автори, вносячи відповідні модифікації, здатні адаптувати таку програму до потреб різних користувачів. Зробивши програму доступною за ліцензією, ліцензіар зберігає всі права на програму та її документацію, і тому може додатково її змінювати, вдосконалювати або використовувати окремі компоненти такої програми для створення якісно нового програмного забезпечення.
Найважливішими типами ліцензій є ексклюзивна (ліцензіар надає ліцензію лише одній особі), неексклюзивна (ліцензіар може надавати ліцензію необмеженій кількості осіб) та субліцензія (ліцензіат може надавати ліцензію субліцензіатам).
Ексклюзивна ліцензія надається найменш часто. Вона може використовуватися для створення «індивідуального» програмного забезпечення, наприклад, для банку. Ідея такої ліцензії зводиться до того, що користуватися нею можуть лише ті, хто замовляє програму. Ліцензіар не може надавати ліцензію іншому. Найчастіше ж для ПЗ використовуються неексклюзивні ліцензії.
Виконавець програми може також передавати замовнику повні авторські права на комп’ютерну програму. Варто сказати, що хоча таке рішення не є вигідним для самого виконавця (адже він найчастіше зацікавлений у подальшій розробці свого програмного забезпечення та наданні третім особам доступу до нього), на практиці воно застосовується нерідко. Воно може стосуватися, наприклад, ноу-хау. Замовник, маючи деякі технічні знання конфіденційного характеру, доручає створити програму на основі цих знань, тому прагне мати повні майнові права на створену програму. У такій ситуації в договорі повинні бути відповідні положення щодо передачі авторських прав замовнику.
7. Гарантії
Гарантії про виконання роботи (програмного забезпечення) захищають, перш за все, його замовника. До договору важливо включити пункт про гарантію виконавця про те, що створена ним програма не має недоліків. Варто прописати, що у випадку виявлення недоліків у програмі замовник має право вимагати зменшення вартості робіт, або що виконавець повинен виправити їх у визначений договором строк, інакше замовник має право відмовитися від договору. Важливо також, що виконавець може виключити або обмежити цю відповідальність у договорі.
Програма не повинна бути обтяжена правами третіх сторін. Дефекти та помилки можуть зачіпати окремі модулі або також менші одиниці програмного коду. А оскільки виконавець програмного забезпечення може працювати над ним разом із субпідрядниками на основі такого ж або іншого цивільно-правового договору, то права власності на частину створеної комп’ютерної програми належатимуть субпідряднику, якщо сам виконавець не забезпечить належну передачу авторських прав. Якщо замовник бажає бути цілком впевненим, що цього не станеться, він може прописати у договорі, що виконавець зобов’язується виконувати роботу самостійно і не передаватиме її стороннім особам.
8. Додаткові умови
Угоди про створення комп’ютерної програми часто містять положення щодо оновлення програмного забезпечення, обслуговування, підтримки користувачів виконавцем такого ПЗ тощо.
Перш за все, пункти про оновлення програмного забезпечення повинні визначати, як часто буде виконуватися таке оновлення. У випадку, якщо воно призведе до значних змін у програмному забезпеченні, замовник повинен у договорі передбачити, що виконавець проводитиме додаткове навчання для користувача (замовника). Варто також пам’ятати, що нова версія програмного забезпечення, як правило, є новим твором у розумінні авторських прав, тому при використанні програмного забезпечення за ліцензією, необхідно вказати обсяг ліцензії та передбачити, що ліцензія включає також використання нових оновлених версій програм.
Регулювання питання обслуговування програмного забезпечення гарантує практично безперебійне використання програмного забезпечення та швидке усунення недоліків. Отже, пункти договору щодо технічного обслуговування повинні вказувати на час, протягом якого розробник програмного забезпечення зобов’язується усунути дефекти, відновивши нормальне функціонування програми. Також варто класифікувати недоліки програмного забезпечення в договорі, вказавши, які з них будуть недоліками, які повністю перешкоджають використанню програмного забезпечення, а які мають незначне значення.
