Мы познакомились с Владиславом Архиповым во время питерской конференции 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 запреты и оговорки, как уже, в общем, было отмечено, дают разработчику шанс получить дополнительный аргумент в защите от притязаний третьих лиц и государственных органов, если такие притязания необоснованы.
Интересные примеры связаны с проектами, в которых идет оборот виртуальных предметов за реальные деньги. В случае, если приложение предполагает наличие такого оборота в какой-либо форме, но разработчик не задумал свое приложение как некий «инвестиционный» сервис, который можно официально использовать для заработка, это также можно отразить в 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 и медиа в России и за рубежом, но я понимаю, что этот вариант жизнеспособен только при хороших инвестициях в проект и оценке актуальности юридических рисков, скорее, уже самим инвестором.
Второй возможный вариант – найти юриста, с которым ИР может обсудить возможность участия в проекте юриста на «рисковых» началах, при которых юрист получит свое вознаграждение в случае получения прибыли от проекта. Не все юридические фирмы и частнопрактикующие юристы, если они исходят из того, что выполняют функции независимого советника по правовым вопросам (а для адвокатов такая позиция определена законом и кодексом профессиональной этики) могут на это согласиться, поскольку в такой ситуации юрист фактически становится частью команды, а это налагает дополнительные, по крайней мере, моральные обязательства. Однако, в общем, такой вариант возможен.
Наконец, имея определенный опыт и знания в юридических вопросах, теоретически, можно попытаться обойтись своими силами – например, написав свои документы на основе примеров, полученных от коллег. Но этот вариант достаточно рискован – не владея системными знаниями в области права, есть большая опасность не только не снизить риски, но и создать дополнительные. Кроме того, крайне нежелательно прямое копирование чужих документов, поскольку они сами по себе могут представлять собой результаты интеллектуальной деятельности, ведь объектами авторских прав, по крайней мере, по российскому законодательству, из числа юридических документов не являются только официальные документы органов государственной власти, местного самоуправления и международных организаций. «Частные» документы охраняются. Не менее важно и то, что документ по другому проекту может просто не отражать критические, с точки зрения закона, аспекты вашего проекта.
Плюс ко всему, можно представить и смешанный вариант, предполагающий меньшие затраты – создать проект документа(-ов) самому, а потом дать его на проверку юристу, и если не потребуются изменения, это может сократить бюджет на правовое сопровождение.
И последний вопрос. Указанные документы располагаются то в сторе, то в самом приложении, то на сайте поддержки. Есть ли какое-либо требование или стандарт, которого нужно придерживаться?
Так же, как и в ситуации с вопросом об обязательности данных документов, прямых законодательных требований к этому в целом нет, но правила размещения могут быть предусмотрены соглашением с соответствующей площадкой цифровой дистрибуции или иным издателем, если такой есть. С другой стороны, прослеживается общий принцип, согласно которому, чем более непосредственным является знакомство пользователя с данными документами, тем ниже риск того, что недобросовестный пользователь, нарушающий правила, сможет оспорить их применимость на том основании, что они были ему не известны. За этими словами стоят различные юридические нюансы, но в целом это именно так. Данному правилу, собственно, и следуют те разработчики, которые технически обязывают пользователя «прокрутить» соглашение до конца и поставить галочку, нажать «Я принимаю» и т.п. перед там как «допустить» его в приложение.
Автор: kamagames
