Правовые риски свободных программ. Чем юристы пугают ваших инвесторов::БИТ 08.2018
 
                 
Поиск по сайту
 bit.samag.ru     Web
Рассылка Subscribe.ru
подписаться письмом
Вход в систему
 Запомнить меня
Регистрация
Забыли пароль?

Календарь мероприятий
ноябрь    2018
Пн
Вт
Ср
Чт
Пт
Сб
Вс
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

показать все 

Новости партнеров

16.11.2018

Как открыть малый бизнес: пошаговая инструкция

Читать далее 

16.11.2018

Teradata Форум 2018: Всеобъемлющая Аналитика данных становится стандартом индустрии

Читать далее 

16.11.2018

Астана примет итоговый в этом году, 27-й по счету, “Код ИБ”

Читать далее 

15.11.2018

«Ростелеком» представил единую платформу сервисов кибербезопасности

Читать далее 

15.11.2018

Конференция «Управление рисками в промышленности», организованная группой «Просперити Медиа» и порталом CFO-Russia.ru, состоится 7 декабря 2018 года

Читать далее 

15.11.2018

Цифровая трансформация российской экономики: от виртуальных решений до реальных проектов

Читать далее 

14.11.2018

Правовое регулирование криптовалют в России: новые вызовы и возможности

Читать далее 

показать все 

Статьи

14.11.2018

Трубка мира для студентов, преподавателей и работодателей

Читать далее 

14.11.2018

Правовые риски свободных программ. Чем юристы пугают ваших инвесторов

Читать далее 

14.11.2018

Опрос. Люди и роботы: союз или конкуренция?

Читать далее 

14.11.2018

Опрос. СПО для бизнеса

Читать далее 

25.06.2018

Посетить или пропустить?

Читать далее 

21.04.2017

Язык цифр или внутренний голос?

Читать далее 

16.04.2017

Планы – ничто, планирование – все. Только 22% компаний довольны своими инструментами для бизнес-планирования

Читать далее 

16.04.2017

Цифровизация экономики

Читать далее 

23.03.2017

Сервисная компания – фея или Золушка?

Читать далее 

17.02.2017

Информационные технологии-2017

Читать далее 

показать все 

Правовые риски свободных программ. Чем юристы пугают ваших инвесторов

Главная / Архив номеров / 2018 / Выпуск №08 (81) / Правовые риски свободных программ. Чем юристы пугают ваших инвесторов

Рубрика: Тема номера /  СПО для бизнеса


Татьяна Никифоровамагистр права (Оксфорд), советник международной юридической фирмы Dentons, Санкт-Петербург

Правовые риски свободных программ
Чем юристы пугают ваших инвесторов

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

И в этот момент на передний план выходят юридические аспекты организации проекта.

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

Картина, которую видит юрист, проводящий юридическую проверку (due diligence) ИТ-стартапа, зачастую такова: договоры между разработчиками не заключались, создание программного продукта документально не оформлено. А тут еще выясняется, что разработка на 80% состоит из Open Source… «Все ясно, концов не найти!» – понимает юрист и выносит свой вердикт – «Высокий риск потери прав на объект интеллектуальной собственности».

С точки зрения методологии выявления правовых рисков, свободные программы не сильно отличаются от «несвободных».

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

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

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

  1. Кто авторы продукта?
  2. Как подтверждается творческий вклад каждого автора?
  3. Как юридически оформлены отношения между участниками проекта?

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

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

А авторы кто?

Не бывает программного кода, который никому не принадлежит. Бывает программный код, автор которого неизвестен. Неизвестность – это риск.

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

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

Какие ваши доказательства?

После того как определились с составом авторов, следует подумать о том, как можно подтвердить авторство каждого из них.

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

Необходимо помнить, что компьютерные программы охраняются правом, как литературные произведения

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

Эти обстоятельства делают традиционный бумажный документооборот неэффективным и порождают необходимость альтернативы.

Решением являются различные автоматизированные системы, предназначенные для управления циклом разработки и трекинга вносимых изменений (Jira, Yodiz, Redmine etc.).

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

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

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

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

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

Работники и неработники

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

Это может быть:

  • трудовой договор;
  • гражданско-правовой договор.

Исключительное право на служебные произведения принадлежит работодателю в силу ст. 1295 Гражданского кодекса РФ. Соответственно, если разработка осуществляется силами штатных разработчиков, необходимо проследить, чтобы наличествовали трудовые договоры, а наименования должностей и содержание должностных обязанностей работников соответствовали фактически выполняемым ими функциям. В судебной практике нередки примеры споров, в которых выясняется, что разработчик ценной для компании программы работает по трудовому договору, но занимает должность, обязанности по которой не включают создание программных продуктов, например веб-дизайнер или системный администратор. Суды в таких случаях, как правило, встают на сторону работников и признают их правообладателями созданных программ.

Подтверждение прав на созданное ПО

Если к созданию программы привлекаются сторонние разработчики, отношения с ними тоже должны быть оформлены договором. Вне зависимости от того, как такой договор может быть назван сторонами (договор на разработку, договор заказа и т.д.), по своей правовой природе он в большинстве случаев будет являться договором авторского заказа, регулирование которого определяется статьей 1288 Гражданского кодекса РФ. Особенность этого вида договоров состоит в том, что предметом договора является творческая деятельность автора по созданию произведения, а переход к заказчику исключительного права на созданное произведение происходит только в том случае, если это прямо предусмотрено договором. Договор фиксирует возникновение обязательств, а их исполнение фиксируется в другом документе – акте. Соответственно, юристам, которые будут проверять правовой статус программы, нужно предъявить не только сам договор, но и все относящиеся к нему акты, свидетельствующие о создании произведения (или его фрагментов) и о передаче заказчику исключительного права.

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

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

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

Открытая лицензия в контексте ГК РФ

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

Характерный для открытых лицензий принцип наследования лицензионных условий производными произведениями в российском законодательстве раскрывается через следующую формулировку (ч. 2 ст. 1286.1):

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

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

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

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

Зачем так сложно?

Дело в том, что закон (ч. 4 ст. 1286.1 ГК РФ) дает каждому автору в этой цепочке право в одностороннем порядке отказаться от договора (отозвать лицензию) в случае, если использование производного произведения будет нарушать условия открытой лицензии, применимой к творческому вкладу данного автора. Это может сделать невозможным использование итогового программного продукта и даже повлечь применение мер ответственности, включая возмещение убытков и выплату компенсации (ст. 1252 ГК РФ).

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

Какие еще правовые риски нужно учитывать?

При анализе лицензионной чистоты свободного ПО учитываются следующие риск-факторы:

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

Соответствие бизнес-целям проекта

Открытая лицензия может содержать требования обязательного раскрытия программного кода при распространении лицензируемой программы или производных произведений (так называемые copyleft-лицензии, например, лицензия GNU GPL различных версий). Для сообщества разработчиков это гарантия того, что программные продукты будут оставаться свободными и будут далее развиваться по модели свободного ПО. Однако для потенциального инвестора такое условие лицензии – это повод задуматься, насколько оно соответствует бизнес-целям проекта. Если заказчик не готов раскрывать программный код своего продукта каждому пользователю, использование copyleft-лицензии в продукте будет для него стоп-фактором.

С открытыми copyleft-лицензиями может быть связана еще одна опасность: не все открытые лицензии совместимы между собой

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

  • Android SDK License Agreement запрещает создавать программы, не предназначенные для платформы Android или не совместимые с ней.
  • Лицензионное соглашение на использование набора средств разработки Yandex AppMetrica SDK обязывает пользователя предоставлять лицензиару статистические данные об использовании объекта лицензирования, причем перечень такой информации является открытым.

Вопрос совместимости лицензий

С открытыми copyleft-лицензиями может быть связана еще одна опасность: не все открытые лицензии совместимы между собой. Если в программном продукте использованы компоненты, распространяемые под различными copyleft-лицензиями (например, GPL и EPL), то требования, предъявляемые каждой из этих лицензий к использованию итогового программного продукта, могут оказаться взаимно противоречащими. Поэтому для того, чтобы сделать заключение о наличии или отсутствии правовых рисков программного продукта, созданного с использованием свободного ПО, юристу потребуется выявить все применимые лицензии и проверить их на совместимость правовых условий. Помочь разобраться в вопросах совместимости открытых лицензий могут лицензионные обзоры и карты лицензионной совместимости, которые время от времени выпускаются отдельными разработчиками или сообществами.

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

Толкование понятий «модификация» и «производное произведение» может составлять практические сложности. Это хорошо видно на примере судебного дела Hellwig vs VMware . В 2015 году один из разработчиков ядра Linux Кристоф Хельвиг (Christoph Hellwig) подал в окружной суд Гамбурга судебный иск о нарушении авторских прав к корпорации VMware. По мнению г-на Хельвига, его имущественные авторские права были нарушены тем, что компания VMware при создании своего продукта ESXi (а точнее, его компонента vmkernel) скомбинировала код ядра Linux со своим проприетарным кодом, не раскрывая при этом свои исходные тексты. Это является нарушением GPL-лицензии, под которой создается и распространяется операционная система Linux, и в том числе программный код, созданный г-ном Хельвигом.

Обеспечение лицензионной чистоты ПО

Защищаясь от предъявленного обвинения, компания VMware пояснила в суде, что, по ее мнению, нарушения лицензии GPL не произошло, так как не было прямого заимствования кода. По мнению VMware, в рамках продукта ESXi компоненты под лицензией GPL осуществляют взаимодействие с компонентом vmkernel, однако программный код самого vmkernel не является заимствованием какого-либо кода под лицензией GPL, а следовательно, требования данной лицензии на vmkernel не распространяются.

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

Что если лицензиар передумал?

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

Что же делать?

Для того чтобы подготовить свой проект к юридической проверке со стороны потенциального инвестора, рекомендуется провести следующий комплекс мероприятий:

  1. В части подтверждения исключительных прав на программный продукт:
    • Вспомните всех авторов продукта.
    • Определите творческий вклад каждого автора.
    • Документально оформите отношения с авторами.
    • Помните: нет кода, который никому не принадлежит!
  2. В части обеспечения лицензионной чистоты программного продукта:
    • Составьте перечень всех компонентов продукта.
    • Определите применимые лицензии.
    • Проверьте совместимость лицензий.
    • По спорным правовым вопросам заручитесь мнением юриста.

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

В начало⇑

 

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи

Выпуск №08 (81) 2018г.
Выпуск №08 (81) 2018г. Выпуск №07 (80) 2018г. Выпуск №06 (79) 2018г. Выпуск №05 (78) 2018г. Выпуск №04 (77) 2018г. Выпуск №03 (76) 2018г. Выпуск №02 (75) 2018г. Выпуск №01 (74) 2018г.
Вакансии на сайте Jooble

           

Tel.: (499) 277-12-41  Fax: (499) 277-12-45  E-mail: sa@samag.ru

 

Copyright © Системный администратор

  Яндекс.Метрика