Licenciamento de software e API

1) Por que isso é importante para iGaming

A plataforma é baseada em código próprio, bibliotecas de terceiros, provedores de jogos/pagamentos SDK e APIs públicas/privadas. Erros nas licenças resultam em reclamações, blocos de integração, vazamentos de IP e riscos regulatórios (privacidade/sanções/exportação de criptografia). O objetivo é criar um circuito transparente de direitos, o que pode ser publicado, integrado, transferido para os parceiros e como proteger suas próprias APIs.

2) Modelos de licenciamento de software (visão geral)

Proprietary (licença fechada): permissões exclusivas do vendedor; para B2B (operadoras, estúdios, PSP).

• Permissive: MIT, BSD, Apache-2. 0 (bolsa de patentes).
• Copyleft: GPL/LANGPL/AGPL - compatibilidade «contágio»; cuidado com os módulos fechados.
• Dual/Multi-licensing: ramo OSS gratuito + licença comercial com direitos/suporte avançados.
• SaaS licenciamento: acesso como serviço; o código não é transmitido, os direitos de utilização.

As regras de escolha são serviços críticos (motor de jogo, antifrode, cálculos) - evitar copyleft; Bibliotecas UI - permissiva; torso interno - pode ser GPL quando isolado.

3) Direitos e restrições: o que olhar nas licenças

Quantidade de direitos (scope): área, data limite, usuários/instalação, ambientes (prod/estágio/dave).
Modificações e derivados: se você pode forçar, alterar, distribuir.
Sublocação/transferência: se é válido para afiliados/white-label.
Bolsa de patentes e terminação definível (Apache-2. 0, MPL): riscos de patentes e licenças cruzadas.
Auditoria e relatórios - direito do vendedor a fazer verificações de licenciamento.
Segurança/exportação: restrições à criptografia, países/sanções.
Indemity e responsabilidade: quem cobre as reclamações de PI/dano.

4) Open Surce: política e controle

Lista branca: MIT/BSD/Apache-2. 0, MPL-2. 0.
Amarelo: LANGPL-3. 0 (com links dinâmico e condições).
Vermelho: AGPL/GPL-3. 0 em serviços fechados, se não houver isolamento (serviço-limite, rede copyleft).
SBOM (Software Bill of Materials): lista obrigatória de dependências com versões/licenças.
Processo OSS: solicitação de yur/ti-avaliação de compatibilidade fixação no registro auditoria periódica.
Aporte para OSS (upstream): CLA/DCO, verificação de divulgação de IP, concordância com o Legal.

5) SDK e licenças de provedores (jogos, pagamentos, KYC)

Requisitos típicos: proibição de desenvolvimento reverso, proibição de cajagem fora de condições, controle de logotipo/branding, versões mínimas, direito de auditoria.
Dados: limites de «dados de operadora» vs «dados do provedor», quem possui as métricas e o Derived Data.
Restrições de exportação/sanções: geo-blocs, listas de RER/sanções - obrigatório de verificação em TS/licença.
Suporte/atualizações: SLA para patches, breaking-changes, prazos de migração.

6) API: condições legais de acesso (para associados/afiliados/B2V)

• Acesso e autenticação: OAuth2/HMAC/mutual-TLS; A proibição da transferência de chaves a terceiros.
• Rate limits e quotas: RPS/minutos/por dia; «uso honesto»; política burst.
• SLA e suporte: disponibilidade (por exemplo, 99. 9%), janelas de serviço, plano de incidentes/comunicações.
• Versioning/deposição: SemVer, data EOL (por exemplo, ≥ 9-12 m), envio de notificações.

• O Serviço-Generated Data (logs, métricas) é o dono da API;
• Customer/Player Data - cliente/operador;
• Derived Data - por contrato (permitido/limitado, anonimato).
• Armazenamento e armazenamento em dinheiro: o que e como você pode armazenar (TTL, proibição de armazenamento de campos pessoais/sensíveis).
• Privaciy/AML/KYC: rol (controlador/processador), DPA/DSA, transferências, DPIA para cenários high-risk.
• Segurança: encriptação em trânsito/at-rest, segredo-gerenciamento, requisitos de SOC2/ISO 27001 (se aplicável).
• Restrições: engenharia reversa, screaping, medição/benchmarking sem consentimento, modificação de respostas API.
• Auditoria e logs: direito de verificação, requisitos de registro de consulta.
• Sanções e exportação: proibição de uso em países/usuários de listas, screening.
• Exclusão de garantias e limite de responsabilidade: cap (por exemplo, 12 x média. pagamento).
• Interrupção do acesso: imediato em caso de ameaça à segurança/lei; plano de saída de dados.

7) Política de versionização e compatibilidade

SemVer: MAJOR (breaking), MINOR (features), PATCH (fix).
Contratos de esquema: JSON Schema/OpenAPI; Testes contracto para clientes.
Procedimento Deprecation: anúncio → período de compatibilidade (≥ 6 mi) → EOL → remoção; Hyde migratório.
Função flags: para marcações «suaves».

8) Controle de exportação, sanções, criptografia

Exportação de criptografia: verificação de regras locais; notificações/código ESS/comprimento de bits.
Sanções: proibição de atender/dar acesso a residentes de jurisdições/pessoas; O recrining periódico.
Regulação de falhas: cláusulas de suspensão do serviço em risco regulatório.

9) Matriz de Risco (RAP)

10) Folha de cheque antes do lançamento/integração

• SBOM recolhido; as licenças foram verificadas (não há incompatíveis).
• As licenças Vendor/SDK foram assinadas; direitos de dados e marca.
• Os DPA/DSA estão formalizados; os papéis de controlador/processador são definidos.
• Os API Terms/EULA foram atualizados; rate limits/SLA/despreceção.
• Screening de sanções/exportação em processos.
• Segurança: chaves, rotação, criptografia, registro.
• Plano de incidentes e revogação de acesso (killswitch) pronto.

11) Registros e artefatos (formatos recomendados)

11. 1 SBOM/Registro de Licenças

yaml component: "payment-gateway-sdk"
version: "4. 2. 1"
license: "Apache-2. 0"
source: "maven"
usage: "runtime"
notes: "requires notice file"
dependencies:
- name: "okhttp"
version: "4. 12. 0"
license: "Apache-2. 0"
- name: "commons-io"
version: "2. 16. 1"
license: "Apache-2. 0"
owner: "Engineering"

11. 2 Registro de clientes API

yaml client_id: "aff-778"
app_name: "AffTrack"
scopes: ["reports:read","players:read_limited"]
rate_limit_rps: 5 quota_daily: 50_000 dpa_signed: true sanctions_screened_at: "2025-11-05"
status: "active"
owner: "API Ops"

11. 3 Registry SDK/vendedores

yaml vendor: "GameProviderX"
agreement: "SDK-License-2025-10"
audit_rights: true brand_rules: true data_rights:
provider_metrics: "vendor"
operator_metrics: "shared"
derived_data: "anonymized_allowed"
sla:
incidents: "P1:2h,P2:8h"
updates: "quarterly"

12) Modelos (fatias)

12. 1 EULA (parte interna)

12. 2 API Terms (parte interna)

12. 3 Licenciamento de código/docas

13) Privacidade e dados (API/SDK)

Minimizar: Não dê mais campos (PII), use identificadores translúcidos.
TTL do armazenamento: estritamente fixado; a proibição da cópia local de dampos completos.
Direitos das entidades de dados: Rotação de solicitação (access/erasure) por meio da operadora; Protocolo.
Pseudônimo/anonimato: para analistas/Dados Derived - antes da publicação.

14) Playbooks

P-LIC-01: Encontrado copyleft no serviço de prod

Uma auditoria da SBOM uma opção de migração/isolamento para avaliação juramental plano de lançamento retrospectiva.

P-API-02: Fuga da chave API

A revisão da chave a notificação do cliente forense a rotação dos segredos o update da política.

P-SDK-03: O vendedor quebra a compatibilidade

O adaptador de transição uma API temporária negociar a extensão da janela de distribuição aos clientes.

P-XPORT-04: Bandeira de sanções

Acesso automático → confirmação de jogos → avaliação jurídica → documentos para o regulador.

15) KPI/métricas

SBOM Coverage% e proporção de componentes aprovados.
Hora de encerramento do incidente de licença (copyleft/incompatibilidade).
Deprecation Compliance% (clientes na versão atual).
Time-to-Revoke a chave de saída e MTTR em API.
Proporção de clientes com DPA/DSA assinado e screening de sunk percorrido.

16) Mini-FAQ

É possível incorporar o WOLFPL? Sim, com linha dinâmica e condições, captamos no SBOM.
Quem é o dono da API? Por padrão, possui API (Service-Generated) e o cliente tem licença limitada.
Posso treinar ML em API? Apenas anónimos/agregados e se for permitido ToS/DPA.
Quanto tempo a EOL? Recomendado 9-12 meses com hide migratório.

17) Conclusão

As licenças de software e API não são «assinadas separadamente», mas um ciclo contínuo: escolha de licenças compatíveis, gerenciamento de SBOM, API claro Terms (dados/quotas/SLA/despreceção), DPA/sanções, e playbooks operacionais. Normalize os registros e modelos e reduza os riscos legais, simplifique a integração e proteja o seu próprio IP e dados dos jogadores.