FSL: Una licencia para el bazar, no para la catedral
Una nueva “Functional Source License” (FSL) para software SaaS busca bloquear a competidores comerciales durante dos años mientras promete un cambio automático posterior a una licencia abierta permisiva. Sus defensores la ven como una forma pragmática de financiar el desarrollo y limitar el “free-riding” de grandes proveedores cloud, sin dejar de ofrecer acceso al código y una salida a largo plazo; los críticos sostienen que socava principios básicos del software libre, complica las contribuciones y los forks, y difumina la línea entre open source y los modelos source-available. El intercambio también revela preocupaciones legales y de confianza en torno a los cambios de licencia con plazos y destaca la tensión más amplia entre sostener negocios SaaS comerciales y preservar la libertad irrestricta del software.
Alcance y naturaleza de FSL
- FSL se considera una licencia “source-available, eventually-open”: el código puede usarse ahora con una restricción de no competencia, y pasa automáticamente a Apache 2.0 después de dos años.
- La restricción apunta principalmente a ofertas SaaS competidoras; se permite el autoalojamiento no comercial y no competidor.
- Algunos la describen como la “menos mala” para SaaS: mejor que algo totalmente propietario o BUSL, pero claramente no FOSS durante el período de exclusividad.
Forks, “bazar vs catedral” y dinámica de contribución
- Los críticos sostienen que FSL es estructuralmente de tipo catedral: una parte especial controla el uso comercial; los forks significativos deben ir dos años por detrás y seguir el ritmo del equipo original.
- Preocupa que las correcciones de seguridad y las funciones en el fork “comunitario” estén siempre dos años atrasadas, lo que dificulta la competencia real o la seguridad.
- Otros responden que los forks siguen siendo posibles, especialmente si el proyecto principal se estanca, y señalan que muchos proyectos abiertos ya requieren CLA o concesiones especiales para contribuyentes.
Preocupaciones legales y prácticas
- Un hilo cuestiona si la relicencia con retraso temporal y la terminación automática son válidas bajo algunas leyes de la UE; otros responden que las concesiones por fases temporales son comunes y que los términos se conocen de antemano.
- Se plantean casos límite: qué ocurre si la referencia a la licencia futura (por ejemplo, Apache) “desaparece”; las respuestas sugieren que los tribunales probablemente mantendrían la intención y que los forks existentes conservan la licencia que ya tienen.
- La ambigüedad sobre qué cuenta como “uso competidor” y “exponer APIs” hace que algunos recelen del riesgo legal.
Modelo de negocio y debate sobre el “free rider”
- Los defensores presentan FSL como una protección frente a proveedores cloud o revendedores que reempaquetan el producto como servicio alojado sin financiar su desarrollo.
- Los críticos dicen que el software no “se desgasta” como los bienes comunes físicos; el “free-riding” dañino es realmente un problema de modelo de negocio, no de licencia.
- Algunos sostienen que el open source renuncia por naturaleza al monopolio de la explotación comercial; si eso es inaceptable, el proyecto debería ser abiertamente propietario.
Relación con las definiciones de FOSS y el mensaje
- Muchos enfatizan que FSL no es Free/Open Source según las definiciones de FSF/OSI debido a restricciones de campo de uso (no competencia).
- Hay una fuerte reacción en contra del marketing que llama al producto “open source” o “single-source open source”; varios consideran que eso enturbia la terminología establecida.
- Representantes de Sentry reconocen que FSL no es Open Source hasta que expira, la describen como alineada con “open source ideals” y dicen que parte de la redacción pública se revisará.
Alternativas e impacto en el ecosistema
- Algunos sugieren AGPL/GPL como soluciones más simples y establecidas; las contraargumentaciones subrayan el estigma de GPL en entornos comerciales, la incompatibilidad con tiendas de apps y el riesgo percibido de tipo “viral”.
- Varios comentaristas dicen que no contribuirían bajo FSL, viendo inaceptable un retraso de dos años sobre la libertad; a otros les importa principalmente tener el código fuente para depurar y autoalojar, no el estatus formal de FOSS.