Привет, Хабр! Меня зовут Максим. Я занимаюсь QA около двух лет, хотя тестированием и проверкой функциональности немного дольше. Работаю как с веб-продуктами, так и standalone-приложениями. Во время аудитов и при тестировании проектов мы периодически сталкиваемся с использованием защищенных лицензией продуктов, например, библиотек.  И хотя большинство разработчиков знакомы с лицензиями, об авторском праве и правах правообладателя нередко забывают. Если не соблюдать «технику безопасности», могут возникнуть серьезные проблемы.

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

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

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

Предисловие

Разобраться в теме лицензирования подтолкнул достаточно типичный случай – очередной мерж в экспериментальной ветке.

Разработчик нашел «супербиблиотеку», которая решала львиную долю его задач и позволяла минимизировать написание кода. И, как это часто бывает, оказалось, что она защищена лицензией. Подвох был в том, что используемая библиотека распространяется под двумя лицензиями (Примечание. Схожие библиотеки выпускаются под разной лицензией и немного отличаются в функциональности и сопровождении). Одна из них предназначалась для open source проектов, а вторая – для коммерческого использования. Как вы понимаете, для приложения взяли бесплатную версию, которая не может применяться в продукте без открытия исходного кода. 

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

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

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

Зачем нужны лицензии

Для начала давайте рассмотрим пример.

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

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

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

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

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

Наблюдение — многие в РФ думают, что нарушение лицензий не приведёт к суду. Полагают, что они никому не интересны и ничего страшного не случится, если какие-то из пунктов будут нарушены. Более того, что использование части продукта, кода или функциональности не приведёт к потерям, а, наоборот, позволит «сэкономить». Но если с их продуктом поступят аналогично, эти же люди будут отстаивать свои права в суде, что у них украли собственность и пользователь поступает неправомерно и выходит за рамки лицензии, под которой распространяется их продукт. 

Что такое лицензия программного обеспечения?

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

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

Лицензия – это разновидность договора. Самый близкий пример – договор на аренду квартиры или техники. Ты можешь её использовать, как хочешь, но все желания должны укладываться в рамки соглашения с арендодателем. Нельзя переделывать или передавать в субаренду. Арендодатель будет следить, чтобы ты не нарушил эти правила, а если ты их нарушил (например, перекрасил стены), то он вправе выкатить тебе штраф и даже выселить из квартиры или забрать технику.

Рассмотрим лицензии, как их видят каждая из сторон.

Автор

Когда начинаешь создавать программное обеспечение, автоматически становишься его автором, правообладателем и первым пользователем.

Автор – тот, кто создал программное обеспечение (человек или группа людей). Грубо говоря, написал исходные инструкции ПО. Это важная тонкость определения.

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

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

В дальнейшем мы будем выделять понятие «Автор как сущность» – тот, кто производит продукт при помощи инструментов. Также важно понимать, что инструменты – это продукты, произведенные другими авторами. Когда автор их применяет, он становится пользователем. Про это никогда не нужно забывать.

Авторские права разработчика охраняются, как и авторское право писателя. Говоря проще – написанные инструкции и код приравнены к литературным произведениям и сборникам. Можете добавить в резюме отдельной строкой пункт, что вы «писатель, а также редактор и литературный критик», если занимались код-ревью и оставляли фидбек для авторов:)

Правообладатель (владелец)

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

Например, мы создали ПО и продали его. Поскольку в договоре передаем свои права на владение, изменение, обслуживание третьей стороне, мы всё также остаёмся автором этого ПО, но уже не являемся его владельцем.

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

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

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

Пользователь

Пользователь (user, юзер) – тот, кто использует продукт. Уточнение — установка продукта к себе на компьютер не дает права говорить, что это твой продукт, если иначе не сказано в лицензии. Непонимание отличий между владельцем и пользователем часто приводит к драме, когда пользователь решает: раз это приложение у него, он может делать с ним всё, что захочет.

Права пользователя охраняются в рамках прав потребителя, но они ограничены рамками контракта (лицензии), что является полностью правомерной практикой.

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

Необходимо также помнить и про языки. Хороший пример недопонимания в этом — Java. После 16 апреля 2019 года изменилась лицензия для Java SE. Это привело к затруднениям при использовании новых версий Oracle Java SE для коммерческого применения без подписки. После этого появилось множество ответвлений, например, Oracle OpenJDK, Oracle JDK, Adopt OpenJDK и так далее. Всё это разные сборки Java и распространяются они под разными лицензиями (GNU GPL v.2+CPE, NFTC, etc). Есть сборки, которые распространяются под строгой лицензией GNU GPL v.2 (не путайте с GNU GPL v.2+CPE), и их нельзя использовать в коммерческом проекте без выкладывания исходного кода продукта. Уточните у своих разработчиков, какую версию Java они используют, от какого поставщика и под какой лицензией она распространяется – с большой долей вероятности они не смогут ответить на эти вопросы, а значит есть повод задуматься.

Для чего заключают лицензионное соглашение

Изначальная цель соглашения – автор и правообладатель хотят ограничить пользователя и сохранить свои возможности и права на продукт и производные от него.

Основные причины: воровство (как прямое, так и непрямое), убеждения (желание автора, чтобы продукт всегда оставался открытым), безопасность (возможность сохранить время и деньги, если конфликт дойдет до судебного разбирательства).

Цели автора

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

Важно учесть, что некоторые вещи могут перейти в общественное достояние (если это допускается законом страны правообладателя) и тогда сохранять авторство необязательно. Например, при использовании продукта под лицензией public domain нельзя указывать авторство, потому что это публичный продукт. То есть, создал продукт не автор, а мы, общество.

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

Цели правообладателя (владельца)

Изначально автор и правообладатель – один и тот же человек. Правообладатель определяет границы разделения и правила использования. Именно он решает, будет ли имя автора в продукте или нет, и определяет, что можно делать с его продуктом.

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

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

Цели пользователя

Тут всё просто – получить всё, сразу, надолго и бесплатно.

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

Возможные проблемы для пользователя

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

Первая заключается в указании границ по лицензии. Но практически ни в одной из них не указаны обязательства. То есть автор и правообладатель предоставляет программное обеспечении, как оно есть (фразой «as it is») – будь то библиотека, набор скриптов, обработчик или комплексный полноценный продукт. Другими словами, программный продукт предоставляется, как он есть, и использование данного инструмента ничего не гарантирует. Более того, если в результате его использования что-то сломалось, кто-то пострадал или пользователь понес финансовые потери, автор и правообладатель не несут за это ответственности.

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

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

Хороший пример такого конфликта — MIT и GPL лицензии. Поверх MIT лицензии можно наложить GPL, но поверх GPL нельзя наложить лицензию MIT. Как один из вариантов реализации такой совместимости, разделение приложения на две физически разные ветки, два продукта. В одном хранится закрытая часть исходников и самого продукта, собираемого из этих исходников, во второй части – открытый исходный код, а сама часть приложение общедоступна для использования и загрузки. Но такое разделение возможно только в том случае, если это оговорено в лицензии продукта.

Почему так важен этот вопрос?

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

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

Проблема проверки лицензий заключается в уникальности лицензий, а не некоторых частей приложения. Используя приложения по анализу пакетов и частей приложения (исходных и бинарников) вроде Black Duck, можно найти сходства одних продуктов с другими, но в работе самого приложения есть множество ложных срабатываний, что затрудняет саму проверку. Необходимо вручную сверять и перепроверять результат проверки – для каждого отдельного случая. Эти знания не раз помогали нам в реализации типичных задач QA.

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

Надеемся, материал был вам полезен.

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