[Перевод] FAQ от EFF по реверс-инжинирингу


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

Содержание

  1. Введение
  2. По каким аспектам наиболее высоки юридические риски?
  3. Как правовые доктрины затрагивают реверс-инжиниринг?
  4. Авторское право ограничивает реверс-инжиниринг
  5. Авторское право разрешает реверс-инжиниринг
  6. Судебные решения по реверс-инжинирингу
  7. Законодательство о секрете производства и реверс-инжиниринг
  8. Положения DMCA о запрете обхода технических мер защиты
  9. Исключения статьи 1201 DMCA
  10. Распространение исключений статьи 1201
  11. Договорное право и реверс-инжиниринг
  12. Закон о конфиденциальности электронной связи
  13. Заключение: Как ограничить юридический риск


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

О чем этот FAQ и для кого он?

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

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

Не стесняйтесь связаться с EFF, если вам нужна помощь в поисках квалифицированного юриста по вопросам реверс-инжиниринга.


Начнем с неприятного: какие типы реверс-инжиниринга обладают наибольшими юридическими рисками?

Употребляя в тексте понятие «юридические риски», мы не утверждаем, что деятельность в целом является легальной или нелегальной. Мы говорим, что есть области деятельности, к которым применим закон, поэтому любой исследователь, уделяющий внимание таким аспектам, должен уделить время на обдумывание таких аспектов и, возможно, получить некоторую юридическую помощь.
  • Если ваш доступ к программному коду или компьютерной системе, которую вы изучаете, регулируется какими-либо договорными нормами (например, лицензионным соглашением с конечным пользователем (EULA), уведомлением об условиях обслуживания (TOS), уведомлением об условиях использования (TOU), соглашением о неразглашении (NDA), соглашением разработчика или соглашением об использовании API), ваши юридические риски выше, чем в случае, когда вы не связаны подобными соглашениями. Вам следует обсудить с юристом, прежде чем соглашаться на какие-либо условия и начинать изучать любое распространяемое программное обеспечение, даже если вы стали обладателем кода такой программы без согласия на какие-либо условия.
  • Чрезвычайно высоки риски в случае разглашения или использования любой полученной вами информации, использование которой регулируется NDA или иным договорным обязательством о конфиденциальности.
  • Имеются юридические риски в случае изучения программы, если вы обладаете ею незаконно.
  • Имеются юридические риски при изготовлении копий программы, если вы не уполномочены на такие действия правообладателем (например, по условиями лицензионного соглашения).
  • Имеются юридические риски при обходе любых «технических мер защиты» (например, проверки подлинности, шифровании протокола, парольной аутентификации, обфускации кода, подписывании кода), которые контролируют доступ к коду или какому-либо определенному функционалу.
  • Высок юридический риск в случае копирования кода в программу, которую вы создаете в результате реверс-инжиниринга, поскольку такое копирование будет нарушать авторские права, за исключением случаев добросовестного использования, предусмотренного авторским правом. Отметим, что копирование может включать в себя одновременно как имитацию нефункциональных элементов, так и буквальное копирование.
  • Имеется юридические риск в случае выполнения любой проверки сетевых пакетов, за исключением случаев, когда (1) сеть сконфигурирована для свободного доступа, (2) вы имеете согласие от всех пользователей, чьи пакеты вы проверяете или (3) вы имеет согласие от сетевого провайдера, когда такая проверка необходима для оказания услуг или защиты прав и имущества провайдера.

В любом случае, не чувствуйте себя безнадежными. Ознакомьтесь с нашим последним разделом FAQ о том, как снизить юридический риск.


Какие юридические доктрины наиболее явно затрагивают реверс-инжиниринг?

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


Как авторское право может ограничивать мою возможность легально осуществлять реверс-инжиниринг?

Реверс-инженеры извлекают код и/или делают копии программного обеспечения как часть анализа принципов работы программы. Авторское право в целом дает правообладателям определенный набор исключительных прав, включая право на создание копий авторских произведений. Программное обеспечение — это одна из категорий произведений, охраняемых авторским правом. Как результат, если вы создаете копии программы, вы в целом должны получить согласие от правообладателя на это, или ваше копирование должно подпадать под исключение, предусмотренное законами об авторском праве. Согласие должно следовать из прямой продажи копии программы или из лицензионного соглашения. Исключением авторского права, наиболее относимым к реверс-инжинирингу, является доктрина добросовестного использования.

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


Что разрешают доктрины авторского права США в отношении реверс-инжиниринга?

Согласие: правообладатель может всегда дать вам согласие на изготовление копий (например, в лицензионном соглашении), и в зависимости от природы такого согласия, оно может разрешать реверс-инжиниринг. К примеру, если лицензионное соглашение позволяет вам «использовать» программу, и явным образом не выражает запрет на реверс-инжиниринг, это может быть тем самым согласием, которое вам нужно.

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


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

Некоторые из таких:
  • В деле Sega Enterprises v. Accolade,1 производитель ведущей консоли для видеоигр (Sega Genesis) подал иск к издателю игр (Accolade) после того, как издатель произвел реверс-инжиниринг консоли в целях создания совместимых игр. Accolade установила декомпилятор в схему консоли в момент загрузки трех разных лицензионных игр. Затем она сравнила дизассемблированный код с целью определить интерфейсные спецификации консоли. Эта информация затем была собрана в письменное руководство, которое использовали программисты для разработки собственных игр Accolade для консоли Genesis. Код самой компании Sega при этом не был скопирован в игры от Accolade — код Accolade был полностью оригинальным. Хотя Accolade в первой инстанции проиграла судебное дело в окружном суде, Суд девятого округа в конечном итоге определил, что «промежуточное» копирование со стороны Accolade (например, копирование исключительно в целях определения функциональных спецификаций интерфейса, которые затем были самостоятельно реализованы) было добросовестным использованием, основанным на том, что дизассемблирование было единственным путем для получения доступа к концепциям и функциональным элементам, содержащихся в компьютерной программе Sega и тем самым, у Accolade было достаточное на то основание для определения такого доступа. (Отметим, что Sega продавала Genesis без какого-либо лицензионного соглашения, поэтому суду не пришлось исследовать какие-либо договорные запреты в отношении реверс-инжиниринга.)
  • Дело Sony Computer Entertainment v. Connectix2 касалось издателя ПО (Connectix), который разработал программу, известную как Virtual Game Station, эмулирующую игровую консоль Sony PlayStation на компьютерах с операционными системами Macintosh и Windows. При разработке Virtual Game Station пришлось прибегнуть к реверс-инжинирингу, который включал в себя извлечение BIOS консоли PlayStation и ее наблюдение с помощью отладочной программы, а также дизассемблирование объектного кода BIOS. Sony подала иск, Connectix проиграла спор в первой инстанции, и была обязана соблюсти запрет на распространение Virtual Game Station. Тем не менее, в конечном итоге, Суд девятого округа пересмотрел это решение, определив, что промежуточное копирование со стороны Connectix было добросовестным использованием. Суд обратил особое внимание на промежуточный характер копирования (например, никакой код, входящий в BIOS Sony, не вошел в состав кода Virtual Game Station), необходимость реверс-инжиниринга и важность потребительской доступности игр PlayStation на новых платформах. (Как и в деле Sega, в этом деле не было никаких лицензионных соглашений, поэтому суд не делал каких-либо суждений в отношении толкования договорных условий против реверс-инжиниринга.)
  • Дело Atari Games Corp. v. Nintendo of America, Inc.3: Nintento создала код блокировки — 10NES — для пресечения запуска неавторизованных игровых картриджей на консоли Nintendo Entertainment System (NES). Atari безуспешно пыталась взломать 10NES путем мониторинга обмена данных между авторизованными игровыми чипами и чипом консоли с последующим физическим исследованием чипов. Потом компания стала лицензиатом Nintendo, получив ограниченный доступ к программе 10NES. По условиям лицензии, Atari могла разрабатывать 5 игр для NES ежегодно, и Nintendo должна была встраивать код 10NES, чтобы игра была доступна для запуска на консоли. Затем Atari обманным путем получила копию 10NES из Управления по авторским правам США. Она использовала эту копию для отладки микроскопического исследования кода из чипа. Затем Atari разработала оригинальную программу, которая не использовала никакой код из 10NES, но которая выполняла ту же самую функцию. Суд определил, что Atari нарушила права путем создания копии 10NES, поскольку она не была уполномочена на такое владение ею. Любые попытки реверс-инжиниринга, не сопровождающиеся неправомерным копированием, включая удаление слоев химическим путем, изучение чипа под микроскопом, транскрибирование объектного кода в рукописный лист с единицами и нолями, кодированной информацией в компьютере, когда дизассемблируется объектный код, были правомерными случаями добросовестного использования. Но любой реверс-инжиниринг, в результате которого использовалась копия, похищенная из Управления по авторским правам США, был неправомерным. В довершение ко всему, программа-деблокиратор от Atari была существенно схожей с программой 10NES и в тех направлениях, которые не являются обязательными для повторения функционала разблокирования консоли NES. Даже если программа была написана для другого чипа и на другом языке программирования, такие сходства дают основания полагать, что программа Atari не являлась самостоятельной разработкой, а была неавторизованной копией.
  • Дело Compaq Computer Corp. v. Procom Technology, Inc.4: Суд определил, что созданная компанией Compaq компиляция пороговых значений для параметров, используемых для определения неизбежности сбоя в работе жесткого диска, представляла собой достаточно творческое решение, чтобы быть охраняемым авторским правом. Компания по своему усмотрению определила целый ряд параметров, а также определила, какие конкретные параметры необходимо отслеживать, и таким образом пороговые значения не являлись просто фактами. Procom продавала жесткие диски, которые были совместимы с серверами, продвигаемыми Compaq, и сделала свои жесткие диски конкурирующими с дисками Compaq, скопировав пороговые значения и затем сделав доступными схожие предупреждения о неполадках. Т.к. Procom сделала материальные носители таких пороговых значений, охраняемых авторским правом, и затем использовала их без изменений, такие материальные носители являлись контрафактными.
  • Дело Blizzard v. BnetD5: BnetD была программой с открытым исходным кодом, которая позволяла игрокам играть в популярные игры Blizzard типа World of Warcraft на сторонних серверах за рамками сервиса Battle.net, таким образом предлагая игрокам больше вариантов. Программисты BnetD согласились с Blizzard’овскими условиями лицензионного соглашения с конечным пользователем (EULA) и условиями использования сервиса (TOU) Battle.net, прежде чем начать реверс-инжиниринг игры для создания BnetD. EULA и TOU явным образом запрещали реверс-инжиниринг и размещение игр Blizzard на других серверах. Суд восьмого округа постановил, что такие лицензии по клику для массового рынка являлись имеющими обязательную юридическую силу договорами и что программисты нарушили несколько положений EULA, включая положение о реверс-инжиниринге. Даже если реверс-инжиниринг является добросовестным использованием по федеральному законодательству об авторском праве, программисты отказались от таких своих прав, приняв условия EULA. Суд также постановил, что программисты нарушили положения DMCA о запрете обхода технических мер защиты, когда они программировали BnetD-серверы для эмуляции процесса аутентификации между игровым ПО от Blizzard и сервером Battle.net. Сделав это, команда BnetD обошла технические меры защиты Blizzard, которые контролировали доступ к программному коду игры, охраняемой авторским правом. Далее, оговорка в DMCA относительно реверс-инжиниринга для достижения взаимодействия с независимо созданной компьютерной программой не применима. Положения EULA не давали право программистам BnetD использовать игровое ПО на сервере, не принадлежащем Blizzard. Команда BnetD допустила работу ПО, нарушающего авторские права. В конечном счете, команда BnetD скопировала кода больше, чем это было необходимо в целях обеспечения взаимодействия для предоставления идентичной игровой среды.


Как может закон о секрете производства ограничивать реверс-инжиниринг?

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

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

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


Как положения DMCA о запрете обхода технических мер защиты ограничивают реверс-инжиниринг?

Статья 1201 раздела 17 Свода законов США, где изложены положения DMCA о запрете обхода технических мер защиты, запрещает обход «технических мер защиты», который «позволяет успешно контролировать доступ» к объектам авторских прав. Закон также запрещает реализацию средств, которые изначально созданы, применимы или распространяемы для обхода таких мер.

Другими словами, статья 1201 создает потенциальную правовую преграду для исследователя или кодера, если производитель ПО применяет механизмы управления доступа к своему ПО или иные доступные средства для этого. Многие думают, что статья 1201 запрещает взлом систем цифрового управления правами (DRM). Как бы то ни было, формулировка статьи 1201 запрещает более чем просто взлом традиционных механизмов «защиты от копирования», применяемых в DVD и загрузках цифрового видео. Она также запрещает взлом «контроля доступа». Производители ПО аргументируют или пытаются аргументировать, что такие технологии, как проверка подлинности, подписывание кода, обфускация кода и шифрование протокола — все вместе определяются как «технические меры защиты», охраняемые положениями DMCA. В то время как исследование таких техник может быть, тем не менее, правомерным по различным причинам, исследователи, работающие над программами по шифрованию, безопасности и взаимодействию, должны беспокоиться о том, не применима ли к их исследованию статья 1201.

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


Какие исключения статьи 1201 DMCA разрешают реверс-инжиниринг?

Статья 1201 содержит исключение как для реверс-инжиниринга, так и для исследования безопасности, шифрования и распространения средств безопасности, все из которых могут быть применимы к реверс-инжинирингу. Тем не менее, эти исключения прописаны очень узко. Если ваше исследование может подразумевать применение к нему статьи 1201, проконсультируйтесь с юристом, чтобы определить, можете ли вы выполнять свою работу тем образом, который разрешен одним из предусмотренных исключений или исключением, которое периодически предоставляется Управлением по авторским правам США. Следующие факторы существенны для определения того, вправе ли вы осуществлять реверс-инжиниринг, исследование или исключения безопасности. Тем не менее, наличие одного или всех этих факторов не обязательно защитят вашу работу. Предлагаемый список лишь предоставляет вам концепцию о тех аспектах, которые позволяют разграничить допустимый реверс-инжиниринг от недопустимого:
  • Вы надлежащим образом получили право использовать компьютерную программу;
  • Вы разгласили информацию, которую получили, добросовестным образом, который не позволяет утверждать о каком-либо нарушении авторских прав или компьютерном мошенничестве;
  • Единственной вашей целью в обходе является определение и анализ частей программы, необходимых для достижения взаимодействия;
  • Реверс-инжиниринг выявляет информацию, необходимую для достижения взаимодействия;
  • Любая взаимодействующая программа, созданная вами в результате реверс-инжиниринга, не является объектом нарушения прав;
  • Вы уполномочены от правообладателя или оператора программы или защищенной компьютерной системы, в отношении которой проводится реверс-инжиниринг, на проведение такого исследования;
  • Вы вовлечены в правомерный обучающий курс, вы трудоустроены или вы обладаете соответствующими навыками или опытом в сфере шифрования;
  • Вы предоставляете своевременное уведомление о ваших находках правообладателю.


Если я провожу исследование в рамках исключений статьи 1201, могу ли я затем распространять код, возникший в результате такого исследования?

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


Как договорное право может ограничивать реверс-инжиниринг?


Большинство ПО распространяется сейчас вместе с EULA, и такие EULA могут содержать условия о запрете на реверс-инжиниринг. Веб-сайты и иные Интернет-сервисы также могут иметь свои TOS или TOU, предназначенные для запрета какой-либо исследовательской деятельности в их отношении. Исследователи и программисты иногда получают доступ к соответствующему коду на условиях NDA, соглашения разработчика или соглашения об использовании API, которое запрещает право на сообщение об уязвимостях в безопасности. Правовой статус договорных запретов на исследование безопасности или сообщении об уязвимостях продолжает оставаться не полностью определенным. Хотя более вероятно, что суд отдаст предпочтение NDA, согласованному сторонами, чем EULA, предназначенному для массового рынка, закон не однозначен. Обязательно проконсультируйтесь с юристом, если код, который вы собираетесь изучать, является объектом договорных ограничений любого рода.


Как может Закон о конфиденциальности электронной связи регулировать реверс-инжиниринг?


Этот закон, статья 2510 и последующие раздела 18 Свода законов США запрещают перехват электронных данных, передаваемых по сети. Т.к. пакеты данных являются сообщениями, перехват сетевых пакетов данных может нарушать положения закона. Есть много исключений касательно этого запрета. К примеру, провайдер сервиса может перехватывать и использовать данные как часть «любой деятельности, которая является неотъемлемым элементом его сервиса или защитой прав или имущества провайдера такого сервиса, за исключением случаев, когда провайдер общественной услуги проводной связи не должен использовать свою услугу для наблюдения или случайного мониторинга, если только это не в целях механического регулирования или проверки качества оказания услуги». В дополнение, если стороны таких сообщений согласны, с этим также нет проблем. Этот закон является запутанным документом, поэтому если ваше исследование включает в себя перехват сетевых пакетов данных — даже если вы заинтересованы только в адресной информации, такой как начальный и конечный адреса, вы должны вначале проконсультироваться с юристом, чтобы быть уверенным, что ваша деятельность подпадает под одно из исключений.


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

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


Сноски и примечания

  1. ↑ 977 F.2d 1510 (9th Cir. 1992).
  2. ↑ 203 F.3d 596 (9th Cir. 2000).
  3. ↑ 975 F.2d 832 (Fed. Cir. 1992).
  4. ↑ 908 F. Supp. 1409 (S.D. Tex. 1995).
  5. ↑ Davidson & Associates DBA Blizzard Entertainment, Inc.; Vivendi Universal Inc. v. Jung et al., 422 F.3d 630 (8th Cir. 2005). // прим. пер. — про это дело также можно почитать в материале «Судебные хроники. Blizzard Entertainment».
  6. ↑ В деле DVD CCA v. Bunner, ответчик разместил копию DeCSS, созданную в результате реверс-инжиниринга и DVD CCA заявила о нарушениях Единого Акта о секретах производства штата Калифорния. Суд первой инстанции постановил, что секреты производства были определены в результате реверс-инжиниринга в нарушение лицензионного соглашения и, следовательно, определены ненадлежащими средствами. DVD Copy Control Ass’n, Inc. v. Bunner, 31 Cal.4th 864 (Cal. 2003). Хотя мнение Верховного Суда штата Калифорния касалось только того, был ли временный судебный запрет нарушением первой поправки, совпадающим мнением был отклонен аргумент о том, что положение EULA о запрете реверс-инжиниринга преобразовало реверс-инжиниринг в нечто иное, отличное от «справедливого и честного» пути определения секретов производства. См. там же на 875, 901 n.5 (Cal. 2003) (Moreno, J., concurring) ([Н]игде не признано, чтобы сторона, желающая защитить собственную информацию, может применить потребительский договор для, по факту, изменения установленного законом о секрете производства определения «ненадлежащих средств», включив в их число и реверс-инжиниринг, чтобы предполагаемый обладатель секрета производства мог подать иск даже к лицу, не являющемуся стороной в таком договоре»).


© Megamozg