Red Hat genera Polémica tras anunciar cambios de publicación de su RHEL y pone en hacke a la industria.

Red Hat genera Polémica tras anunciar cambios de publicación de su RHEL y pone en hacke a la industria.

Hace más de dos años, Red Hat presentó CentOS Stream como el punto focal para la colaboración en torno a Red Hat Enterprise Linux (RHEL). CentOS Stream acorta la ventana de retroalimentación entre los ingenieros de Red Hat y los socios, clientes y comunidades, al mismo tiempo que proporciona una visibilidad aún mayor de las próximas innovaciones en RHEL. Hemos visto un gran éxito en la comunidad de Grupos de Interés Especial (SIG) para ayudar a integrar y reunir nuevas tecnologías más rápido que nunca. El SIG automotriz es un excelente ejemplo de esto. Los socios de hardware también han aumentado para usar CentOS Stream para un soporte más rápido de nuevas tecnologías de hardware. Gracias a CentOS Stream, el desarrollo de Red Hat Enterprise Linux es más transparente y abierto que nunca.

A medida que la comunidad de CentOS Stream crece y el mundo del software empresarial aborda nuevas dinámicas, queremos agudizar nuestro enfoque en CentOS Stream como la columna vertebral de la innovación empresarial de Linux. Continuamos nuestra inversión y aumentamos nuestro compromiso con CentOS Stream. CentOS Stream ahora será el único repositorio para las versiones públicas de código fuente relacionadas con RHEL. Para los clientes y partners de Red Hat, el código fuente permanecerá disponible a través del Portal de clientes de Red Hat.

Para ser claros, este cambio no significa ningún cambio en el Proyecto CentOS, CentOS Stream o disponibilidad de fuente para CentOS Stream o CentOS SIGs.

Así lo había anunciado días atrás Mike McGrath, el vicepresidente de ingeniería de plataformas de RedHat.

¿Por qué hacer este cambio ahora?

Antes de CentOS Stream, Red Hat impulsó las fuentes públicas para RHEL a git.centos.org. Cuando el proyecto CentOS cambió para centrarse en CentOS Stream, mantuvimos estos repositorios a pesar de que CentOS Linux ya no se estaba construyendo aguas abajo de RHEL. El compromiso en torno a CentOS Stream, los niveles de inversión de ingeniería y las nuevas prioridades que estamos abordando para clientes y socios ahora hacen que el mantenimiento de repositorios separados y redundantes sea ineficiente. El último código fuente seguirá estando disponible a través de CentOS Stream.

A pesar de lo que se dice actualmente sobre Red Hat, hacemos que nuestro arduo trabajo sea fácilmente accesible para los no clientes. Red Hat utiliza y siempre utilizará un modelo de desarrollo de código abierto. Cuando encontramos un error o escribimos una característica, contribuimos con nuestro código aguas arriba. Esto beneficia a todos en la comunidad, no solo a Red Hat y a nuestros clientes.

No nos limitamos a tomar paquetes ascendentes y reconstruirlos. En Red Hat, miles de personas dedican su tiempo a escribir código para habilitar nuevas funciones, corregir errores, integrar diferentes paquetes y luego dar soporte a ese trabajo durante mucho tiempo, algo que nuestros clientes y socios necesitan.

Se trata de las horas y las noches que pasamos portando un parche al código que ahora tiene entre 5 y 10 años o más; En cualquier momento dado, admitimos 3-4 flujos de lanzamiento principales, mientras aplicamos parches y backports a todos. Además, cuando desarrollamos correcciones para problemas en RHEL, no solo las aplicamos a RHEL, sino que primero se aplican aguas arriba, a proyectos como Fedora, CentOS Stream o el propio proyecto del kernel, y luego las portamos. Mantener y dar soporte a un sistema operativo durante 10 años es una tarea hercúlea: hay un enorme valor en el trabajo que hacemos.

Siempre enviaremos nuestro código aguas arriba y cumpliremos con las licencias de código abierto que utilizan nuestros productos, que incluyen la GPL. Cuando digo que cumplimos con las diversas licencias de código abierto que se aplican a nuestro código, lo digo en serio. Me sorprendió y decepcionó la cantidad de personas que se equivocaron tanto sobre el software de código abierto y la GPL en particular, especialmente los observadores de la industria e incluso los veteranos que creo que deberían saber mejor. Los detalles, incluidas las licencias y los derechos de código abierto, son importantes, y estas son cosas que Red Hat ha ayudado no solo a formar, sino también a preservar y evolucionar.

Siento que gran parte de la ira de nuestra reciente decisión en torno a las fuentes posteriores proviene de aquellos que no quieren pagar por el tiempo, el esfuerzo y los recursos que se destinan a RHEL o aquellos que quieren volver a empaquetarlo para su propio beneficio. Esta demanda de código RHEL es falsa.

Tenemos que pagarle a la gente para que haga ese trabajo, esos colaboradores apasionados que trabajan esas largas horas y noches que creen en los valores del código abierto. Simplemente reempaquetar el código que producen estas personas y revenderlo tal cual, sin valor agregado, hace que la producción de este software de código abierto sea insostenible. Eso incluye el trabajo crítico de backport y las características y tecnologías futuras en desarrollo aguas arriba. Si ese trabajo se vuelve insostenible, se detendrá, y eso no es bueno para nadie.

Quiero mencionar específicamente los reconstructores, diferentes de las distribuciones que podrían, por ejemplo, agregar una nueva arquitectura o compilar flag (lo apoyamos completamente en la expansión de las capacidades de Linux en lugar de imitarlas).

Hubo un tiempo, no hace mucho tiempo, en que Red Hat encontró valor en el trabajo realizado por reconstructores como CentOS. Empujamos nuestros SRPM para git.centos.org en un paquete ordenado que los hizo fáciles de reconstruir; Incluso les quitamos la marca. Más recientemente, hemos determinado que no hay valor en tener un reconstructor aguas abajo.

La posición generalmente aceptada de que estas reconstrucciones gratuitas son solo embudos que producen expertos en RHEL y se convierten en ventas simplemente no es la realidad. Ojalá viviéramos en ese mundo, pero no es así como realmente se desarrolla. En cambio, hemos encontrado un grupo de usuarios, muchos de los cuales pertenecen a organizaciones de TI grandes o muy grandes, que desean la estabilidad, el ciclo de vida y el ecosistema de hardware de RHEL sin tener que soportar realmente a los mantenedores, ingenieros, escritores y muchos más roles que lo crean. Estos usuarios también han decidido no utilizar una de las muchas otras distribuciones de Linux.

En un ecosistema de código abierto saludable, la competencia y la innovación van de la mano. Red Hat, SUSE, Canonical, AWS y Microsoft crean distribuciones de Linux con esfuerzos asociados de desarrollo de ecosistemas y marcas. Todas estas variantes utilizan y contribuyen con el código fuente de Linux, pero ninguna afirma ser «totalmente compatible» con las demás.

En última instancia, no encontramos valor en una reconstrucción de RHEL y no tenemos ninguna obligación de facilitar las cosas a los reconstructores; Este es nuestro llamado. Eso me lleva a CentOS Stream, del cual hay una inmensa confusión. Reconozco que este es un cambio en una tradición de larga data en la que fuimos más allá, y un cambio como este puede causar cierta confusión. Esa confusión se manifestó como acusaciones sobre nosotros yendo a código cerrado y sobre supuestas violaciones de GPL. Hay CentOS Stream el entregable binario y CentOS Stream el repositorio de origen. El código fuente de gitlab de CentOS Stream es donde construimos versiones de RHEL, al aire libre para que todos las vean. Llamar a RHEL «código cerrado» es categóricamente falso e inexacto. CentOS Stream se mueve más rápido que RHEL, por lo que puede que no esté en HEAD, pero el código está ahí. Si no puede encontrarlo, es un error, háganoslo saber.

También ofrecemos suscripciones gratuitas a Red Hat Developer y Red Hat Enterprise Linux (RHEL) para infraestructura de código abierto. La suscripción de desarrollador proporciona RHEL sin costo a los desarrolladores y permite el uso de hasta 16 sistemas, nuevamente, sin costo. Esto puede ser utilizado por individuos para su propio trabajo y por clientes de RHEL para el trabajo de sus empleados. RHEL for Open Source Infrastructure está destinado a dar a los proyectos de código abierto (estén o no afiliados a Red Hat de alguna manera) acceso a RHEL sin costo para sus necesidades de infraestructura y desarrollo.

Finalmente, me gustaría dirigirme a todas las empresas de código abierto, ya sea que su código esté abierto hoy o que esté considerando pasar a un modelo de código abierto. Desde cualquier punto de vista, Red Hat lo ha «logrado» y espero que muchas empresas de código abierto puedan tener éxito como nosotros. Puede decidir por sí mismo si las reconstrucciones posteriores son valiosas para usted y es su decisión hacerlo fácil o no.

Simplemente reconstruir el código, sin agregar valor o cambiarlo de ninguna manera, representa una amenaza real para las empresas de código abierto en todas partes. Esta es una amenaza real para el código abierto, y una que tiene el potencial de revertir el código abierto en una actividad solo para aficionados y piratas informáticos.

No queremos eso y sé que los miembros de nuestra comunidad, clientes y socios no quieren eso. La innovación ocurre en el upstream. Construir sobre los hombros de otros es de lo que se trata el código abierto. Sigamos impulsando la innovación, apoyémonos unos a otros y sigamos avanzando.

Los clientes y partners de Red Hat pueden acceder a las fuentes de RHEL a través de los portales de clientes y partners, de acuerdo con su acuerdo de suscripción.

Dijo Mike McGrath argumentando la decisión de Red Hat.

Hablemos ahora sobre la respuesta del equipo de CloudLinux:

CloudLinux reafirma su compromiso de ser patrocinador de la AlmaLinux OS Foundation. A pesar de los recientes anuncios de Red Hat, CloudLinux mantiene su apoyo a AlmaLinux y su intención de respaldar su desarrollo. CloudLinux OS 8 y 9 se basan en el código fuente de Red Hat Enterprise Linux (RHEL) y han sido reconocidos por su compatibilidad con RHEL. CloudLinux planea continuar ofreciendo soporte y actualizaciones de seguridad para CloudLinux OS 8 y 9 durante un ciclo de vida completo de 10 años, para atender las necesidades de los proveedores de servicios.

Además, CloudLinux tiene planes de lanzar una versión gratuita de CloudLinux OS 8 y 9 que recibirá actualizaciones de seguridad durante su ciclo de vida de 10 años. Esta versión gratuita será una alternativa local a AlmaLinux/RockyLinux para aquellos clientes que tengan preocupaciones específicas sobre el uso de AlmaLinux o RockyLinux. Sin embargo, es importante tener en cuenta que esta versión gratuita no incluirá todas las características adicionales del sistema operativo CloudLinux, como LVE, CageFS, AccelerateWP y HardenedPHP.

CloudLinux también se compromete a proporcionar una fácil migración y ruta de actualización desde AlmaLinux/RockyLinux/RHEL, y trabajará en estrecha colaboración con los proveedores de paneles de control para garantizar la compatibilidad total.

En resumen, CloudLinux sigue respaldando a AlmaLinux y planea ofrecer soporte continuo para CloudLinux OS 8 y 9, al tiempo que proporciona una versión gratuita como alternativa a AlmaLinux/RockyLinux para aquellos que lo prefieran. Si utilizas CentOS, te animamos a migrar a AlmaLinux/RockyLinux o bien CloudLinux, de momento cuentan con un soporte de 10 años según lo anunciado. En SNHC ya hemos iniciado una migración de sistemas basados en el RHEL 7 a sistemas basados en RHEL 8 y 9 de manera escalonada, teniendo en cuenta la disponibilidad de soporte y vida útil anunciada para estas, en particular de AlmaLinux y CloudLinux, ya que tal como lo anunciábamos hace semanas atrás, en poco menos de un año llegará el fin de vida del RHEL 7 (30 de junio de 2024) bajo el cual corren sistemas como CentOS7, Cloudlinux7, Cloudlinux Shared Pro 7.

En conclusión, estamos listos para estos cambios y trabajando conjuntamente el equipo de CloudLinux, AlmaLinux y de cPanel, como DirectAdmin para ir realizando estos cambios en los sistemas operativos y de paneles de control, manteniendo una compatibilidad con aplicativos de alta demanda, si utiliza servicios como Hosting WordPress, Hosting Reseller, o servicios bajo acuerdos especiales de administración sobre los mismos, realizaremos este cambio generando el menor traumatismo posible para nuestros usuarios. En el caso de servicios no gestionados o semigestionados como: VPS, Dedicados o servicios de Colocación, por favor, valide con su ejecutivo de cuenta sus opciones y solicite una cotización sin compromisos si así lo desea o requiere.

En desarrollo….

Entrada anterior Simplifica y potencia tu presencia en línea con nuestro nuevo servicio: ¡WordPress Gestionado!
Entrada siguiente Una Comparativa Detallada entre los Paneles de Control de Hosting: Webuzo, cPanel, DirectAdmin y Plesk