Что такое terms of service и privacy policy
Как написать Privacy Policy
Команда VERSUS.legal продолжает публиковать статьи о правовых вопросах геймдева. В прошлый раз вы могли прочитать о множестве юридических подсказок для игровых разработчиков. А сегодня мы начинаем серию материалов о базовых документах, которые могут понадобиться на релизе вашей игры. В первой статье расскажем об одном из самых распространенных соглашений в индустрии – о политике конфиденциальности или Privacy Policy.
Без privacy policy сейчас не может обойтись, пожалуй, ни одно приложение. Так или иначе собирают персональные данные почти все. Если в вашей игра есть регистрация, встроенные покупки, аналитика использования в любом виде (в частности, логи ошибок) – то есть если клиент игры отправляет обратно разработчику любую информацию – то вам нужен такой документ. Его размещения в публичном доступе требуют как и законы многих стран (правда, иногда их требования к содержанию политики разнятся), так и правила App Store (начиная с 8 декабря 2020 года) и Google Play. По ссылкам вы можете ознакомиться с детальным перечнем функционала, который требует политику конфиденциальности.
Что будет, если у меня нет такой политики?
Вы можете быть признаны нарушающими закон и правила маркетплейса.
Штрафы за отсутствие опубликованной политики разнятся в зависимости от страны. Например, в России штраф составит от 15 000 рублей для юридических лиц. По правилам GDPR он может составить куда больше, вплоть до 20 миллионов евро. Но на практике самый большой штраф на сегодня составил 1800 евро – в Испании была оштрафована компания Solo Embrague за отсутствие политики конфиденциальности и баннера cookie на главной странице корпоративного сайта.
Что касается санкций от маркетплейсов, то они могут быть весомее, вплоть до удаления приложения. Например, Google присылает сообщения “Warning of Google Play Developer policy violation: Action Required Policy issue” («Предупреждение о нарушении политики Google Play Developer: Необходимо принять меры»).
Privacy Policy and Terms of Service
1 policy terms
2 Legal disclaimer and Privacy policy
3 Policy-based service level management
4 Privacy Policy
5 Scientific Policy Planning service (Belgium)
6 policy terms
7 privacy policy
8 special policy terms
9 policy terms
10 special policy terms
11 privacy policy
12 Scientific Policy Planning service
13 policy
policy of neutrality, neutrality policy — политика нейтралитета
policy of appeasement, appeasement policy — политика умиротворения
near-optimal policy — политика, близкая к оптимальной
short-sighted [myopic\] policy — недальновидная [близорукая\] политика
subtle policy — тонкая [умная\] политика
prudent policy — разумная [предусмотрительная\] политика
cautious policy — осторожная [осмотрительная\] политика
clear-cut [clear\] policy — четкая [ясная\] политика
rigid policy — твердая [жесткая\] политика
sound [wise\] policy — здравая [мудрая\] политика
long-run [long-range\] policy — долгосрочная политика, политика дальнего прицела
consistent policy — последовательная [неизменная\] политика
deliberate policy — обдуманная [взвешенная\] политика
moderate policy — умеренная [сдержанная\] политика
to carry out [to conduct, to operate\] a policy — проводить политику
to implement a policy — осуществлять [проводить\] политику
to effect a policy — осуществлять [реализовать\] политику
to set [to set down\] a policy — устанавливать политику
to form [shape\] a policy — вырабатывать политику
to reverse a policy — резко [круто\] изменить политику
to adhere to [to follow, to pursue\] a policy — следовать политике, придерживаться политики, проводить политику
to ease [to relax\] policy — ослаблять [смягчать\] политику
easing [relaxation, ease\] of policy — ослабление [смягчение\] политики
policy tool — средство проведения политики, орудие [инструмент\] политики
policy manual — руководство, инструкция
policy objective — цель [задача\] политики
two-track [twin\] policy — двойственная политика
government policy on wages [wages policy\] — государственная политика в области оплаты труда
information policy — информационная политика, политика в области информации
language policy — языковая политика, политика в области [в отношении\] языка
export policy — экспортная политика, политика в области экспорта
import policy — импортная политика, политика в области импорта
education policy, educational policy — образовательная политика, политика в области образования
science policy — научная политика, политика в области науки
fishery policy, fisheries policy — политика рыболовства, политика в области рыболовства, рыболовная политика
privacy policy — политика конфиденциальности, политика (в отношении) конфиденциальности личной [частной\] информации
Our policy is to submit all contracts to the legal department. — Мы придерживаемся политики предоставления всех контрактов на изучение в юридический отдел.
It is not the normal policy of the council to give grants for more than three years. — Выдавать гранты более чем на три года не в правилах совета.
The government made a policy statement [a statement of policy\]. — Правительство сделало программное заявление.
for reasons of policy — по политическим соображениям, по соображениям политики
The first step in ensuring your computer security is up to scratch is to write a security policy. — Первый шаг на пути обеспечения поддержания вашей компьютерной безопасности на должном уровне — разработка политики безопасности.
to issue [write up, write\] a policy — выдавать [выписывать\] полис
to take out a policy — получить [приобрести\] полис, застраховаться
to effect a policy — застраховаться, приобрести полис
to carry a policy — иметь (страховой) полис, быть застрахованным
to purchase [to buy\] a policy — покупать полис
to obtain [get\] a policy — приобрести полис
to terminate a policy — прекратить действие полиса, аннулировать полис
termination of a policy — прекращение действия [аннулирование\] полиса
to void a policy — признавать полис недействительным, аннулировать полис
to keep a policy in force — поддерживать полис в силе, сохранять действие полиса
This policy covers the cost of injury or damage caused by another driver who is not insured. — Этот полис покрывает [страхует, распространяется на\] расходы, связанные с травмой или ущербом, причиненным незастрахованным водителем. [Этот полис предоставляет страховую защиту от расходов, связанных с травмой или ущербом, причиненным незастрахованным водителем.\]
This portion of the policy covers you in the event a claim or lawsuit is brought against you for bodily injury or property damage as the result of an accident or event occurring on your property. — Эта часть полиса предоставляет вам страховую защиту в случае [страхует вас на случай\] подачи жалобы или иска против вас в связи с нанесением телесных повреждений или имущественного ущерба в результате несчастного случая или иного события, произошедшего на территории вашего владения.
to be covered by a policy — покрываться [охватывается, страховаться\] полисом
policy amount, amount of a policy — сумма полиса
a policy expires, a policy lapses, a policy matures — срок действия полиса истекает
expired [lapsed, matured\] policy — истекший [прекративший действие\] полис
policy endorsement, endorsement to a policy, policy rider, rider to a policy — приложение [дополнение\] к полису
14 terms
15 charging policy
политика взимания оплаты (в информационных технологиях)
(ITIL Service Strategy)
Политика, определяющая цель процесса взимания оплаты и способ её расчёта.
См. тж. затраты.
[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
charging policy
(ITIL Service Strategy)
A policy specifying the objective of the charging process and the way in which charges will be calculated.
See also cost.
[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
Тематики
16 information security policy
политика информационной безопасности
Совокупность документов, определяющих управленческие и проектные решения в области ЗИ.
[Домарев В.В. Безопасность информационных технологий. Системный подход.]
политика информационной безопасности
(ITIL Service Design)
Политика, которая определяет подход организации к управлению информационной безопасностью.
[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
information security policy
(ITIL Service Design)
The policy that governs the organization’s approach to information security management.
[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
Тематики
17 SPPS
18 data parsimony
19 secretary
State secretary, NSC Member — государственный секретарь — член СНБ
20 document
документ
Объект информационного взаимодействия в социальной среде, предназначен-ный для формального выражения социальных отношений между другими объектами этой среды.
[ ГОСТ Р 52292-2004]
документ
Текст, имеющий наименование, определенную структуру и обозначение, который может быть сохранен, отредактирован, найден и заменен как единое целое.
[ ГОСТ Р ИСО/МЭК 2382-23-2004]
документ
документированная информация
Зафиксированная на материальном носителе информация с реквизитами, позволяющими ее идентифицировать.
[ ГОСТ Р 51141-98]
документ
Зафиксированная на материальном носителе информация с реквизитами, позволяющими ее идентифицировать. Документ может иметь бумажную, электронную (или другую) форму представления и изменять ее в процессе документооборота.
[ОАО РАО «ЕЭС России» СТО 17330282.27.010.001-2008]
документ
Материальный объект, содержащий в зафиксированном виде информацию, оформленную установленным образом на определенном языке и носителе информации, имеющий в соответствии с действующим законодательством правовое значение.
[МУ 64-01-001-2002]
документ
Информация, представленная на соответствующем носителе.
Пример
Записи, спецификация, процедурный документ, чертеж, отчет, стандарт.
Примечания
1. Носитель может быть бумажным, магнитным, электронным или оптическим, компьютерным диском, фотографией или эталонным образцом, или их комбинацией.
2. Комплект документов, например, спецификаций и записей, часто называется «документацией».
3. Некоторые требования (например, требование к разборчивости текста) относятся ко всем видам документов, однако могут быть особые требования к спецификациям(например, требование к управлению пересмотрами) и записям (например, требование к восстановлению).
[ ГОСТ Р ИСО 9000-2008]
документ
Объединяющее звено разнотипной информации, присутствующее на всех стадиях цифровой печати и меняющее свою форму от физического оригинала или цифрового файла в электронных средах до тиражируемой твердой копии на бумаге.
Материальный объект, содержащий в зафиксированном виде информацию, оформленную установленным порядком и имеющую в соответствии с действующим законодательством правовое значение [http://www.rol.ru/files/dict/internet/].
[ http://www.morepc.ru/dict/]
документ
Информационный объект в виде текста. В качестве документов могут выступать: нормативные, распорядительные, организационные, договорные, плановые, другие внутренние и внешние документы.
[ Департамент лингвистических услуг Оргкомитета «Сочи 2014». Глоссарий терминов ]
документ
Информация, представленная в удобной для чтения форме. Документ может быть бумажным или электронным. Например, политика, соглашение об уровне услуги, запись об инциденте или план компьютерного зала. См. тж. запись.
[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
документ
1. Носитель информации, используемый в любых системах управления, в том числе и автоматизированных. Их информационная база — документы разного вида (плановая, статистическая, бухгалтерская, техническая документация и т.д.). 2. В информационно-поисковых системах (ИПС) документом называют любой объект, внесенный в «память» системы: книгу, Д. в обычном смысле слова, статистическую таблицу, заметку из газеты, патент, чертеж и т.д. Каждый Д. в ИПС имеет «поисковый образ«, по которому при поступлении соответствующего запроса его и находит компьютер.
[ http://slovar-lopatnikov.ru/]
document
fixed and structured amount of information intended for human perception that can be managed and interchanged as a unit between users and systems
NOTE 1 The term document is not restricted to its meaning in a legal sense.
NOTE 2 A document can be designated in accordance with the type of information and the form of presentation, for example overview diagram, connection table, function chart.
[IEC 61082-1, ed. 2.0 (2006-04)]
document
information on a data medium
NOTE 1 The term document is not restricted to its meaning in a legal sense.
NOTE 2 Normally a document is designated in accordance with the type of information and the form of presentation, for example overview diagram, connection table, function chart.
NOTE 3 Information may appear in a static manner on paper and microform or dynamically on (video) display devices.
[IEC 62023, ed. 1.0 (2000-04)]
document
Information object in textual form. Documents can be regulatory, administrative, organizing, contractual, planning or other internal and external documents.
[ Департамент лингвистических услуг Оргкомитета «Сочи 2014». Глоссарий терминов ]
document
Information in readable form. A document may be paper or electronic – for example, a policy statement, service level agreement, incident record or diagram of a computer room layout. See also record.
[Словарь терминов ITIL версия 1.0, 29 июля 2011 г.]
document
quantité d’informations fixe et structurée destinée à être perçue par les personnes et qui peut être gérée et échangée comme un tout entre utilisateurs et systèmes
NOTE 1 Le terme document n’est pas réduit à sa signification au sens légal.
NOTE 2 Un document peut être désigné selon le type d’information et la forme de présentation, par exemple schéma d’ensemble, tableau de connexion, diagramme fonctionnel.
[IEC 61082-1, ed. 2.0 (2006-04)]
document
information sur un support de données
NOTE 1 Le terme «document» n’est pas réduit à son sens légal.
NOTE 2 Normalement, un document est désigné conformément au type d’information et à la forme de présentation, par exemple schéma de système, tableau des connexions, diagramme fonctionnel.
NOTE 3 Les informations peuvent apparaître d’une manière statique sur papier et microforme ou d’une manière dynamique sur des dispositifs d’affichage (vidéo).
[IEC 62023, ed. 1.0 (2000-04)]
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 и медиа в России и за рубежом, но я понимаю, что этот вариант жизнеспособен только при хороших инвестициях в проект и оценке актуальности юридических рисков, скорее, уже самим инвестором.
Второй возможный вариант – найти юриста, с которым ИР может обсудить возможность участия в проекте юриста на «рисковых» началах, при которых юрист получит свое вознаграждение в случае получения прибыли от проекта. Не все юридические фирмы и частнопрактикующие юристы, если они исходят из того, что выполняют функции независимого советника по правовым вопросам (а для адвокатов такая позиция определена законом и кодексом профессиональной этики) могут на это согласиться, поскольку в такой ситуации юрист фактически становится частью команды, а это налагает дополнительные, по крайней мере, моральные обязательства. Однако, в общем, такой вариант возможен.
Наконец, имея определенный опыт и знания в юридических вопросах, теоретически, можно попытаться обойтись своими силами – например, написав свои документы на основе примеров, полученных от коллег. Но этот вариант достаточно рискован – не владея системными знаниями в области права, есть большая опасность не только не снизить риски, но и создать дополнительные. Кроме того, крайне нежелательно прямое копирование чужих документов, поскольку они сами по себе могут представлять собой результаты интеллектуальной деятельности, ведь объектами авторских прав, по крайней мере, по российскому законодательству, из числа юридических документов не являются только официальные документы органов государственной власти, местного самоуправления и международных организаций. «Частные» документы охраняются. Не менее важно и то, что документ по другому проекту может просто не отражать критические, с точки зрения закона, аспекты вашего проекта.
Плюс ко всему, можно представить и смешанный вариант, предполагающий меньшие затраты – создать проект документа(-ов) самому, а потом дать его на проверку юристу, и если не потребуются изменения, это может сократить бюджет на правовое сопровождение.