Software crackeado en GitHub: por qué el DMCA se atasca

Un desarrollador independiente pasó un mes pidiéndole a GitHub que retirara copias crackeadas de su software. Siguen ahí. El relato apareció en Hacker News y se volvió ese tipo de hilo que todo el que vende software lee con un nudo en el estómago. Software crackeado en GitHub no es nada nuevo. Lo nuevo es darse cuenta de que el camino "oficial" para resolverlo puede tardar más que tu lanzamiento.

No conozco los detalles internos del caso. No sé qué decía la notificación ni qué respondió GitHub en cada etapa. Pero conozco bien el proceso, y explica mucho de por qué pasa esto. Explica también qué puedes hacer tú, que escribes JavaScript y quizá vendes algo, antes de llegar a ese punto.

Qué pasó con el software crackeado en GitHub

El resumen es simple. Alguien tomó un software de pago, quitó la verificación de licencia y publicó el resultado en repositorios públicos. El autor envió la solicitud de retirada. Un mes después, las copias seguían accesibles.

En el hilo se ven dos reacciones. Una parte de los comentarios va contra GitHub: "Microsoft tiene dinero para contratar gente, ¿por qué un mes?". La otra va contra el proceso: "la notificación tiene que estar exactamente en el formato, si no vuelve al final de la cola".

Las dos tienen algo de razón. Y ahí es donde el tema se pone interesante.

Cómo funciona una solicitud DMCA en GitHub

GitHub sigue el DMCA, la ley estadounidense de derechos de autor. Quien aloja contenido obtiene protección legal si retira el material infractor cuando recibe una notificación válida. La clave está en ese "válida".

Una notificación necesita, a grandes rasgos:

• identificación de la obra protegida (tu software, con enlace a donde se vende o distribuye)
• la URL exacta de cada archivo o repositorio infractor
• tus datos de contacto
• una declaración de buena fe y otra de que la información es verdadera, bajo pena de perjurio
• firma

Parece burocracia tonta, pero cada punto tiene su motivo. Sin ellos, cualquiera tumba el repositorio de cualquiera con un correo. Eso ya ha pasado muchas veces, incluso con proyectos legítimos.

GitHub además publica todas las notificaciones en un repositorio público, github/dmca. Vale la pena abrirlo. Verás miles de solicitudes, muchas de empresas grandes, muchas mal redactadas.

Hay un detalle que atrapa a mucha gente: los forks. Si el repositorio crackeado tiene 200 forks, la notificación tiene que dejar claro que toda la red de forks infringe, o listar cada uno. Si no, GitHub retira el original y los 200 forks siguen ahí. Envías la solicitud, celebras, y descubres que el problema solo cambió de dirección.

Y existe la contranotificación. Quien publicó puede impugnar. En ese caso, el material vuelve a estar en línea en 10 a 14 días hábiles, salvo que presentes una demanda. Para un dev solo, demandar a un anónimo en otro país es una broma de mal gusto.

El DMCA protege primero a la plataforma. Tú vienes después.

Por qué esto importa si escribes JavaScript

El tema aquí es JavaScript por una razón muy práctica. JS es el lenguaje más fácil de crackear que existe. Le entregas el código fuente al usuario. Minificado, tal vez ofuscado, pero se lo entregas.

Extensión de navegador, app Electron, plugin de editor, componente de UI de pago, plantilla de dashboard. Todo eso corre en la máquina de quien lo compró, y cualquiera con las DevTools abiertas puede leerlo.

Mira el patrón que más veo en productos pequeños:

// verificación de licencia 100% en el cliente
const res = await fetch('https://api.meuapp.com/license/' + key)
const { valid } = await res.json()

if (!valid) {
  showPaywall()
  return
}

unlockProFeatures()

Para crackear esto nadie necesita ser hacker. Basta con cambiar if (!valid) por if (false) y listo. O interceptar la respuesta y devolver { "valid": true }. Lleva unos cinco minutos, y cuatro de ellos son para encontrar el archivo correcto en el bundle.

La ofuscación retrasa, pero no impide. Las herramientas de desofuscación recuperan buena parte de la estructura, y quien crackea software lo hace por hobby. Estás apostando tu tiempo de trabajo contra el tiempo libre de alguien que se divierte con esto. Spoiler: pierdes.

Qué cambia en tu código: lleva el valor al servidor

La única protección que funciona de verdad es no entregar en el cliente lo que vale dinero. Si la feature pro corre en el navegador, se puede copiar. Si depende de algo que solo hace tu servidor, la copia crackeada queda coja.

En la práctica, significa cambiar "el cliente pregunta si puede" por "el servidor solo responde si puede":

// Bun + Hono, por ejemplo
app.post('/api/export-pdf', async (c) => {
  const user = await getUser(c)
  if (!user?.plan || user.plan === 'free') {
    return c.json({ error: 'upgrade required' }, 402)
  }

  const pdf = await renderPdf(await c.req.json())
  return c.body(pdf, 200, { 'Content-Type': 'application/pdf' })
})

Aquí no hay ningún if en el front que quitar. La generación del PDF ocurre en el servidor. Quien crackee el front tendrá un botón bonito que devuelve 402.

No todos los productos lo permiten. Una plantilla de dashboard es solo código y no tiene servidor. Una app offline tiene que funcionar sin red. En esos casos, algunas cosas ayudan a reducir el daño:

• Licencia firmada, no "válida o no". El servidor firma un token (JWT con clave privada, Ed25519) con email, plan y vencimiento. La app valida la firma con la clave pública. Esto no impide el crack, pero sí impide el generador de claves falsas.
• Marca de agua por cliente. Incluye un identificador del comprador en el build que descarga. Cuando la copia se filtre, sabrás de dónde salió y tendrás una prueba concreta para la solicitud de retirada.
• Las actualizaciones como valor. La copia crackeada se congela en la versión que se filtró. Si lanzas mejoras cada mes, el pirata se queda atrás solo.

¿Vale la pena pelear contra la piratería?

Aquí va mi opinión, y es algo impopular. Para la mayoría de los devs independientes, perseguir copias crackeadas es un pésimo uso del tiempo.

Quien descarga la versión crackeada de un plugin de 30 dólares, en general, nunca iba a pagar 30 dólares. No es una venta perdida, es un usuario que nunca sería cliente. Cada hora rellenando notificaciones y respondiendo correos del soporte de GitHub es una hora sin mejorar el producto para quien paga.

Pero esto tiene un límite. No es lo mismo que alguien lo crackee y lo use en casa que alguien publique la copia en un repositorio que aparece en Google antes que tu página de ventas. El segundo caso duele de verdad. Te quita tráfico, confunde al usuario y a veces viene con malware incluido, lo que se convierte en un problema de reputación para ti. Ahí sí tiene sentido actuar, y actuar bien:

1. Arma la notificación completa a la primera, con cada URL y la mención explícita a los forks.
2. Guarda pruebas: commits originales con fecha, página de ventas, la marca de agua si la tienes.
3. Denuncia también en Google, con el formulario de retirada por derechos de autor. A veces quitarlo de la búsqueda resuelve más rápido que quitarlo de GitHub.
4. Si el repositorio distribuye malware, denúncialo como abuso. Ese canal suele avanzar más rápido que el de derechos de autor.

Lo que me llevo de este caso

GitHub se merece la crítica por la demora. Un mes es mucho para un caso que parece obvio, y la plataforma tiene recursos para hacerlo mejor. Pero confiar en que GitHub va a proteger tu modelo de negocio es poner la cerradura en la puerta del vecino.

Si vendes algo hecho en JavaScript, parte de la base de que lo van a copiar. Pon lo que vale dinero donde el usuario no llega y haz que la versión de pago mejore más rápido de lo que cualquier pirata puede seguir. Es lo que intento aplicar en los proyectos que mantengo: si el código está en el navegador, ya es público.

Un dev pasó un mes pidiéndole a GitHub que bajara copias crackeadas de su software. Siguen en línea.

El DMCA protege primero a la plataforma. Tú vienes después: notificación con el formato exacto, cada fork en la lista, y encima puede llegar una contranotificación.

Quien vende algo en JavaScript tiene que aceptar una verdad: si el código corre en el navegador, ya es público. Cambiar un if (!valid) lleva cinco minutos.

La protección que funciona es sacar del cliente lo que vale dinero y dejarlo en el servidor. Lo demás ayuda: licencia firmada, marca de agua por comprador y actualizaciones constantes.

Escribí en el blog cómo armar una solicitud de retirada que funcione y cuándo vale la pena pelear contra la piratería. Si vendes software, merece la lectura.

#JavaScript #GitHub #DesarrolloDeSoftware #IndieHacker #Seguridad