Аутсорсинговый договор с клиентом из США. Что необходимо учесть?

Аутсорсинговый договор с клиентом из США. Что необходимо учесть?

26 июня встретились онлайн для обсуждения особенностей составления договора на услуги разработки ПО для клиентов из США.

Спикер встречи:

 

Аутсорсинговый договор с клиентом из США. Что необходимо учесть?

Дмитрий Дубограев

Управляющий партнер и СЕО международной юридической компании femida.us

План статьи:

  1. ВременнЫе рамки соглашений.
  2. Структура аутсорсного соглашения.
    2.1. Outsourcing Agreement с точки зрения девелопера.
    2.2. Outsourcing Agreement с точки зрения клиента.
  3. Вопросы обладания правами.
  4. Стороны договора – видимые и невидимые.
    4.1. Со стороны разработчика.
    4.2. Со стороны клиента.
  5. Проблема неплатежа – что делать?
  6. Защита исполнителя.
  7. Выбор юрисдикции – на что он влияет?
  8. На какие аспекты еще обратить внимание?

Особенности контрактов в США и их отличие от европейских начинаются с правовой системы. В Соединенных Штатах основное внимание сосредоточено на договоренности сторон. Именно, исходя из понимания этого, надо подходить и к составлению соглашения. Отсюда вытекает и такое понятие как «качество контракта», в котором следует предусмотреть все возможные сценарии развития событий и постараться закрыть все «бреши в кольчуге». Чтобы при разрешении спорных моментов (в суде, в арбитраже, при заключении досудебного соглашения и пр.) у каждой из сторон была возможность аргументировать свою позицию с точки зрения «я поступил законно и этично, так как я поступил по контракту».

Кроме того, следует очень внимательно отнестись к законодательным нормам, которые могут сильно различаться от штата к штату. Где-то они приближены к европейским и безапелляционно регламентируют, например, правила взаимодействия с исполнителями и субконтракторами, или же то, как будет разрешаться вопрос ответственности сторон с точки зрения возмещения ущерба.

Ниже рассмотрим подробнее некоторые моменты, которые следует учесть при составлении договора на аутсорс-разработку ПО для американского клиента, и которые позволят минимизировать проблемы при возникновении спорных ситуаций.

1. Временны́е рамки соглашений

Взаимодействие с клиентом в рамках договора осуществляется в несколько этапов, традиционно – в пяти, которые включают:

  1. Non-disclosure agreement (NDA) – изучение бизнеса, технологий, предварительное соглашение о неразглашении.
  2. Оговариваются основные согласования по ценам, условиям. Могут осуществляться в переписке.
  3. Подписание соглашения. Каждая сторона дает некие заверения и гарантии (representations and warranties), например, об отсутствии банкротства, не включении подписывающего лица в санкционные списки и пр.
  4. Непосредственно «совершение» – closing. На этом этапе основные обязательства вступают в действие, а representations and warranties «мертвы», если иное не предусмотрено в соглашении (прописываются гарантии на определенный период). Вступают в силу основные обязательства, такие как «передача лицензии», «оплата» и т.д.
    Возможен временной промежуток между фазами «подписали соглашение» и «соглашение начинает действовать», например после выполнения условия «внесение заказчиком оплаты в размере …» – т.наз. «pre-closing».
    Часто 3 и 4 фазы в договорах могут быть соединены, т.е. договор вступает в действие с момента подписания соглашения.
  5. Прерывание или истечение договора. При этом некоторые из обязательств «выживают».

2. Структура аутсорсного соглашения

Западная и восточная структуры контракта очень различаются, в первую очередь разными подходами и терминологией. Плохая идея – использовать привычную восточноевропейскую форму, чьи «уши торчат» в первую очередь в формулировке «subject of agreement».

Коренное отличие будет заключаться в подходе. Американский основан на Laissez-faire (невмешательстве), что следует понимать «как написано, так и будет». В то время как европейский – на Civil Code (гражданском кодексе), который может вносить ограничения в любые договоренности между сторонами.

Что касается структуры, то помимо основного соглашения, контракт должен включать statement of work — документ по управлению проектом, который регулирует сотрудничество между двумя компаниями, проще – техническое задание. Именно в нем должны быть прописаны все нюансы соглашения между клиентом и IT-компанией с целью максимально подробного описания задачи, а также сведения к минимуму риска противоречий и недопониманий между сторонами. Соответственно, формулировки в нем должны быть ясными, однозначными и не допускающими создания условий для интерпретации даже в рамках описания «extra tasks» для разработчиков – по объему, таймингу, фидбэку, количеству исправлений и т.д. с четким распределением ответственности. Составляется также SOW для Time & Materials, где прописываются обязательства относительно квалификации исполнителей, возможных претензий к трудовой дисциплине и результата выполненной работы.

Modern structure договор состоит из двух основных частей. Первая – Main/short with business terms – основная «для бизнеса». Все остальное – с юридическими подробностями – оформляется в виде дополнения (приложения). Такая структура позволяет легче проходить через комплайнс в больших компаниях, не «утяжеляя» подробностями бизнесовую часть, и в то же время позволяя прописать все возможные камни преткновения, которые могут возникнуть в спорных вопросах.

2.1. Outsourcing Agreement с точки зрения девелопера (в порядке агрессивности) может включать:

  • «Romalpa» clause – передача прав на владение кодом заказчику после факта передачи и, главное, только после оплаты. Следует отметить, что такая формулировка проходит редко, если на стороне клиента достаточно опытные юристы.
  • Work for hire – формулировка, которая более приемлема для больших компаний. Т.е. разработка принадлежит клиенту с момента начала написания кода. Но обезопасить сторону разработчика можно попробовать уточнением того, что title переходит в собственность заказчика в момент оплаты. Казалось бы, противоречивые требования, однако можно попытаться оформить их как «связанные события», например зафиксировав их как «payment» (внесение оплаты в строго определенный срок) затем право на «title».
  • Clean work for hire – даже в этом случае есть возможность ограничить права заказчика, если предусмотреть полную передачу прав до факта оплаты:

а) прописыванием наличия временнЫх ключей;

б) прописыванием того, что deliverables находится в залоге (но! в случае неоспоримости invoices – когда надлежащее исполнение было подтверждено).

Факт нахождения разработки в залоге по большому счету прав на нее разработчику не дает, но может послужить инструментом давления на заказчика по оплате, если информировать об этом обстоятельстве хостеров, платформы, его собственных клиентов и т.д.

  • Title reverts back to developer – право на владение разработкой возвращается к исполнителю, если оплата не произведена через оговоренный срок. Такая формулировка может обернуться trap for client. Если исполнитель обнаруживает, что клиент, не оплативший разработку, ею пользуется, то может привлечь на свою сторону общественное давление (информирование) с целью возмещения ущерба.

2.2. Outsourcing Agreement с точки зрения клиента

На каких формулировках может настаивать клиент?

  • work for hire;
  • title переходит к клиенту в момент начала написания кода;
  • обязанность оплаты не связана с title. (Задача стороны разработчика – эти два события связать!)

Полная версия доступна только для действующих членов Клуба.

Читать полную версию


Другие публикации по теме:


BICC International объединяет экспортные ИТ-компании Беларуси для сотрудничества, обмена опытом и важной информацией.
Клуб — это:

  • закрытое сообщество из 200+ владельцев и руководителей,
  • обмен лидами и бенчем в Bench_Exchange,
  • консультации для ваших бухгалтеров и юристов,
  • регулярные встречи и отраслевые исследования.