Кому принадлежат доработки, которые оплачивает ваш клиент?

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

Представим, что у вас есть платформа, которой пользуются несколько клиентов. Новый клиент оплачивает добавление в неё функции согласования заявок и подключение платформы к своим внутренним системам. В его договоре написано:

“All intellectual property rights in the Deliverables and all developments and improvements arising from the Services belong to the Customer.”

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

В статье я разбираю договоры по английскому праву на программы для бизнеса: кому принадлежат авторские права в Великобритании и как об этом договориться. Для патентов, прав на базы данных и других прав может понадобиться отдельная проверка.

Передаёт ли оплата разработки права клиенту?

Одна только оплата не определяет, кому принадлежат авторские права. По общему правилу они сначала принадлежат автору. Но если сотрудник пишет код в рамках своих обязанностей по трудовому договору, права обычно сразу получает работодатель, если они не договорились иначе. Если ваша компания работает с фрилансерами, нужно подтвердить, как она получила права от них. Для передачи авторских прав нужен письменный документ с подписью того, кто передаёт права, или его представителя. Статья 11 Закона об авторском праве, промышленных образцах и патентах 1988 года (CDPA); статья 90.

Если договор об этом молчит, обстоятельства работы всё же могут давать клиенту разрешение использовать программу. Такое разрешение называется подразумеваемой лицензией. В некоторых случаях суд может решить, что разработчик обязан передать авторские права, даже если стороны прямо не записали это в договоре. Одной оплаты недостаточно для любого из этих выводов. Прямо договоритесь, может ли клиент изменять программу, привлекать другого разработчика или продавать результат. Разъяснения британского ведомства интеллектуальной собственности (IPO) о работах, созданных по поручению клиента; дело Griggs, [2005] EWCA Civ 11, пункты 13–15. В моём руководстве о ранее созданных разработках разобрано, почему суды пришли к разным выводам в делах Griggs и Clearsprings. Второе дело касается программы.

В статье о коде внешних разработчиков я разбираю эти исходные правила. Здесь вопрос в том, какие права разработчику стоит оставить себе и какие передать клиенту.

Что входит в вашу платформу?

Определите, какие части платформы остаются у вас, и проверьте, достаточно ли у вас прав, чтобы выполнить обещания клиенту. В договоре может быть исключение для «Background IP». Так называют права на разработки, которые у вас уже были. Такое исключение может защитить существующую платформу. Но если исключение касается только того, что создано до договора, права на новые доработки могут перейти клиенту, даже если вы планировали использовать их в других проектах.

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

Я бы начал с такой таблицы и обсудил её с командой разработки:

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

В приложении к договору назовите конкретные компоненты, функции или результаты работы. Если появляется новая задача, сразу договоритесь, к какой группе относится её результат. Это не должно зависеть от того, как вы или клиент назовёте его в конце работы. О чужих компонентах читайте в статье об open source и обещаниях клиенту.

Что на самом деле нужно клиенту?

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

Пример

Для чего клиенту продукт?

Для своей компании · Платформа и общие доработки

Сохранить основу для других проектов.

Оставить за собой платформу и общие доработки, включая новые. В договоре разрешить клиенту пользоваться ими в составе продукта.

Уточнить срок, пользователей и возможность сменить команду поддержки.

Как ответить на английском

Let's identify the platform and reusable improvements that should remain ours. We can then agree the rights you need to use and maintain them as part of the product.

Для своей компании · Код для клиента

Определить, какие права нужны клиенту.

Для разработки под конкретную задачу можно договориться о передаче прав или о лицензии. Назвать эту часть продукта в договоре.

Общие доработки платформы, которые нужны вам и для других проектов, выделить отдельно. Согласовать доступ к исходному коду.

Как ответить на английском

Let's identify the work built specifically for you and agree whether you need ownership or a licence. Reusable improvements to our platform should be dealt with separately.

Для своей компании · Сторонние библиотеки

Сверить лицензии с задачей клиента.

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

Договор с клиентом не меняет условия чужой лицензии. Для некоторых компонентов может понадобиться отдельное разрешение.

Как ответить на английском

The product includes third-party libraries under their own licences. Let's identify them and confirm that those terms support your intended use and maintenance.

Для продажи своим клиентам · Платформа и общие доработки

Разрешить продажу продукта. Сохранить права на платформу.

Согласовать распространение нужных частей платформы и её доработок вместе с продуктом. Определить, что смогут делать покупатели клиента.

Отдельно обсудить изменения и поддержку. Разрешения использовать программу только внутри компании недостаточно.

Как ответить на английском

We can discuss rights to distribute the required platform components, including agreed improvements, with your product. Let's define what your customers may do while keeping the agreed platform rights with us.

Для продажи своим клиентам · Код для клиента

Согласовать права для дальнейшей продажи.

Определить, на какую новую разработку клиент получит права, а какую сможет включать в свой продукт по лицензии.

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

Как ответить на английском

Let's agree which new deliverables you will own and which you may distribute under licence. The rights should support your sales model without including all of our reusable work.

Для продажи своим клиентам · Сторонние библиотеки

Проверить условия распространения.

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

Нельзя автоматически разрешить покупателям всё на ваших условиях. Их права должны соответствовать лицензиям этих компонентов.

Как ответить на английском

Before agreeing resale rights, let's check the distribution conditions for each third-party component. Your customers may need notices, source code or permissions under the original licences.

Конкретные условия зависят от ваших прав и сторонних лицензий.

Уточните также, смогут ли пользоваться программой другие компании группы клиента и где её разрешено размещать.

Статья 50C CDPA в определённых случаях позволяет законному пользователю копировать или изменять программу для исправления ошибок, если это необходимо для её законного использования и не запрещено соответствующим соглашением. Но она не решает все вопросы поддержки. Согласуйте права клиента на изменение программы и привлечение другой команды, а также доступ к исходному коду, который позволит воспользоваться этими правами.

Проверьте и срок лицензии, и случаи, когда она прекращается. Даже если лицензия названа «бессрочной», нужно уточнить, когда она может закончиться и сохранится ли после окончания договора на разработку или поддержку. Руководство правительства Великобритании по интеллектуальной собственности, раздел 1.6.

Если клиент пользуется вашим сервисом онлайн (SaaS), отдельно обсудите доступ к сервису и права на его код. Бессрочная лицензия на программу сама по себе не обязывает вас постоянно обеспечивать её работу, оказывать поддержку или выпускать новые версии. Договор должен объяснять, что останется доступно после окончания подписки.

Какие права оставить себе, а какие дать клиенту?

Вы сохраняете права на платформу и доработки для других проектов

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

При этом объясните, за что платит клиент. Например, за разработку его функции в первую очередь, подключение к его системам или выпуск к нужной дате. Запишите это в договоре, чтобы использование кода в других проектах не стало для него неожиданностью.

Клиент получает права на то, что вы создали специально для него

Клиент может получить права на код, который связывает платформу с его системами, а вы можете сохранить права на платформу и функцию согласования. Но клиенту также нужно разрешение использовать те части платформы, без которых этот код не работает. Если договор об этом молчит, суд может решить, что клиент получил необходимые ему права из самой договорённости о цели проекта. В итоге клиенту может быть разрешено больше, чем вы рассчитывали.

Если вы хотите использовать в других проектах материалы, права на которые переходят клиенту, получите его разрешение. Это называется обратной лицензией. Укажите в ней, какие материалы и для чего вы можете использовать. Разрешение поддерживать созданный для клиента код само по себе не позволяет продавать его другим. При этом ваша лицензия не должна лишать клиента оговорённого преимущества перед конкурентами, за которое он заплатил.

Что, если договориться о совместном владении правами?

Если права принадлежат вам и клиенту вместе, нужны отдельные правила. Это не означает, что каждый может свободно использовать код в других проектах. В Великобритании для копирования и изменения кода, а также выдачи лицензий другим обычно нужно согласие остальных владельцев прав, если закон не предусматривает исключение. Заранее договоритесь, что каждый может делать без нового согласования и кому можно выдавать лицензии. Решите, как делить доходы, кто будет защищать права при нарушении и что произойдёт, если кто-то захочет выйти из совместного владения. Доли 50 на 50 этих вопросов не решают. Иногда проще оставить права одному владельцу, а другому дать подходящую лицензию. Статья 16 CDPA; статья 173(2); разъяснения IPO о соавторах.

Клиент оплачивает эксклюзивность на определённый срок

Если клиенту важно преимущество перед конкурентами, вы можете на время обязаться не предлагать определённую разработку конкретным конкурентам или на выбранном рынке. Укажите, о каких функциях идёт речь, что именно вы не будете делать, как долго и какие есть исключения. Сохраните возможность поддерживать существующих клиентов и делать другие, не связанные с этой договорённостью улучшения.

Исключительная лицензия устроена иначе: действия, которые она разрешает клиенту, не может совершать больше никто, включая самого владельца прав. По статье 92 для такой лицензии нужен письменный документ с подписью владельца прав или его представителя. Ограничение на предложение этой разработки конкурентам нужно записать в отдельном условии договора. Нужно проверить, будет ли оно иметь силу и не нарушает ли законы о защите конкуренции. Статья 92 CDPA.

Кроме того, права на код не обязательно позволяют клиенту запретить другим создавать программы с такими же функциями. Авторское право не защищает функции сами по себе. Ваше обещание не предлагать эту разработку конкурентам не мешает независимой компании создать похожую функцию. Дело SAS Institute, C-406/10, пункты 39–46; решение Апелляционного суда, [2013] EWCA Civ 1482, пункты 45–52.

Можно ли повторно использовать код, написанный для клиента?

Это возможно, если у вас есть нужные права и вы соблюдаете договор, конфиденциальность и условия лицензий на чужие компоненты. Даже если авторские права остались у вас, использовать код без ограничений можно не всегда.

В деле Clearsprings Management Ltd v Businesslinx Ltd [2005] EWHC 1487 (Ch), пункты 23 и 38–53 договор прямо не определял, кому принадлежат авторские права. Суд признал, что клиент получил неисключительную лицензию: он мог пользоваться системой, поддерживать и обновлять её, но не стал владельцем прав и не мог выдавать лицензии другим. Разработчик тоже не мог свободно использовать систему целиком, в том числе продавать её другой компании. При этом он мог использовать универсальные блоки кода в других проектах, соблюдая ограничения, которые защищали рабочие процессы клиента. Где именно проходила граница этого ограничения, суд окончательно не определил. Выводы зависели от обстоятельств дела. Поэтому лучше прямо записать в договоре, что вы можете использовать в других проектах.

В нашем примере код функции согласования и закрытые внутренние правила клиента требуют разных условий. Даже если убрать из кода название клиента, его конфиденциальная информация может там остаться. Использование или раскрытие коммерческой тайны в нарушение обязанности сохранять её в секрете незаконно. Укажите, что вы можете использовать в других проектах, какие материалы клиента из этого исключены и как отделить их в коде. Trade Secrets Regulations 2018, правило 3.

Как права влияют на цену?

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

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

Что я изменил бы в условии о правах?

Вернёмся к требованию клиента передать ему все разработки и улучшения. Исключение только для ранее написанного кода не решает вопрос с новой функцией согласования. Правка должна ясно отражать договорённость сторон.

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

Чтобы использовать эту формулировку в договоре, в пунктах 12.2 и 12.3 нужно записать саму передачу прав и лицензию: как клиент может использовать, изменять и поддерживать платформу и доработки, в том числе с другой командой. У вас должны быть права, которые вы обещаете клиенту. Если нужны другие виды интеллектуальных прав, их следует описать отдельно.

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

Укажите, какой документ действует при противоречии: например, если в задании на работы или более позднем соглашении права описаны иначе.

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

Что произойдёт, если разработчик больше не сможет поддерживать продукт?

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

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

Можно использовать эскроу исходного кода. Код и другие согласованные материалы хранятся у независимой компании. Она передаёт их клиенту, если наступит указанное в договоре событие. Руководство правительства Великобритании описывает этот вариант для случая, когда права остаются у разработчика. В нём также предусмотрено согласование событий для передачи материалов и обновление копий, которые хранятся у независимой компании. Руководство к Model Services Contract, раздел 2.7.3.

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

Что проверить перед подписанием?

1. Определите, какая часть платформы остаётся у вас. Перечислите компоненты, с которыми вы приходите в проект, и подтвердите права на них.
2. Договоритесь, кому принадлежат новые разработки. Включите и доработки для других проектов, и результаты для конкретного клиента. Обновляйте договорённость, когда меняется объём работы.
3. Проверьте, что клиент сможет делать с программой. Сможет ли он запускать, изменять и передавать её другим, поручать поддержку другой команде? Что изменится после окончания договора? Ответы должны учитывать, получает ли клиент саму программу или пользуется онлайн-сервисом.
4. Запишите, что вы можете использовать в других проектах. Уточните, что вы обещаете клиенту в отношении его конкурентов. Соблюдайте конфиденциальность и права на материалы клиента и чужие компоненты.
5. Подготовьте переход к другой команде. Одних прав недостаточно: нужны доступ к коду, выгрузка данных и передача материалов. Если используете эскроу, проверьте и его условия.
6. Проверьте договор целиком. Значения терминов, задания на работы, обещания о правах, ограничения лицензии и условия окончания договора должны соответствовать друг другу.

Договор должен позволять клиенту использовать оплаченный результат на согласованных условиях и ясно показывать, какие разработки вы можете продолжать использовать в своём бизнесе.

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

Общая информация, а не рекомендация по конкретному договору.