Skip to content

Proteção de Propriedade Intelectual — visão geral

Leia no seu idioma: English · Português · Español

Status do escopo (pós-congelamento de escopo 2026-05-10) — 17 patent claims documentados na família DOM/OOBI/GATEWAY/RELAY/PURE/OBP/ Cloud/SPAN/TREX. Provisional patent filing na Phase 5 (~$20-30k attorney + drafting). Ver ADRs 0014, 0019-0025 para mapeamento técnico das claims.

Este documento descreve a estratégia em camadas de proteção de IP aplicada ao TLSStress.Art. É deliberadamente escrito para duas audiências:

  1. Usuários autorizados (funcionários da Cisco + parceiros certificados) — para você entender as proteções que existem antes de contribuir ou distribuir os PDFs de relatório
  2. Qualquer um considerando uso indevido deste trabalho — para entender que o custo de detecção é alto e a exposição legal é real

As cinco camadas

Camada Mecanismo Propósito
1. Distribuição Repositório GitHub privado, access broker, aceitação de licença equivalente a NDA Controla quem recebe uma cópia em primeiro lugar
2. Legal PolyForm Noncommercial 1.0.0 + Appendix A, CLA em contribuições, proteção de trademark (planejada) Define o que um usuário autorizado pode / não pode fazer
3. Fingerprinting forense Marcadores intencionais no código, números mágicos, prefixos de naming, hashes de assets Prova origem se um produto derivado aparecer
4. Telemetria external_labels Prometheus license-aware em toda métrica Detecta deployments derivados através da observabilidade deles mesmos
5. Detecção Alertas GitHub code search, Google Alerts, comparação de asset-hash em releases Faz aparecer clones na natureza

As camadas são aditivas. Nenhuma camada isolada é suficiente. Combinadas, tornam um clone economicamente desinteressante.

Camada 3 — Fingerprinting forense (a parte que a maioria dos projetos pula)

A base de código contém fingerprints intencionais embarcadas em locais sutis. As fingerprints são projetadas para:

  1. Parecerem naturais — aparecem como código, comentários ou dados ordinários, de modo que um pass de refatoração não consegue removê-las sem intenção explícita
  2. Cobrirem múltiplas categorias — comentários de código, números mágicos, prefixos de naming, strings honeypot, hashes de assets — de modo que remover uma categoria deixa as outras intactas
  3. Serem cruzadas entre si — múltiplas fingerprints existem em diferentes módulos; um competidor precisaria identificar e remover cada uma

Os locais e padrões exatos não são publicados. São registrados apenas em um registry privado, revisados apenas pelo detentor do copyright, usados apenas ao comparar um derivado suspeito com o original. Publicar o registry derrotaria seu propósito.

O que você pode verificar

Você pode verificar que o fingerprinting está ativo sem aprender onde estão as fingerprints:

  • O workflow CI .github/workflows/forensic-tamper-check.yml roda em todo PR e valida que fingerprints registradas ainda existem. O workflow carrega padrões de um GitHub Actions Secret — nunca da base de código.
  • Toda release publica um artifact asset-hashes.txt listando SHA-256 de cada YAML/Markdown/Caddyfile próprio. Se você suspeita que um produto de terceiro carrega assets desta base de código, compare hashes contra o manifest publicado.

O que acontece se um clone for descoberto

O proprietário roda uma comparação forense: pull do derivado suspeito, grep de cada fingerprint registrada, contagem de matches. Os limiares são documentados internamente:

Matches Conclusão
5+ Forte evidência de derivação; avança para review legal
2-4 Suspeita razoável; investigar mais
0-1 Provavelmente reimplementação independente; encerra investigação

Sob a política de audiência, avançar para review legal pode incluir DMCA takedown, cease-and-desist, ou escalação para outside counsel.

Camada 4 — Telemetria license-aware

Toda métrica raspada da instância Prometheus enviada com este projeto carrega external_labels:

license: PolyForm-Noncommercial-1.0.0+AppendixA
audience: cisco-employees-and-certified-partners
procurement_use: denied

Esses labels viajam com os dados da métrica para onde quer que sejam exportados (federation, remote-write, Grafana downstream). Se um produto derivado ingerir esses labels em seu próprio stack de observabilidade, os labels são evidência de origem.

Esta camada é documentada em USAGE_POLICY.pt-BR.md e visível em observability/prometheus/prometheus.yml.

Camada 1 — Controle de distribuição

Veja PRIVATE_REPO_SETUP.pt-BR.md para os detalhes operacionais. Resumo:

  • Repositório é privado; GitHub não habilita ACLs de leitura por branch, então todos os colaboradores veem todas as branches
  • Acesso é concedido apenas via fluxo do Access Broker aprovado por maintainer
  • Branch protection na main requer PR + 8 status checks + linear history
  • GitHub Pages permanece público apenas para docs — operadores avaliando o projeto podem ler tudo; apenas o source code é gateado
Mecanismo Status Documento
PolyForm Noncommercial 1.0.0 ativo LICENSE
Appendix A (audiência + campo de uso) ativo LICENSE
Contributor License Agreement (CLA) planejado TBD
Registro de trademark planejado (sujeito a review da Cisco Legal) —
Procedimento DMCA takedown ativo (via GitHub Trust & Safety) —

Camada 5 — Detecção

Monitores ativos:

  • GitHub code search saved queries — o maintainer tem queries salvas para strings únicas; GitHub manda email em hits
  • Google Alerts — para o nome do projeto + frases distintivas da documentação
  • Comparação de asset hash — toda release publica asset-hashes.txt; se um terceiro publica um Grafana dashboard que hasheia idêntico, o match é detectado no próximo sweep

Reportando derivados suspeitos

Se você encontrar um produto de terceiro que parece ser derivado do AI_forSE, por favor abra uma issue neste repositório (use o template bug-report, marque severity HIGH) ou envie email para gallonccie@gmail.com diretamente. Por favor inclua:

  • URL ou canal de distribuição do derivado suspeito
  • Evidência específica que você notou (dashboards similares, estrutura YAML idêntica, imagens byte-iguais)
  • Sua relação com o vendor suspeito (nenhuma / cliente / competidor — para contexto, não exclusão)

Quem reporta derivados confirmados pode ser reconhecido no arquivo NOTICE do projeto, com seu consentimento.

Por que publicamos este documento

A maioria dos projetos implementa proteção de IP mas nunca documenta. Isso é uma oportunidade perdida:

  • Um usuário autorizado se beneficia de saber que as proteções existem (reforça sua postura de compliance)
  • Um potencial bad actor se beneficia de saber que detecção é real (muda o cálculo de custo-benefício)
  • Um competidor se beneficia de saber o que não é protegido — reimplementações clean-room de ideias (não implementação) são explicitamente permitidas sob copyright law e bem-vindas como evolução saudável de mercado

Publicar este documento é em si uma forma de proteção: remove a defesa "eu não sabia" de uma reclamação futura de infração.

Relacionados