Copias crackeadas en GitHub: qué hace el dev JavaScript

Un desarrollador fue a Hacker News a contar que le pidió a GitHub retirar copias crackeadas de su software. Esperó más de un mes y los repositorios siguen ahí, públicos, con instrucciones de instalación y todo. El post es Tell HN: GitHub refuses to remove cracked copies of my software after a month, y el hilo se convirtió en un desahogo colectivo de quienes venden software. Si tienes un producto en JavaScript con versión de pago, el caso te interesa directamente. Puede haber copias crackeadas de tu código alojadas en la mayor plataforma de código del mundo, y sacarlas de ahí cuesta más de lo que parece.

Voy a separar el tema en dos partes. Primero, qué puedes hacer cuando el crack ya está publicado. Después, qué cambia en tu código para que el crack haga menos daño.

Qué pasó, en resumen

El guion es conocido. Lanzas una app de pago. Alguien quita la verificación de licencia, sube el resultado a un repositorio público y escribe un README muy cuidado. A veces el README es mejor que el tuyo. El crack llegó antes que tu changelog.

Entonces haces lo que todo el mundo recomienda: abres una solicitud de retirada por DMCA. Y esperas. Según el autor, la espera pasó de un mes sin que los repositorios cayeran.

En el hilo aparecieron las dos lecturas de siempre. Un lado cree que GitHub está siendo omiso con los dueños del código. El otro recuerda que la plataforma recibe un volumen enorme de solicitudes, muchas abusivas, y que tumbar repositorios sin revisar también es un problema. Las dos cosas pueden ser ciertas a la vez.

Cómo funciona el DMCA en GitHub (y por qué tarda)

GitHub tiene un proceso formal y público. Las solicitudes aceptadas se publican en el repositorio github/dmca, sin los datos personales. Eso ya dice mucho: es un proceso jurídico, no un botón de denuncia.

Algunos detalles que traban a mucha gente:

• Cada URL cuenta. La solicitud tiene que listar los repositorios que infringen. "El usuario X tiene varias copias" no basta.
• Los forks no caen solos. Si no dices de forma explícita que todos los forks también infringen, y no explicas por qué, la retirada puede afectar solo al repositorio original. En un proyecto crackeado, los forks se multiplican rápido.
• Una solicitud incompleta vuelve. ¿Faltó la declaración de buena fe, la firma o la descripción clara de la obra original? La solicitud queda parada hasta que la corrijas, y muchas veces nadie te avisa con la urgencia que te gustaría.
• Existe la contranotificación. El dueño del repositorio puede impugnar. En ese caso, el contenido puede volver tras unos días hábiles, salvo que acudas a la justicia.

O sea: el proceso es lento por diseño. Parte de la idea de que quien denuncia puede estar mintiendo. Es frustrante cuando tienes razón, pero es el mismo mecanismo que impide que un competidor tumbe tu repositorio con una denuncia falsa.

El DMCA protege tu derecho, no tu plazo.

Qué hacer cuando la copia crackeada ya está publicada

Si estás en esta situación ahora, el camino práctico es este:

1. Lista todo. Repositorio original, forks, releases con binario, gists. Pega las URLs una por una.
2. Menciona los forks de forma explícita. Di que el proyecto entero es una copia no autorizada y que todos los forks heredan la infracción.
3. Demuestra la autoría. Enlace a tu sitio, a tu repositorio privado, fecha del primer release, hash de un archivo que aparece idéntico en la copia.
4. Haz seguimiento con soporte. Si pasaron una o dos semanas sin respuesta, abre un ticket citando la solicitud original. El silencio suele significar "solicitud incompleta", no "solicitud rechazada".
5. Ataca también el descubrimiento. El usuario casi nunca encuentra el crack navegando por GitHub. Lo encuentra en el buscador. Pedir la retirada de los resultados de búsqueda suele reducir más el daño que tumbar un repositorio que mañana reaparecerá con otro nombre.

Este último punto es el que poca gente hace. Tumbar la copia es como secar hielo. Sacarla de la primera página de Google es cerrar el grifo.

Por qué la verificación de licencia en JavaScript cae tan fácil

Ahora la parte que duele. Si tu producto es JavaScript que corre en el cliente, ya sea una app Electron, una extensión de navegador o un CLI en Node o Bun, quien tiene el archivo tiene el código. Minificar no esconde nada. Ofuscar solo retrasa.

La verificación más común que veo por ahí es algo así:

const license = localStorage.getItem('license')

if (license === 'PRO') {
  unlockProFeatures()
}

Romper esto lleva menos tiempo que leer este párrafo. Basta con abrir DevTools y asignar la clave. O cambiar el if por true en el bundle.

Un paso más arriba es validar la licencia con firma digital. Firmas la licencia en tu servidor con una clave privada y la app solo la verifica con la clave pública. Con Web Crypto se puede hacer sin ninguna dependencia, en navegadores modernos, Node y Bun:

const PUBLIC_KEY_B64 = 'MCowBQYDK2VwAyEA...' // tu clave pública Ed25519

const fromB64 = (s: string) => Uint8Array.from(atob(s), (c) => c.charCodeAt(0))

export async function isValidLicense(payload: string, signatureB64: string) {
  const key = await crypto.subtle.importKey(
    'spki',
    fromB64(PUBLIC_KEY_B64),
    { name: 'Ed25519' },
    false,
    ['verify'],
  )

  return crypto.subtle.verify(
    'Ed25519',
    key,
    fromB64(signatureB64),
    new TextEncoder().encode(payload),
  )
}

Esto resuelve un problema real: nadie puede generar claves de licencia falsas, porque no tiene tu clave privada. Se acaba la era del keygen.

Pero sé honesto contigo mismo. Quien crackea no necesita generar licencias. Borra la llamada a isValidLicense y listo. La firma protege contra la falsificación, no contra la edición del código.

Dónde funciona la protección de verdad

La pregunta correcta no es "cómo impedir el crack". Es "qué no puede entregar el crack".

Todo lo que corre en la máquina del usuario se puede copiar. Lo que corre en tu servidor, no. Así que mueve el valor hacia allí:

• Sincronización y backup entre dispositivos.
• Funciones que dependen de tu API, como procesamiento pesado, IA, integraciones o exportaciones.
• Actualizaciones automáticas. La versión crackeada se queda congelada en el tiempo, y cada release tuyo aumenta la distancia.
• Soporte y cuenta. Quien paga tiene dónde reclamar. Quien crackeó tiene un README.

En la práctica, el código del cliente pide un token corto al servidor, y el servidor solo lo emite si la licencia está activa:

const res = await fetch('https://api.tuapp.com/session', {
  headers: { Authorization: `License ${licenseKey}` },
})

if (!res.ok) return showFreeTier()

const { token } = await res.json() // expira en minutos, se usa en las llamadas de pago

El crack todavía puede liberar la interfaz. Pero la interfaz sin el backend es una cáscara bonita. Y eso cambia la conversación: en lugar de proteger el código, proteges el servicio.

¿Vale la pena pelear con GitHub?

Vale la pena enviar la solicitud, y enviarla bien hecha. Es tu derecho y es barato. Pero yo no apostaría el modelo de negocio a eso. Aunque GitHub actúe en una semana, el mismo archivo aparece en otro host, en un Discord, en un torrent.

Mi opinión, y sé que hay gente que no está de acuerdo: en el software JavaScript que corre en el cliente, la guerra contra el crack está perdida desde el primer npm run build. La mayoría de quienes descargan cracks nunca iban a pagar. Quien iba a pagar quiere actualizaciones, soporte y la tranquilidad de que la app no le va a robar la contraseña. Un binario crackeado de un repositorio cualquiera es, de hecho, una forma excelente de instalar malware. Vale la pena recordarlo en tu página de precios, con educación.

Así que el reparto de esfuerzo que sugiero es simple. Una hora para escribir un DMCA completo, con URLs y forks. Una tarde para cambiar la verificación ingenua por una licencia firmada. Y el resto del tiempo construyendo cosas que solo funcionan con tu servidor del otro lado.

El caso de Hacker News es un recordatorio incómodo, pero útil: ninguna plataforma va a proteger tu producto por ti. La arquitectura sí. Si quieres ver cómo pienso este equilibrio entre cliente y servidor en las apps que construyo, echa un vistazo a mis proyectos.

Le pedí a GitHub que retirara copias crackeadas de mi software. Un mes después, siguen ahí.

Ese fue el desahogo de un dev en Hacker News, y muestra una verdad incómoda: el DMCA protege tu derecho, no tu plazo.

Si tu producto es JavaScript que corre en el cliente, quien tiene el archivo tiene el código. Minificar no esconde nada y ofuscar solo retrasa.

Una licencia firmada con Ed25519 acaba con el keygen, pero no impide que nadie borre el `if`.

La protección que funciona de verdad está en la arquitectura: sync, API, IA y updates corriendo en tu servidor. El crack libera la interfaz, pero sin el backend se queda en una cáscara bonita.

Escribí en el blog el paso a paso de un DMCA que funciona y de cómo mover el valor del producto al servidor. Si vendes software, vale la pena leerlo.

#JavaScript #DesarrolloDeSoftware #GitHub #SaaS #SeguridadInformática