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

/ Unsplash.com / Luke Southern
/ Unsplash.com / Luke Southern

Немного контекста

Рынок открытого программного обеспечения один из самых горячих в ИТ-индустрии. По данным Statista, его объем составляет порядка $32 млрд, но аналитики из Open Source Services Market прогнозируют, что к 2026 году эта цифра вырастет до $66 млрд. Подогревает ситуацию тот факт, что на open source все чаще переходят автопроизводители, ретейлеры, энергетические компании, интернет-провайдеры и научные лаборатории. Например, в CERN отказались от коммерческих продуктов еще в 2019 году [первым делом компания заменила сервисы электронной почты и IP-телефонии], а два крупных американских телекома применяют фреймворк ONAP для быстрого сегментирования сетей.

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

В последние годы активными участниками комьюнити становятся государственные организации. Так, в конце прошлого года Еврокомиссия упростила процедуру, по которой внутренние подразделения могут передавать свои наработки в open source. В то же время примерно две трети ИТ-бюджета Барселоны уходит на развитие открытых проектов. Многие из них внедряют не только на территории Испании — например, систему Sentilo Platform для анализа погодных датчиков используют в Японии.

Рост интереса к открытому ПО наблюдается и в России. Еще до того, как многие западные компании объявили об уходе с отечественного рынка, аналитики предсказывали, что к 2026 году на open source перейдет более 90% организаций. Наиболее перспективными эксперты посчитали разработки в области инфраструктуры, ИТ-поддержки и аналитических процессов.

Слегка приоткрытое ПО

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

/ Unsplash.com / Katerina Pavlyuchkova
/ Unsplash.com / Katerina Pavlyuchkova

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

Одними из первых по этому пути пошли авторы документоориентированной системы управления базами данных MongoDB. Они представили собственную лицензию Server Side Public License (SSPL), в основу которой положили GPLv3, но с условием — сторонние поставщики не могут предлагать СУБД в качестве сервиса. Для этого нужно или получить у разработчиков разрешение, или выпустить всю связанную инфраструктуру на условиях SSPL.

Следом за MongoDB свою лицензию модифицировали в Redis Labs. Компания перешла на Redis Source Available License (RSAL) и запретила бесплатное коммерческое использование наиболее популярных модулей.

В целом за последние пять лет условия лицензионного соглашения поменяли десятки open source проектов. Среди них — TimescaleDB и CockroachDB, система журналирования Graylog и аналитический инструмент Plausible. Сторонники изменений отмечают, что частичная коммерциализация продуктов откроет для разработчиков дополнительные источники дохода и поможет эффективно развиваться и масштабироваться. И уже есть первые результаты — когда в 2019 году команда Handsontable отказалась от открытой лицензии, их доходы выросли на $1,5 млн.

Правовые вопросы

Ряд участников ИТ-сообщества предлагает не останавливаться на общих ограничениях, а разработать лицензии, способные запретить использовать код конкретным компаниям — по аналогии с персонализированными соглашениями. Например, под Anyone But Richard Stallman License код могут модифицировать и перепродавать все, кроме основателя проекта GNU Ричарда Столлмана.

/ Unsplash.com / alireza nazari
/ Unsplash.com / alireza nazari

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

Еще несколько лет назад The Graph Foundation сделали форк графовой СУБД Neo4j, назвали новый проект ONgDB и стали продвигать его как альтернативную разработку. В 2018 году Neo4j перешла на новую лицензию AGPLv3 с дополнительными ограничениями, запрещающими перепродажу кода. Однако The Graph Foundation продолжили продвигать свое приложение как открытое. После череды судебных разбирательств, в марте калифорнийский суд наконец постановил, что компания нарушает права разработчиков исходной системы. Ей пришлось сделать новый форк из ветки до изменения лицензии.

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

Поворот не туда

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

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

Хотя здесь справедливости ради стоит заметить, что большинство open source проектов и так поддерживают компактные команды мейнтейнеров (или вообще «тот самый энтузиаст» в свободное время). Например, одно время разработкой OpenSSL занимались четыре инженера. При этом во главе ключевых проектов open source экосистемы — включая Linux, Python или Elm — находится всего один человек. В контексте открытого ПО таких специалистов принято называть «великодушными пожизненными диктаторами», то есть людьми, принимающими окончательные решения по проекту.

/ Unsplash.com / Pablo García Saldaña
/ Unsplash.com / Pablo García Saldaña

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


Больше материалов в нашем блоге на Хабре:


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


  1. garwall
    11.05.2022 13:02
    +2

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


  1. rsashka
    11.05.2022 13:33
    +2

    Термин «открытое программное обеспечение» подразумевает, что исходный код можно модифицировать и даже коммерциализировать.

    "Смешались в кучу кони, люди ..."

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


    1. andreymal
      11.05.2022 13:49

      Вы всё ещё отказываетесь признавать определение Open Source от OSI?


      1. rsashka
        11.05.2022 14:04
        +1

        Мы с вами уже обсуждали тот факт, что определение организации Open Source Initiative требуется только для тех, кто хочет использовать логотип Open Source Initiative (OSI). Но никак не влияет на открытость исходников или на использование термина Open Source по отношению к программам с несвободными лицензиями но с доступным исходным кодом.


        1. andreymal
          11.05.2022 14:09
          +3

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

          Ну и процитированный вами кусок из статьи ссылается именно на определение OSI


    1. vassabi
      11.05.2022 13:52
      +8

      в статье действительно смешались "кони и люди"

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

      Пока свободное и открытое ПО было небольшими утилитками - всем было норм. Но когда в опенсорс вышли базы данных - это породило эффект, когда команда разрабатывающая основное ПО фиксит баги и делает фичи А, Б, В, в то время как условный рептилоид делает форк в личный репозиторий, добавляет фичи Е, Ж, З и предоставляет услуги "БД как сервис" на своих личных серверах (ака "облако").

      Таким образом - рептилоид 1) не делится своими фичами с оригинальной командой, 2) как только команда разработчиков делает новую фичу Г, он тут же может добавить ее себе.

      В общем - сплошное переманивание клиентов и собака на сене.

      Собственно лицензии Монги и т.д. - это чтобы отвадить таких нехороших рептилоидов с их облачными сервисами от высасывания их кода (или принудить их делиться фичами в основной проект).

      Однако такие ограничения все еще делаются "по месту" (и со своими перегибами), и не всеми воспринимаются как "полезные ограничения" (изза перегибов).

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


      1. Tanner
        12.05.2022 00:55
        +2

        Всё правильно, но стоит ещё добавить, что рептилоид сначала делает цены на свой сервис ниже, чем может стоить запуск открытой БД on-premises. И фичи Е, Ж, З он плодит не просто так, а чтобы разработчик открытой БД не мог зарабатывать на поддержке бывшего своего продукта. А уж потом, когда пользователи перейдут к нему и оригинальный разраб загнётся с голоду, тогда можно задрать цены и отыграться.


        1. vassabi
          12.05.2022 11:21
          +1

          да, есть и такие рептилоиды.

          В общем - явление "ПО как сервис" вынуждает общество опенсорса активнее "не стоять на месте" :)


  1. olku
    11.05.2022 18:13
    +2

    AWS переименовали ElasticSearch в OpenSearch, но не сдались.


  1. ikle
    11.05.2022 21:48
    +3

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

    Лично для меня, свободные лицензии — это что-то вроде BSD-2 и MIT, где лицензия запрещает удалять саму лицензию (не автору, то есть обходить лицензию) и в ней есть отказ от ответственности (защита автора от законодательств некоторых стран).

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

    Так, требование предоставлять изменённые исходные коды в GPL требует механизма для выполнения этого требования. Это не только сама пересылка по требованию или публикация, но и обеспечение синхронности между версией продукта и версией исходных кодов: нельзя просто так дать клиенту версию 1.2.3 + какие-то тестовые изменения и не зафиксировать эту комбинацию — клиент по запросу должен получить именно ту комбинацию исходников, из которых собран продукт, ни больше, ни меньше.

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

    Обратная связь методом пересылки патчей в теле письма в 20-х годах 21-го века, да ещё и когда сама система пересылки почты не гарантирует битовой целостности? Сообщение об ошибке особым образом сформированным письмом для регистрации факта ошибки и весь обмен комментариями такими же письмами с Web-страницей только для просмотра и поиска других сообщений (угадайте проект с такой bug tracking system)?

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

    P.S. Я ни в коем случае не призываю использовать какую-либо конкретную лицензию или, наоборот, не использовать какую-либо иную: выбор лицензии — это прерогатива исключительно автора.


  1. visirok
    11.05.2022 23:06
    +2

    его объем составляет порядка $32 млрд

    Вам известны хотя бы общие принципы подсчета? Откуда взялась эта оценка?