Представим ситуацию — инвестор хочет купить долю в IT-стартапе, который занимается продуктовой разработкой ПО. Стартап сразу говорит, что с правами на ПО все хорошо. Но злодеи-юристы после due diligence продукта пришли к противоположному выводу. Надо срочно все спасать. Что можно сделать? Рассказывает эксперт Moscow Digital School Анастасия Нерчинская.
На первых встречах до начала due diligence стартапа команда проекта пытается убедить юристов инвестора в том, что «ПО писали люди из штата», «трудовые отношения оформлены как надо», «авторы все свои», «вот свидетельство о государственной регистрации ПО».
Дальше юристы смотрят документы и видят, что первая коммерческая версия ПО, запущенная в продажу, была создана задолго до появления компании. Позже выясняется, что два человека «из штата» 2 года писали код ПО «под пальмами» «сами для себя», а потом к ним «присоединился ИП». В трудовых отношениях по факту никто с компанией во время разработки MVP не состоял. На вопрос, откуда у стартапа появились права на ПО, компания показывает лицензионный договор, заключенный с «aффилированным лицом», которое и предоставило ему права. И вообще, раз в распоряжении группы есть исходные коды ПО, значит именно стартапу все права и принадлежат. А документы? «Документы все потом подпишут, какие надо».
За месяц до этого инвестор оценил enterprise value стартапа исходя из наличия у него нематериального актива, красиво описанного в презентациях, и подтвержденной выручки от его коммерциализации. Но потом пришли юристы и все испортили.
Такой сценарий или его вариации встречаются до неприличия часто.
Вопрос: как помочь стартапу получить инвестиции, не расстроить инвестора срывом сделки, и чтобы потом никому не было мучительно больно?
Отсутствие прав на ПО у технологической компании – это безусловный deal-breaker. Права на ПО компании или принадлежат, или нет. Половина, треть или «немножко» прав – это явно не то, чего ожидал инвестор, перед которым лежит свежий многостраничный due diligence report.
Что нужно делать?
Итак, прав на ПО у компании нет, потому что они изначально возникли у других лиц и по причине неправильно оформленных документов к компании не перешли. Зато, как следствие, у компании есть многочисленные юридические риски и неработающая финмодель.
Если ПО создавалось силами работников компании (без привлечения подрядчиков), никто из них не уволился, а ПО не зарегистрировано в Роспатенте, есть надежда все исправить в текущем моменте. В остальных случаях это будет намного сложнее.
Скорее всего, юристы сказали, что не подтвердился режим «служебного» ПО. По законодательству, права на созданное работниками ПО возникают у компании только в том случае, если создание такого ПО входило в их должностные обязанности. Казалось бы, какая банальность. Но при юридической проверке прав на ПО постоянно обнаруживаются одни и те же «классические» ошибки – обязанности разработчиков сформулированы неправильно, не сформулированы вообще, либо работники не ознакомлены со своими должностными инструкциями под роспись. Даже если при этом в трудовых договорах предусмотрена оговорка о том, что все ПО, созданное работниками, считается служебным и исключительное право на него принадлежит компании, это не поможет: само по себе такое положение в трудовом договоре не обеспечивает автоматический переход к компании прав на ПО.
Избегайте подхода «мы сейчас всё найдем»
В такой ситуации владельцам стартапа бывает крайне сложно удержаться от того, чтобы внезапно «найти», «вспомнить все» и показать юристам все необходимые документы.
Но инвестору раннего раунда следует помнить, что его успешный exit во-многом зависит от входа нового инвестора, юристы которого могут оказаться более придирчивым к качеству ключевого актива. Поэтому от любых «схемотехник» по восстановлению прав на ПО, которые иногда предлагают особо креативные юристы («которые решают вопросы и не создают лишних проблем»), следует сразу же отказаться. В первую очередь, – от применения популярной методики «а давайте все подпишем задним числом». Подписание прошедшей датой само по себе не всегда одинаково «вредно». Но ситуаций, в которых это может быть оправдано и не повлечет серьезных юридических последствий, крайне мало.
Также не стоит всерьез рассматривать вариант с подписанием правильных дополнительных соглашений (которые содержат правильные обязанности разработчиков, положения об авторском вознаграждении, правила использования информационных систем и репозиториев, уведомления работодателя о создании ПО и т.п.) к трудовым договорам с ретроактивной оговоркой. То есть не следует подписывать текущим числом, но в самом документе указывать, что он распространяется на отношения сторон с определенной даты в прошлом. Суды не признают силу таких оговорок в трудовых отношениях. Поэтому если недовольный работник решит обратиться в суд, компания его, скорее всего, проиграет.
Установите всех причастных
Чтобы компания могла восстановить права на ПО, сначала нужно идентифицировать всех работников, которые участвовали в его непосредственной разработке. IT-юристы с высокой точностью могут установить всех действительных авторов ПО без проведения технической экспертизы и с правовой точки зрения оценить роль каждого работника в создании ПО. Например, если генеральный директор придумал концепцию продукта и «дирижировал» командой разработки в течение нескольких лет, но при этом в создании кодовой базы или технической документации не участвовал, автором ПО он считаться не может. Даже если он указан единственным автором в свидетельстве о государственной регистрации ПО.
Именно у авторов возникает первоначальное исключительное право на ПО. Поэтому от точности установления их круга зависит дальнейшая судьба прав на продукт. Ошибка хотя бы в одном авторе, особенно если он создал существенную часть кода, может дорого стоить компании.
Установив круг авторов ПО, дальше нужно проанализировать всю историю переходов прав на него от авторов до действительных правообладателей. Главное не пропустить «звенья» цепочки переходов исключительного права, иначе снова можно ошибиться и компания в этой части ПО окажется «лжеправобладателем». Работники, с кем по документам не подтвердился режим «служебности», и есть действительные правообладатели ПО, при условии, что внутри корпоративной группы права на ПО не отчуждались. Если это единое ПО – каждый такой автор-работник обладает долей в исключительном праве совместно с другими в отношении всего программного комплекса. В этом случае в отношении такого ПО возникает режим совместного правообладания, когда компания не может законно заключать со своими клиентами лицензионные договоры без согласия таких со-правообладателей.
Можно только так и никак иначе
«Восстановить» права на ПО, которых нет и никогда не было, можно только одним способом – путем их отчуждения от тех лиц, у кого они есть (например, от работников-авторов) тому, кому они нужны (то есть компании). В отношении уже созданного ПО для этого есть только одна юридическая конструкция – договор об отчуждении исключительного права. Все остальные варианты, обычно, сопряжены со значительными рисками. В том числе попытки применения положений ст. 183 ГК РФ о последующем одобрении надлежащей стороной (правообладателем) сделок с ПО, совершенных неуполномоченным лицом («лжеправообладателем»).
Такой договор (об отчуждении исключительного права) можно заключить только «сегодня», то есть текущей датой. «Вредный совет», который поначалу кажется правильным, о придании такому договору ретроактивной силы применять на практике не рекомендуется. То есть вариант «а давайте мы текущей датой подпишем договор об отчуждении исключительного права в пользу компании, а в договоре укажем, что его положения распространяются на конкретную дату в прошлом, и что на самом деле права на ПО компании перешли к компании не сегодня, а тогда» – не подходит.
В одном из споров суд указал, что «условия договора об отчуждении исключительного права нельзя распространить на отношения, возникшие до заключения соответствующего договора, поскольку это противоречит вышеприведенным положениям Кодекса [ст. ст. 1229 и 1234 ГК РФ] и существу отношений между обладателем исключительного права и неопределенным кругом лиц, имеющих право обратиться к правообладателю за разрешением на использование результата интеллектуальной деятельности»*.
* Постановление Тринадцатого арбитражного апелляционного суда от 11 февраля 2019 года по делу №А56-44762/2018, подтвержденное Постановлением Суда по интеллектуальным правам от 6 августа 2019 года по делу № А56-44762/2018.
Таким образом, Суд по интеллектуальны правам в 2019 году подтвердил, что так делать нельзя (вне зависимости от того, зарегистрировано ПО в Роспатенте или нет).
Следует помнить, что, если ПО уже зарегистрировано в Роспатенте или в Минцифре, такая ретроактивность сразу приведет к явной недостоверности сведений о правообладателе, а в последнем случае – к риску исключения из реестра отечественного ПО.
То факт, что при смене правообладателя ПО все действующие лицензии сохраняют свою силу, не может свободно применяться к ситуации с ретроактивной «заменой» правообладателя. Отсутствуют какие-либо серьезные аргументы в пользу позиции, что положения п. 7 ст. 1235 ГК РФ работают в «обе стороны». То есть как в отношении будущей смены правообладателя, так и «ретроактивной», то есть с эффектом в прошлом. С учетом позиции СИПа о том, что «поменять» правообладателя ПО (и тем самым автоматически затронуть права и законные интересы третьих лиц – контрагентов текущего правообладателя и нового «ретроактивного» или как минимум создать предпосылки для нарушения их прав) волей двух сторон обязательства, отчуждать исключительное право с ретроактивной оговоркой не рекомендуется.
Некоторые юристы иногда рекомендуют в таких ситуациях подписывать не договор об отчуждении исключительного права, а некий акт, в котором предлагают указывать, что работники – авторы ПО и компания «просто подтверждают», что «ПО на самом деле было создано в режиме служебного произведения, в соответствии с трудовыми обязанностями работников, права на него принадлежат компании, работник вознаграждение получил и претензий к компании не имеет». Так вот сама по себе такая бумага, без положений об отчуждении исключительного права в полном объеме от лица А лицу Б, не решает проблему, если создание ПО не входило в служебные обязанности работника.
О чем еще следует помнить
В идеале лучше сделать один многосторонний договор об отчуждении исключительного права со всеми действительными правообладателями единого продукта, а не много двусторонних о передаче разрозненных фрагментов с каждым отдельным правообладателем. По этому договору компании также нужно передать исключительное право на: (i) подготовительные материалы к ПО (все «бумажные» или «электронные» материалы, созданные при разработке ПО, в том числе техническую документацию, прототип и все «удачные и не очень» версии ПО, предшествующие MVP; (ii) собственно MVP и все последующие версии ПО; (iii) пользовательскую документацию / руководства по эксплуатации, технические задания на разработку ПО (права на это все лучше продавать не как часть ПО, а как произведение науки / литературы); (iv) все базы данных, к которым обращается ПО, если они создавались специально для его работы (особенно важно для систем ИИ); (v) все картинки, объекты дизайна и графики, которые используются в ПО (права на них лучше отчуждать и как на часть ПО, и как на самостоятельные объекты); (vi) подбор и расположение программных компонентов (составительство), если отчуждаются права на составное ПО.
При заключении такого договора компания должна будет заплатить вознаграждение за отчуждение прав всем правообладателям. Здесь возникает много вопросов и рисков, особенно если права восстанавливаются перед инвестиционной сделкой. Бизнес обычно не готов платить в этом случае правообладателям (авторам- работникам) рыночную стоимость прав на ПО. Суммы вознаграждения подлежат налогообложению. Не заплатить вознаграждение за отчуждение прав (в отличие, например, от предоставления прав по лицензии) по закону нельзя. От цены приобретения прав на ПО зависит балансовая стоимость НМА у компании-приобретателя. Чем вознаграждение ниже, тем меньше балансовая стоимость актива. Капитализировать фактические затраты на разработку в виде зарплат разработчикам в таком случае не получится.
Если дальше права будут отчуждаться для целей сделки в SPV по рыночной стоимости, которая будет существенно выше цены приобретения ПО компанией, у налоговых органов могут возникнуть вопросы и к компании, и к инвестору. Это лишний раз доказывает, что нужно стараться все делать правильно сразу, как бы сложно это ни казалось, потому что дальше будет еще сложнее.
Если ПО ранее передавалось внутри группы
Часто компания, считая себя правообладателем ПО, передает на него права другим лицам внутри корпоративной группы по договору об отчуждении исключительного права. Если прав у компании нет, все их переходы недействительны и не имеют силы. Поэтому при восстановлении прав на ПО все такие «мнимые» промежуточные звенья можно пропустить и отчуждать права сразу на нужное лицо – инвестиционный таргет. Иными словами, если ПО создали работники компании А, а она затем «передала» права компании Б, а Б – компании В, то нет никакого смысла восстанавливать всю цепочку по исключительному праву. Права сразу надо передавать на конечную компанию В, если она является объектом инвестиций.
Как устранить риски за прошлые периоды
Если в указанном выше примере компании Б и В фактически использовали ПО (например, создавали его модификации), хотя прав на него не имели, нужно заключить с действительными правообладателями лицензионные договоры с ретроактивной оговоркой (когда договор распространяет действие на конкретный период в прошлом). В отличие от договоров об отчуждении исключительного права, в составе лицензионных договоров такие положения являются законными и признаются судами. Но так можно сделать только в том случае, если компания никому не предоставляла права использования ПО на условиях исключительной лицензии в соответствующий период в прошлом.
Договоры нужно заключать строго в хронологическом порядке (сначала «восстанавливается» неавторизованное использование MVP, потом – все, что дописывалось «сверху»). При этом надо помнить, что в разные периоды времени у разных версий и фрагментов ПО могут различаться правообладатели. Лицензионные договоры за соответствующий период должны быть заключены именно с «правильными» правообладателями, предусматривать все необходимые способы использования ПО и право сублицензирования. Это сделать нужно непосредственно до момента заключения правообладателями (например, работниками компании) договора об отчуждении исключительного права на ПО.
После приобретения прав на ПО у работников, компания В из приведенного выше примера вряд ли обратится в суд за взысканием компенсации к компаниям А и Б за неправомерное использование ее ПО в прошлом. Если переходов исключительного права на ПО внутри группы не было, компания А тем более не пойдет в суд «против себя», если она долгое время использовала ПО работников без правового основания. Работники же, после отчуждения исключительного права на ПО, лишаются права на иск против компании.
Зачем тогда нужны ретроактивные лицензии? Они помогают закрыть следующие риски. Компании (А, Б, В – любые из цепочки) ранее могли заключать договоры на использование ПО с рынком, по которым на компанию приходил входящий денежный поток и формировался финансовый результат. И при этом предоставлять лицензиатам или реселлерам заверения о наличии прав на ПО, прав на заключениелицензионных / сублицензионных договоров и т.п. Если эти заверения были ложными, а клиенты не получили указанные в договоре права, с компании А, Б или В можно будет взыскать убытки / неустойку. Подписание такого «ретроактивного» договора позволит снять риски, связанные с взысканием с компании таких убытков в большинстве случаев.
Конечно, история с ретроактивными лицензиями выглядит сложно. Можно ли как-то обойтись без этого? К сожалению, полноценной (безрисковой) замены этой модели нет.
Например, существует мнение, что все сделки, ранее заключенные компанией с ПО в отсутствие у нее прав на ПО, являются сделками без полномочий или с превышением таковых (ст. 183 ГК РФ). А, следовательно, нет ничего проще, чем запросить у действительного правообладателя (если это позволяет переговорная позиция) обычное последующее одобрение всех таких сделок с ПО, заключенных компанией с рынком в период, когда она не являлась правообладателем.
Данная позиция очень не бесспорна, поскольку правила ст. 183 ГК РФ могут применяться только в ситуации, когда имеют место отношения представительства – то есть когда компания пытается создать у контрагента понимание, что она действует не от своего имени, а от имени третьего лица (представляемого) и все права по сделке должны возникнуть именно у представляемого. В ситуации, когда изначально имеет место продажа или лицензирование компанией фактически «чужого» ПО, даже если компания об этом не догадывается и считает правообладателем именно себя, правила данной статьи (183 ГК РФ) автоматически применяться не могут.
Иными словами, отсутствие полномочий по ст. 183 ГК РФ – это отсутствие полномочий действовать от имени другого лица. А не отсутствие распорядительных полномочий в отношении прав на ПО, если компания выступает от своего имени. Поэтому получение последующего одобрения от действительного правообладателя в отношении всех заключенных в спорный период сделок с ПО, само по себе полезная вещь, но вряд ли это закроет все спорные моменты, связанные с неавторизованным использованием ПО (особенно, если ПО использовалось не самыми распространенными способами). И в любом случае наличие таких согласий вызовет массу вопросов у проверяющих юристов при последующем due diligence прав на ПО (то есть так же, как и ретроактивные лицензии, но последние, в отличие от одобрений, при этом полностью легализуют всю конструкцию).
Иными словами, такое согласие / одобрение (если оно фактически не дублирует положения лицензионного договора между действительным правообладателем и компанией) не сможет полноценно решить проблему и заменить собой ретроактивную лицензию. Но, как говорится, «на безрыбье…»
Когда «служебность» ПО подтверждается, но не полностью
Если принадлежность компании прав на ПО подтверждается лишь частично (если с некоторыми работниками документы были оформлены правильно), при этом ПО давно лицензируется третьим лицам – попросите у всех соправообладателей согласие на одобрение таких сделок. Заключение лицензионного договора – это уже акт распоряжения исключительным правом на ПО. В этом случае лицензии с третьими лицами сохранят силу и риск претензий со стороны контрагентов минимален (они с высокой вероятностью проиграют суд). Но компании нужно быть готовой выплатить по требованию соправообладателей часть вознаграждения, полученного ей по таким лицензионным договорам.
Внештатная разработка
Часто бывает, что MVP полностью или частично создавалось до регистрации компании. Или компания при разработке ПО привлекала подрядчиков, которые разрабатывали ПО совместно с работниками компании или самостоятельно дорабатывали отдельные ее компоненты. Очень часто при создании ПО внештатными разработчиками (особенно в первом случае) какие-либо договоры не заключаются вообще (ПО пишется «для себя»), либо они содержат ошибки (например, в договоре авторского заказа забыли распределить права на ПО, и по умолчанию они принадлежат исполнителю). Во всех случаях, когда действительность договора вызывает серьезные сомнения, с авторами ПО нужно текущей датой заключить договор об отчуждении исключительного права на ПО с положениями о предоставлении ретроактивной лицензии за прошлые периоды (по указанной выше модели). Новых договоров авторского заказа или каких-то других заключать не нужно, потому что ПО уже создано, а все такие договоры заключаются в отношении ПО, которого еще нет.
Если между заказчиком и исполнителем был заключен вполне нормальный договор на заказную разработку ПО, он был исполнен (ПО у заказчика, деньги у исполнителя), в нем не было положений о том, что права на ПО принадлежат исполнителю, но в нем были неточности, не связанные с его недействительностью / незаключенностью, достаточно подписать к договору акт (даже если договор уже прекратил действие). В акте нужно подтвердить факт, в отношении которого могли возникнуть сомнения (по конкретному моменту перехода прав на ПО к заказчику, по размеру вознаграждения и т.п.) и отсутствие у сторон претензий друг к другу.
Иногда в таких случаях можно услышать странное предложение «принять на работу» нужных разработчиков ПО на конкретную дату в прошлом. Вопрос, как компания собирается в этом случае восстанавливать выплаты, статистическую и налоговую отчетность по работнику за соответствующие периоды, оказывается риторическим. Поэтому от таких «опций» сразу же следует отказываться.
При создании ПО использовались компоненты третьих лиц
Если при создании ПО авторы использовали проприетарные компоненты третьих лиц, следует запросить согласия их правообладателей на использование таких компонентов в составе ПО. А еще лучше – заключить с ними лицензионные договоры на использование принадлежащих им компонентов путем переработки или включения в составной объект с максимально возможным сроком действия. В противном случае, существуют серьезные риски предъявления претензий со стороны правообладателей таких компонентов к компании за неавторизованное использование их ПО путем переработки.
