Nuevo capítulo en el último drama generado por Red Hat, aunque muy probablemente no será el último, y es que el cambio en la política de distribución del código de Red Hat Enterprise Linux (RHEL) va más allá de lo expuesto y no en el buen sentido.

Recapitulando, Red Hat ha decidido terminar con el repositorio de CentOS a través del cual se redistribuía el código fuente de RHEL con compatibilidad a nivel binario, el utilizado por todos los clones del sistema desde siempre. Un movimiento inesperado, pero coherente, dado que Red Hat acabó con la existencia de CentOS en su forma tradicional y nada la obliga a mantener las cosas como estaban, por más que pueda incomodar o dificultar a los clones su actividad.

A este respecto cabe recordar que Red Hat transformó CentOS en Centos Stream (1, 2), esto eso, terminó con la existencia del clon a nivel binario de RHEL y como testigo dejó una distribución de actualización continua cuyo código sigue siendo accesible de manera pública, pero no se corresponde con el de RHEL y, por lo tanto, no permite generar clones cien por cien compatibles con esta, como era CentOS y como son Oracle Linux, AlmaLinux o Rocky Linux, entre otros.

Así, Red Hat deja como única puerta de acceso al código de RHEL el disponer de una suscripción de este, motivo por el cual se asumía que esto dificultaba el trabajo de proyectos como los mencionados, puesto que no solo deberían pasar por caja, sino que además tendrían que asumir la labor adicional que supone el debranding de todos los paquetes que componen la distribución, ya que redistribuir una compilación modificada con la marca de Red Hat es ilegal.

Sin embargo, había una trampa en el proceder de Red Hat y no una cualquiera, sino una que nadie hubiese esperado encontrar en todo un estandarte del código abierto como es la compañía del sombrero rojo: la prohibición de redistribución de código GPL bajo determinadas circunstancias, cláusula de aceptación mediante. Según se indica en el punto 1.2 (g) del documento Software Subscriptions and Support Subscriptions (PDF):

Unauthorized Use of Subscription Services. Any unauthorized use of the Subscription Services is a material breach of the Agreement. Unauthorized use of the Subscription Services includes: (a) only purchasing or renewing Subscription Services based on some of the total number of Units, (b) splitting or applying one Software Subscription to two or more Units, (c) providing Subscription Services (in whole or in part) to third parties, (d) using Subscription Services in connection with any redistribution of Software or (e) using Subscription Services to support or maintain any non-Red Hat Software products without purchasing Subscription Services for each such instance (collectively, “Unauthorized Subscription Services Uses”).

Las partes destacadas en negrita son las importantes. Dicen:

Uso no autorizado de los servicios de suscripción.

(d) usar Servicios de Suscripción en relación con cualquier redistribución de Software o (e) usar Servicios de Suscripción para respaldar o mantener cualquier producto de software que no sea de Red Hat sin comprar Servicios de suscripción para cada instancia (colectivamente, “Usos no autorizados de los servicios de suscripción”).

En otras palabras, la suscripción de RHEL otorga al usuario el acceso al código fuente del sistema, pero el contrato que ha firmado previamente le impide hacer uso de una de las libertades que otorga la licencia GPL por la que se rigen la mayoría de componentes de la distribución, impidiendo su redistribución con los motivos señalados. La pregunta es qué pesa más a nivel legal, el contrato que se firma o la licencia del software, dado que la segunda imposición invalida a la primera. Y lo cierto es que ni siquiera los expertos lo tienen claro, aunque las consideraciones previas que transmiten no son optimistas.

A raíz de esta situación Mike McGrath, vicepresidente de Core Platforms en Red Hat publicó un artículo defendiendo la actuación de la compañía en el que explica, por ejemplo, el esfuerzo que supone mantener una infraestructura de software como la de Red Hat, o el compromiso de colaboración que tienen con todos los proyectos de software que utilizan, con los que contribuyen enviando sus parches y, en este caso, respetando estrictamente la licencia la GPL. También realiza algunas declaraciones delicadas cuando menos, por las respuestas que pueden suscitar.

Así, McGrath comenta: «Siento que gran parte de la ira por nuestra reciente decisión sobre el código downstream proviene de aquellos que no quieren pagar por el tiempo, el esfuerzo y los recursos que destinamos a RHEL, de aquellos que quieren reempaquetarlo para su propio beneficio. Esta demanda del código de RHEL es deshonesta». Uno de sus argumentos señala que «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 marcas asociadas y esfuerzos de desarrollo del ecosistema. Todas estas variantes utilizan y aportan código fuente de Linux, pero ninguna afirma ser «totalmente compatible» con las demás».

McGrath apunta también al plan gratuito, el cual permite el uso de Red Hat sin restricciones para hasta 16 máquinas en producción. Sin embargo, concluye su exposición con un argumento controvertido: «Simplemente recompilar 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 tiene el potencial de volver a convertir el código abierto en una actividad solo para aficionados y piratas informáticos».

La comunidad, por supuesto, no ha tardado en contestar al movimiento y postura de Red Hat, y por comunidad entendemos en este caso a muchas partes bien diferenciadas entre sí. Por ejemplo, AlmaLinux reafirma su compromiso por encontrar una solución al problema, tanto a nivel técnico como en lo que respecta a la colaboración con Red Hat, al tiempo que recuerda que hacen mucho más que «recompilar código sin agregar valor añadido»; Rocky Linux afea el comportamiento de Red Hat y sugiere las formas en que están pensando en saltarse el bloqueo.

No hay solución amable para este problema, parece. En MuyLinux hemos hablado en multitud de ocasiones del desastre que supone la división de esfuerzos en mil y un proyectos cuya aportación al ecosistema tiende a ser nula; esas decenas de distribuciones, calcadas unas de las otras -ocurre también con las aplicaciones, en menor medida- cuyo impacto es más negativo que positivo. Hemos hablado mucho de la distinción entre diversidad y fragmentación, se podría resumir… y lo que en el ámbito comunitario genera contrariedades para el propio ecosistema, en el corporativo puede afectar a los beneficios.

Es por ello, quizás, que Red Hat tuvo la torpeza de acabar con CentOS como lo hizo, esperando que no hubiese reacción. Y es por ello, y de esto ya no hay ninguna duda, que Red Hat ha decidido restringir el acceso y uso del código de RHEL como lo ha hecho. La cuestión de fondo, el eje sobre el que pivota todo proyecto basado en software de código abierto, es que uno no puede decidir por su cuenta cuándo respeta una licencia, o en qué grado lo hace. El código abierto favorece la innovación y la colaboración, pero también el aprovechamiento en perjuicio de quien pone el esfuerzo.

En este sentido, Red Hat es una de las compañías que más contribuye con el código abierto del que se nutre el ecosistema de Linux, así como es una de las compañías más grandes del sector. Pero ninguno de estos dos hechos es casual: Red Hat contribuye en la medida en que su envergadura lo permite y que su dependencia precisa, algo que nunca hubiera sido posible si no se hubiesen aprovechado de la prerrogativa que proporciona una licencia como la GPL para construir y mantener su sistema a lo largo de toda su trayectoria.

Imagen: Unsplash

La entrada Red Hat pone a la GPL en una posición complicada y los clones barajan opciones es original de MuyLinux