На прошлой неделе проект Rocky Linux заявил, что нашел способ продолжить выпуск своего дистрибутива на основе RHEL. Теперь у нас есть некоторая информация о том, как это делается.
Многолетняя битва между Red Hat и различными организациями, клонирующими ее корпоративный дистрибутив Linux, приняла новый оборот. Если вы недавно следили за новостями, Red Hat выступила против перестроений RHEL, прекратив публикацию исходного кода своего корпоративного дистрибутива в своем репозитории Git. Вскоре после этого мы сообщили о том, что проект Rocky Linux объявил, что нашел обходной путь.
В сообщении блога, смело озаглавленном «Сохранение открытого исходного кода открытым», проект описывает два различных способа получения исходного кода RHEL без нарушения лицензионных соглашений Red Hat.
Один из них — через общедоступные образы контейнеров UBI Hat. Эти так называемые универсальные базовые образы представляют собой дискретные подмножества пользовательской земли RHEL, предназначенные для запуска в инструменте оркестрации контейнеров в качестве полностью совместимого контейнера для запуска приложений, специфичных для RHEL. Это все хорошо, но по своему определению контейнер не содержит ядра или драйверов операционной системы — это просто компоненты пользовательского пространства. Тем не менее, эти UBI доступны для всех, независимо от того, являются ли они клиентами RHEL или нет, поэтому они обеспечивают хороший старт.
Однако для создания полного автономного дистрибутива вам также необходимо получить исходный код ядра и драйверов. Этот исходный код доступен клиентам Red Hat — и в настоящее время только клиентам — в виде SRPM или исходных RPM. Почти во всех дистрибутивах Linux для каждого бинарного пакета, содержащего скомпилированную, готовую к запуску программу, также имеется соответствующий пакет исходного кода в репозиториях дистрибутива.
При обычном использовании они вам никогда не понадобятся, но природа программного обеспечения с открытым исходным кодом заключается в том, что вы можете скомпилировать его самостоятельно. Так, например, если вам нужна программа, которой нет в репозиториях вашего дистрибутива, вы можете получить исходный код этой программы и собрать ее самостоятельно. Проблема в том, что большинство нетривиальных программ включают в себя фрагменты множества других программ — в некоторых случаях их невероятное количество. Это проблема, на которую иногда указывают светила открытого источника; например, эссе Пола-Хеннинга Кампа «Поколение, потерянное на базаре», в котором указывалось, что даже в 2012 году для компиляции Firefox требовалось 122 внешних пакета. (Это было как раз в начале цикла быстрого выпуска Mozilla для Firefox.)
Вам может не понадобиться пересобирать части самого дистрибутива, но вам все равно нужен исходный код, чтобы создавать вещи, которые не часть дистрибутива. Таким образом, дистрибутивы включают в себя пакеты с исходным кодом, а это то, что нужно сборщикам RHEL.
Контейнеры RHEL UBI также включают ядро заголовки – исходный код, необходимый для компиляции модулей ядра. Если вы запустите дистрибутив Linux на виртуальной машине и установите гостевые дополнения гипервизора — например, для включения 3D-ускорения — вы, возможно, увидите предупреждающее сообщение о том, что вам необходимо установить исходный пакет заголовков ядра.
Другой обходной путь проекта Rocky использует виртуальные машины RHEL у поставщиков общедоступных облаков с оплатой по факту использования. Эти облачные виртуальные машины работают с полными экземплярами RHEL. Система непрерывной интеграции Rocky может запускать экземпляр RHEL в облаке, тем самым делая их клиентами Red Hat, по крайней мере на короткое время, используя этот экземпляр для получения всех новых или измененных исходных пакетов и размещения их содержимого на серверах Rocky Git, а затем выключается и удалить виртуальную машину… после чего право собственности и лицензионное соглашение прекращаются.
Во всяком случае, это теория. В сообщении блога говорится:
Похоже, проект уверен, что он полностью соответствует лицензии, хотя и отмечает:
Мы подозреваем, что такой подход может быть подлежит изменению довольно быстро. Хотя право собственности RHEL на экземпляр виртуальной машины действительно временное, облачные провайдеры фактически действуют как торговые посредники продуктов Red Hat. В нашей исходной статье мы отметили, что попытки использовать бесплатные учетные записи разработчиков Red Hat для доступа к исходному коду RHEL вполне могут привести к играм в кошки-мышки, когда учетные записи Hat, закрывающие, по ее мнению, нарушают авторские права. Мы подозреваем, что это в равной степени относится к учетным записям поставщиков облачных услуг: если они используются для получения источника способами, которые не нравятся Шляпе, нам кажется весьма вероятным, что Шляпа даст указание поставщикам облачных услуг закрыть эти учетные записи клиентов… или рискуете потерять права на перепродажу RHEL.
RHEL остается важным продуктом для многих крупных компаний, о чем свидетельствует тот факт, что Big Purple только что продлил срок службы поддержки для RHEL 7. Это должно было закончиться в следующем году, через десять лет после того, как оно было введен, но только что получил отсрочку исполнения: ELS до 2028 года… в комплекте с ядром версии 3.10.
Как мы сообщали ранее, многие люди в более широком сообществе пользователей Red Hat по-прежнему очень расстроены этим изменением политики исходного кода, и многие из них сообщают, что они изучают возможность перехода на другие дистрибутивы — в частности, на Debian, возможно, для его Жизненный цикл долгосрочной поддержки. Проблема в том, что корпоративные пользователи выбирают дистрибутивы не на основе технических достоинств, а скорее с точки зрения сторонней поддержки. Если вы используете оборудование, поставщик которого предлагает только драйверы для RHEL, или приложения, которые вам нужны, поддерживаются только в RHEL — или, что еще хуже, в конкретной (и, вполне возможно, уже устаревшей) версии RHEL — тогда вы не можете свободно перемещаться ни к чему другому.
Как мы недавно описали, Red Hat делает все возможное, чтобы обеспечить поддержку и безопасность старых ядер. Мы подозреваем, что отчасти это может быть причиной того, что они с удовольствием раздают образы контейнеров — потому что они не включают в себя это крайне важное, сверхстабильное ядро.
Никто не выбирает RHEL, потому что это современный уровень техники. Это не так. На самом деле, это настолько далеко от современного искусства, насколько это возможно, и в быстро меняющемся мире открытого исходного кода это очень желательный атрибут для определенного типа покупателей. Они выбирают его, потому что одна конкретная версия будет поддерживаться более десяти лет, и именно поэтому поставщики поддерживают RHEL, и часто только RHEL. Еще в 1990-х годах была кампания, сайт которой был назван redhatisnotlinux.org – именно потому, что в глазах очень многих людей и компаний Red Hat Linux действительно был единственным значимым дистрибутивом. Сегодня для крупного бизнеса его потомок часто остается. ®
