Код

28 июл 2022
0

Коварный Open Source: какие опасности кроются в открытом и свободном ПО

Рассказываем, как не стать жертвой мошенников, наживающихся на пользователях Open Sourсe, и самому случайно не оказаться в рядах правонарушителей.

Иллюстрация: DC Studio / Shutterstock / Teddy / Rawpixel / Annie для Skillbox Media

Анна Арзуманян

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

Вряд ли кто-то будет спорить, что Open Source и свободное ПО — это прекрасно. Собственно, оно и было придумано для того, чтобы облегчить жизнь разработчикам.

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

Из этой статьи вы узнаете:

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

Плагиаторы поневоле

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

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

Ситуации могут быть самые разные. Например, вы использовали в своём проекте код, распространяемый под разрешительной лицензией, а потом выяснилось, что он включает в себя части проприетарного кода, который скопировали нелегально. Или кто-то не особо щепетильный в юридических вопросах объединил в одну библиотеку фрагменты кода из источников, выпущенных под разными лицензиями. Либо же, не заморачиваясь, изменил вид лицензии — скажем, с GPL на MIT.

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

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

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

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

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

Как наказывают провинившихся программистов

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

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

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

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

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

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

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

Напомню один из самых известных имущественных процессов. В 2017 году компания Artifex, создавшая Ghostscript, подала в суд на Hancom, включившую эту разработку в свой офисный пакет.

Суть спора заключалась в следующем: у Artifex было две лицензии на Ghostscript — свободная (GPL) и коммерческая. В Hancom решили схитрить: воспользоваться открытой версией Ghostscript, но свой продукт в качестве свободного ПО не выпускать. Истец счёл это нарушением условий лицензии.

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

Берите что дают

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

Однако полный отказ от гарантий и ответственности создаёт определённые риски для пользователей. Если им будет причинён вред, они не смогут предъявить претензии, поскольку согласились с условиями лицензии. Зато, если пользователь в результате работы с таким ПО нанесёт ущерб третьим лицам, он понесёт перед ними ответственность.

С какими проблемами сталкиваются суды

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

Понятно, что современные версии наиболее популярных лицензий, таких как GPLv3, основаны на международных стандартах авторского права, а потому ближе к российскому законодательству — например, к поправкам в часть 4 ГК РФ (статьи 1286 п. 5; 1286.1). Но риски противоречий всё-таки сохраняются.

Наши суды чаще всего сталкиваются с проблемами в следующем:

Идентификация сторон договора. В свободных лицензиях автор и правообладатель — одно лицо. Но остаётся проблема соавторства: открытое ПО — нередко результат труда многих разработчиков. Согласно ГК РФ, лицензиатом становится любой, кто принял условия лицензии.
Идентификация предмета договора. Гражданский кодекс РФ определяет, что предметом открытой лицензии становится не само произведение, а право его использования в предусмотренных договором пределах. Таким образом, взаимные или копилефт-лицензии распространяют своё действие не только на первоначальную, но и на производные программы.
Форма договора. Согласно ст. 1286.1 ГК РФ, лицензионные договоры должны заключаться в простой письменной форме. В открытой лицензии можно указывать действия, совершение которых будет считаться принятием её условий. В этом случае письменная форма договора считается соблюдённой.
Ограничение личных неимущественных прав автора. Свободные лицензии, предоставляющие право на модификацию программы, ограничивают право автора на неприкосновенность произведения. В российском законодательстве такое ограничение запрещено: переработка признаётся новым произведением на основе существующего. Остаётся вопрос, можно ли каждую модификацию программы считать переработкой.
Распространение условий первоначального договора на последующих пользователей. Если пользователь раздаёт немодифицированную программу, последующие пользователи получают права не от него, а от правообладателя. Если же программа модифицирована и модификация может считаться переработкой, права передаёт её автор.

Но когда мы имеем дело с множеством соавторов, каждый из которых вносит свой вклад в продукт, установить, кто кому передаёт права в каждый конкретный момент времени, практически невозможно.

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

Как всё это совместить

Вот несколько простых правил, которые позволят вам работать, не опасаясь неприятностей с законом:

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

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

Следи за ПО, будь осторожен

Проекты Open Source задействуют большое количество участников. Не все из них разбираются в вопросах безопасности ПО. Если централизованная проверка созданного кода не проводится, возникает опасность включения вредоносных фрагментов вроде backdoor и spyware.

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

Например, уязвимость в Apache Log4j — библиотеке, которая используется миллионами корпоративных приложений и Java-серверами, — позволяла преступникам выполнять произвольный код на сервере или устройстве, чтобы похитить данные или внедрить вредоносную программу.

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

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

Определённую роль играет уход с российского рынка иностранных поставщиков ПО. Поскольку быстро заменить коммерческие решения не получается, повышается спрос на решения Open Source. Отсюда повышенные риски.

Кто и как борется за безопасность свободного ПО

В зарубежной практике есть система договоров-стратегий SLA (Service Level Agreement, соглашение об уровне обслуживания). Его заключают заказчик и поставщик Open Source для уменьшения рисков отсутствия обратной связи и решения проблем информационной безопасности.

Хорошо известны инструменты по повышению безопасности открытого ПО:

статические анализаторы исходного кода (SAST);
динамические анализаторы безопасности приложений (DAST);
автоматизированные сценарии тестирования в процессе проверки качества (QA);
анализаторы многоуровневых взаимозависимостей между своими и сторонними компонентами (SCA);
анализаторы безопасности скриптов, используемых для построения «инфраструктуры как кода»;
анализаторы безопасности образов и конфигураций контейнеров и средств для их оркестрации.

В 2020 году Linux Foundation совместно с GitHub, Google, IBM, JPMorgan Chase, Microsoft, NCC Group, OWASP Foundation и Red Hat учредила новый совместный проект OpenSSF (Open Source Security Foundation), целью которого стало повышение безопасности ПО с открытым кодом. К инициативе также присоединились GitLab, HackerOne, Intel, Uber, VMware, ElevenPaths, Okta, Purdue, SAFECode, StackHawk и Trail of Bits.

В числе задач проекта названы:

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

Среди других проектов, исследующих защищённость открытого ПО, — Coverity, созданный в сотрудничестве со Стэнфордским университетом; PVS-Studio; сообщество Open Web Application Security Project (OWASP).

В последнее время повышенное внимание безопасности открытого кода уделяется и в отечественной IT-индустрии.

Например, по инициативе Федеральной службы по техническому и экспортному контролю (ФСТЭК) создан Технологический центр исследования безопасности ядра Linux. В октябре 2021 года представители ФСТЭК, научного сообщества и IT-рынка раскрыли концепцию центра и рассказали, как он будет работать.

Центр будет исследовать и совершенствовать защиту отечественных дистрибутивов Linux и всего, что на них создано. А также «обеспечивать технологическую независимость российских компаний-разработчиков дистрибутивов и программно-аппаратных средств от внешних игроков».

В апреле 2022 года начала работать АНО «Открытый код». Её директором стала Любовь Орлова, в 2014–2015 годах возглавлявшая Российскую ассоциацию свободного программного обеспечения (РАСПО). В состав учредителей входят Ростелеком, Т1, VK, Россельхозбанк, «АДС Групп», Фонд информационной демократии и другие. В планах организации — создать среду для разработчиков национальных проектов с открытым кодом.

Читайте также: