Bruce Perens, uno de los autores de la definición de Código Abierto y cofundador de la Open Source Initiative, presentó el primer borrador de una nueva licencia llamada "Post-Open Zero-Cost", destinada a abordar los problemas acumulados relacionados con la interacción entre los desarrolladores de software de código abierto y las empresas comerciales en el contexto de obtener un retorno justo del uso comercial del código. La licencia refleja la posibilidad de imponer condiciones adicionales para el uso comercial, por ejemplo, a cambio de los beneficios obtenidos del uso del software de código abierto, se les ofrece a las empresas compensar ya sea participando en el desarrollo o pagando regalías que se distribuirán entre los desarrolladores directos.
La diferencia clave de la licencia Post-Open respecto a las licencias abiertas existentes, como la GPL, es la introducción de un componente contractual, disponible para la rescisión en caso de violación de las condiciones de la licencia. Se prevén dos tipos de acuerdos contractuales: gratuito y de pago. El contrato de pago prevé la posibilidad de celebrar un acuerdo para otorgar derechos adicionales y se aplica a la distribución comercial de productos o a modificaciones sin divulgación pública.
La licencia también define la organización "POST-OPEN ADMINISTRATION", que actúa en nombre de los licenciantes, siendo su representante legal, defendiendo sus derechos cuando sea necesario y gestionando la distribución de los fondos obtenidos teniendo en cuenta la contribución al desarrollo. La estructura de la organización, que debe utilizar procesos transparentes en sus operaciones, así como mecanismos financieros, aún no ha sido definida y es objeto de futuras discusiones.
Entre las situaciones que conducen a la terminación del componente contractual se mencionan: violaciones de los términos de la licencia; presentación de reclamaciones por infracción de patentes; imposición de condiciones adicionales (por ejemplo, la inclusión de sanciones en el contrato con clientes en caso de divulgar información sobre la corrección de vulnerabilidades); modificaciones que caen bajo la ley de control de exportaciones (por ejemplo, para objetivos militares y creación de armas); ocultación de información sobre vulnerabilidades o dificultad en su divulgación; uso de código para el entrenamiento de modelos de aprendizaje automático, distribuidos bajo otras condiciones. Las relaciones contractuales no se rompen de inmediato, sino solo 60 días después de informar sobre la infracción. Si las infracciones se corrigen dentro de los 60 días, los derechos otorgados permanecen vigentes.
Entre los problemas de GPL que se intentan resolver en la nueva licencia, se destaca la orientación de la GPL únicamente hacia la concesión de derechos, sin posibilidad de revocar derechos a otros. Esta característica permite a las empresas eludir los requisitos de la licencia GPL relacionados con la concesión de acceso ilimitado al código fuente. En particular, se utilizan lagunas para restringir la disponibilidad del código, vinculando condiciones contractuales adicionales al usuario final que limitan la redistribución del código abierto que subyace al producto.
Por ejemplo, al comprar un paquete de RHEL, el cliente firma un contrato con la empresa Red Hat para soporte y actualización, en el que se limita la redistribución de datos y se menciona el derecho a rescindir el contrato si hay discrepancias entre las copias de RHEL instaladas y las compradas, lo que obliga a elegir entre la libertad de manejar el software y mantener el estatus de cliente de Red Hat. Los parches suministrados para RHEL que corrigen vulnerabilidades se aplican al código GPL y, de acuerdo con la licencia, el usuario tiene derecho a distribuirlos, pero esto puede ser interpretado como una violación del contrato con Red Hat y dar lugar a la suspensión de los servicios de la empresa.
Anteriormente, cuando los cambios se publicaban en el repositorio de CentOS, la comunidad hacía la vista gorda a este tipo de prácticas, pero tras el cambio en la política de acceso a los códigos fuente de los paquetes de RHEL, surgió la necesidad de revisar los mecanismos de interacción entre los desarrolladores de proyectos abiertos y las empresas que utilizan su trabajo.
Fuente: opennet.ru
