В феврале 2021 года компания Elastic выпустила свои программные предложения под новой лицензией Elastic License 2.0. Благодаря этому шагу значительный набор программного обеспечения, включая Elasticsearch и Kibana, был переведен на новую, открытую и упрощенную модель лицензирования. Как и почему это произошло, и что это значит?
Новая лицензия Elastic - это кульминация сильной тенденции в лицензировании лучших практик для компаний с открытой моделью разработки. Это не лицензия с открытым исходным кодом, но она направлена на установление минимальных ограничений, необходимых для установления справедливого баланса между свободой использования, обмена и изменения программного обеспечения и предотвращением действий, которые могут нанести вред сообществу.
UNIX, Linux, свободное программное обеспечение и открытый исходный код
Чтобы понять новую тенденцию в лицензировании, представленную Elastic License 2.0, необходимо понять, как она выросла из движения за лицензирование открытого исходного кода.
Движение за открытый исходный код или свободное программное обеспечение возникло из опасений разработчиков по поводу приватизации и "форка" программного обеспечения. Искрой для этих опасений стала UNIX, самая популярная операционная система своего времени. В течение многих лет UNIX лицензировалась на очень щедрых условиях, поскольку ее разработчику, компании AT&T Bell Labs, по закону было запрещено извлекать прибыль из своих исследовательских проектов, которые включали UNIX и язык C, согласно постановлению о согласии 1956 года. Ученые, исследователи и разработчики начали делиться своими изменениями и улучшениями, и вскоре UNIX стала лидером в функциональности операционных систем. Как только в 1983 году постановление о согласии было отменено, AT&T начала лицензировать систему на обычных коммерческих условиях, которые не позволяли делиться изменениями. UNIX разделилась на множество несовместимых "вкусов", и лицензиаты больше не могли сотрудничать.
Движение за свободное программное обеспечение и последовавшее за ним движение за открытый исходный код возникли в ответ на приватизацию UNIX и стремились предотвратить повторение закрытия инфраструктурного программного обеспечения. Хотя в центре движения стоял Linux, альтернатива UNIX, оно вскоре переросло в более широкое движение, основанное на философии, согласно которой все программное обеспечение должно быть свободным - свободным, как свобода слова, если не как свободное пиво. Одними из основных принципов этого движения были доступ к исходному коду и право на внесение улучшений и изменений и обмен ими. Эти принципы были воплощены в Стандартной общественной лицензии GNU (GPL), которая требует от распространителей двоичных файлов предоставлять соответствующие исходные тексты.
Со временем и с помощью интернет-бума и краха начала 2000-х годов лицензирование открытого кода становилось все более популярным. И хотя некоторые лицензии, например GPL, были новаторскими и сложными и вызывали некоторое недоумение из-за юридических проблем, они проложили путь к сотрудничеству между предприятиями. В период после 2000 года открытый исходный код - и сотрудничество, которое он обеспечивал, - был полностью принят всем технологическим сектором. Сегодня открытый исходный код является основой электронной коммерции, а предприятия регулярно сотрудничают в области программной инфраструктуры.
Разрыв в облаках и AGPL
Лицензии, подобные GPL, требуют совместного использования изменений. Но они налагают условия совместного использования исходного кода только при распространении двоичных файлов. Они позволяют создавать и использовать "частные копии" без требования делиться изменениями. Это хорошо работало для принуждения к обмену в те времена, когда большинство программ распространялось локально. Но с начала 2000-х годов программное обеспечение начало перемещаться в публичные облака. Больше не было необходимости распространять программное обеспечение - клиенты могли использовать программное обеспечение, не получая его локальной копии.
По мере того, как облачные услуги становились большим бизнесом, эта смена парадигмы создала противоречие между ожиданиями сообщества разработчиков открытого кода и таких компаний, как Amazon Web Services (AWS). У поставщиков облачных услуг не было никакого юридического принуждения делиться своими улучшениями. По иронии судьбы, это иногда называли "лазейкой Google", поскольку компания Google хорошо известна тем, что использует Linux для работы своей поисковой службы. Это было иронично, потому что Google - и многие другие ведущие поставщики облачных услуг, такие как IBM - уже внесли значительный вклад в сообщество разработчиков открытого кода, в частности Linux. Сообщество свободного программного обеспечения отреагировало на это, в частности, созданием альтернативной формы GPL под названием Affero GPL (AGPL). AGPL 3.0 почти идентична GPL 3.0, но с положением об удаленном сетевом взаимодействии, которое гласит: "Если вы изменяете Программу, ваша измененная версия должна на видном месте предлагать всем пользователям, взаимодействующим с ней удаленно через компьютерную сеть... возможность получить Соответствующий источник вашей версии, предоставляя доступ к Соответствующему источнику с сетевого сервера бесплатно, с помощью какого-либо стандартного или обычного средства облегчения копирования программ....". Эта новая лицензия была призвана заставить поставщиков облачных услуг делиться своими улучшениями исходного кода, подобно тому, как это успешно делала GPL для дистрибутивов Linux.
AGPL и двойное лицензирование
AGPL вызывала споры с момента ее первого выпуска. Во время процесса разработки GPL 3.0, завершившегося выпуском этой лицензии в 2007 году, одна фракция хотела изменить GPL на модель сетевого авторского права. Вместо этого сообщество решило сохранить "лазейку" в GPL 3.0, а несколько месяцев спустя выпустило AGPL в качестве альтернативы для ее закрытия. Но AGPL не получила широкого распространения. Более того, неоспоримым "убийственным приложением" для лицензии стала MongoDB, чрезвычайно популярный продукт распределенной базы данных. Хотя частным компаниям поначалу было трудно понять и принять AGPL, большинство пользователей никогда не меняли и не предлагали программы в качестве услуги, поэтому они смогли принять обоснованное решение использовать программы под AGPL.
MongoDB использовала AGPL как один из путей бизнес-модели "двойного лицензирования", в которой программное обеспечение было доступно под одной из двух лицензий на выбор лицензиата: AGPL или согласованной коммерческой лицензии на программное обеспечение. Те, кто не хотел соблюдать требования AGPL - или не хотел заниматься юридическим анализом, чтобы выяснить, могут ли они их соблюдать - выбирали путь коммерческой лицензии. Пионером этой бизнес-модели была компания MySQL, использовавшая вариант GPL. Но со временем AGPL стала предпочтительной лицензией для двойного лицензирования. MongoDB была весьма успешна с этой моделью лицензирования. AGPL подходила для двойного лицензирования, потому что это была самая сильная лицензия с авторским паром из общеупотребительных, а значит, наиболее полезная для коммерческих переговоров. Но составители AGPL критиковали такое использование лицензии, называя бизнес-модель токсичным вытряхиванием денег. Тем не менее, условий совместного использования исходного кода в лицензии оказалось недостаточно, чтобы воспрепятствовать коммерческому использованию в массовом масштабе таким образом, который ничего не дает сообществу разработчиков или пользователей.
Стрип-майнинг
Подобно тому, как переход к облакам "сломал" модель GPL, в 2010-х годах прогресс в облачных вычислениях начал оказывать давление на модель двойного лицензирования AGPL. На этот раз проблема была иной: сфера действия GPL, или AGPL, распространялась только на одну единственную исполняемую программу. Эта "особенность" была специально предусмотрена в GPL, исходя из теории, что авторская лицензия может диктовать условия только для одного произведения, охраняемого авторским правом. Поэтому GPL содержит требования о совместном использовании исходного кода для производных произведений, но не для коллективных произведений. Граница между этими двумя понятиями в законе настолько неясна, что находится в голове смотрящего, но по мере того, как GPL набирала популярность, в промышленности сложилась прочная практика определения одной программы как одного исполняемого процесса. Фонд свободного программного обеспечения уже давно изложил эти принципы в своем FAQ по GPL.
Однако по мере развития облачных услуг произошли две вещи.
- Во-первых, программная инженерия стала больше ориентироваться на развертывание облаков. Если раньше провайдерам облачных услуг приходилось улучшать или адаптировать программное обеспечение, чтобы запустить его в облачной среде, то благодаря достижениям в области программной инженерии существующее программное обеспечение с открытым исходным кодом стало более "plug and play" для провайдеров облачных услуг.
- Затем поставщики облачных услуг начали внедрять инновации за пределами основного исполняемого ПО. Они разработали дополнительное программное обеспечение для управления, мониторинга и развертывания программного обеспечения, и эти инновации привели бизнес к облачным услугам. Даже AGPL ничего не делала для того, чтобы заставить делиться этими улучшениями.
Таким образом, сложилась динамика, в которой коммерческие компании с открытым исходным кодом стали, по сути, забалансовыми научно-исследовательскими цехами крупных облачных провайдеров. Проблема была особенно острой для "платформенного программного обеспечения" или промежуточного программного обеспечения - программного обеспечения, которое располагается ниже приложений верхнего уровня и выше операционной системы в вычислительном стеке. Эта категория программного обеспечения необходима для современных вычислений и очень полезна для развертывания облаков.
В этот момент в деловом мире поднялось возмущение против использования облачными провайдерами программного обеспечения с открытым исходным кодом. В переломном манифесте 2018 года Салил Дешпанде из Bain Capital написал: "Чтобы было понятно, это не является незаконным. Но мы считаем это неправильным и не способствующим устойчивому развитию сообществ с открытым исходным кодом". Другой комментатор написал: "AWS наносит удар по ахиллесовой пяте открытого исходного кода: использование чужой работы и аренда доступа к ней". Проблема в том, что использование программного обеспечения таким образом разрешено всеми основными лицензиями open source.
Коммерческие компании с открытым исходным кодом и их инвесторы страдали от ограничения возможностей модели открытого исходного кода. Ни одна из имеющихся в их распоряжении лицензий - ни GPL, ни AGPL - не могла использовать закон об авторском праве для принуждения облачных провайдеров к совместному использованию. Более того, облачные провайдеры с огромными клиентскими базами имели "липкие" отношения - программное обеспечение можно было добавить одним нажатием виртуальной кнопки на таких платформах, как AWS, Azure или Google Cloud. Некоторые разработчики предлагали свои собственные облачные сервисы, но им было слишком сложно конкурировать с крупными провайдерами, которые использовали их программное обеспечение бесплатно. Даже если услуги разработчика были лучше, привлечение нового поставщика услуг требовало операционных издержек, в отличие от простой "галочки" для добавления программного пакета в существующий облачный аккаунт.
SSPL и лицензирование доступности исходных текстов
В 2018 году отрасль достигла переломного момента. Поскольку AWS продолжала набирать популярность в качестве хостинга программного обеспечения для платформ с открытым исходным кодом, разработчики начали принимать меры. Далее произошел быстрый эффект домино - смена лицензий.
Компании отреагировали на проблему стрип-майнинга, пойдя по двум разным дорогам: сверхсильная сетевая лицензия с авторским правом и ограниченная лицензия на доступный код. Ни одна из этих категорий не была четко определена до того времени. Обе они были предназначены для поддержки модели двойного лицензирования, подобной той, которая помогла создать MySQL и MongoDB.
Сверхсильный подход с авторским правом отстаивала компания MongoDB, выпустившая в 2018 году свою лицензию Server Side Public License или SSPL. SSPL была почти идентична AGPL, но расширяла сферу действия "Удаленного сетевого взаимодействия" AGPL и гласила:
13. Предоставление Программы в качестве услуги.
Если вы предоставляете функциональность Программы или модифицированной версии третьим лицам в качестве услуги, вы обязаны сделать Исходный код Услуги доступным для всех желающих посредством сетевой загрузки без взимания платы на условиях настоящей Лицензии. Предоставление функциональности Программы или модифицированной версии третьим лицам в качестве услуги включает, без ограничений, предоставление третьим лицам возможности взаимодействовать с функциональностью Программы или модифицированной версии удаленно через компьютерную сеть, предложение услуги, ценность которой полностью или в основном вытекает из ценности Программы или модифицированной версии, или предложение услуги, которая выполняет для пользователей основную цель Программы или модифицированной версии.
"Исходный код услуги" означает Соответствующий исходный код Программы или модифицированной версии, а также Соответствующий исходный код всех программ, которые вы используете для предоставления Программы или модифицированной версии в качестве услуги, включая, без ограничений, программное обеспечение для управления, пользовательские интерфейсы, интерфейсы прикладных программ, программное обеспечение для автоматизации, программное обеспечение для мониторинга, программное обеспечение для резервного копирования, программное обеспечение для хранения данных и программное обеспечение для хостинга, причем все это таким образом, что пользователь может запустить экземпляр услуги, используя Исходный код услуги, который вы предоставляете.
Эта лицензия была написана для того, чтобы создать решение проблемы стрип-майнинга с открытым исходным кодом. Ее требования к совместному использованию исходного кода гораздо шире, чем у AGPL. Широта этих требований была разработана для того, чтобы работать аналогично требованиям GPL для распределенного программного обеспечения. MongoDB продолжает работать по модели двойного лицензирования: ее программное обеспечение доступно по SSPL или на согласованных коммерческих условиях.
MongoDB представила SSPL на утверждение в Инициативу по открытым исходным кодам (OSI). После нескольких месяцев бурных споров лицензия была отозвана из процесса утверждения, но MongoDB продолжает использовать SSPL для варианта с открытым исходным кодом в своей модели двойного лицензирования. Обсуждение того, почему эта лицензия подходит или не подходит под определение открытого исходного кода, было сложным, но соответствие определению не было единственным критерием, и в итоге было неясно, будет ли лицензия с такой широтой требований к совместному использованию "гарантировать свободу программного обеспечения".
Другие пошли по другому пути. Некоторые компании приняли Commons Clause, инициатором которой был Салил Дешпанде, а другие разработали собственные лицензии, например, Redis, Confluent и CockroachDB, а также Elastic со своей Elastic License 1.0. В отличие от SSPL, эти лицензии никогда не были предназначены для того, чтобы соответствовать определению открытого исходного кода. Вместо этого они имели ограничение, специально направленное на использование стрип-майнинга.
Почему это отдельные пути? Это связано с тем, что называется Freedom Zero: "Свобода запускать программу так, как вы хотите, для любых целей".
Основной характеристикой лицензии открытого или свободного программного обеспечения является то, что она не содержит лицензионных ограничений или запретов.3 Сравните типичные лицензии коммерческого программного обеспечения. Лицензии для конечных пользователей, такие как те, которые вы нажимаете кнопку "принять" для личного пользования, позволяют только использовать программное обеспечение, но не изменять или распространять его. Корпоративные лицензии устанавливают ограничения на количество пользователей, серверов или физических объектов, которые могут использовать программное обеспечение, и требуют, чтобы компании проводили аудит его использования. Но лицензии на открытый исходный код не содержат таких ограничений. Поэтому, возможно, контринтуитивно, такие ограничения, как некоммерческое использование, по определению не относятся к открытому исходному коду - даже если исходный код предоставляется бесплатно.
Это означает, что любое лицензионное ограничение выводит лицензию за рамки категории открытого исходного кода.
Все лицензии, которые были выпущены в ходе волны перелицензирования, прошедшей в 2018 году и далее, имеют примерно одинаковые ограничения. Хотя у каждой из них свои условия, все они сосредоточены на том, чтобы позволить пользователям использовать программное обеспечение бесплатно, запрещая при этом использование программного обеспечения для предоставления конкурирующей хостинговой услуги.
Лицензия Elastic License 2.0
В начале 2021 года компания Elasticsearch проложила тропу, следуя по обоим этим путям. Он сделал свой набор программного обеспечения доступным по двум свободным вариантам: SSPL и новой Elastic License 2.0 (ELv2).
Новая лицензия Elastic 2.0 коротка (чуть больше одной страницы), написана простым языком и допускает почти все свободы лицензии с открытым исходным кодом. Получатели программного обеспечения могут свободно использовать, изменять и распространять его. Даже если вы никогда раньше не читали лицензию на программное обеспечение, с ней стоит ознакомиться.
В ней есть два ключевых ограничения:
- Вы не можете предоставлять программное обеспечение третьим лицам в качестве размещенной или управляемой услуги, когда услуга предоставляет пользователям доступ к любому существенному набору функций или возможностей программного обеспечения.
- Запрещается перемещать, изменять, отключать или обходить функциональность лицензионного ключа в программном обеспечении, а также удалять или скрывать любую функциональность программного обеспечения, защищенную лицензионным ключом.
Первое ограничение направлено на решение проблемы стрип-майнинга. Включая это ограничение, лицензия не разрешает такое поведение, и поэтому использование программного обеспечения в нарушение этого ограничения приведет к нарушению прав на программное обеспечение.
Второе ограничение призвано запретить взлом лицензионного ключа программного обеспечения. Такие ограничения давно распространены в лицензиях на программное обеспечение, но их использование в лицензиях на доступные исходные тексты только начинается. Эти положения позволяют разработчикам запускать платные сервисы, взаимодействующие с программным обеспечением, или сохранять некоторые компоненты программного обеспечения для платных функций.
Остальные условия лицензии очень просты и должны быть знакомы каждому, кто читал лицензии с открытым исходным кодом.
Почему двойное лицензирование?
Предлагая пользователям выбор между SSPL и Elastic License, Elasticsearch пошел необычным путем. Сегодня многие компании используют модель "открытого ядра", и действительно, Elasticsearch ранее также использовал эту модель. Разница между этими двумя моделями может быть тонкой. Модели с открытым ядром предлагают основное программное обеспечение под лицензией с открытым исходным кодом, чаще всего под разрешительной лицензией типа Apache 2.0. Затем они предлагают дополнительные функции - обычно те, которые полезно развернуть в масштабах предприятия - по ограниченной лицензии или только в качестве услуги. Но в своей новой лицензии Elasticsearch придерживается модели двойного лицензирования, когда одно и то же программное обеспечение доступно под двумя разными лицензиями. Пионером этой модели была компания MySQL, и обычно в качестве свободного лицензирования используется лицензия с авторским правом, например GPL, AGPL или SSPL. В последние годы популярность этой модели снизилась, в основном из-за противоречий между лицензированием открытого кода и облачными услугами.
Выбор Elastic был еще более необычным, поскольку он предлагал выбор из двух бесплатных лицензий: SSPL и Elastic License 2.0. Двойное лицензирование обычно предлагает только один бесплатный вариант. Сделав этот уникальный выбор, Elasticsearch подчеркнула свою гибкость, сделав программное обеспечение доступным бесплатно практически для всех пользователей.
Лицензия Elastic License 2.0 и современное состояние лицензирования
Elasticsearch перешел на новую модель лицензирования, чтобы оставаться максимально открытым, сохраняя при этом устойчивую бизнес-модель, справедливую как для пользователей, так и для разработчиков. При этом он повторяет цели других участников движения за доступность исходных кодов, и при создании лицензии он стремился к участию своих коллег.
Как указано в FAQ по изменению лицензии, ожидается, что изменение лицензии Elastic не затронет ни одного из ее клиентов и лишь немногих пользователей сообщества. Большинство пользователей создают приложения на базе программного обеспечения Elastic и не занимаются "предоставлением программного обеспечения третьим лицам в качестве размещенной или управляемой услуги".
Создание лучшей лицензии
Кроме того, выделив ресурсы на разработку Elastic License 2.0, компания Elastic стремилась продвинуться вперед в области разработки лицензий. В некотором смысле, лицензирование доступных исходных текстов существует так же давно, как и программное обеспечение. Фактически, лицензирование только двоичных файлов стало продуктом стандартизации платформ PC/Mac в 1980-х годах; до этого времени почти все программное обеспечение лицензировалось в формате исходного кода. Но форма и средства развертывания лицензий со временем сильно изменились.
Elastic License 2.0 является кульминацией этой тенденции. По форме она переняла некоторые из наиболее популярных особенностей лицензирования с открытым исходным кодом: простое и интуитивно понятное составление и лицензирование по шаблону. Положение о сохранении лицензионного ключа также легко позволяет поставщикам использовать лицензию для программного обеспечения, имеющего как бесплатные, так и платные функции.
Подобно разрозненным несовместимым версиям проприетарной UNIX десятилетия назад, лицензирование проприетарных систем представляет собой безумное одеяло из пользовательских условий и положений. Даже простая лицензия конечного пользователя для среднего потребительского программного продукта обычно настолько длинна и заумна, что непонятна большинству пользователей. Ходят шутки о том, что никто их не читает. Но большая часть этой сложности не нужна. Это один из уроков лицензирования открытого исходного кода, особенно разрешительных лицензий: простого набора правил дорожного движения должно быть достаточно, и чем более понятными они будут, тем больше вероятность того, что пользователи будут их соблюдать.
Elastic License 2.0 не только коротка, проста и понятна, она также доступна для использования другими в качестве шаблона. С тех пор, как начались дебаты против стрип-майнинга, растет спрос на простые, понятные лицензии с разумными ограничениями, развертываемые без особых усилий. Но у большинства небольших компаний, занимающихся разработкой программного обеспечения, нет ресурсов для составления собственных соглашений. Поэтому неудивительно, что многие начинающие разработчики программного обеспечения рассматривают такие лицензии, как Elastic 2.0 и Confluent Community License, как модели, которые они могут перенять.
Эта категория стала настолько популярной, что одна инициатива, Fair Code, создала для нее стандарт. Он гласит:
Fair-code - это не лицензия на программное обеспечение. Он описывает модель программного обеспечения, при которой программное обеспечение:
- в целом свободно для использования и может распространяться кем угодно
- имеет открытый доступ к исходному коду
- может быть расширено кем угодно в общественных и частных сообществах
- коммерчески ограничено его авторами
Хотя эта инициатива находится на очень ранней стадии, ясно, что индустрия начинает признавать необходимость парадигмы, справедливой как для пользователей, так и для разработчиков, и позволяющей коммерческим разработчикам устанавливать баланс между ними, причем более гибкий, чем модель с открытым исходным кодом. Один комментатор зашел так далеко, что назвал последние изменения в лицензировании "эрой после открытого исходного кода". Но на самом деле лицензирование доступных исходников обычно идет рука об руку с лицензированием открытых исходников, поскольку бизнес и модели лицензирования продолжают развиваться. Таким образом, эти две модели скорее дополняют друг друга, чем строго заменяют.
Существуют и другие варианты стандартизированного лицензирования. В 2020 году группа юристов начала проект PolyForm Project, чтобы разработать набор шаблонных лицензий на доступность исходного кода. Эти лицензии прошли экспертную оценку юристов, имеющих опыт лицензирования как открытых источников, так и проприетарных лицензий. Как и Creative Commons для лицензирования открытого контента, он предоставляет меню вариантов, таких как некоммерческие, только для оценки и антиконкурентные лицензии. Все они, как и Elastic License 2.0, являются бесплатными, предоставляют доступ к исходному коду и выдают необходимые патентные лицензии. PolyForm Perimeter и PolyForm Shield похожи на своих предшественников, таких как Confluent Community License, и Elastic 2.0 следует этой тенденции, расширяя доступные варианты.