Licenças e restrições do Open Nature
1) Porquê OSS no iGaming e onde estão os riscos
A OSS acelera o desenvolvimento de uma plataforma (frente/back, integração de pagamentos, antifrode, analista), mas erros de licenciamento levam à divulgação de código fechado, bloqueios de lançamentos e disputas com os provedores. Necessita de políticas claras, registro de dependências (SBOM), processos de auditoria e escolha correta de licenças.
2) Mapa de licenças: tipos e sentido
2. 1 Permissive (permissões)
MIT, BSD-2/3-Clause, Apache-2. 0
A principal obrigação é salvar a notificação/copiar, em Apache-2. 0 e a bolsa de patentes + «definível termination».
Adequado para quadros UI, utilitários, clientes SDK, bibliotecas de loging/NTTR.
2. 2 Weak copyleft (fraco copileft)
MPL-2. 0, LGPL-2. 1/3. 0
Exigem a abertura de alterações dentro da própria biblioteca/pod, mas não de todo o projeto.
O linking dinâmico com o LGPL é normalmente permitido quando as condições são cumpridas (substituição da versão pelo usuário, notificação).
2. 3 Strong copyleft (copileft forte)
GPL-2. 0/3. 0, AGPL-3. 0
Quando você se conecta com o seu código, a obrigação de revelar o derivado sob a mesma licença (termos «tivoization», «SaaS-circuito» fecha o AGPL).
Risco para módulos fechados núcleo de jogo, antifrode, passarelas de pagamento.
3) Linkagem e «derivado» (simplificado)
Link estático com GPL → alto risco de «infecção».
Linkagem dinâmica com LGPL é normalmente permitida se as condições (substituível, notificações) forem cumpridas.
IPC/REST/gRPC, os processos individuais → reduzem o risco de produção, mas não anulam a análise (AGPL interpreta «através da rede» como «conexão»).
Plugins/script → são avaliados por integração real (API, download no espaço de endereços).
4) Patentes e reservas
Apache-2. 0 dá licenciamento de patentes do autor → reduz o risco de reclamações de patentes.
GPL-3. 0/AGPL-3. 0 têm posições anti-patentes/anti-circular.
Se o seu módulo for patenteado (matemática RNG, algoritmos antifrod), evite licenças sem bolsa de patentes ou adicione covenantes individuais a acordos comerciais.
5) Responsabilidades de OSS: exatamente o que fazer
Salvar notificações/NOTICE (permisisive).
Exponha as modificações de componentes de copileft (MPL/LANGPL/GPL) e a forma de cruzar.
Fornecer fontes para a distribuição de binários sob GPL/LANGPL (e acesso à rede sob AGPL).
Especifique uma licença na caixa Sobre/página Credits OSS.
Monitorar licenças third-party em entregas (jogos vendedores/SDK/bilds móveis).
6) Política OSS para plataforma (mínimo recomendado)
1. Classificação de licenças: verde (MIT/BSD/Apache/MPL), amarelo (LANGPL em condições), vermelho (GPL/AGPL/SSPL para partes fechadas).
2. Processo de tolerância de componente: solicitação de avaliação jurídica e técnica gravação no SBOM auditoria periódica.
3. Isolamento de copileft: processo/microsserviço separado, limite gRPC/HTTP, sem linkagem estática.
4. SBOM por montagem: para cada lançamento prod/estágio.
5. Notificações e fontes: geração automática de NOTICE/THIRD-PARTY e publicação de origem onde for necessário.
6. Depósitos (upstream): CLA/DCO, verificação de falta de segredos/patentes, concordância com o Legal.
7. Segurança: scan de vulnerabilidade, política de patches, proibição de versões vulneráveis «pin» sem waiver.
7) OSS em zonas típicas de iGaming (best pratice)
Matemática de jogo/RNG: evitar GPL/AGPL; Prefira o seu próprio código ou biblioteca permissiva.
UI/cliente: React/Vue/Bandlers - permissive →, monitorar licenças e fontes.
Pagamentos/CUS: SDK vendedores com ToS rigorosos; não misturar com copileft.
Portatility/DevOps: Prometheus/Grafana/Elastic - considerar suas licenças (parte dos módulos não-OSS); ler «server side» condições.
Antifrod/mapeamento: modelo/regras - properioso; libes de terceiros - permissive/MIT/Apache.
8) Tabela de compatibilidade (resumo)
9) Matriz de Risco (RAP)
10) Folhas de cheque
Antes de adicionar biblioteca
- Licença da biblioteca na lista verde/amarelo.
- Verificou-se a compatibilidade do linker (static/dinamic/IPC).
- Entrada em SBOM + versão + fonte.
- Notificações geradas (LICENSE/NOTICE).
Antes do lançamento
- O SBOM para montagem foi salvo (prod/estágio).
- As vulnerabilidades foram ultrapassadas; crítico - fechado ou waiver.
- Os fontes/patches exigidos estão prontos para serem emitidos (se necessário).
- «OSS Credits »/About página atualizada.
Para depósitos (contribuições)
- CLA/DCO está assinado.
- Review a falta de segredos/patentes.
- Copyright/copyright estão corretamente colocados.
11) Política OSS (fatias)
11. 1 Classificação
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 modules11. 2 Processo de tolerância
request → legal+tech review → approve/deny → SBOM entry → periodic audit11. 3 Isolamento do copileft
Serviço separado, interface de rede, sem fusão de binários, sem linkking estático.
Documentação de montagem e atualização de bibliotecas (MBPL/MPL).
12) Registros (modelos 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 fontes OSS para divulgação
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) Segurança e conformidade
SCA/SAST em CI, escâner automático de novas dependências.
Política P1 de vulnerabilidade - ≤72 h, P2 - ≤14 dias.
Dinheiro dos artefatos: armazene os LICENSE/NOTICE originais; verifique a integridade (hashi).
Exportação/sanções: não use componentes/espelhos de países proibidos; configure as verificações.
14) Playbooks (cenários operacionais)
P-OSS-01: Encontrado GPL em módulo fechado
Inventário de vínculos → opção de isolamento/substituição → conclusão legal → lançamento-fix → retrô de processo.
P-OSS-02: Exigência de origem
Determinar o volume de compromissos → preparar arquivos e NOTICE → remeter dentro do prazo legal → atualizar a documentação.
P-OSS-03: Vulnerabilidade crítica dependendo
Backport/atualização → lançamento extraordinário → notificação dos interessados → pós-mar e regras de pinning.
15) Mini-FAQ
É possível usar o WOLFPL? Sim, com linkagem dinâmica/IPC e conformidade (substituição, notificação).
AGPL no servidor sem distribuição de binário - seguro? Não: o AGPL requer que os usuários que interagem com o serviço na rede forneçam fontes.
Precisamos de uma bolsa de patentes? Desejável para módulos com novidades algoritmicas; Apache-2. 0 preferido.
Basta especificar OSS no site? Não, cumpra todos os requisitos de notificação, origem, instruções.
16) Conclusão
Trabalhar com OSS é um processo, não um teste descartável, como padrões de tolerância, isolamento de copileft, notificações automatizadas e SBOM completo para cada montagem. Seguindo este artigo, você vai manter a velocidade de desenvolvimento e evitar armadilhas legais, desde «copileft de rede» até reclamações de patentes.