На що звернути увагу, підписуючи договір. Чеклист пунктів

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

Мене звати Зоряна, я старша юристка Legal IT Group. У цій статті я розкажу, як розробнику, помічаючи справді важливе, читати договори, які компанія пропонує до підписання, і які пункти варто видаляти.

Що на словах — те на папері

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

«The Customer orders and the Contractor obliges to provide software development and testing services according to the terms hereof (the „Services“) and the Customer shall accept the Deliverables and proceed with the payment for the Services pursuant to the terms herein*».

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

Особливу увагу приділіть цьому розділу, якщо у вас є статус ФОП, адже такі послуги повинні відповідати вашим КВЕДам.

Так, наприклад, якщо у вас КВЕД «Комп’ютерне програмування», то формулювання ваших послуг як «розробка та тестування об’єктів 2D та 3D дизайну за Завданнями Замовника, включаючи креативну та технічну адаптацію таких об’єктів дизайну до конкретних потреб користувачів» не відповідатиме йому і його краще видалити.

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

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

«The specification, scope, methods of performance and timescales of Services shall be mutually agreed upon via the System, email or other means of communication on a monthly basis. Parties are entitled to make amendments to the type of Services, the scope of Services, and the terms of the Services provision».

Вихід є завжди (або принаймні повинен бути)

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

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

«Either Party may unilaterally terminate this Agreement upon providing fourteen (14) calendar days’ prior notification to the other Party».

Також перевірте, чи не передбачено прихованого випробувального строку в договорі. Якщо він є і це не було погоджено, то його слід видалити. Його можете побачити, наприклад, у такій редакції:

«Протягом перших 3 (трьох) календарних місяців з дати набрання чинності цим Договором, Замовник має право негайно розірвати цей Договір в односторонньому порядку за умови повідомлення Виконавця про це за допомогою Системи».

Альтернативно ви можете відредагувати цей пункт наступним чином:

«Протягом перших 3 (трьох) календарних місяців з дати набрання чинності цим Договором, Замовник будь-яка зі Сторін цього Договору має право негайно розірвати цей Договір в односторонньому порядку за умови повідомлення Виконавця іншої Сторони про це за допомогою Системи щонайменше за 3 (три) календарні дні до бажаної дати розірвання Договору».

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

«In case of Contractor’s violation of the terms of performance of the obligations defined herein or through the communication of the Parties via the System, due to the fault of the Contractor, or provision of Deliverables with Defects, the Customer may terminate this Agreement unilaterally with immediate effect upon providing notification to the other Party in this regard via the System».

Що ми кажемо вічним правкам? — Не сьогодні!

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

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

Однак тут виникає інший момент: досконалості немає меж і замовник може вносити правки до безкінечності, змінюючи свою думку декілька разів. Як вам таке положення?

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

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

«Кількість запитів Замовника щодо внесення змін та виправлень у Результати Послуг, які були надані Виконавцем, не обмежується протягом всього строку дії Договору».

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

«Кількість звернень Замовника щодо внесення змін та виправлень до Результатів Послуг, наданих Виконавцем, обмежується 2 (двома) зверненнями протягом усього строку дії Договору. Подальше внесення змін та виправлень у Результатах Послуг, які були надані Виконавцем, можуть здійснюватися за додаткову плату, умови якої погоджуються Сторонами через Систему».

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

«Замовник може перевірити Результати Послуг. Після отримання будь-яких Результатів Послуг, наданих у відповідному місяці, Замовник матиме період у 10 (десять) робочих днів, протягом яких проводить перевірку таких Результатів Послуг та повідомляє Виконавцю про результати перевірки через Систему, якщо Сторони не погодили інше».

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

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

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

За порушення договору настає відповідальність і це ОК. Питання лише у тому: наскільки вона (ні, не сувора, як ви могли подумати) співмірна з таким можливим порушенням.

Розділи про відповідальність за договором можна поділити на 2 категорії:

1) Відповідальність за законом.

«Сторони несуть відповідальність за порушення положень цього Договору відповідно до чинного законодавства України».

2) Штрафи, штрафи, штрафи.

У своїй практиці я зустрічала штрафи і 5 000 USD, і 100 000 USD. Штрафи можуть бути за порушення NDA, за перехід до конкурента чи клієнта, за прострочення надання послуг, за будь-яке порушення договору, за те, що керівник у поганому настрої. Щодо останнього, звісно, легко буде оскаржити, якщо реальних договірних підстав немає. Попри це, я не раджу погоджуватися на санкції, навіть якщо ви переконані в тому, що замовнику не вдасться їх застосувати, або ж у тому, що така ситуація ніколи не трапиться. Хто ж буде стягувати 100 000 USD за те, що робота була здана на день пізніше?! Ви матимете рацію з точки зору здорового глузду, але свобода договору передбачає те, що ви вільно і з повним розумінням майбутніх зобов’язань підписували договір, а отже повинні його виконувати.

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

Тримай язика за зубами на віки вічні

Положення про нерозголошення вже давно стали частиною нормальної бізнес-практики. Втім рекомендую зважати на три моменти:

1. Скоуп інформації, яка вважається конфіденційною.

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

2. Розголошення конфіденційної інформації колегам для цілей виконання своїх обов’язків за договором не повинно бути порушенням.

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

3. Строк, протягом якого діють зобов’язання з конфіденційності.

Якщо бачите варіант «безстроково» чи років 10-20 — раджу видаляти. Конфіденційна інформація також має здатність застарівати і втрачати свою актуальність.

Навіть коли до нас за розробкою договору звертається ІТ-компанія, то ми зазвичай не радимо вказувати такий довгий період дії положення про нерозголошення, адже на практиці, у випадку виникнення спорів і звернення до суду, суд може вважати і строк у 10 років занадто обтяжливим для виконавця. Зазвичай в договорах розробки програмного забезпечення CRM-систем вказують термін у 3–5 років (після припинення договору) для збереження конфіденційності. І цього цілком достатньо.

Ніхто, крім нас, або Більше ніколи ні на кого не працюй

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

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

«Виконавець підтверджує, що не буде співпрацювати/надавати послуги замовникам, постачальникам, підрядникам, працівникам Замовника за прямими контрактами, а також не буде надавати клієнтам Замовника послуги...».

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

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

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

Тепер вправа на закріплення знань: що краще видалити звідси?

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

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

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

А що з ШІ та open-source ресурсами

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

Клієнт може піти шляхом повної заборони використання ШІ-ресурсів; обмеженого дозволу щодо конкретних ресурсів/для конкретних потреб; чи повного дозволу.

Нижче приклад того, як може виглядати положення щодо використання ШІ:

«Виконавець має право використовувати системи штучного інтелекту (надалі — „ШІ“), включаючи, але не обмежуючись, обробку природної мови, алгоритми глибокого навчання, моделі машинного навчання або інші генеративні ШІ, для надання Послуг за цим Договором виключно за умови, що такі системи ШІ забезпечують повне відчуження майнових прав інтелектуальної власності на згенеровані матеріали на користь Виконавця з можливістю їхньої передачі Замовнику. Виконавець гарантує, що згенеровані матеріали придатні для використання Замовником у комерційних та інших цілях без обмежень, передбачених законодавством чи умовами третіх осіб. Виконавець зобов’язується ознайомлюватися з публічними умовами використовуваних систем ШІ та неухильно їх дотримуватися, несучи повну відповідальність за будь-яке їх порушення, включаючи неможливість використання Замовником згенерованих матеріалів у комерційній чи іншій діяльності. Виконавець гарантує, що не вводитиме в системи ШІ жодної належної Замовнику Конфіденційної інформації та персональних даних».

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

Доволі адекватним буде, якщо ви зустрінете наступне положення:

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

Віддавай усі свої права на все-все-все

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

1) Скоуп об’єктів, на які переходять права інтелектуальної власності.

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

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

2) Момент переходу прав інтелектуальної власності.

Найчастіше моментом переходу майнових прав інтелектуальної власності від розробника до замовника може бути:

• момент, наступний за створенням відповідних об’єктів права інтелектуальної власності;
• момент оплати замовником послуг, в рамках надання яких були створені відповідні об’єкти права інтелектуальної власності;
• момент підписання акта приймання-передачі наданих послуг.

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

«Усі майнові права інтелектуальної власності на Об’єкти в повному обсязі переходять від Виконавця до Замовника з моменту оплати рахунку Виконавця».

Висновок: підписуйте лише той договір, умови якого ви розумієте

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

Чеклист для перевірки:

• Предмет реально відображає суть послуг.
• Є порядок одностороннього розірвання договору.
• Порядок перевірки результатів послуг є адекватним, немає вічних безкоштовних правок.
• Відповідальність за договором є прийнятною, штрафи (якщо є) не сягають небес.
• Є чіткий і адекватний строк дії зобов’язань по нерозголошенню конфіденційної інформації.
• Договір не містить умов щодо неконкуренції або вони мають чіткі обмеження.
• Ви розумієте умови використання ШІ та open-source ресурсів.
• Майнові права інтелектуальної власності переходять до клієнта після оплати і ваші позаробочі напрацювання у безпеці.

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

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