8 Самых Распространенных Ошибок при Передаче Интеллектуальной Собственности в Соглашениях о Разработке Программного Обеспечения

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

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

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

В интересах ИТ-компании лежит полное владение всеми правами на интеллектуальную собственность на программное обеспечение (которое является передаваемым), чтобы она могла продолжать бесперебойно эксплуатировать программное обеспечение с экономической точки зрения, а также модифицировать его, обновлять и т. д. Поэтому ИТ-компании следует обращать особое внимание на то, как будет регулироваться вопрос о том, кто владеет интеллектуальной собственностью, созданной разработчиком. Это особенно подкрепляется тем, что компании часто даже не осознают, как много одно слово может изменить весь смысл передачи прав. В этой связи может произойти фатальная ошибка в неправильной формулировке разницы между передачей (продажей) программного обеспечения и его лицензированием. Также не редко неверно описывается предмет передачи, то есть программное обеспечение, и тем самым ошибочно определяется интеллектуальная собственность, а также неправильно определяется момент передачи прав на программное обеспечение и т. д.

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

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

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

В случае применения законодательства Республики Сербии следует иметь в виду положение Закона о авторском праве и смежных правах Республики Сербии, которое предписывает, что если компьютерная программа (программное обеспечение) была разработана на основе соглашения о разработке программного обеспечения, сторона, заказавшая такую разработку — клиент (в нашем случае, ИТ-компания) приобретает все права на использование этой компьютерной программы, если иное не предусмотрено соглашением. Таким образом, клиент, который «заказал» программное обеспечение, по умолчанию получает все передаваемые права, но закон позволяет соглашениям о разработке программного обеспечения предусматривать иное решение. Поэтому крайне важно точно регулировать этот вопрос в соглашении и избегать любых сомнений.

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

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

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

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

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

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

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

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

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

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

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

Хотя эти пункты не встречаются слишком часто в соглашениях о разработке программного обеспечения, когда они присутствуют, это вызывает усилия по переговорам, как правило. Существует несколько причин для этого, и одной из ключевых является намерение ИТ-компании быть единственным владельцем всего, созданного во время договорных отношений, особенно если программное обеспечение является высококонкурентным продуктом. Однако может ли память кого-то фактически быть ограничена? Этот вопрос требует обсуждения. Поэтому этот пункт требует осторожности при его регулировании.

Было сказано, что передачу прав на интеллектуальную собственность от разработчика к ИТ-компании, которая заключила с ним договор на разработку программного обеспечения, следует рассматривать как первичную передачу прав в цепи.

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

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

Это следует особенно учитывать, если материнская ИТ-компания планирует продать (любую) дочернюю компанию в будущем. Факт того, что дочерняя компания имеет лицензию или другое право на программное обеспечение, может значительно увеличить стоимость этой компании при продаже третьему лицу. Ожидается, что покупатель дочерней компании проведет проверку в ходе покупки, и если эти вопросы не (правильно) регулируются в договоре на разработку программного обеспечения, это может отпугнуть потенциального покупателя, т.е. инвестора. Это особенно важно, если связанные стороны не согласны, а общий интерес в использовании программного обеспечения остается.

Одним из распространенных примеров из практики является запрос от продавца при изменении статуса (в нашем примере это была бы материнская компания, которая продает дочернюю компанию) гарантировать и подтвердить, что он является единственным владельцем и держателем всех прав на интеллектуальную собственность и что его интеллектуальная собственность не подлежит никаким ограничениям, которые бы препятствовали их передаче третьим лицам. Если эта гарантия была неверной из-за неправильной передачи, материнская компания может подвергнуться серьезным убыткам за гарантирование чего-то, что не является правдой.

Хотя на первый взгляд кажется, что они не относятся к данному контексту, торговые секреты являются еще одним важным аспектом интеллектуальной собственности, который составляет неотъемлемую часть любого соглашения о разработке программного обеспечения. Любое разглашение коммерческой тайны компании несет риск потенциального ущерба, который может быть нанесен, если торговая тайна попадет в неправильные руки. С другой стороны, обмен конфиденциальной бизнес-информацией с другой стороной неизбежен в любых деловых отношениях; таким образом, необходимо найти идеальный баланс – раскрыть столько, сколько необходимо для успешного сотрудничества, но защитить себя от возможных рисков.

Именно здесь вступает в силу клaузула о конфиденциальности в соглашении о разработке программного обеспечения, точно определяя, какая информация является конфиденциальной, какие обязательства несут стороны соглашения относительно ее защиты, и возможные санкции за нарушение этих обязательств. Хотя нет сомнений в том, что отдельное соглашение о конфиденциальности является лучшим способом регулирования этого вопроса, если стороны по каким-то причинам не соглашаются на подписание отдельного NDA, рекомендуется, чтобы соглашение о разработке программного обеспечения содержало как минимум всеобъемлющий клоз о конфиденциальности, который спасет владельца конфиденциальной информации от поздних трудностей в случае спора относительно разглашения.

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