El README te vende. El código te confiesa.
La ley te deja estudiar el software que usas y quedarte con sus ideas. La ingeniería inversa creó la industria del PC. Y la IA te acaba de dar la linterna para hacerlo tú.
Dentro del expediente
El README de un proyecto te vende. El código te confiesa. En la web pone lo que quieren que compres. En el código está lo que de verdad han tenido que resolver, con las cicatrices puestas. Aprender a leer esa diferencia es el superpoder más barato que existe, y casi nadie lo usa.
Esto va de ingeniería inversa. Y antes de que nadie se lleve las manos a la cabeza: es legal, la inventaron los buenos, y probablemente construyó el ordenador desde el que me estás leyendo.
La ingeniería inversa creó la industria del PC. Y fue legal
1981. IBM saca su PC y lo controla todo, porque el corazón, la BIOS, es suyo y está protegido. Copiarla es ilegal. Parece el fin de la historia.
Entonces aparece una jugada de bar elevada a arte: la sala limpia. Un equipo estudia la BIOS de IBM y escribe una especificación de qué hace, sin copiar ni una línea. Un abogado revisa esa especificación para asegurarse de que no lleva nada protegido. Y un segundo equipo, que nunca ha visto el código original, la reimplementa desde cero mirando solo esa especificación. Fuente primaria ↗
Eso hicieron Columbia Data Products primero, y sobre todo Compaq en 1982 y Phoenix Technologies en 1984. IBM no pudo hacer nada, porque nadie había copiado nada: habían recreado el comportamiento partiendo de las ideas, no del texto. Phoenix licenció su BIOS a los fabricantes por 290.000 dólares y de ahí salió toda la industria del PC compatible. Fuente primaria ↗
Léelo otra vez: la ingeniería inversa, bien hecha, rompió el monopolio del gigante de la época. Con una especificación y un abogado. No con un pleito ni con un cheque.
En España tienes derecho a abrir el capó. Por ley
Y aquí viene la parte que a tu audiencia de despacho le va a gustar, porque no es opinión, es Código. El Texto Refundido de la Ley de Propiedad Intelectual, artículo 100, apartado 3, dice negro sobre blanco que el usuario legítimo de un programa puede observarlo, estudiarlo y verificar su funcionamiento, sin pedirle permiso al dueño, con el fin de determinar las ideas y los principios que hay detrás de cualquiera de sus elementos. Fuente primaria ↗
Traducido: la ley te da derecho a abrir el capó del software que usas y aprender cómo está hecho. No a robar el motor, a entender el diseño. Y por si a algún vendedor se le ocurre metértelo en la letra pequeña, la Directiva europea que hay detrás lo remata: toda cláusula de contrato que intente quitarte ese derecho es nula, sin valor ni efecto. Fuente primaria ↗
O sea que cuando un comercial te diga que no puedes mirar cómo funciona lo que le has comprado, no solo te está apretando: te está pidiendo que renuncies a un derecho que la ley declara irrenunciable.
La raya: ideas sí, código no
Aquí es donde hay que ser fino, y por eso lo escribo un abogado y no un pirata. El derecho de autor protege la expresión concreta, el código tal cual está escrito, no las ideas que hay detrás. Una idea, un patrón, una forma de resolver un problema, no se patentan con copyright. Puedes aprenderlos libremente.
Lo que no puedes es copiar y pegar el código de otro dentro de tu producto y venderlo como tuyo. Ahí sí hay licencia, y si es de las copyleft, como la GPL, te obliga a abrir el tuyo también. Por eso la sala limpia separa al que lee del que escribe: para quedarse con la idea y dejar fuera la expresión. Esa es la línea exacta, y respetarla es lo que convierte el ingenio en método y no en denuncia.
El método, en corto
Aquí solo doy pinceladas, porque el detalle es la parte que me guardo. Pero el hábito es este. Cuando necesito resolver algo, no busco quién me lo vende. Busco el mejor proyecto abierto que ya lo resuelve, y me leo su código, no su README. Ahí encuentro los patrones que valen: cómo decide cuándo callarse en vez de arriesgar, cómo guarda las cosas en local en vez de colgarse de un servicio ajeno, cómo filtra permisos antes de enseñar nada. Me quedo el patrón, no el archivo, y me lo monto a mi manera y para mi oficio.
Porque no hay un molde para todos. El código de otro te enseña la forma de pensar; el traje te lo cortas tú. Un patrón que a ellos les sirve para un blog, a un despacho fiscal hay que blindarlo con validaciones donde una cifra mal es una sanción. Ese trabajo no te lo hace un vendedor de talla única, y por eso no te lo va a enseñar.
Y ahora el capó se abre en una tarde
Lo que antes era para hackers, hoy lo tienes tú. Un proyecto serio son cien o doscientas mil líneas de código, y hasta hace nada leer eso era una carrera. Ahora le pones una IA delante y te lo explica pieza a pieza en una tarde. La barrera de entrada a la ingeniería inversa se ha caído de golpe.
Con una condición, la de siempre en esta casa: la IA que te lee el código también se puede equivocar al leerlo. Te sirve para orientarte y para ir rápido, no para fiarte a ciegas. El patrón que te dice que ha encontrado, lo confirmas tú en el código antes de montarlo. Ingeniería inversa con IA, sí. Ingeniería inversa por fe, no.
Deja de preguntar quién te lo vende. Empieza a preguntar quién ya lo ha resuelto y déjame ver cómo. La ley te deja abrir el capó, la historia demuestra que ahí se ganan las guerras, y la IA te acaba de dar la linterna. El que solo lee el README paga. El que lee el código, aprende a no pagar.
Lo que me preguntan cuando cierro el portátil.
¿Es legal la ingeniería inversa de un programa?
Dentro de unos límites, sí, y en España está en la ley. El artículo 100.3 del Texto Refundido de la Ley de Propiedad Intelectual permite al usuario legítimo observar, estudiar y verificar el funcionamiento de un programa, sin permiso del titular, para determinar las ideas y principios que hay detrás. La descompilación para lograr interoperabilidad también está amparada. Lo que no está permitido es copiar el código concreto en tu propio producto.
¿Puedo usar en mi empresa lo que aprendo del código de otro?
Puedes usar las ideas y los patrones, porque el derecho de autor protege la expresión concreta, no las ideas. Lo que no puedes es copiar y pegar el código ajeno, sobre todo si tiene una licencia copyleft como la GPL, que te obligaría a abrir tu propio producto. La regla práctica es la de la sala limpia: separa entender el patrón de copiar la implementación.
¿Para qué sirve leer el código en vez del README?
El README y la demo están escritos para vender; el código está escrito para funcionar. En el código ves las decisiones reales: cuándo el sistema decide no arriesgar, cómo guarda los datos, cómo controla los permisos. Son patrones que ningún comercial te va a enseñar y que puedes adaptar a tu caso. Con una IA que te explique el código, leer un proyecto grande deja de ser cosa de expertos, siempre que verifiques lo que la IA te dice en la fuente.
Antes de comprar una solución, lee el código del mejor proyecto abierto que ya la resuelve.
El expediente detrás del artículo.
Diseño de sala limpia: Phoenix y Compaq recrearon la BIOS de IBM y crearon la industria del PC compatible ↗Wikipedia (Clean-room design) / History of Information · 1982-1984Historia técnica documentadaLey de Propiedad Intelectual ↗BOE · texto consolidado; artículos citados en cada expediente · 1996
Texto consolidado; comprobar redacción aplicableDirectiva 2009/24/CE sobre protección jurídica de programas de ordenador: art. 5.3 (observar/estudiar), art. 6 (descompilación) y nulidad de toda cláusula contraria ↗DOUE / BOE · 2009
Normativa UE
Fuentes consultadas el 29 de septiembre de 2026. Las recomendaciones y ejemplos son elaboración editorial y no se atribuyen íntegramente a estas fuentes. Comprueba versión y ámbito antes de aplicar una norma.
Divulgación general. Ninguna herramienta de esta web certifica la revisión, seguridad o conformidad de un proceso.