|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
В разработке одного программного продукта могут одновременно участвовать десятки разработчиков, требования к итоговому результату постоянно изменяются и уточняются, а важные изменения в программу могут представлять собой незначительные по объему фрагменты кода. Эти обстоятельства делают традиционный бумажный документооборот неэффективным и порождают необходимость альтернативы. Решением являются различные автоматизированные системы, предназначенные для управления циклом разработки и трекинга вносимых изменений (Jira, Yodiz, Redmine etc.). Эти системы создаются и используются в первую очередь для решения задач управления проектами и контроля качества разработки, однако имеющийся функционал позволяет решать также и правовую задачу подтверждения авторства программного продукта, поскольку дает возможность отследить, какой фрагмент программы был поручен тому или иному работнику и когда задача была работником выполнена. Однако для того, чтобы информация в автоматизированной системе могла быть использована как доказательство, имеющее юридическую силу, необходимо провести определенную документальную работу на уровне внутренних нормативных документов компании. Рекомендуется:
Важно, чтобы задачи в системе адресовались конкретным лицам, а не отделам или коллективам. Мне известен случай, когда компания была вынуждена судиться со своим бывшим работником, который оспаривал служебный статус написанного им программного кода. Несмотря на то что в компании использовалась автоматизированная система управления разработкой, оказалось, что задачи в ней направлялись тем или иным отделам без дальнейшего распределения по конкретным разработчикам. Это дало основания бывшему сотруднику заявлять в суде, что задания работодателя не были адресованы конкретно ему, а следовательно, созданный им программный код не является служебным произведением и компания не может претендовать на обладание исключительным правом. Работники и неработникиНеобходимо, чтобы со всеми авторами были оформлены договорные отношения, т.к. только договор обеспечивает переход прав на программу от автора к иному лицу: работодателю, заказчику, пользователю. Это может быть:
Исключительное право на служебные произведения принадлежит работодателю в силу ст. 1295 Гражданского кодекса РФ. Соответственно, если разработка осуществляется силами штатных разработчиков, необходимо проследить, чтобы наличествовали трудовые договоры, а наименования должностей и содержание должностных обязанностей работников соответствовали фактически выполняемым ими функциям. В судебной практике нередки примеры споров, в которых выясняется, что разработчик ценной для компании программы работает по трудовому договору, но занимает должность, обязанности по которой не включают создание программных продуктов, например веб-дизайнер или системный администратор. Суды в таких случаях, как правило, встают на сторону работников и признают их правообладателями созданных программ.
Если к созданию программы привлекаются сторонние разработчики, отношения с ними тоже должны быть оформлены договором. Вне зависимости от того, как такой договор может быть назван сторонами (договор на разработку, договор заказа и т.д.), по своей правовой природе он в большинстве случаев будет являться договором авторского заказа, регулирование которого определяется статьей 1288 Гражданского кодекса РФ. Особенность этого вида договоров состоит в том, что предметом договора является творческая деятельность автора по созданию произведения, а переход к заказчику исключительного права на созданное произведение происходит только в том случае, если это прямо предусмотрено договором. Договор фиксирует возникновение обязательств, а их исполнение фиксируется в другом документе – акте. Соответственно, юристам, которые будут проверять правовой статус программы, нужно предъявить не только сам договор, но и все относящиеся к нему акты, свидетельствующие о создании произведения (или его фрагментов) и о передаче заказчику исключительного права.
Если нештатные разработчики подключаются к автоматизированной системе управления разработкой наряду со штатными сотрудниками, рекомендуется также отражать это в договорах авторского заказа. При этом в отличие от служебных произведений, исключительное право на которые принадлежит работодателю в силу закона, передача исключительного права на результат работ нештатного разработчика требует совершения отдельного задокументированного действия. Поэтому с внештатными работниками рекомендуется периодически составлять акты передачи исключительных прав даже в том случае, когда само создание продукта фиксируется в трекинговой системе. Все сказанное выше по поводу формализации отношений с авторами в равной мере касается как свободного, так и обычного (проприетарного) программного обеспечения. Однако есть правовые вопросы, характерные именно для свободных программ. Они проистекают из особенностей правового статуса открытых лицензий, установленного законодательством, и правовых норм, содержащихся в самих открытых лицензиях. Открытая лицензия в контексте ГК РФПравовой статус открытых лицензий в России определяется статьей 1286.1 Гражданского кодекса РФ. Открытая лицензия – это лицензионный договор, заключаемый в упрощенном порядке. По модели заключения открытая лицензия является договором присоединения, поскольку все условия такого вида договоров формируются одной стороной (лицензиаром), а другая сторона (лицензиат) может либо присоединиться к договору в целом, либо отказаться от него. Характерный для открытых лицензий принцип наследования лицензионных условий производными произведениями в российском законодательстве раскрывается через следующую формулировку (ч. 2 ст. 1286.1):
«Лицензиар может предоставить лицензиату право на использование принадлежащего ему произведения для создания нового результата интеллектуальной деятельности. В данном случае, если иное не предусмотрено открытой лицензией, считается, что лицензиар сделал предложение заключить договор об использовании принадлежащего ему произведения любым лицам, желающим использовать новый результат интеллектуальной деятельности, созданный лицензиатом на основе этого произведения, в пределах и на условиях, которые предусмотрены открытой лицензией. Акцепт такого предложения считается также акцептом предложения лицензиара заключить лицензионный договор в отношении этого произведения». Таким образом, программа, созданная на основе другой программы, распространяемой на условиях открытой лицензии, содержит в себе два результата интеллектуальной деятельности: первоначальную программу и производную программу. Пользователь новой программы вступает в лицензионные отношения сразу с двумя лицензиарами: с лицензиаром изначальной программы и лицензиаром производной программы. Чем больше программа дорабатывается и развивается, тем больше становится количество входящих в нее результатов интеллектуальной деятельности и тем с большим количеством лицензиаров заключает договор каждый следующий лицензиат. Для юриста, проверяющего правовой статус итогового программного продукта, это означает, что необходимо размотать этот клубок лицензионных отношений до самого основания, выявить всех лиц, участвовавших в доработке продукта, начиная с автора самой первой версии, и проверить соблюдение прав каждого из них. Зачем так сложно?Дело в том, что закон (ч. 4 ст. 1286.1 ГК РФ) дает каждому автору в этой цепочке право в одностороннем порядке отказаться от договора (отозвать лицензию) в случае, если использование производного произведения будет нарушать условия открытой лицензии, применимой к творческому вкладу данного автора. Это может сделать невозможным использование итогового программного продукта и даже повлечь применение мер ответственности, включая возмещение убытков и выплату компенсации (ст. 1252 ГК РФ). Поэтому, если вы не уверены в том, кто в действительности написал программу, тот факт, что она распространяется под открытой лицензией, не снимает риска незаконного использования объекта авторского права. Какие еще правовые риски нужно учитывать?При анализе лицензионной чистоты свободного ПО учитываются следующие риск-факторы:
Соответствие бизнес-целям проектаОткрытая лицензия может содержать требования обязательного раскрытия программного кода при распространении лицензируемой программы или производных произведений (так называемые copyleft-лицензии, например, лицензия GNU GPL различных версий). Для сообщества разработчиков это гарантия того, что программные продукты будут оставаться свободными и будут далее развиваться по модели свободного ПО. Однако для потенциального инвестора такое условие лицензии – это повод задуматься, насколько оно соответствует бизнес-целям проекта. Если заказчик не готов раскрывать программный код своего продукта каждому пользователю, использование copyleft-лицензии в продукте будет для него стоп-фактором.
Другие примеры лицензионных требований, возможность соблюдения которых юрист посоветует заказчику проверить до сделки:
Вопрос совместимости лицензийС открытыми 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-компонентов. По мнению некоторых экспертов, если бы суд в этом вопросе встал на сторону истца, то аналогичные претензии могли бы быть предъявлены ко многим производителям проприетарных продуктов, которые используют подобные методы стыковки компонентов в своих продуктах. Что если лицензиар передумал?Еще одной проблемой может стать решение лицензиара изменить условия лицензирования своего продукта. Например, программный продукт в течение некоторого времени распространялся по открытой лицензии, допускавшей его модификацию лицензиатом, но с какого-то момента правообладатель стал предлагать свой продукт по обычной коммерческой лицензии с традиционным набором прав и ограничений. Теоретически, если вы начали использовать эту программу, пока она еще была свободным ПО, ваша открытая лицензия продолжает действовать и вы можете по-прежнему использовать программу или ее модифицированную версию. Однако для этого нужно будет документально подтвердить момент заключения соответствующего лицензионного договора (открытой лицензии). Что же делать?Для того чтобы подготовить свой проект к юридической проверке со стороны потенциального инвестора, рекомендуется провести следующий комплекс мероприятий:
Итогом этих усилий будет положительное юридическое заключение, которое наверняка оценит ваш будущий инвестор.
Комментарии отсутствуют Комментарии могут отставлять только зарегистрированные пользователи
Вакансии на сайте Jooble
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Каждый ИТ-стартап рассчитывает рано или поздно привлечь солидного инвестора и вырасти в преуспевающий и стабильный ИТ-бизнес. Разумеется, главное на пути к этой цели – содержание самого ИТ-продукта, именно уникальный продукт позволит привлечь внимание к вашему проекту. Но простого внимания недостаточно. Чтобы привлечь инвестиции или получить заказ на разработку, нужно показать тот актив, в который инвестору предлагается вложить свои деньги
_cover.jpg)
_cover.jpg)
_cover.jpg)
_cover.jpg)
