Незаконная переработка ПО: доказывание в суде

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

"Баланс вероятностей" – это стандарт, характерный для гражданско-правовых споров (обстоятельства скорее доказаны, чем нет). В доктрине об этом пишут давно и суды начали потихоньку подхватывать (например, Постановление СИПа по делу А56-5216/2020).

Применительно к переработке судом ставится вопрос:

"Насколько вероятно, что объект создан ответчиком самостоятельно, а не является переработкой чужого"

По моим наблюдениям суды, отвечая на вопрос о вероятности переработки, особенно обращают внимание на два момента:

1️⃣ Чем больше объем совпадений, тем менее вероятно параллельное творчество (например, Постановление СИПа по делу А41-68274/2022).

К этому количественному критерию я бы добавил качественный, который используется в спорах по товарным знакам: "Чем более оригинально обозначение, тем менее вероятно, что два лица могли его начать использовать самостоятельно, независимо друг от друга" (по описанию количественного и качественного критерия рекомендую посмотреть посты по контролю над частью произведения и частью ПО).

2️⃣ ПО является переработкой, если в ПО Ответчика обнаружены уникальные элементы из ПО Истца:

➡️ Например, комментарии в коде (как в Постановлении СИПа по делу А40-102447/2020).

➡️ Или нефункциональная и бесполезная строка кода (в деле А56-39703/2022 использование базы данных было доказано через уникальные маркеры – данные о несуществующих машинах).

Напоследок напомню, что не всегда использование вашего ПО или его части будет именно переработкой (об этом писал здесь).

Незаконная переработка ПО: доказывание в суде. Часть 2

В продолжение предыдущего поста нужно сделать важное замечание.

«Классические» объекты авторского права обычно размещаются в интернете или иным способом доступны любому желающему. И их без труда можно переработать.

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

⭕ Соответственно, на практике у Истца при подаче иска может не быть исходного кода программы ответчика или иного подтверждения нарушения (хотя бывает и по-другому и тогда все сильно облегчается).

В свою очередь, чтобы сравнить две программы, суду нужно получить код как истца, так и ответчика.

Возникает вопрос, должен ли суд истребовать код у ответчика (или обязать его предоставить код эксперту). Ну очевидно, что не всегда.

В моем понимании, истец должен доказать обоснованность своих подозрений о нарушении ответчика (похожая логика была использована СИПом деле № А40-241794/2019).

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

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

1️⃣ у ответчика (такая возможность подтверждена как в п. 18 ППВС № 12, так и в судебной практике, например, в упомянутом выше деле) или

2️⃣в Роспатенте (если программа зарегистрирована).

Создание программы искусственным интеллектом.
Часть 3

(См. Часть 1 и Часть 2)

28 июня на одной из сессий ПМЮФа разбирали «творчество» искусственного интеллекта.

А.И. Савельев рассказывал о создании программы искусственным интеллектом (начиная с 46 минуты). Назовём это сгенерированным кодом.

В рамках своего выступления он затронул три темы:

1️⃣ Охраноспособность сгенерированного кода
2️⃣ Качество сгенерированного кода (качество лицензируемого ПО)
3️⃣ Нарушение прав третьих лиц сгенерированным кодом

Остановимся подробнее на первом вопросе.

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

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

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

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

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

✔️ Соответственно, если мы сейчас скажем, что такого рода сгенерированный код неохраноспособен, это позволит проще решать споры, связанные с плагиатом (то есть нужно будет "вывести за скобки" сгенерированный код и смотреть что осталось (насколько там есть совпадения)).

Создание программы искусственным интеллектом.
Часть 4

(См. Часть 1, Часть 2, Часть 3)

В комментариях к 3 части задали интересный вопрос.

Вопрос

Как в случае спора установить, был код сгенерирован ИИ или написан вручную? Код ИИ выглядит абсолютно идентично с оригинальным кодом.

Мое мнение

В целом это относится к вопросу факта и решается в каждом конкретном деле. То есть каждая сторона должна обосновать свою позицию.

Но я согласен, что иногда это кажется невозможным.

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

1️⃣ Отсутствие творчества: ограниченное количество способов написания кода (в западных юрисдикциях это называется merger doctrine).

2️⃣ Отсутствие автора: разработка кода системой ИИ.

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

1 аргумент может доказываться без привязки к ИИ.

По второму аргументу есть следующая идея.

Если у вас есть такой же код, то вы его либо украли, либо тоже сгенерировали при помощи ИИ.

✔️ Если сгенерировали, то можете воссоздать запрос и зафиксировать результат работы ИИ, чтобы доказать, что код был сгенерирован и Истцом (либо ссылаться на отсутствие творчества/параллельную разработку).

✔️ Если в сервисе сохраняются все промпты и их результаты, то еще легче – нужно достать эту информацию и передать суду.

Ну а в будущем будем надеятся, что сгенерированные объекты будут маркироваться 😁

Суд в США отклонил почти все претензии разработчиков к GitHub Copilot (сервис с использованием ИИ) по иску о нарушении авторских прав по DMCA.

Первоначальный иск содержал 22 требования к GitHub, Microsoft и OpenAI, которых обвиняли в нарушении закона об авторском праве (осталось 2). По мнению истцов, ответчики позволили помощнику по написанию кода GitHub Copilot, работающему на основе искусственного интеллекта, обучаться на работах разработчиков.

Сначала суд постановил, что предлагаемый Copilot код не был достаточно близок к первоисточнику. После этого истцы внесли изменения в свой иск.

В измененной версии иска ставился под сомнение фильтр GitHub по обнаружению дублирования, который пользователи могут включить, чтобы «обнаружить и подавить» предложения Copilot, копирующие чужой из GitHub. Утверждалось, что GitHub дает пользователям возможность «получать идентичный код» при выключенном фильтре. В иске также приводилось исследование, показывающее, как модели искусственного интеллекта могут «запоминать» и повторять части своих обучающих данных, которые потенциально могут включать код, защищенный авторским правом.

Но и эти доводы не убедили суд. Судья решил, что код, который GitHub якобы скопировал у разработчиков, не был достаточно похож на их оригинальную работу. Он также упомянул часть цитируемого исследования, в которой говорится, что GitHub Copilot «редко выдает запомненный код в обычных ситуациях».

В общем в противостоянии AI и IP, по крайней мере в части ПО, пока побеждает AI.

Интересно, как история с GitHub Copilot будет развиваться дальше. Продолжаем следить 👀

Ограничение использования производного ПО. Часть 1

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

Здесь хочу кратко поделиться своей позицией и мыслями.

В декабре 2022 года Суд по интеллектуальным правам высказался в пользу возможности ограничения использования производных произведений, указав, что «договором может быть ограничено в какое производное произведение осуществляется переработка, а также, каким образом может использоваться производное произведение» (дело № А40-100965/2021).

Это первое судебное дело, в котором суд прямо высказался по данному вопросу (указанную логику в последующем СИП подтверждал в своих постановления как в 2023, так и в 2024 годах).

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

1️⃣ Договорное ограничение

2️⃣ Ограничение в рамках исключительной монополии правообладателя (абсолютно-правовой механизм)

В зависимости от механизма предполагаются совершенно разные последствия.

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

Ограничение использования производного ПО. Часть 2

Мой вывод основывается на следующем.

🔹В 1995 году Э.П. Гаврилов писал, что производное произведение является «зависимым» от оригинального произведения (при этом не уточняя, в чем заключается такая зависимость).

🔹В.О. Калятин писал, что рассмотрение переработки как использование формы произведения дало возможность поставить ее под контроль правообладателя. В том числе обеспечить контроль правообладателя и за фрагментарным использованием формы произведения (автор признает переработку использованием формы оригинального произведения, хотя неясно, ограничивается ли в понимании автора контроль правообладателя предоставлением согласия на переработку, или можно ограничить в том числе способы использования производного произведения).

Косвенно такая позиция (об использовании оригинального произведения при переработке) подтверждается и практикой СИПа (дело № А40-207329/2015):

«При переработке произведение видоизменяется, когда его форма частично заменяется другими элементами. Но при этом само произведение, взятое в оригинальной, первоначальной форме, используется, остается узнаваемым».

Развивая логику В.О. Калятина и СИПа отмечу, что если мы признаем использование оригинального произведения при переработке (как процессе, подпадающем под контроль правообладателя оригинального произведения), то не можем не признать такое использование при использовании (извиняюсь за тавтологию) прозводного произведения (как результате переработки).

🔹В моем понимании к схожей позиции пришла А.С. Ворожевич в своей докторской диссертации, которая отметила, что правообладатель оригинального произведения может запрещать (разрешать) правообладателю переработки использовать свое произведение, которое воплощено в переработке.

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

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

В свою очередь, лицензиат может использовать РИД только в пределах тех прав и теми способами, которые предусмотрены лицензионным договором (право использования результата интеллектуальной деятельности, прямо не указанное в лицензионном договоре, не считается предоставленным лицензиату) (ст. 1235 ГК РФ).

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

P.s. В посте я использовал термин "произведение", а не ПО, так как выводы в первую очередь применимы к произведениям (и именно этот термин используется в приводимых судебных делах, научной литературе и законе). Тем не менее, ПО является объектом авторского права и охраняется как литературное произведение. Соответственно, эти выводы применимы и к ПО. А так как сферой моих интересов является именно программное обепечение, был выбран соответствующий заголовок.

Уход зарубежных вендоров ПО и распределение ответственности. Часть 1. Введение.

В 2022 году много зарубежных вендоров прекратили техническую поддержку и закрыли доступ к своему ПО. Возникло много правовых вопросов.

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

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

1️⃣ Взаимодействие с пользователями. Зарубежные вендоры в большинстве случаев не работают напрямую с пользователями. Зачастую они работают через дистрибьюторов и реселлеров.

2️⃣ «Вендор -> Дистрибьютор -> Пользователь = несколько разных отношений. Так как вендоры взаимодействуют с пользователями опосредовано, у нас возникает несколько разных отношений:

🔹Вендор -> Дистрибьютор

🔹Дистрибьютор -> Пользователь

🔹Вендор -> Пользователь (за исключением отношений с лицензией и сублицензией)

3️⃣ Коммерциализация ПО. Зарубежные вендоры зарабатывают на ПО в том числе через реализацию лицензий и продажу технической поддержки ПО. Техническая поддержка, в свою очередь, может включать как предоставление обновлений, так и оказание консультационных и похожих услуг.

4️⃣ Договорная обвязка. В зависимости от того, как именно вендор зарабатывает на ПО (пункт 3), могут меняться используемые типы договоров.

Уход зарубежных вендоров ПО и распределение ответственности. Часть 2. Сертификаты на ПО

Зарубежные вендоры часто упаковывают свои лицензии или тех. поддержку в сертификаты. Эти сертификаты впоследствии продаются дистрибьюторами пользователям. По таким сертификатам пользователь впоследствии устанавливает отношения напрямую с правообладателем (иностранным вендором).

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

❗Главный вопрос по этим делам – кто отвечает за прекращение исполнения вендора: сам вендор или дистрибьютор?

Чтобы это понять, разберем эти отношения поподробнее.

В судебной практике отношения по продаже сертификатов (т.е. отношения «Дистрибьютор-> Пользователь») часто квалифицируют в качестве договора поставки. Причем сам сертификат, по мнению судов, является товаром.

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

То есть по договору дистрибьютора с пользователем передается право на заключение договора с вендором. А после получения этого сертификата (права) устанавливаются отношения «Вендор -> Пользователь» (лицензионные, оказания услуг или смешанные).

Сначала я думал, что тут уместнее квалификация отношений «Дистрибьютор-> Пользователь» в качестве договора уступки.

Но потом А.И. Савельев своей статьей напомнил мне о том, что имущественные права также могут быть объектом договора купли-продажи и сертификат в этом случае является формой передачи такого права (рекомендую эту статью для более глубокого изучения вопроса).

И что это означает?

Если кратко, то следующее.

1️⃣ Дистрибьютор заключает с пользователем договор поставки (купли-продажи), по которому передает право на заключение договора с зарубежным вендором (которое выражено в сертификате).

2️⃣ Пользователь получает сертификат и заключает договор с вендором на использование ПО или его тех. поддержку.

3️⃣ Обязанности дистрибьютора по передаче права считаются исполненными, так как право не может быть некачественным (оно либо есть, либо его нет).

4️⃣ Если вендор приостанавливает возможность использования ПО или тех. поддержку, то именно он должен нести за это ответственность по договору, заключенному с пользователем.

5️⃣ Но если дистрибьютор в своем договоре с пользователем перенес на себя риски приостановки деятельности вендора, то пользователь может обратиться к дистрибьютору (свободу договора никто не отменял).

Суды в вопросах распределения ответственности часто приходят к такому же выводу (хотя существует и обратная практика).

Программа для ЭВМ, ПО и прочее: вопрос терминологии

Термин «Программа для ЭВМ» устарел. Думаю, нет смысла это доказывать, т.к. очевидно.

Но какая альтернатива подходит лучше всего?

В научной литературе в качестве альтернативы используется «программное обеспечение (ПО)» или «компьютерная программа». Но не все любят ссылки на доктрину, поэтому вот еще ссылки на законы.

1️⃣ Программное обеспечение (ч. 1 ст. 12.1 Закона об информации)

2️⃣ Компьютерная программа (ст. 273 УК РФ)

А в базе знаний сделал у себя отдельный раздел с примерами НПА, в которых упоминаются альтернативные названия (в процессе заполнения).

P. s. К счастью ноушен продолжает работать и запасной план по полной миграции не понадобился 😁

Программный комплекс. Часть 1: вопрос терминологии

Зачем я пишу про термины? Тут ведь все очевидно, все уже пишут ПО или программа.

Я считаю, что термины важны. С них все начинается. И их нужно знать.

Например, программный комплекс. Что это и как соотносится с программой для ЭВМ?

В ст. 1261 ГК РФ указано «авторские права на все виды программ для ЭВМ (в том числе на операционные системы и программные комплексы) …».

Получается, что программный комплекс – это разновидность программы для ЭВМ?

❗И да, и нет.

В свое время я проводил исследование по этому поводу, но в итоге не стал письменно его фиксировать, оставив все в голове. А недавно наткнулся на позицию А.И. Савельева по этому вопросу, которая резонирует с моим пониманием. Далее небольшой отрывок.

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

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

Если вы так же как и я работаете с ПО, то должны понимать ценность такого подхода. А начинается все с понимания термина.

Программный комплекс. Часть 2: практика

В своем втором посте на этом канале я рассказывал про строение программы. Там описывалась структура классической монолитной программы. То есть единой программы с множеством подсистем.

Но это не единственный способ проектирования программы. Сейчас многие компании переходят от монолита к так называемой микросервисной архитектуре (например, так сделали в Авито).

Микросервисная архитектура – это когда бизнесово одна программа на деле состоит из множества (относительно) независимыых программ, которые взаимодействуют друг с другом, например, через программный интерфейс (т.н. API).

Другими словами, это и есть, по сути, программный комплекс. Огромное количество программ у нас построено именно так.

❗В чем здесь практический интерес для юриста.

1️⃣ Весь программный комплекс в совокупности и отдельно каждую программу можно рассматривать как отдельные объекты авторского права (и регистрировать, соответственно).

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

2️⃣ В будущем компания может захотеть развивать одну из программ как отдельный продукт (самостоятельно или с партнерами) или продать ее. Правильная структуризация поможет сделать это безболезненно.

Служебные ПО. Часть 3. Инициатива работодателя на создание ПО или служебное задание в устной форме

(См. Часть 1 и Часть 2)

В прошлую субботу выступал на IP конференции в секции про IT(ПО).

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

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

Далее постараюсь кратко описать эту логику (по крайней мере, как это увидел я).

1️⃣ Программист, который работает в компании, может создавать программы как в рамках работы, так и для себя (например, в рамках side проектов и др.).

2️⃣ В первом случае программы будут служебными, а во втором - нет. И эти ситуации нужно как-то разграничить.

3️⃣ Разграничение по рабочему времени, очевидно, не работает. Программист может работать над рабочим кодом и во внерабочее время: по своей инициативе (если что-то не успел доделать) или, например, из-за появления ошибок после релиза обновлений.

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

5️⃣ Инициатива работодателя не всегда фиксируется письменно (хоть и желательно), она может быть и устной. Продолжая описанное в Части 1 разделение отношений на трудовые и гражданско-правовые, работодатель конкретизирует условия рамочных гражданско-правовых отношений в том числе посредством устных служебных заданий.

Такой подход не ограничивается законом и подтверждается судебной практикой:

✅ Например в апелляционном постановлении по делу № А43-5621/2020

✅ И косвенно в постановлении СИПа от 2022 года по делу А05-12896/2018. В этом деле суд не потребовал само служебное задание, и ему было достаточно пояснений, что задание существовало.

6️⃣ В таком случае наличие инициативы подтверждается иными обстоятельствами взаимодействия работника и работодателя (отдельно или в совокупности) и их желательно прописать в локальных актах. Мне в голову приходят следующие примеры:

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

🔹 написание и обсуждение кода в рабочем репозитории (не обязательно, но в совокупности с другими аргумент можно использовать).

🔹 подготовка рабочей документации для программы/модуля/кода.

🔹 информация в таск-треккерах (если там сформулировано задание, то это одно дело. К сожалению на практике во многих случаях коммуникация там очень отдаленно напоминает задания)

🔹 иные доказательства, явно свидетельствующие о служебном характере ПО.

На практике отношения сторон не такие простые. Программист работает над кодом совместно с другими программистами, они обсуждают код друг с другом, с продактами, проджектами, архитекторами и др. И следы такого обсуждения остаются в системе.

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

Судебная экспертиза по вопросам переработки ПО. Часть 1. Вопросы права и вопросы факта

ПО – особый, технически сложный объект авторских прав.

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

Поэтому судебные споры по поводу ПО практически всегда сопровождаются экспертизой. И споры о переработке – не исключение.

Круг вопросов для эксперта определяется судом с учетом мнения и предложений сторон.

✅ И тут начинается самое интересное.

Суд не может ставить перед экспертом вопросы права, т.е. вопросы, которые относятся к исключительной компетенции суда (ППВС № 23 от 04.04.2014).

В случае с переработкой ПО можно привести следующие примеры вопросов права:

1️⃣ Является ли программа А результатом переработки программы В? (пример из дела № А40-102447/2020)

2️⃣ Является ли программа А производной от программы В? (пример из дела № А56-38522/2020)

Но в чем здесь, собственно, проблема?

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

ВС РФ в этой связи прямо указывает, что перед экспертом может быть поставлен только вопрос факта, и нарушение этого правила может привести к отмене решения (дело № 310-ЭС20-7837).

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

Судебная экспертиза по вопросам переработки ПО. Часть 2. Примеры вопросов эксперту

Вопросы эксперту зависят от конкретных обстоятельств дела, целей истца и иных вводных.

Тем не менее, для некого ориентира предлагаю следующие примеры. Я их взял из двух дел (А56-10049/2019, А56-38522/2020), структурировал и адаптировал для удобства восприятия.

Вопросы можно условно разелить 2 подраздела.

1️⃣ История происхождения программ

🔹 Какова история происхождения и модификации сравниваемых программ?

🔹 Какая из представленных на экспертизу программ создана ранее другой?

2️⃣ Совпадение исходного кода программ

🔹 Имеется ли различие во фрагментах исходного кода представленных программ? Если да, то каковы различия такого кода?

🔹 Каков процент совпадения исходных кодов сравниваемых программ?

🔹 Являются ли представленные на экспертизу программы продуктами, разработанными независимо друг от друга?

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

Структурирование IT-бизнеса: актуальные вопросы и последние тренды

3 декабря мы с Марией Кабановой, моей коллегой из налоговой практики, проведем вебинар.

За последние 2 года мы сопроводили ряд крупных проектов по реструктуризации IT-бизнеса. Проанализировали, что у них общего, убрали все конфиденциальное и получился вебинар!

Чтобы у вас было примерное представление структуры, о чем мы будем говорить (более подробно по ссылке):

1⃣ Предпосылки реструктуризации бизнеса

2⃣ Подходы к структурированию сделок

3⃣ Юридические особенности сделок по реструктуризации

4⃣ Жизнь после сделки

Буду рад вопросам, так что присоединяйстесь!