Nadie paga por FOSS, podemos obligarlos a hacerlo

Artículo original ↗ Discusión en Hacker News ↗

Una propuesta para hacer que las empresas paguen por el software libre y de código abierto (FOSS) cobrando por el acceso a los registros de paquetes ha reavivado tensiones de larga data sobre cómo —o si— debería monetizarse el open source. Los comentaristas debaten estrategias de licencias, cambios de licencia tipo “bait and switch”, doble licencia y ventas en tiendas, y si los registros o los gobiernos podrían canalizar dinero de forma realista hacia los mantenedores. Muchos sostienen que introducir pagos obligatorios distorsionaría los incentivos, fragmentaría los ecosistemas y socavaría la ética de “gratis como en libertad”, mientras que otros ven algún modelo de pago como necesario para sostener la infraestructura crítica.

Percepciones de FOSS y el dinero

  • Muchos sostienen: si publicas código como FOSS, aceptas implícitamente que la mayoría de los usuarios, especialmente las empresas, no pagarán; no puedes quejarte después de exactamente lo que la licencia permitía.
  • Otros responden: el sistema es estructuralmente injusto; infraestructura crítica se mantiene gratis mientras otros la monetizan, así que cambiar los incentivos es legítimo.
  • Algunos enfatizan que escriben FOSS para beneficiar a otros, no para cobrar, y ven la posterior presión por monetizar como una corrupción de ese espíritu.

Modelos de licencia y “bait-and-switch”

  • Varios comentaristas critican proyectos que empiezan con licencias permisivas, ganan popularidad y contribuciones, y luego endurecen las licencias como una especie de “enshittification” o tirón de alfombra.
  • Otros responden que no es un bait-and-switch: las versiones antiguas siguen bajo la licencia antigua; nadie tiene derecho a que las versiones futuras sigan siendo permisivas.
  • Debate sobre “source-available”, OpenRAIL, AGPL y licencias restringidas para negocios:
    • A favor: se podrían haber evitado los problemas actuales si los proyectos hubieran empezado con términos de “paga si los ingresos > $5M”.
    • En contra: es difícil de auditar, invita a batallas legales y no logra tracción de adopción temprana.

Registros que cobran a las empresas para financiar a los mantenedores

  • Propuesta central: los registros de paquetes cobran a las organizaciones y distribuyen fondos a los mantenedores.
  • Quienes la apoyan la ven como una forma pragmática de monetizar la “oferta” (registros cómodos y predeterminados) mientras se mantiene el software libre.
  • Los críticos plantean problemas:
    • Los propios registros son empresas que pueden acaparar valor.
    • Enorme complejidad legal/fiscal para canalizar dinero de forma justa entre jurisdicciones y proyectos.
    • Riesgo de gamificación: spam de dependencias, forks triviales e incentivos perversos para PRs y el forkeo.
    • Podría fracturar la confianza o alejar a la gente de contribuir.

Financiación alternativa y modelos de negocio

  • Modelos mencionados: binarios de pago en tiendas de aplicaciones; doble licencia (AGPL + comercial); contratos de soporte; “soporte extendido” para versiones EOL; crowdfunding y promesas con umbral; SaaS construido sobre FOSS.
  • Algunos afirman que la mayoría de los intentos de “vender el FOSS en sí” fracasan; las vías sostenibles son el soporte, los servicios o cobrar como empleado/contratista.
  • Otros proponen arreglos más sistémicos: financiación pública (“Public Money, Public Code”), UBI o tratar las pilas de software como infraestructura financiada vía impuestos.

Filosofía: “gratis” y capitalismo

  • Aclaraciones repetidas: FOSS es “free as in speech”, no necesariamente “free as in beer”, aunque en la práctica suele ser ambas cosas.
  • Desacuerdo sobre el papel del capitalismo: algunos ven la presión por monetizar como tóxica; otros insisten en que el alquiler y la comida requieren dinero, así que los mecanismos de financiación son necesarios.
  • Preocupación de que añadir dinero cambie la dinámica de la comunidad y las motivaciones de formas impredecibles.

Debate sobre el estilo del artículo / uso de LLM

  • Varios comentaristas sospechan que el artículo está escrito por LLM o influido por LLM, citando ciertas formulaciones; otros discrepan fuertemente y lo encuentran coherente.
  • Algunos agradecen las advertencias tempranas sobre “AI slop”; otros encuentran esas quejas más molestas que cualquier problema de estilo.