Право на реверс. Как обратная разработка выглядит с юридической точки зрения

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

Введение

Фанаты Starcraft наверняка помнят те времена, когда можно было играть не через Battle.net, а через левый сервер на эмуляторе bnetd (или даже поднять собственный). Игра была той же, но лицензионный ключ не требовался. Или вспомнить другой случай: несколько лет назад многие радовались новости о том, что простой американский парень Джордж Френсис Хоц — младший aka geohot (тот самый, что в прошлом году объявил о создании своего автопилота для автомобилей) «обул» корпорацию Sony, взломав защиту PlayStation 3.

Ни Blizzard, ни Sony, ясное дело, не были рады таким публичным пощечинам и в конечном счете нашли крайних. В первом деле такой оказалась компания Internet Gateway, во втором — Джордж и сотоварищи из сообщества fail0verflow. В обоих кейсах дело касалось в том числе реверс-инжиниринга программного кода.

К чему мы это вспомнили? К тому, что занятие обратной разработкой софта без согласия правообладателя кода законно и ненаказуемо только в очень редких случаях. Да-да, букве закона (и не только американского, но и нашего) знакомо такое явление, как реверс-инжиниринг. Конечно, не настолько хорошо и детально, как хотелось бы, но и то, что есть, — это намного лучше, чем ничего. Но давай-ка начнем с самого начала.

Обратная разработка и закон

Итак, обратная разработка (обратный инжиниринг, реверс-инжиниринг или, кратко, реверсинг; от англ. reverse engineering) — это «исследование некоторого устройства или программы, а также документации на них с целью понять принцип его работы и, чаще всего, воспроизвести устройство, программу или иной объект с аналогичными функциями, но без копирования как такового».

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

Законы, которые ограничивают реверсинг, в каждой стране (а в США — в каждом штате) свои, и их нормы могут сильно различаться. Давай пройдемся по основным из них.

США

• Закон об авторском праве и положения о добросовестном использовании (раздел 17 Свода законов США (U. S. C.) и статья 107 указанного раздела)
• Закон о секрете производства
• Положения о запрете обхода технических мер защиты Закона об авторском праве в цифровую эпоху (он же тот самый DMCA) (статья 1201 раздела 17 Свода законов США)
• Закон о конфиденциальности электронной связи (статья 2510 раздела 18 Свода законов США)

Россия

• Гражданский кодекс (часть четвертая)
• Федеральный закон «О коммерческой тайне»
• Федеральный закон «Об информации, информационных технологиях и о защите информации»

Евросоюз

• Директива 2009/24/ЕС о правовой охране компьютерных программ

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

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

Вот, например, как выглядит лицензионное соглашение для Kaspersky Rescue Disk 10:

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

А вот EULA для продуктов Cisco:

Customer specifically agrees not to:
(iii) reverse engineer or decompile, decrypt, disassemble or otherwise reduce the Software to human-readable form, except to the extent otherwise expressly permitted under applicable law notwithstanding this restriction or except to the extent that Cisco is legally required to permit such specific activity pursuant to any applicable open source license...

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

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

В России дел, связанных с реверсом, почти нет, так что детали пока не успели накопиться. Гораздо интереснее изучить прецеденты в США, где примеров много. В рамках этой статьи я рассмотрю упомянутый в начале кейс Blizzard.

Blizzard против bnetd

Началась эта история еще в 1998 году, когда фирма Blizzard приступила к продажам игры Starcraft. Спустя несколько месяцев студент Калифорнийского университета в Сан-Диего Марк Бейзингер (Mark Baysinger) занялся реверс-инжинирингом протокола, по которому игра подключалась к серверу Battle.net.

Результатом работы стал эмулятор StarHack. И почти сразу же Бейзингер получил от Blizzard письмо с предупреждением о нарушении прав компании и требованием прекратить нарушение. В ответ он поинтересовался, в каких именно действиях было выражено нарушение авторских прав компании. Не получив ответа на свой вопрос, Бейзингер решил все же прекратить заниматься развитием проекта, но выложил в интернет исходники под лицензией GPL. Так появился опенсорсный проект bnetd — клон Battle.net, который, в частности, использовался на сервере bnetd.org.

В 2002 году в Blizzard начали бета-тестирование следующей игры — Warcraft III. А в 2003 году умельцы зареверсили протокол новой игры и написали форк bnetd под названием Warforge — с поддержкой Warcraft III.

Через несколько дней после релиза Warforge компания Internet Gateway, предоставлявшая хостинг проекту bnetd, получила аналогичное письменное предупреждение (так называемое C&D, cease and desist letter) от Blizzard, содержание которого сводилось к тому, что создатели bnetd нарушали права Blizzard. Поскольку после отправки предупреждения проект bnetd не был закрыт, руководство Blizzard приняло решение обратиться в суд.

В 2002 году адвокаты Blizzard подали иск к хостеру bnetd.org, а также к Тиму Джангу (Tim Jung), президенту компании Internet Gateway и одному из разработчиков проекта bnetd. Иски получили и системные администраторы домена bnetd.org, а позднее список ответчиков еще вырос. В иске Blizzard говорилось, что bnetd — серверная программа, которая эмулирует сервис Battle.net, но при этом не проверяет подлинность ключа, чтобы определять, легальное ли используется клиентское ПО. Помимо этого, разработчиков bnetd обвинили в незаконном копировании фрагментов кода компьютерных программ Blizzard.

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

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

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

Российские законы

Если говорить о российском законодательстве, то в целом оно допускает проведение реверс-инжиниринга, о чем идет речь в статье 1280 Гражданского кодекса РФ. Эта статья дает понять, что обратная разработка допустима только в случае соблюдения определенных критериев.

Вот фрагмент текста самой статьи Кодекса.

Как видишь, в законе упомянут только старомодный термин «программа для ЭВМ» — Гражданский кодекс не оперирует более узкими понятиями вроде мобильных и веб-приложений, протоколов, баз данных и тому подобных вещей.

Здесь можно выделить три важных момента:

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

Теперь рассмотрим наиболее важные вопросы, которые относятся к легальности реверс-инжиниринга.

Можно ли привлекать других лиц для выполнения реверс-инжиниринга?

Ответ на этот вопрос может дать следующее решение суда:

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

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

Допустимо ли проведение реверс-инжиниринга, если в лицензионном соглашении, на условиях которого распространяется программа, ничего об этом не говорится?

Ответ опять же можно найти в одном из постановлений:

Аналогичный ответ, кстати, содержится и в Постановлении Пленума ВС РФ и Пленума ВАС РФ от 26 марта 2009 года № 5, 29 «О некоторых вопросах, возникших в связи с введением в действие части четвертой Гражданского кодекса Российской Федерации».

Допустимо ли проводить реверс-инжиниринг, чтобы проверить, не является ли исследуемая программа объектом нарушения прав?

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

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

Выводы

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

WWW

Справочные материалы на русском

Перевод FAQ по реверс-инжинирингу Фонда Электронных Рубежей
Статья 1280. Право пользователя программы для ЭВМ и базы данных

На английском

Coders’ Rights Project Reverse Engineering FAQ
Intellectual Property Law for Reverse Engineering Computer Programs in the European Community
Reverse Engineering of Computer Programs under the DMCA: Recognizing a "Fair Access" Defense
The Law and Economics of Reverse Engineering (PDF)