Skip to content

Protección de Propiedad Intelectual — visión general

Lee en tu idioma: English · Português · Español

Estado del alcance (post-congelación de alcance 2026-05-10) — 17 patent claims documentados en la familia DOM/OOBI/GATEWAY/RELAY/PURE/ OBP/Cloud/SPAN/TREX. Provisional patent filing en Phase 5 (~$20-30k attorney + drafting). Ver ADRs 0014, 0019-0025 para el mapeo técnico de las claims.

Este documento describe la estrategia en capas de protección de IP aplicada a TLSStress.Art. Está deliberadamente escrito para dos audiencias:

  1. Usuarios autorizados (empleados de Cisco + partners certificados) — para que entiendas las protecciones que existen antes de contribuir o distribuir los PDFs de reporte
  2. Cualquiera considerando el uso indebido de este trabajo — para que entiendas que el costo de detección es alto y la exposición legal es real

Las cinco capas

Capa Mecanismo Propósito
1. Distribución Repositorio GitHub privado, access broker, aceptación de licencia equivalente a NDA Controla quién recibe una copia en primer lugar
2. Legal PolyForm Noncommercial 1.0.0 + Appendix A, CLA en contribuciones, protección de trademark (planeada) Define qué puede / no puede hacer un usuario autorizado
3. Fingerprinting forense Marcadores intencionales en el código, números mágicos, prefijos de naming, hashes de assets Prueba origen si un producto derivado aparece
4. Telemetría external_labels Prometheus license-aware en cada métrica Detecta deployments derivados a través de su propia observabilidad
5. Detección Alertas GitHub code search, Google Alerts, comparación de asset-hash en releases Hace aparecer clones en la naturaleza

Las capas son aditivas. Ninguna capa sola es suficiente. Combinadas, hacen un clon económicamente poco atractivo.

Capa 3 — Fingerprinting forense (la parte que la mayoría de proyectos saltan)

La base de código contiene fingerprints intencionales embebidos en ubicaciones sutiles. Los fingerprints están diseñados para:

  1. Parecer naturales — aparecen como código, comentarios o datos ordinarios, de modo que un pase de refactorización no puede removerlos sin intención explícita
  2. Cubrir múltiples categorías — comentarios de código, números mágicos, prefijos de naming, strings honeypot, hashes de assets — de modo que remover una categoría deja las otras intactas
  3. Estar cruzados entre sí — múltiples fingerprints existen en diferentes módulos; un competidor necesitaría identificar y remover cada uno

Las ubicaciones y patrones exactos no se publican. Se registran solo en un registry privado, revisados solo por el titular del copyright, usados solo al comparar un derivado sospechoso contra el original. Publicar el registry derrotaría su propósito.

Lo que puedes verificar

Puedes verificar que el fingerprinting está activo sin aprender dónde están los fingerprints:

  • El workflow CI .github/workflows/forensic-tamper-check.yml corre en cada PR y valida que los fingerprints registrados aún existen. El workflow carga patrones desde un GitHub Actions Secret — nunca desde la base de código.
  • Cada release publica un artifact asset-hashes.txt listando SHA-256 de cada YAML/Markdown/Caddyfile propio. Si sospechas que un producto de tercero carga assets de esta base de código, compara hashes contra el manifest publicado.

Qué pasa si un clon es descubierto

El propietario corre una comparación forense: hace pull del derivado sospechoso, hace grep de cada fingerprint registrado, cuenta matches. Los thresholds están documentados internamente:

Matches Conclusión
5+ Fuerte evidencia de derivación; avanzar a review legal
2-4 Sospecha razonable; investigar más
0-1 Probablemente reimplementación independiente; cierra investigación

Bajo la política de audiencia, avanzar a review legal puede incluir DMCA takedown, cease-and-desist, o escalación a outside counsel.

Capa 4 — Telemetría license-aware

Cada métrica raspada de la instancia Prometheus enviada con este proyecto carga external_labels:

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

Esos labels viajan con los datos de la métrica a donde sean exportados (federation, remote-write, Grafana downstream). Si un producto derivado ingiere esos labels en su propio stack de observabilidad, los labels son evidencia de origen.

Esta capa está documentada en USAGE_POLICY.es.md y visible en observability/prometheus/prometheus.yml.

Capa 1 — Control de distribución

Ver PRIVATE_REPO_SETUP.es.md para los detalles operacionales. Resumen:

  • El repositorio es privado; GitHub no habilita ACLs de lectura por branch, por lo que todos los colaboradores ven todas las branches
  • El acceso se concede solo vía el flujo del Access Broker aprobado por maintainer
  • Branch protection en main requiere PR + 8 status checks + linear history
  • GitHub Pages permanece público solo para docs — operadores evaluando el proyecto pueden leer todo; solo el source code está restringido
Mecanismo Estado Documento
PolyForm Noncommercial 1.0.0 activo LICENSE
Appendix A (audiencia + campo de uso) activo LICENSE
Contributor License Agreement (CLA) planeado TBD
Registro de trademark planeado (sujeto a review de Cisco Legal) —
Procedimiento DMCA takedown activo (vía GitHub Trust & Safety) —

Capa 5 — Detección

Monitores activos:

  • GitHub code search saved queries — el maintainer tiene queries guardadas para strings únicos; GitHub envía email en hits
  • Google Alerts — para el nombre del proyecto + frases distintivas de la documentación
  • Comparación de asset hash — cada release publica asset-hashes.txt; si un tercero publica un Grafana dashboard que hashea idéntico, el match es detectado en el siguiente sweep

Reportando derivados sospechosos

Si encuentras un producto de tercero que parece ser derivado de TLSStress.Art, por favor abre un issue en este repositorio (usa el template bug-report, marca severity HIGH) o envía email a gallonccie@gmail.com directamente. Por favor incluye:

  • URL o canal de distribución del derivado sospechoso
  • Evidencia específica que notaste (dashboards similares, estructura YAML idéntica, imágenes byte-iguales)
  • Tu relación con el vendor sospechoso (ninguna / cliente / competidor — para contexto, no exclusión)

Quienes reportan derivados confirmados pueden ser reconocidos en el archivo NOTICE del proyecto, con su consentimiento.

Por qué publicamos este documento

La mayoría de proyectos implementan protección de IP pero nunca lo documentan. Eso es una oportunidad perdida:

  • Un usuario autorizado se beneficia de saber que las protecciones existen (refuerza su postura de compliance)
  • Un potencial bad actor se beneficia de saber que la detección es real (cambia el cálculo de costo-beneficio)
  • Un competidor se beneficia de saber qué no está protegido — reimplementaciones clean-room de ideas (no implementación) están explícitamente permitidas bajo copyright law y son bienvenidas como evolución saludable del mercado

Publicar este documento es en sí una forma de protección: remueve la defensa "yo no sabía" de una reclamación futura de infracción.

Relacionados