license provided что значит

Использование свободных лицензий при создании ПО: проблемные вопросы и риски разработчика (часть 3)

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

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

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

разрешительные (permissive license)

взаимные лицензии (reciprocal license, также используется понятие «copyleft»)

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

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

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

Самыми известными разрешительными свободными лицензиями являются Berkeley Software Distribution license (BSD, существует в двух основных версиях – «оригинальной» (BSD-4 Clause) и «модифицированной» (BSD-3 Clause)) и MIT.

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

В свою очередь, взаимные лицензии (наиболее известными примерами являются лицензии, разработанные Фондом Свободного Программного обеспечения – GNU General Public License (GPL) (Существует несколько версий, новейшей является версия 3.0 (Version 3 /v3)), GNU Affero General Public License (AGPL), GNU Lesser General Public License (LGPL) (Существует несколько версий, новейшей является версия 3.0 (Version 3 /v3)) предоставляют разработчику гораздо меньшую свободу и «отравляют» собой созданную программу, поскольку использование модифицированной программы на условиях, отличных от условий соответствующей взаимной лицензии, будет являться неправомерным.

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

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

Данную проблему можно конкретно рассмотреть на примере условий взаимной свободной лицензии GNU General Public License (GPL). Здесь и далее приведены выдержки из новейшей Version 3 в переводе на русский язык (), при этом необходимо иметь в виду, что переводы лицензии с английского языка не признаются официально действительными..

Данная лицензия (рассматривается Version 3) устанавливает в разделах 5 и 6, что модифицированные версии программы, распространяемой на условиях данной лицензии, также должны распространяться на условиях лицензии.

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

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

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

в силу раздела 4 Лицензии:

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

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

сохранить все уведомления об отсутствии каких-либо гарантий

предоставить всем получателям вместе с Программой копию лицензии

в силу раздела 5 Лицензии:

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

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

Кроме того, согласно разделу 4 Лицензии вы вправе взимать плату за каждую копию, которую вы передаете (в том числе путем предоставления ссылки на скачивание копии программы с распространяющего сайта), или распространять копии бесплатно; также вы можете предложить поддержку или гарантию за отдельную плату.

Однако, обратите, пожалуйста, внимание, что аналогичное право будут иметь и все пользователи вашей программы, и вы, например, не сможете пресечь распространение копий вашей программы бесплатно, если какой-либо пользователь решит осуществить его, независимо от того, за плату вы сами распространяете копии или бесплатно. Из положений Лицензии GPL (как рассматриваемой Version 3, так и более ранних версий 1 и 2, неофициальный перевод на русский язык) следует, что соответствующие действия охватываются объемом разрешенного использования программы и не требуют дополнительного согласования с правообладателем.

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

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

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

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

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

«Когда программа и ее внешние модули считаются единой комбинированной программой? ( #GPLPlugins )

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

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

Применение общей памяти для обмена сложными структурами данных вполне эквивалентно динамическому связыванию»

C учетом данной позиции и дополнительных разъяснений Фонда Свободного Программного обеспечения, если главная (заимствованная) программа и разработанные вами модули составляют комбинированную программу, то это значит, что вы должны выпускать модули на условиях Лицензии. Если же архитектура вашей модификации позволит прийти к выводу о том, что разработанный вами модуль является отдельным от первоначальной программы, то право использования ваших модулей может предоставляться пользователям на условиях, отличных от Лицензии GPL.

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

Продолжение следует, будем рады ответить на ваши вопросы в комментариях!

Алексей Переверзев, Младший юрист Semenov&Pevzner

Источник

В чём разница между популярными Open Source лицензиями? Объясняет Github

Авторизуйтесь

В чём разница между популярными Open Source лицензиями? Объясняет Github

В сентябре Github добавила на страницы проектов, которые используют стандартные Open Source лицензии, секцию, в которой эта лицензия указывается:

После переработки условий использования сервиса, которые прояснили (наконец-то) правовой статус GitHub относительно проектов, которые он хранит, компания решила пойти дальше в том, чтобы помочь пользователям разобраться, на что они имеют право, а на что — нет. С этой целью на страницу просмотра файла LICENSE из корневой директории проекта были добавлены краткие сведения о лицензии с сайта Choose A License:

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

Пояснения некоторых значений таблиц

Разрешения * распространять, * использовать в коммерческих целях или * изменять работу значат ровно то, что написано — вы можете пользоваться этими правами, но лишь до тех пор, пока соблюдаете условия, указанные в секциях * «Требует» и * «Запрещает».

Пункт * «Разрешает личное использование» (англ. private use) означает, что если вы изменяете работу, вы не обязаны её распространять — на своей машине вы можете делать с кодом всё, что захотите.

Пункт * «Предоставление патентных прав» означает что соавторы работы (контрибьюторы) отказываются от патентных прав (если они есть) на те части кода, которые они добавили; это гарантирует безопасность при использовании работы — иск на вас точно не подадут.

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

GNU AGPLv3

Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав

Требует:
* Распространять исходный код вместе с продуктом
* Упоминания авторства и лицензии в работе
* Указывать изменения, внесённые в работу
* Использование по сети приравнивается к распространению
* Производные продукта необходимо выпускать под той же лицензией

Запрещает:
* Отказ от ответственности
* Никакой гарантии

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

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

GNU GPLv3

Оригинальный текст Перевод на русский
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав

Требует:
* Распространять исходный код вместе с продуктом
* Упоминания авторства и лицензии в работе
* Указывать изменения, внесённые в работу
* Производные продукта необходимо выпускать под той же лицензией

Запрещает:
* Отказ от ответственности
* Никакой гарантии

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

GNU LGPLv3

Оригинальный текст Перевод на русский
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав

Требует:
* Распространять исходный код вместе с продуктом
* Упоминания авторства и лицензии в работе
* Указывать изменения, внесённые в работу
* Производные продукта необходимо выпускать под той же лицензией (но можно использовать продукт в качестве библиотеки)

Запрещает:
* Отказ от ответственности
* Никакой гарантии

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

Mozilla Public License 2.0

Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав

Требует:
* Распространять исходный код вместе с продуктом (в случае использования в качестве библиотеки — только исходный код библиотеки)
* Упоминания авторства и лицензии в работе
* Производные продукта необходимо выпускать под той же лицензией (но можно использовать продукт в качестве библиотеки)

Запрещает:
* Отказ от ответственности
* Никакой гарантии
* Не передаются права на торговые марки

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

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

The MIT License

Оригинальный текст Перевод на русский
Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование

Требует:
* Упоминания авторства и лицензии в работе

Запрещает:
* Отказ от ответственности
* Никакой гарантии

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

Apache License 2.0

Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав

Требует:
* Упоминания авторства и лицензии в работе
* Указывать изменения, внесённые в работу

Запрещает:
* Никаких обязательств
* Никакой гарантии
* Не передаются права на торговые марки

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

The Unlicense

Разрешает:
* Коммерческое использование
* Распространение
* Изменение
* Личное использование
* Предоставление патентных прав

Требует:
(Ничего не требует)

Запрещает:
* Никаких обязательств
* Никакой гарантии

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

А как же остальные лицензии? Как же BSD?

Этого набора более чем достаточно, если вы хотите выбрать лицензию для своего Open Source проекта — не надо писать свою лицензию или использовать что-то более специфическое. Путаница, которая возникает из-за обилия лицензий и их совместимости друг с другом — актуальная проблема Open Source. Лицензия BSD достаточно популярна, но её сокращённый вариант полностью совпадает по смыслу с лицензией MIT, и GNU советуют использовать именно последнюю. Если же вы столкнулись с проектом, который использует какую-то нестандартную лицензию, и хотите узнать, что она вам разрешает, вы можете подсмотреть в шпаргалке на сайте Choose A License.

Источник

Terms of Service, Privacy Policy и License Agreement: ликбез для мобильного инди-разработчика

Мы познакомились с Владиславом Архиповым во время питерской конференции WNCONF, где он выступал с докладом. В его выступлении особое внимание уделялось важной для нас теме трактовки gambling для social casino. В ходе разговора, в котором участвовали и другие коллеги, выяснилось, что юридическим моментам в своей работе инди-девелоперы уделяют очень мало внимания, создавая необходимые документы по остаточному принципу. Мы решили восполнить этот пробел и провести вместе с практикующим юристом небольшой “ликбез”.

Владислав Архипов – адвокат, советник практики интеллектуальной собственности, информационных технологий и телекоммуникаций международной юридической фирмы Dentons. Владислав является одним из немногих юристов-практиков, специализирующихся в области правовой поддержки индустрии компьютерных игр. Неравнодушен к компьютерным играм как таковым в любых проявлениях – играет сам с начала 1990-х и давно наблюдает за развитием индустрии. Будучи также кандидатом юридических наук, доцентом юридического факультета Санкт-Петербургского государственного университета, Владислав уделяет в своих курсах внимание и академическим game studies.

Владислав, ни для кого не секрет, что инди-разработчик, выкладывая свое приложение в стор, не обращает внимания на юридические документы, которые его просят указывать. Начнем с простого вопроса: что такое Terms of Service, Privacy Policy, License Agreement?

И Terms of Service, и Privacy Policy, и License Agreement – это документы, которые предназначены для регулирования отношений между конечным пользователем приложения и тем, кто распространяет и поддерживает это приложение, обеспечивает его работоспособность, является его правообладателем. Строго говоря, это может быть как сам инди-разработчик, так и тот, кому инди-разработчик передал права на свою разработку полностью или в части, если он не распространяет приложение самостоятельно. Давайте, тем не менее, условно называть эту сторону соглашений «разработчиком», хотя мы понимаем, что речь будет идти чаще всего о том, кто поддерживает проект уже после релиза (это, конечно, не исключает последующую разработку). При этом значение данных документов может выходить и часто выходит за рамки отношений между разработчиком и пользователем – их содержание может учитываться при определении различных вопросов ответственности разработчика в суде, а также – с возникновением и стремительным развитием различных площадок цифровой дистрибуции – может быть принципиальным для таких площадок, о чем мы, собственно, и говорим сейчас.

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

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

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

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

Рассмотрим каждый из документов поподробнее.

Terms of Service чаще всего определяет правила использования приложения в той части, в которой это не касается интеллектуальной собственности, и Terms of Service наиболее актуальны для игр и иных приложений с элементами онлайн-взаимодействия. По сути, они определяют правила использования услуги (хотя в России, с юридической точки зрения, вопрос о том, можно ли считать сервисы приложений именно услугами, как их понимает Гражданский кодекс, до конца не определен), но могут включать в себя и правила поведения в виртуальном пространстве, нарушение которых, например, может являться основанием для бана – скажем, оскорбление других игроков, использование ботов, продажа и покупка «нафармленного» золота за реальные деньги и т.п.

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

Интересные примеры связаны с проектами, в которых идет оборот виртуальных предметов за реальные деньги. В случае, если приложение предполагает наличие такого оборота в какой-либо форме, но разработчик не задумал свое приложение как некий «инвестиционный» сервис, который можно официально использовать для заработка, это также можно отразить в Terms of Service. Например, п. 11 B (iv) «Пользовательского соглашения аукциона Diablo III с продажей за настоящие деньги» прямо предусматривает, что аукционы не должны использоваться в качестве инструмента инвестиций. Не уверен, что Blizzard какие-либо органы власти из-за этого аукциона действительно могли бы официально счесть финансовой организацией (что потенциально повлекло бы серьезные юридические последствия), но если бы не было такой оговорки, такой риск стал бы все же несколько выше. Кстати, в п. 1 User Agreement and Software License, которое Wizards of the Coast используют для Magic: The Gathering Online (обратите внимание, что здесь как раз соединены в одном документе пользовательское, в смысле о поведении, и лицензионное соглашения), игре, в которой неотъемлемым элементом является виртуальная торговля цифровыми картами MTG за «тикеты», изначально продаваемые разработчиком за 1 Доллар США каждый, на «рынке» которых есть свои взлеты и падения, условно позволяющие «инвестировать», такое же правило выражено наоборот – от общего к частному: пользователям разрешается использовать цифровые объекты только для целей игры.

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

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

При разработке Privacy Policy российским компаниям следует помнить, что наименьшие риски связаны со случаями, когда персональные данные используются только для взаимодействия конкретно разработчика и пользователя в рамках одного приложения – это, во многих случаях, может подпадать под категорию обработки персональных данных для исполнения договора, стороной которого является субъект персональных данных, о которой говорится в п. 5 ч. 1 ст. 6 Федерального закона «О персональных данных», что не требует согласия субъекта персональных данных, то есть пользователя, по особой форме. Более сложные, с юридической точки зрения, ситуации возникают тогда, когда разработчик обрабатывает персональные данные для широкого круга целей, например, в целях маркетинга, и, особенно, при этом осуществляет передачу персональных данных для обработки третьим лицам и (или) за рубеж. Для таких ситуаций российское законодательство требует развернутое согласие пользователя в письменной форме, с учетом требования законодательства об электронных подписях.

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

License Agreement, наверное, наиболее понятный, с юридической точки зрения, документ – он определяет то, в каких пределах пользователь может использовать приложение как результат интеллектуальной деятельности, т.е. предоставляет пользователю ту или иную лицензию. Думаю, не будет ошибкой сказать, что исторически этот документ, из числа рассматриваемых, появился по отношению к компьютерным играм первым, поскольку законодательство об интеллектуальной собственности было наиболее разработанным на момент появления первых компьютерных игр. Более того, для однопользовательских игр, распространяемых на физических носителях без «живой» поддержки, это и сейчас может быть единственным документом, хотя таких игр, конечно, уже крайне мало (вероятно, это уже по большей части только нераспроданные «антикварные» экземпляры). Часто можно встретить более развернутое название данного документа – End User License Agreement, т.е. «Лицензионное соглашение с конечным пользователем».

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

Регулирование лицензионных отношений в целом имеет нюансы в разных странах, но общие принципы сохраняются, поскольку данное регулирование основано на одних и тех же международных соглашениях. В России общие положения о лицензионных договорах закреплены в ст. 1235 Гражданского кодекса Российской Федерации. Так, результат интеллектуальной деятельности может быть передан только в тех пределах и теми способами, которые предусмотрены лицензионным договором. По общему правилу, лицензионный договор должен быть заключен в письменной форме, иначе он считается недействительным. В лицензионном договоре должна быть указана территория, на которой допускается использование результата интеллектуальной деятельности, а если такая территория не указана, то лицензиат вправе осуществлять использование лицензируемого продукта на всей территории Российской Федерации (но не за рубежом). Срок лицензионного договора не может превышать срок действия исключительных прав. Для компьютерных программ, права на которые регулируются также как и литературные произведения (за исключением некоторых дополнительных положений), этот срок, по общему правилу, составляет жизнь автора и 70 лет с момента смерти автора, считая с 1 января года, следующего за годом смерти автора. Если срок не определен, то договор считается заключенным на пять лет, если иное не предусмотрено Гражданским кодексом. При отсутствии указания размера вознаграждения или порядка его определения договор считается незаключенным. Кроме того, лицензионный договор должен определять предмет договора и способы использования лицензируемого результата интеллектуальной деятельности.

Нужно ли эти документы создавать в обязательном порядке всегда или это опциональное требование?

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

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

По моему опыту общения с ИР, многие сейчас начинают задумываться о юридических аспектах своих проектов, что хорошо, поскольку может заранее уберечь ИР от ряда рисков. Если есть такая возможность – то при получении каких-либо инвестиций имеет смысл забюджетировать юридические услуги – их объем можно заранее согласовать с юристом, лучше – если он (юрист) прямо специализируется в области права интеллектуальной собственности, информационных технологий и медиа (последнее также важно, поскольку на сегодняшний день развивается и законодательство, и судебная практика в области регулирования интернет-технологий и контента). Это, как минимум, необходимо, чтобы избежать ситуаций в стиле описанных в цитате #427206 c «Башорга» – когда заказчик просил разработать логотип с серпом и молотом, а когда не смог его зарегистрировать по понятным причинам, попросил разработать новый логотип с Марио (любые ассоциации с недавними мобильными хитами случайны и ненамеренны).

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

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

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

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

Источник