DEV Community: Raúl González (rafex)

Autoría, inteligencia artificial y del dominio público a la originalidad: lo que realmente resolvió el AD 6/2025

Raúl González (rafex) — Mon, 01 Jun 2026 02:10:56 +0000

"…el argumento jurídico más importante que nadie discutió: la sentencia terminó desplazando el debate desde la autoría hacia la propia noción de originalidad."

El Amparo Directo 6/2025 de la Suprema Corte de Justicia de la Nación fue presentado por la mayoría de los medios como un asunto simple: la inteligencia artificial no puede ser autora. Correcto, pero incompleto. Una lectura del expediente completo —tanto del proyecto de sentencia como del engrose definitivo— revela dos conversaciones distintas: la que se publicó antes de la sesión y la que realmente quedó en la resolución vinculante. Y en la diferencia entre ambas está el argumento jurídico más importante que nadie discutió.

1. Lo que circuló en los medios: el dominio público de toda obra generada con IA

Antes de la sesión del 2 de julio de 2025, la SCJN publicó el proyecto de sentencia —un documento de trabajo que no constituye resolución vinculante. En ese proyecto, la Segunda Sala incluyó los siguientes párrafos:

“100. Por lo tanto, el producto de la IA es una extensión de la capacidad creativa de la humanidad. Por ello, lo realizado por la IA no es susceptible de registro y, en consecuencia, dichos productos pasan al dominio público con el fin de que se difundan gratuitamente sobre todo si el producto puede beneficiar a toda la humanidad.”

“101. En conclusión, los productos de la IA son de dominio público por no ser una obra original y, en consecuencia, no son registrables ya que se basan en conocimientos previos que tiene en su conjunto la humanidad.”

“102. Lo anterior, no significa que no pueda registrarse los software o los programas informáticos por los cuales se crea una IA... no menos cierto es que el hecho de pagar por esta, no significa que los 'productos' obtenidos como resultado de su empleo pasen a ser propiedad del suscriptor, sino que siguen siendo estos de dominio público.”

“103. ...aquellos 'productos' emitidos como resultado de la implementación, uso o aprovechamiento de la IA, con independencia de si se paga por obtener un beneficio mayor para su aprovechamiento, pasan a ser de dominio público.”

Esos párrafos generaron titulares inmediatos. La narrativa que circuló fue: la Corte declaró que todo lo creado con IA es dominio público.

Hay un problema con eso.

2. El matiz que los medios omitieron: proyecto ≠ engrose firmado

El documento que contiene los párrafos 100 a 103 es el proyecto de sentencia (scjn-ad-6-2025.pdf), el borrador que se publica antes de la discusión en sesión para transparencia. No es la resolución.

La sentencia definitiva —el engrose firmado (2_346361_7265_firmado.pdf)— es el documento vinculante. Y ese engrose termina en el párrafo 85, antes de cualquier mención al dominio público.

Los párrafos 100 a 103 simplemente no existen en la resolución obligatoria.

Esto no es un tecnicismo menor. En el derecho mexicano, el proyecto es un insumo de deliberación; el engrose es la ley del caso. Lo que no quedó en el engrose no puede invocarse como precedente ni como criterio jurisprudencial.

Por eso la pregunta correcta no es ”¿qué dijo el proyecto?” sino ”¿qué resolvió la Corte?”

3. Lo que sí resolvió la Corte: tres conclusiones que sí quedaron

El engrose del AD 6/2025 establece tres cosas con claridad:

Primera. La IA no puede ser autora. El artículo 12 de la LFDA es explícito: ”Autor es la persona física que ha creado una obra literaria y artística.” La Corte confirmó que esa definición excluye a cualquier ente artificial.

Segunda. La IA no puede ser titular de derechos morales. El artículo 18 de la LFDA reserva esa titularidad al autor como persona física. Los derechos morales son personalísimos, irrenunciables e inalienables —atributos que no pueden predicarse de un sistema computacional.

Tercera. El caso concreto tenía un planteamiento muy específico. El propio promovente reconoció ante el INDAUTOR que ”la inteligencia artificial fue quien tuvo la capacidad de tomar la decisión en realizar la actividad creativa” y solicitó expresamente los derechos morales para la IA, reservando para sí únicamente los derechos patrimoniales:

Derecho solicitado	Titular propuesto
Derechos morales	Inteligencia Artificial Leonardo
Derechos patrimoniales	Gerald García Báez

La controversia no era ”¿puede una persona registrar una obra asistida por IA?” Sino ”¿puede una IA ser reconocida como autora y titular de derechos morales?” Esa pregunta, con ese planteamiento, tiene una respuesta legal clara en México: no.

Hasta aquí, la resolución es sólida. El problema empieza cuando se avanza un paso más.

4. El problema jurídico real: `originalidad = creación humana`

Dentro del engrose sí quedó un razonamiento que merece análisis cuidadoso. La Corte no se limitó a decir que la IA no puede ser autora —fue más lejos al abordar el concepto mismo de originalidad. En los párrafos 43 y 44 del engrose, la Segunda Sala valida el argumento del TFJA en estos términos:

“43. La Sala Especializada en Materia de Propiedad Intelectual del TFJA, mencionó que, conforme al artículo 3o. de la LFDA, se exige el requisito de originalidad para registrar una obra, la cual deriva por la creatividad humana y no a partir de una inteligencia artificial. Por ende, la Sala señaló que la generación del contenido artificial, como el diseño de la representación gráfica asociada que el actor pretendió registrar, no es producto de una creación humana, por lo que no se cumplió con las condiciones exigidas por la ley en la materia.”

“44. De lo anterior se desprende que, como refirió la Sala responsable, la obra no fue generada por un ser humano, por lo que no tiene condiciones para calificar su originalidad y, por ende, no puede ser reconocida para efecto de registro ante el INDAUTOR.”

Ahí está la ecuación:

❌ sin creación humana → ❌ sin originalidad posible → ❌ sin obra protegible

El problema es que esa ecuación no está escrita en la ley. Veamos los dos artículos por separado:

Artículo 12 LFDA — ”Autor es la persona física que ha creado una obra literaria y artística.”
→ Regula quién puede ser autor. Requisito: persona física.

Artículo 3 LFDA — ”Las obras protegidas por esta Ley son aquellas de **creación original* susceptibles de ser divulgadas o reproducidas en cualquier forma o medio.”*
→ Regula qué es una obra protegible. Requisito: creación original. La LFDA no contiene una definición legislativa expresa de originalidad que equipare dicho concepto con la ausencia de herramientas de inteligencia artificial. Tampoco contiene una disposición que establezca que el uso de inteligencia artificial excluye por sí mismo la originalidad de una obra.

La sentencia parece trasladar al concepto de originalidad el requisito de creatividad humana que explícitamente aparece en el régimen de autoría, aunque sin desarrollar una metodología para determinar cuándo una intervención humana resulta suficiente dentro de procesos creativos asistidos por inteligencia artificial.

Esa lectura tiene consecuencias que van mucho más allá del caso concreto, porque la Corte no estableció ningún umbral: no hay criterio para medir cuánta intervención humana es suficiente para que una obra sea "original" en el sentido del artículo 3.

5. Las preguntas que siguen abiertas

Si la ecuación originalidad = creación humana queda como criterio orientador, surgen preguntas que el AD 6/2025 no responde:

¿La Corte está hablando de IA o de autonomía creativa? Porque el caso concreto no es realmente: uso de IA sino delegación de la creatividad a la IA. Eso es diferente.

¿Qué pasa con las obras asistidas por IA? Una fotografía seleccionada y editada por un humano usando herramientas generativas. Una composición musical donde la IA propone acordes y el músico elige, descarta, reordena. Un guion escrito con sugerencias de un modelo de lenguaje que el autor acepta, rechaza y transforma. ¿Dónde termina la “creatividad humana” suficiente?

¿Puede el Estado presumir ausencia de creatividad humana por el solo uso de IA? La LFDA no excluye herramientas tecnológicas del proceso creativo. Un fotógrafo usa cámaras, un músico usa DAWs, un diseñador usa Photoshop, un programador usa compiladores. La pregunta jurídica históricamente ha sido sobre la aportación creativa, no sobre el instrumento. Si la Corte desplaza esa pregunta hacia la naturaleza de la herramienta, cambia el estándar sin que el legislador lo haya ordenado.

¿Quién tiene la carga de probar la intervención humana? El engrose no lo dice. Si la presunción futura es que toda obra con IA es no-original, la carga recaería en el creador. Si la presunción es la contraria, recaería en quien impugna. Esa asignación no es neutra.

¿Necesita actuar el legislador o puede la jurisprudencia desarrollar el umbral? El AD 6/2025 resolvió un caso extremo —donde el propio promovente cedió la creatividad a la máquina. No resolvió los casos intermedios. Y esos casos intermedios son los que hoy tienen relevancia práctica para millones de creadores.

La dificultad es que el engrose nunca explica cómo debe evaluarse la creatividad humana cuando ésta existe, pero convive con herramientas de inteligencia artificial dentro del mismo proceso creativo.

Porque hoy prácticamente todas las herramientas creativas ya tienen IA integrada.

¿Qué hacer hoy?

Mientras el debate jurídico evoluciona, la medida más concreta disponible es documentar el proceso creativo desde el inicio:

Historial de versiones (Git, commits, snapshots)
Prompts, iteraciones y resultados descartados
Archivos fuente (PSD, Krita, Blender, DAW, etc.)
Capturas del proceso creativo
Registro de decisiones artísticas y selección de resultados

Si el argumento jurídico que finalmente prospere es que hay originalidad cuando hay contribución creativa humana demostrable, esa evidencia será lo que distinja una obra protegible de una que no lo es.

El AD 6/2025 resolvió correctamente que una inteligencia artificial no puede ser autora bajo el marco legal vigente. Sin embargo, el verdadero desafío jurídico no está en las obras creadas exclusivamente por sistemas de IA, sino en las obras creadas por personas que utilizan inteligencia artificial como herramienta.

La pregunta relevante para el futuro del derecho de autor mexicano ya no es si una máquina puede ser autora. La pregunta es cómo identificar, medir y acreditar la contribución creativa humana dentro de procesos de creación cada vez más asistidos por sistemas automatizados.

Esa cuestión permanece abierta. Y probablemente será mucho más importante para los creadores mexicanos que la controversia específica que dio origen al Amparo Directo 6/2025.

Lo que este caso no resolvió

"Este caso no era una obra asistida por IA."

El propio promovente sostuvo que la actividad creativa correspondía a la IA.

Por ello, la sentencia no analizó obras híbridas ni obras asistidas por inteligencia artificial en las que una persona física conserve la dirección creativa principal.

Referencias

SCJN Amparo Directo 6/2025 — Proyecto de sentencia

SCJN Amparo Directo 6/2025 — Engrose firmado

INDAUTOR reconoce la decisión de la SCJN sobre el registro de obras creadas con IA

Ley Federal del Derecho de Autor (LFDA)

Programando con Agentes de IA

Raúl González (rafex) — Sun, 31 May 2026 17:21:41 +0000

La ironía de la IA: los programadores tendremos que hacer justo lo que menos nos gustaba

Durante años existió una especie de consenso silencioso entre muchos desarrolladores:

Documentar era aburrido
Escribir pruebas era algo que se hacía cuando había tiempo.

La parte divertida era construir funcionalidades. Crear productos. Resolver problemas. Escribir código.

Las dos habilidades que más valor están ganando son precisamente documentar y escribir pruebas.

Cuando el programador era la memoria del sistema

Durante décadas gran parte del conocimiento de los proyectos vivía dentro de las cabezas de los desarrolladores. Y actualmente sigue siendo así en casos concretos, ejemplo COBOL.

Sabíamos...

...por qué una función estaba escrita de cierta manera.
...qué endpoints no se debían tocar.
...qué módulo era delicado.
...cuáles eran las reglas de negocio que nunca aparecían en ningún documento.

El problema es que ese conocimiento no escala ni para equipos ni para agentes.

La IA no puede leer tu mente

Los agentes actuales son impresionantes.

Claude Code, OpenCode, Codex, Cursor y otras herramientas pueden generar miles de líneas de código en minutos.

Pero tienen una limitación fundamental:

No pueden leer la mente del equipo.
No conocen las decisiones arquitectónicas que se tomaron hace dos años.
No saben qué convenciones son obligatorias.
No entienden qué partes del sistema son especialmente sensibles (para el negocio).

Solo conocen el contexto que les proporcionamos: Por eso la documentación deja de ser un lujo y se convierte en infraestructura. Ya no documentamos únicamente para futuros desarrolladores.

Documentamos para los agentes que están generando código hoy.

El surgimiento de una nueva documentación

No es casualidad que estén apareciendo estándares como AGENTS.md o propuestas más completas como Agent OS.

Ambos parten de la misma idea: proporcionar contexto estructurado para que los agentes trabajen de forma consistente dentro de un proyecto.
La documentación ya no sirve solamente para onboarding o transferencia de conocimiento.
Ahora también sirve para guiar a los agentes que generan código.

Lo interesante es que estas iniciativas no intentan enseñar a programar a la IA.

Intentan enseñarle cómo programamos nosotros.

La documentación se convierte en contexto ejecutable

Antes un documento podía quedar olvidado durante meses sin generar grandes problemas.

Ahora una buena documentación puede influir directamente en miles de líneas de código generadas por IA.

La documentación dejó de ser pasiva. Se convirtió en una herramienta operativa.

Los tests también cambiaron de función

Los tests protegen conocimiento del negocio cuando la IA modifica el código.

El nuevo perfil del desarrollador

La programación no está desapareciendo.

Está evolucionando.

Cada vez dedicaremos menos tiempo a escribir código repetitivo y más tiempo a definir contexto, reglas, restricciones y criterios de aceptación.

En otras palabras:

Menos tiempo escribiendo implementaciones.
Más tiempo describiendo sistemas.
Menos tiempo creando funciones.
Más tiempo definiendo comportamientos.
Menos tiempo produciendo código.
Más tiempo produciendo conocimiento.
Más tiempo validando.

Ejemplos:

# AGENTS.md

- Usa TypeScript strict
- No uses any
- Ejecuta tests antes de cada PR
- Nunca usar float para cálculos monetarios

// implementación...

import Decimal from 'decimal.js';

export function calculateTotal(
  amount: Decimal,
  taxRate: Decimal
): Decimal {
  return amount.plus(amount.mul(taxRate));
}

// test

it('does not allow withdrawing more money than the available balance', () => {
  const account = new Account(100);

  expect(() => account.withdraw(150)).toThrow(
    InsufficientFundsError
  );
});

"Porque escribir código ya no es el recurso más escaso. La claridad sí."

Referencias

AGENTS.md: https://agents.md/
Agent OS: https://buildermethods.com/agent-os

Claude Code Leak: cuando el hype supera a la ingeniería

Raúl González (rafex) — Wed, 01 Apr 2026 18:55:54 +0000

El día de ayer circularon titulares alarmantes:

“Se filtraron más de 500 000 líneas del código de Claude Code”.

Sin embargo, al analizar el incidente con calma, la realidad es mucho menos dramática.
Lo que realmente se publicó por error fue un source map.

Y el código funcional ya estaba disponible en el paquete npm del proyecto.

1️⃣ El punto de partida: el bundle JS ya estaba público

Si el paquete npm ya incluía el bundle JS, entonces:

La lógica del programa ya estaba disponible.
Cualquiera podía analizarlo con:
- deobfuscadores
- herramientas AST
- agentes LLM
- ingeniería inversa clásica.

En otras palabras:

El bundle JS ya contiene la lógica ejecutable del programa.

El .map no agrega lógica nueva.

Solo agrega:

nombres originales
estructura de archivos
comentarios
metadata de compilación.

Por lo tanto no revela funcionalidad que no estuviera ya ahí.

🧪 Ejemplo simple: cómo funciona un source map

Para entender por qué el .map no contiene lógica nueva, veamos un ejemplo mínimo.

Código original (TypeScript)

export function sum(a: number, b: number): number {
  return a + b;
}

Código compilado/minificado (JavaScript distribuido)

function a(b,c){return b+c}

Este es el código que normalmente termina dentro del bundle publicado en npm.

Archivo source map (simplificado)

Un .map contiene información que permite relacionar el bundle con el código original:

{
  "version": 3,
  "sources": ["src/math.ts"],
  "names": ["sum","a","b"],
  "mappings": "AAAA,SAASA,IAAIC,EAAGC..."
}

Ese archivo indica cosas como:

qué archivo original generó ese código
cómo se llamaban realmente las funciones
qué variables corresponden a qué posiciones en el bundle

Con esa información una herramienta puede hacer esto:

bundle.js + bundle.js.map
        ↓
reconstruir
        ↓
src/math.ts

Pero observa algo importante:

La lógica (return a + b) ya estaba en el bundle.

El source map solo permite reconstruir:

nombres originales
estructura de archivos
posiciones de código

No añade comportamiento nuevo al programa.

2️⃣ Lo que realmente aporta el .map: información para humanos

Esto es clave:

los nombres y comentarios son para humanos

Un agente puede inferir cosas como:

function a(b,c){...}

→ inferir que probablemente es:

executeAgentTask(task, context)

Hoy con análisis semántico eso es trivial.

Por eso muchos proyectos open-source publican directamente el JS compilado sin preocuparse demasiado.

3️⃣ El bundle no “oculta” arquitectura

El bundle no elimina la arquitectura del programa; simplemente reduce su legibilidad.

Aunque esté minificado, aún puedes ver:

imports
llamadas a APIs
flujo del programa
dependencias
estructura de módulos

Ejemplo:

require("./agentLoop")
require("./tools/fileTool")

Eso ya te revela cómo funciona el runtime.

4️⃣ Lo que sí cambia el .map (pero no dramáticamente)

El .map reduce el trabajo humano.

Caso	Esfuerzo
bundle minificado	medio
bundle + LLM	bajo
bundle + map	inmediato

Pero no cambia la información disponible, solo la fricción para analizarla.

Bundle publicado en npm
        ↓
Código JavaScript ejecutable
        ↓
Puede analizarse con
- herramientas AST
- ingeniería inversa
- agentes LLM

Source map
        ↓
solo añade
- nombres originales
- estructura de archivos
- comentarios

5️⃣ El verdadero motivo del ruido mediático

Las noticias exageran por tres razones:

~~“512 000 líneas filtradas”~~ suena dramático

Pero esas líneas ya estaban en el bundle.

~~“código interno de Anthropic”~~

Pero Claude Code no es el modelo ni la infraestructura.

narrativa de ~~“AI company leak”~~

Eso genera clics.

6️⃣ Qué sí sería un leak serio

Algo realmente grave sería filtrar:

pesos del modelo
prompts internos del sistema
pipelines de entrenamiento
datasets
infra de serving
estrategias de RLHF

Eso no ocurrió.

7️⃣ En resumen

El “leak” de Claude Code no es un leak real, sino un source map.
El bundle JS ya estaba público, por lo que la lógica del programa ya era accesible.
El .map solo facilita la lectura humana, pero no revela funcionalidad nueva.
El impacto técnico real es limitado, aunque el hype mediático ha sido grande.

map file ≠ código nuevo
map file = metadata para humanos

El código funcional ya estaba público en npm.

Por eso varios desarrolladores también han comentado que la noticia es más hype que incidente de seguridad real.

Este episodio deja una lección simple:

Si publicas JavaScript en npm, tu lógica ya es pública.

Los source maps solo hacen que el código sea más fácil de leer para humanos.

La verdadera propiedad intelectual de las empresas de IA no está en el CLI que distribuyen,
sino en:

los modelos
los datos
la infraestructura
los sistemas de entrenamiento

Nada de eso fue filtrado en este caso.
Lo único que ocurrió fue que un archivo de depuración llegó a producción.

Este caso también sirve como recordatorio para leer con espíritu crítico las noticias sobre “filtraciones” tecnológicas.
Muchas veces el impacto técnico real es muy diferente al que sugieren los titulares.

COBOL, IA y la democratización del conocimiento técnico

Raúl González (rafex) — Tue, 17 Mar 2026 08:01:22 +0000

Durante décadas, COBOL fue el corazón de muchos sistemas críticos del mundo: banca, seguros, aerolíneas y gobierno.

No porque fuera el único lenguaje capaz de resolver esos problemas, sino porque estaba profundamente integrado con el ecosistema de mainframes, donde gran parte del conocimiento técnico estaba concentrado en pocos lugares.

Aprender COBOL en serio significaba, muchas veces:

trabajar dentro de una gran organización,
acceder a entornos mainframe,
o aprender de consultores especializados.

El conocimiento estaba ahí, pero no era fácilmente accesible.

Durante muchos años, ese modelo funcionó. La tecnología y el conocimiento estaban controlados por un ecosistema relativamente cerrado.

Hoy el panorama es muy distinto. Con la aparición de herramientas abiertas, documentación pública y ahora inteligencia artificial, entender sistemas heredados o incluso escribir código COBOL ya no requiere acceso a un mainframe corporativo.

De hecho, hoy puedes programar COBOL desde tu laptop con Linux usando un compilador open source.

Y ahí aparece una ironía interesante de la historia tecnológica:

Muchos de los expertos que durante años formaron parte de un ecosistema donde el conocimiento era escaso y difícil de acceder, hoy participan activamente en difundir ese conocimiento en internet.

El resultado es algo positivo:

una democratización del conocimiento técnico.

Y para demostrarlo, hagamos algo simple. Programar COBOL en Linux.

Programando COBOL hoy en Linux

Existe un compilador open source llamado GnuCOBOL, disponible en la mayoría de distribuciones Linux.

Este compilador traduce código COBOL a C y luego usa el compilador de C del sistema para generar el ejecutable. Es decir:

COBOL funcionando sobre un stack completamente open source.

Instalar el compilador

En Debian o Ubuntu:

sudo apt update
sudo apt install gnucobol

Verificamos la instalación:

cobc -v

Nuestro primer programa COBOL

Creamos un archivo llamado:

hola.cob

Con el siguiente contenido:

IDENTIFICATION DIVISION.
PROGRAM-ID. HOLA.

PROCEDURE DIVISION.
DISPLAY "Hola mundo desde COBOL en Linux".
STOP RUN.

COBOL tiene una estructura muy clásica basada en divisiones:

IDENTIFICATION DIVISION → metadatos del programa
DATA DIVISION → definición de datos
PROCEDURE DIVISION → lógica del programa

En este ejemplo solo usamos la parte más simple.

Compilar el programa

Usamos el compilador:

cobc -x hola.cob

Esto generará un ejecutable llamado:

hola

Ahora lo ejecutamos:

./hola

Resultado:

Hola mundo desde COBOL en Linux

Lo interesante de todo esto

Hace algunas décadas, compilar COBOL implicaba tener acceso a:

un mainframe
licencias costosas
y conocimientos muy específicos del entorno

Hoy puedes hacerlo con:

Linux
software open source
y documentación pública

Esto refleja un cambio profundo en la industria tecnológica.

El verdadero cambio no es solo la modernización de sistemas COBOL con IA.

El cambio real es que el conocimiento que antes estaba concentrado ahora está disponible para cualquiera que quiera aprenderlo.

Y eso, probablemente, sea una de las transformaciones más importantes de nuestra industria.

Cómo la IA está ayudando a modernizar COBOL

Aquí es donde entra el fenómeno actual.

Durante muchos años, modernizar sistemas COBOL implicaba:

leer millones de líneas de código
entender dependencias
reescribir todo manualmente

Un proceso extremadamente caro y lento.

Hoy la IA está empezando a ayudar en tres áreas clave.

¿Por qué deberíamos decir bibliotecas y no librerías en software?

Raúl González (rafex) — Wed, 25 Feb 2026 19:03:57 +0000

Uno de los errores más comunes que cometemos al hablar de programación en español es referirnos a las software libraries como “librerías”. Aunque parezca una traducción directa e inocente, este término es, en realidad, un falso amigo. En este artículo te explico por qué deberíamos usar la palabra correcta: bibliotecas.

🧠 La trampa del falso amigo

En inglés, library hace referencia a una colección organizada de funciones, clases o recursos reutilizables. En español, la palabra más cercana por significado no es “librería” (que es una tienda de libros), sino biblioteca. Ambas palabras comparten raíz etimológica (liber en latín, biblion en griego), pero tomaron caminos distintos.

Así que cuando decimos ~~“librería de software”~~, estamos usando una palabra que en español significa otra cosa completamente diferente. Es como si tradujéramos actually como “actualmente” cuando realmente significa “en realidad”.

📌 ¿Y por qué importa?

Porque el lenguaje técnico también construye pensamiento. Usar correctamente “biblioteca” en lugar de “librería” no es solo una cuestión de purismo lingüístico: es una forma de comunicarnos con precisión y evitar malentendidos, especialmente cuando explicamos conceptos a personas que están aprendiendo.

Además, muchas traducciones oficiales y comunidades en español ya han adoptado este estándar. Por ejemplo:

En Python, hablamos de la biblioteca estándar.
En Java, usamos el término bibliotecas externas.

📚 Conceptos relacionados

Aquí tienes algunos términos útiles para entender mejor este fenómeno lingüístico:

Falso amigo (False friend)

Palabras que parecen similares en dos idiomas pero tienen significados diferentes. Por ejemplo: library → biblioteca, no librería.
Traducción literal (Literal translation)

Traducir palabra por palabra sin considerar el contexto real.
Calco lingüístico

Adoptar literal y directamente una expresión extranjera, aunque no sea natural en el idioma destino.
Anglicismo

Uso innecesario o incorrecto de una palabra en inglés cuando existe una opción correcta en español.
Malapropismo

Error en el uso de una palabra confundiéndola con otra de sonido similar.

🤔 ¿Y si ya todo el mundo dice “librería”?

Es verdad que el uso está bastante extendido. Pero eso no significa que sea correcto ni que no podamos mejorar nuestra precisión técnica. Muchos términos se han ido afinando con el tiempo, y este es uno que vale la pena corregir.

🇫🇷 Bonus: ¿y en francés?

Sí, es totalmente cierto: en francés, el término correcto para software library también es bibliothèque, no librairie.

Library (software) → bibliothèque logicielle
Librairie → tienda de libros

En la documentación oficial de Python en francés se habla de la “bibliothèque standard de Python”.

The World of Rafex's

¿Te gustó este artículo? ¡Comparte y ayúdame a promover un uso más preciso del lenguaje técnico! 💬

DEV Community: Raúl González (rafex)

Autoría, inteligencia artificial y del dominio público a la originalidad: lo que realmente resolvió el AD 6/2025

1. Lo que circuló en los medios: el dominio público de toda obra generada con IA

2. El matiz que los medios omitieron: proyecto ≠ engrose firmado

3. Lo que sí resolvió la Corte: tres conclusiones que sí quedaron

4. El problema jurídico real: originalidad = creación humana

5. Las preguntas que siguen abiertas

¿Qué hacer hoy?

Lo que este caso no resolvió

Referencias

Programando con Agentes de IA

La ironía de la IA: los programadores tendremos que hacer justo lo que menos nos gustaba

Cuando el programador era la memoria del sistema

La IA no puede leer tu mente

El surgimiento de una nueva documentación

La documentación se convierte en contexto ejecutable

Los tests también cambiaron de función

El nuevo perfil del desarrollador

Ejemplos:

Referencias

Claude Code Leak: cuando el hype supera a la ingeniería

1️⃣ El punto de partida: el bundle JS ya estaba público

🧪 Ejemplo simple: cómo funciona un source map

Código original (TypeScript)

Código compilado/minificado (JavaScript distribuido)

Archivo source map (simplificado)

2️⃣ Lo que realmente aporta el .map: información para humanos

3️⃣ El bundle no “oculta” arquitectura

4️⃣ Lo que sí cambia el .map (pero no dramáticamente)

5️⃣ El verdadero motivo del ruido mediático

6️⃣ Qué sí sería un leak serio

7️⃣ En resumen

Este episodio deja una lección simple:

COBOL, IA y la democratización del conocimiento técnico

Programando COBOL hoy en Linux

Instalar el compilador

Nuestro primer programa COBOL

Compilar el programa

Lo interesante de todo esto

Cómo la IA está ayudando a modernizar COBOL

¿Por qué deberíamos decir bibliotecas y no librerías en software?

🧠 La trampa del falso amigo

📌 ¿Y por qué importa?

📚 Conceptos relacionados

🤔 ¿Y si ya todo el mundo dice “librería”?

🇫🇷 Bonus: ¿y en francés?

4. El problema jurídico real: `originalidad = creación humana`