Licencias y restricciones de código abierto

1) Por qué OSS en iGaming y dónde están los riesgos

OSS acelera el desarrollo de la plataforma (frente de juego/respaldo, integraciones de pago, antifraude, analítica), pero los errores en las licencias conducen a la divulgación de código cerrado, bloqueos de lanzamientos y disputas con proveedores. Necesita: una política clara, un registro de dependencias (SBOM), procesos de auditoría y una correcta selección de licencias.

2) Mapa de licencias: tipos y significado

2. 1 Permissive (permisivo)

MIT, BSD-2/3-Clause, Apache-2. 0

El deber principal es mantener la notificación/redacción, en Apache-2. 0 también la concesión de patentes + «termination defensive».
Adecuado para: marcos de UI, utilidades, clientes SDK, bibliotecas de lógica/NTTR.

2. 2 Weak copyleft (copileft débil)

MPL-2. 0, LGPL-2. 1/3. 0

Requiere abrir los cambios dentro de la propia biblioteca/módulo, pero no todo el proyecto.
El enlace dinámico con LGPL es generalmente admisible cuando se cumplen las condiciones (posibilidad de reemplazar la versión por el usuario, notificación).

2. 3 Strong copyleft (copileft fuerte)

GPL-2. 0/3. 0, AGPL-3. 0

Al «conectar» con su código, surge la obligación de revelar un producto derivado bajo la misma licencia (las condiciones de «tivoization», «SaaS-cierre» cierran la AGPL).
Riesgo para los módulos cerrados del núcleo del juego, antifraude, pasarelas de pago.

3) Linchamiento y «producto derivado» (simplificado)

El enlace estático con la GPL → un alto riesgo de «infección».
El enlace dinámico con LGPL → es generalmente admisible si se cumplen las condiciones (sustituibilidad, notificación).
IPC/NAT/gRPC, procesos individuales → reduce el riesgo de producción, pero no cancela el análisis (AGPL interpreta «vía red» como «conexión»).
Los plugins/scripts → se evalúan por integración real (estabilidad API, carga en espacio de direcciones).

4) Patentes y reservas

Apache-2. 0 otorga licencias de patentes al autor → reduce el riesgo de reclamaciones de patentes.
GPL-3. 0/AGPL-3. 0 tienen posiciones anti-patente/anti-circunvención.
Si su módulo es patentable (matemáticas RNG, algoritmos antifraude), evite las licencias sin concesión de patentes o agregue pactos de patentes individuales a los acuerdos comerciales.

5) Responsabilidades de OSS: qué hacer exactamente

Guardar notificaciones/NOTICE (permisve).
Revelar las modificaciones de los componentes de copileft (MPL/LGPL/GPL) y el método de recomposición.
Proporcionar fuentes cuando los binarios se distribuyen bajo GPL/LGPL (y acceso de red bajo AGPL).
Especifique la licencia en la ventana «Acerca del programa «/página «Créditos OSS ».
Realizar un seguimiento de las licencias de tercera parte en las entregas (vendedores de juegos/SDK/móviles).

6) Política de OSS para la plataforma (mínimo recomendado)

1. Clasificación de licencias: verde (MIT/BSD/Apache/MPL), amarillo (LGPL bajo condiciones), rojo (GPL/AGPL/SSPL para partes cerradas).
2. Proceso de admisión de componentes: solicitud → evaluación legal y técnica → registro en SBOM → auditoría periódica.
3. Aislamiento de copileft: proceso/microservicio separado, límite gRPC/HTTP, sin enlace estático.
4. SBOM por ensamblaje: para cada versión prod/stage.
5. Notificaciones y fuentes: generación automática de NOTICE/THIRD-PARTY y publicación de fuentes donde sea necesario.
6. Contribuciones (upstream): CLA/DCO, verificación de la ausencia de secretos/patentes, acuerdo con Legal.
7. Seguridad: escaneo de vulnerabilidades, política de parches, prohibición de versiones vulnerables «pin» sin waiver.

7) OSS en zonas típicas de iGaming (mejor práctica)

Matemáticas del juego/RNG: evitar la GPL/AGPL; prefiera su propio código o biblioteca permisiva.
UI/cliente: Nat/Vue/Bandlers - permissive → ok, monitorear licencias y fuentes.
Pagos/CUS: SDK vendedores con estrictos ToS; no mezclar con copileft.
Observability/DevOps: Prometheus/Grafana/Elastic - Tener en cuenta sus licencias (parte de los módulos no OSS); leer «server side» condiciones.
Antifraude/puntuación: modelo/reglas - privativo; libretas de terceros - permissive/MIT/Apache.

8) Tabla de compatibilidad (en resumen)

9) Matriz de riesgo (RAG)

10) Hojas de cheques

Antes de agregar una biblioteca

• Licencia de biblioteca en la lista «verde/amarillo».
• Se ha verificado la compatibilidad del link (static/dynamic/IPC).
• Escribir en SBOM + versión + fuente.
• Se han generado notificaciones (LICENSE/NOTICE).

Antes de la versión

• SBOM por ensamblaje guardado (prod/stage).
• Se ha pasado el escaneo de vulnerabilidades; crítico - cerrado o waiver.
• Las fuentes/parches requeridos están listos para ser emitidos (si es necesario).
• «OSS Credits »/About página actualizada.

Para contribuciones (contributions)

• CLA/DCO firmado.
• Revisión de la ausencia de secretos/patentes.
• Los derechos de autor/copyright están correctamente establecidos.

11) Política OSS (fragmentos)

11. 1 Clasificación

green:  [MIT, BSD-2, BSD-3, Apache-2. 0, MPL-2. 0]
amber:  [LGPL-2. 1, LGPL-3. 0] # speaker only/IPC + conditions red: [GPL-2. 0, GPL-3. 0, AGPL-3. 0, SSPL] # disallow for closed modules

11. 2 Proceso de tolerancia

request → legal+tech review → approve/deny → SBOM entry → periodic audit

11. 3 Aislamiento del copileft

Servicio separado, interfaz de red, sin combinación de binarios, sin enlace estático.
Documentación de compilación y actualización de bibliotecas (LGPL/MPL).

12) Registros (plantillas YAML)

12. 1 SBOM / third-party

yaml component: "rng-core-utils"
version: "1. 8. 2"
license: "Apache-2. 0"
source: "maven:com. example:rng-core:1. 8. 2"
linkage: "dynamic"
notices: ["apache-2. 0. txt"]
security:
cvEs: []
owner: "Engineering"
approved_by: ["Legal","Security"]
approved_at: "2025-11-05"

12. 2 fuentes OSS a revelar

yaml package: "lgpl-math-lib"
our_version: "2. 3. 1-gamblehub"
license: "LGPL-3. 0"
modified_files: ["matrix. c","fft. c"]
public_src_url: "https://example. com/oss/lgpl-math-lib-2. 3. 1-src. zip"
build_instructions: "BUILD. md"

12. 3 Registro de depósitos (upstream)

yaml project: "open-telemetry"
pr: 4521 author: "dev_a"
cla: true dco: true files: ["exporter. go"]
review_legal: "2025-10-28"
status: "merged"

13) Seguridad y cumplimiento

SCA/SAST en CI, un auto-scan de nuevas dependencias.
Política de parches: vulnerabilidad P1 - ≤72 h, P2 - ≤14 días.
Caché de artefactos: almacene los originales LICENSE/NOTICE; compruebe la integridad (hashi).
Exportación/sanciones: no utilice componentes/espejos de países prohibidos; Lógica las comprobaciones.

14) Playbucks (scripts operativos)

P-OSS-01: GPL detectada en módulo cerrado

Inventario de conexiones → opción de aislamiento/reemplazo → opinión legal → liberación-fix → retro sobre el proceso.

P-OSS-02: Requerimiento de fuentes

Determinar el alcance de las obligaciones → preparar los archivos y NOTICE → transferir dentro del plazo legal → actualizar la documentación.

P-OSS-03: Vulnerabilidad crítica en dependencia

Backport/actualización → lanzamiento extraordinario → notificación a los interesados → el post-mar y reglas de pinning.

15) Mini preguntas frecuentes

¿Se puede utilizar LGPL? Sí, con enlace dinámico/IPC y cumplimiento de condiciones (sustituibilidad, notificaciones).
AGPL en un servidor sin distribución binaria - ¿seguro? No: AGPL requiere proporcionar fuentes a los usuarios que interactúan con el servicio a través de la red.
¿Se necesita una beca de patentes? Deseable para módulos con innovaciones algorítmicas; Apache-2. 0 preferible.
¿Basta con especificar el OSS en el sitio? No, cumpla con todos los requisitos: notificaciones, fuentes, instrucciones.

16) Conclusión

Trabajar con OSS es un proceso, no una verificación única: estándares de tolerancia, aislamiento de copileft, notificaciones automatizadas y SBOM completo para cada ensamblaje. Siguiendo este artículo, mantendrá la velocidad de desarrollo y evitará las trampas legales, desde el "network copyleft' hasta las reclamaciones por patentes.