Привет! Я Олег Макаров, ведущий юрист ispmanager. Эта статья будет полезна всем, кто зарабатывает на ПО с открытым кодом. Расскажу, как безопасно работать с лицензиями Open source и что бывает с нарушителями — а уже попадались D-Link и Cisco Systems. Российский разработчик Антон Мамичев выиграл дело о нарушении его авторских прав на открытый код у Veeam Software, дочерней компании Amazon.

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

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

Какие вообще бывают лицензии для открытого кода и чем отличаются 

Свободные лицензии бывают двух видов. Их главное отличие — в требованиях, как использовать производное ПО.

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

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

Дальше расскажу о самых распростаненных лицензиях и условиях их использования. Данные о долях лицензий на рынке я привел по данным рейтинга Statista.com

Разрешительные лицензии, их отличия, условия использования и последствия нарушений

Чаще всего на рынке используют три вида разрешительных лицензий:

MIT, «Massachusetts Institute of Technology» — дает возможность свободно использовать, менять и распространять взятое ПО. В 2021 году лицензия MIT занимала самую большую долю рынка Open source — 26%.

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

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

  • в код — если разделяем свой код и заимствованный;

  • в интерфейс исполняемого файла или файла license в репозитории.

Уведомление об авторском праве выглядит так: Copyright (c) <год> <владельцы прав>

BSD, «Berkeley Software Distribution» — разрешает использовать, менять и распространять взятый код, если вы указываете его авторство. У BSD есть разные виды — например, FreeBSD, OpenBSD, BSD 1-4. Рассмотрю наиболее распространенные — BSD 2 и BSD 3. Они занимают около 7% всех Open source проектов.

Условия использования:

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

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

  • Указать в коде, что лицензия и уведомление о правах распространяются только на заимствованную часть кода — как и в лицензии MIT. 

  • Только для BSD 3: не использовать имена авторов ПО и разработчиков, если планируете продвигать ПО в коммерческих целях. 

Apache. Разработчик лицензии — Apache Software Foundation. В России Apache считается самой безопасной лицензией — никто не сможет подать в суд, если в коде оригинала окажется запатентованный компонент, потому что по российским законам код не патентуется по п. 5 ст. 1350 ГК РФ.

Рассмотрю версию Apache 2.0 — она занимает 22% всех Open source компонентов.

Условия использования:

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

  • Отметить любыми доступными средствами кусок оригинального кода, в котором были изменения — например, в комментариях к исходному коду.

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

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

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

Что будет, если нарушить условия разрешительных лицензий. Компанию или разработчика могут обвинить в незаконном использовании заимствованного ПО и подать в суд за компенсацией по нарушению авторских прав. Ее сумма зависит от масштабов бизнеса правообладателя и от того, как именно использовали его ПО. В РФ подобной судебной практики нет, да и за рубежом я не видел громких дел, связанных с нарушением требований разрешительных лицензий — обычно все можно урегулировать в досудебном порядке. Но лучше максимально обезопасить себя и выполнить все требования. 

Копилефтные лицензии — когда подойдут, условия использования, последствия нарушений

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

Чаще всего на рынке используют 6 видов копилефтных лицензий:

GNU GPL v3 (General Public License) — разрешает свободно использовать, менять и распространять ПО. Модифицированное ПО можно свободно распространять только под лицензией GPL v3. Условие — ваш продукт с заимствованным кодом должен быть под лицензией оригинала кода — GNU GPL v3. Занимает 16% всех Open source проектов.

Лицензию написали юристы — в GPL v3 подробно «разжевали» терминологию, учли проблему патентов, тивоизации и добавили информацию о последствиях нарушения условий. 

Скрытый текст

Тивоизация — ситуация, когда разработчик технически запрещает пользователям менять установленное на устройстве ПО. Например, из-за тивоизации нельзя дорабатывать программы на iPhone — можно использовать только ПО из App Store. Термин назвали в честь цифрового видеоплеера Tivo, который запрещал модифицировать установленное на нем ПО. Лицензия GPL v3 пресекла тивоизацию для бытовых товаров, но сохранила запрет на модификацию для важных устройств, где это критично — например, медицинских приборов и аппаратов для голосования.

Условия использования:

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

  • Включить текст лицензии на английском языке в уведомления в интерфейсе исполняемого файла, в файл license в репозитории. А еще — ссылку на текст лицензии, если в ПО не менялся исходный код.

  • Указать в исходном коде, в какую часть внесли изменения, кто их автор и когда поменяли оригинал. 

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

  • Предоставить неограниченному кругу лиц права на использование патента, если он есть в производном ПО.

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

GPL v2 — похожа на GPL v3, но в GPL v2 не учтена проблема тивоизации и патентов. Лицензия писалась разработчиком для разработчиков, поэтому ее текст более понятный и простой. Занимает 10% рынка Open source.

Условия использования: 

  • Включить в UI и в код уведомление об авторском праве.

  • Добавить текст лицензии на английском языке в уведомления в интерфейсе исполняемого файла, в файл license в репозитории. А еще — ссылку на текст лицензии, если в ПО не менялся исходный код.

  • Указать в исходном коде, в какую часть внесли изменения, кто их автор и когда поменяли оригинал. 

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

LGPL v2.1 (Lesser GPL), применяется только для лицензирования библиотек и дополняет GPL v2. Доля среди всех Open source проектов — 6%.

Условия использования:

  • Отметить измененную часть кода, если была модификации библиотеки, указать авторов и дату изменений.

  • Дать пользователю вашего ПО инструменты модификации «втянутой» библиотеки. Запрещено ограничивать право на модификацию соглашением с пользователем (EULA). Это требование касается только статического линкования — «втягивания» кода библиотеки в ваше ПО. Для динамического линкования, когда библиотека не «втягивается» в код, ограничений нет.

AGPL (Affero General Public License) — содержит такие же положения, как GPL v3 и GPL v2. Единственное отличие — лицензия касается и SaaS решений, когда производное ПО распространяется в облачном формате, без физического устройства. 

Условия использования — те же, что для GPL v3 и GPL v2.

Microsoft Public License (Ms-PL) — лицензия Microsoft для распространения исходного кода своих проектов. Не вынуждает раскрывать исходный код программы — достаточно распространять производный код под лицензией MPL. Используется в 3% всех Open source проектов.

Условия использования:

  • Распространять ПО с MPL-компонентами в исходном коде только под этой же лицензией.

  • Распространять ПО с компонентами под MPL в объектном коде можно только с лицензией, по условиям которой не нужно раскрывать исходный код ПО.

    Невозможно не противоречить MPL с классической проприетарной лицензией, потому что она предполагает сокрытие кода исходного и распространяется только в обьектном. Как вариант, можно разделить в коде условия для «своего» и свободного ПО.

  • Предоставить неограниченному кругу лиц права на использование патента, если он есть в производном ПО.

  • Не использовать товарные знаки и имена авторов в производном ПО.

Eclipse Public License v.1 — единственная лицензия, которая прямо разрешает коммерческое использование в определенных случаях. Используется для продуктов компании Eclipse Foundation — разработчика одноименной среды разработки IDE. Занимает всего 1% сферы Open source.

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

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

 Вот несколько примеров из судебной практики.

Германия. Юрист-программист Харальд Велте в проекте gpl-violations.org успешно засуживал компании, которые попадались на нарушении условий GPL. Например, программист подал иск на D-Link — в сентябре 2006 года Мюнхенский суд подтвердил, что компания нарушила условия GPL и обязал D-Link предоставить исходный код и покрыть судебные издержки. 

США. Free Software Foundation и Artiflex удалось через суд принудить Cisco Systems, Palm, Inc., раскрыть исходный код их ПО с GPL-компонентами кода.

Россия — дело Антона Мамичева против Veeam Software. Компания удалила его имя из программного кода и использовала программу в коммерческих целях. В ответ в ходе судебных разбирательств Антона обвинили, что он нарушил условия лицензии GNU GPL v2 и поэтому не имеет право защищать свои авторские права. После 7-летних разбирательств Антону удалось доказать, что даже если нарушены условия копилефтной GPL-лицензии, разработчик не теряет права на защиту своего ПО. 

Вот некоторые выводы, которые Антон Мамичев сформулировал из своего опыта судебных разбирательств:

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

  • Решения судов полностью непредсказуемы, поэтому нужно избегать самого предмета спора.

  • Десять раз подумайте об использовании копилефтных лицензий наподобие GNU GPL.

Все самое важное о лицензиях Open source коротко

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

Не подойдут для коммерческих целей большиство копилефтных лицензий  — по их условиям нужно распространять модифицированное ПО. Важно, чтобы ваши наработки были открытые и бесплатные для других пользователей. Единственная копилефтная лицензия, которую можно использовать в коммерческих целях — Eclipse Public License v.1. Важно — на все претензии к ПО с такой лицензией придется отвечать самостоятельно. 

Три главных мысли на тему Open source:

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

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

Если нужно запретить пользователям менять ПО на устройстве, то подойдут копилефтные лицензии GPL v2, LGLP v2.1 и AGPL.

Первоначально статья опубликована в блоге ispmanager

Другие мои статьи, как соблюдать законы в IT 

Как хостерам попасть в реестр РКН, зачем его придумали и что будет, если этого не сделать

Новый закон для хостинг-провайдеров: как попасть в реестр Роскомнадзора и удержаться

Комментарии (18)


  1. laminar
    26.08.2024 13:14
    +3

    После прочтения статьи понял, что: - "Копилефтные лицензии это плохо". Но остался вопрос, плохо для кого? Для того у кого заимствуют или для того, кто заимствует )


    1. oleggmakarov Автор
      26.08.2024 13:14
      +1

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


  1. ildarz
    26.08.2024 13:14
    +4

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

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

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

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

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

    Вас на фоне этого абзаца не смущает, что на Западе достаточно успешные софтверные компании строят свой бизнес именно на продаже и поддержке ПО с GPL-лицензиями?


    1. oleggmakarov Автор
      26.08.2024 13:14

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

      2. Все верно написали, но как раз таки получение кода конкурентом может привезти к потере преимущества вашего ПО на рынке. А если заставят сделать общедоступным, то тогда такое ПО никто не будет покупать.

      3. Есть такие бизнесы на западе, но основные бенефиты они получают не от продажи экземпляров, а от технической поддержки и доработки такого ПО для заказчика (red hat например)


  1. Andy_U
    26.08.2024 13:14

    Уважаемый автор, а не могли бы вы прояснить ситуацию с использованием "опасных" лицензий при разработке внутрикорпоративного софта?


    1. oleggmakarov Автор
      26.08.2024 13:14

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


  1. arokettu
    26.08.2024 13:14

    Поэтому еще их называют вирусными.

    Не все копилефт лицензии являются вирусными, MPL, CDDL, EPL, etc не "заразят" ваш продукт. Вирусными называют прежде всего семейство GPL


    1. oleggmakarov Автор
      26.08.2024 13:14

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


  1. arokettu
    26.08.2024 13:14

    Eclipse Public License v.1 — единственная лицензия, которая прямо разрешает коммерческое использование в определенных случаях

    Все FOSS лицензии разрешают коммерческое использование в любом случае. Коммерческое использование =/= закрытый код


    1. oleggmakarov Автор
      26.08.2024 13:14

      Все верно, тут именно имелось ввиду в виде закрытого кода с защитой.


  1. PereslavlFoto
    26.08.2024 13:14
    +1

    Не подойдут для коммерческих целей большиство копилефтных лицензий

    Автор имеет право продавать копилефтные произведения. Многие писатели, фотографы, художники, скульпторы выпускают свои произведения по копилефтным лицензиям в одном месте, одновременно продавая их в другом месте.


  1. somech
    26.08.2024 13:14
    +1

    А можно подробнее про AGPL? Есть просто непонимание как она в действительности работает если используется ПО "as is" (развернут инстанс).

    Например: есть объектное хранилище minio. Оно распространяется по лицензиям AGPL и коммерческой. Согласно написаного на их сайте, если инстанс является составной частью продукта (возьмем, например, самописный блог: фото и видео с его мы зачем-то будем хранить в minio) и не используется коммерческая лицензия -- весь продукт должен быть опубликован под лицензией AGPL. Я правильно трактовал их требования, или нет?


    1. agratoth
      26.08.2024 13:14

      By contrast, pipes, sockets, RESTful APIs, and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

      Грубо говоря, пока в приложении нет прям глубокой интеграции, minio и блог будут рассматриваться как два отдельных приложения


    1. oleggmakarov Автор
      26.08.2024 13:14

      As is тут не причем, это никак не влияет на последствия лицензии. Основная идея AGPL в распространении ее условий на продукты, который распространяются по SaaS, то есть это тот же GPL.

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


  1. AndreyDmitriev
    26.08.2024 13:14
    +2

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

    И MPL — это вроде "Mozilla Public License", a Microsoft Public License — это Ms-PL или MS-PL.


    1. PereslavlFoto
      26.08.2024 13:14

      Мне кажется, что эта таблица недооценивает важность копилефта.


  1. salieff
    26.08.2024 13:14

    Уровень анализа, на первый взгляд, не очень. Сразу бросаются в глаза 2 самые распространенные ошибки - путаница free beer / free software и производная-непроизводная работа / статическая-динамическая линковка.


  1. tsvetkovpa
    26.08.2024 13:14

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