Licencias de código abierto para software de investigación: elegir una licencia

Elegir una licencia de código abierto para el código de investigación es una de las decisiones más importantes que toma un investigador, y una que la mayoría de los estudiantes graduados e investigadores principales encuentran por primera vez sin ninguna capacitación formal.

Su elección de licencia determina quién puede usar su código, cómo pueden usarlo, si se abordan las reclamaciones de patentes y si las modificaciones posteriores permanecen abiertas. Afecta directamente a la reproducibilidad, atribución y cumplimiento de los mandatos del financiador. Sin embargo, la comunidad de investigación no tiene un recurso educativo estándar que guíe a los investigadores a través del proceso de decisión real, compare las principales licencias en un lenguaje sencillo o explique la intersección frecuentemente confundida de licencias de datos y licencias de software.

Esta guía aborda esa brecha. Lleva a los investigadores a los pasos prácticos de elegir una licencia, compara las opciones principales, explica los requisitos de financiador, aclara la distinción de datos frente a código y describe las consideraciones institucionales antes de publicar el código.

Por qué es importante la elección de licencia

El concepto erróneo más importante en la comunidad de investigación es que publicar código sin licencia significa que es de dominio público o utilizable libremente. no lo es Según la ley de derechos de autor, el código sin un archivo de licencia explícito sigue siendo totalmente protegido por derechos de autor, lo que significa que nadie más puede copiarlo, modificarlo o distribuirlo legalmente, ni siquiera en entornos académicos. Esta es la realidad legal fundamental que todo equipo de investigación debe entender antes de compartir el código públicamente.

https://open-science-training-handbook.gitbook.io/book/02OpenScienceBasics/03OpenResearchSoftwareAndOpenSource Documenta explícitamente este concepto erróneo y enumera otros mitos comunes sobre las licencias de código abierto.

Más allá del cumplimiento legal, su elección de licencia tiene consecuencias directas para tres áreas:

reproducibilidad

Una licencia de código abierto otorga a otros investigadores permiso legal para ejecutar, modificar y reproducir su trabajo. Sin él, incluso los investigadores que quieren reproducir sus resultados se enfrentan a la incertidumbre legal, una barrera que socava el movimiento de reproducibilidad en la ciencia computacional.

Atribución

Diferentes licencias manejan la atribución de manera diferente. Las licencias permisivas como MIT y BSD requieren atribución en las redistribuciones de fuentes, mientras que las licencias de copyleft como GPL incorporan los requisitos de atribución profundamente en sus términos. La licencia que elija determina cómo se acredita su contribución aguas abajo.

Cumplimiento del financiador

Los principales financiadores de investigación ahora tienen expectativas explícitas de licencia. La política de datos de software de la NASA 41A (SPD-41A) requiere explícitamente una licencia de código abierto permisivo para todo el software desarrollado por proyectos y, en general, prohíbe las licencias patentadas o disponibles en código fuente. Horizon Europe espera licencias permisivas alineadas en la feria. Guía de mejores prácticas de NIH hacia licencias públicas de código abierto. Ignorar estos requisitos puede crear violaciones de cumplimiento después de la publicación.

El proceso de decisión

Elegir una licencia es una decisión estructurada, no una selección aleatoria. Siga estos pasos:

Paso 1: aclara lo que quieres que hagan los demás

Pregúntese: ¿Quiere que otros usen su código libremente en proyectos propietarios, o desea que todas las modificaciones sigan siendo de código abierto? Esta pregunta impulsa el resto de la decisión.

Si desea la máxima adopción, incluido el uso de la industria, los proyectos propietarios y la distribución comercial sin restricciones, las licencias permisivas (MIT, BSD) son apropiadas. Si desea que los trabajos derivados permanezcan de código abierto, las licencias CopyLeft (GPL) son la opción.

Paso 2 — Considere las implicaciones de patente

Si su investigación involucra algoritmos novedosos, métodos de aprendizaje automático o integración de hardware, el riesgo de patentes se vuelve relevante. Apache 2.0 es la única licencia permisiva ampliamente utilizada con una subvención de patente explícita. Esto significa que los colaboradores otorgan a los usuarios posteriores una licencia para cualquier reclamo de patente en poder de los contribuyentes para el código dentro del proyecto. MIT, BSD y GPL no contienen subvenciones explícitas de patentes (GPLV3 incluye una cláusula de represalia de patentes pero ninguna subvención contributiva).

Paso 3: alinear con las convenciones comunitarias

Estudie las licencias utilizadas por proyectos similares en su subcampo. Una biblioteca de métodos numéricos en la ciencia de los materiales computacionales debe considerar qué licencias utilizan los marcos establecidos. La alineación de la comunidad reduce la fricción para los contribuyentes y usuarios.

Para un contexto más profundo sobre los flujos de trabajo de desarrollo de código abierto en entornos de investigación, consulte nuestra guía sobre Contribuir a FIPY, que explica cómo funciona en la práctica el código orientado a la comunidad.

Paso 4: comprobar los requisitos institucionales

Muchas universidades requieren la aprobación de la oficina de transferencias tecnológicas antes de lanzar software bajo una licencia de código abierto. Los contratos de trabajo pueden restringir las decisiones de concesión de licencias. Verifique siempre la política institucional antes de aplicar cualquier licencia.

Paso 5 — Aplicar la licencia elegida

Coloque un archivo de licencia en la raíz del repositorio, denominado exactamente como el texto de la licencia (por ejemplo, LICENSE.mit, LICENSE.apache o LICENSE.gpl). Opcionalmente agregue encabezados de derechos de autor a los archivos de origen, aunque esto no es requerido por la mayoría de las licencias.

Use choosealicense.com como una herramienta interactiva para hacer coincidir su caso de uso con una recomendación de licencia.

Comparación de licencias

Las cuatro licencias más utilizadas en software de investigación son MIT, BSD, Apache 2.0 y GPL. Se dividen en dos familias:

• Permisivo (MIT, BSD, Apache 2.0): Permitir el uso patentado, exigir atribución, breve y simple
• Copyleft (GPL): Requiere que los trabajos derivados sigan siendo de código abierto y una protección comunitaria más fuerte

Licencia del MIT

La más simple de todas las licencias ampliamente utilizadas. un solo párrafo de texto que requiere atribución en las redistribuciones de origen. Sin concesión de patentes, sin copyleft, sin requisitos de compatibilidad para bibliotecas descendentes.

Lo mejor para: Máxima adopción. Cuando desee que se use su código en todas partes, en trabajos académicos, productos propietarios y derivados modificados, sin restricciones.

Adopción de la investigación: El MIT es la licencia más común entre los proyectos de código abierto con licencia (65%), según un estudio de Jahanshahi de 2026. Domina por su simplicidad y amplia compatibilidad con otros tipos de licencias.

Licencia BSD

Muy similar al MIT. La licencia BSD de dos cláusulas es funcionalmente equivalente a MIT. La variante de tres cláusulas agrega una cláusula de no aprobación explícita, lo que impide que otros usen su nombre para promover productos derivados.

Lo mejor para: cuando desee la máxima adopción más protección contra el uso indebido de respaldo. El BSD de tres cláusulas es común en la investigación financiada por el gobierno y las comunidades informáticas de alto rendimiento.

Apache 2.0

La única licencia permisiva ampliamente utilizada con una concesión de patente explícita. Más largo que el MIT o BSD (~200 líneas), incluye términos adicionales sobre el uso de marcas, avisos de derechos de autor y represalias de patentes contribuyentes.

Lo mejor para: Investigación con una exposición significativa a las patentes: algoritmos, métodos de IA, integración de hardware o proyectos comunitarios en los que los contribuyentes puedan tener patentes relevantes para el código.

Adopción de la investigación: Aproximadamente el 12% de los proyectos de código abierto con licencia utilizan Apache 2.0, lo que lo convierte en la segunda opción más común.

GPL (licencia pública general)

La licencia de copyleft más destacada. GPLV2 y GPLV3 son las dos versiones principales. GPLV3 incluye disposiciones anti-Tivoización (prevenir las restricciones de hardware en la ejecución de software modificado) y una cláusula de represalia de patente; GPLV2 carece de estas protecciones. Para el software de investigación moderno, GPLV3 es la elección actual.

Lo mejor para: cuando necesitas código descendente para permanecer de código abierto. GPL se asegura de que cualquier modificación o trabajo derivado distribuido públicamente también debe ser publicado bajo GPL.

Adopción de la investigación: Aproximadamente el 5% de los proyectos con licencia utilizan GPL. Es menos común en la investigación porque muchos investigadores prefieren términos permisivos para una máxima reutilización científica.

Tabla de comparación

La siguiente tabla resume las características clave en las cuatro licencias:

La tabla de comparación anterior sintetiza la guía de https://safeguard.sh/resources/blog/open-source-license-comparison-mit-apache-gpl-bsd y https://ospo.library.jhu.edu/learn-grow/licensing-overview/choose-a-license/ (Johns Hopkins OSPO).

Recomendación

Para la mayoría de los códigos de investigación: solucionadores numéricos, herramientas de simulación, scripts de análisis de datos, recomendamos MIT. Es el más simple, más compatible, y permite que cualquier persona que no use barreras legales utilice su código. La amplia adopción de MIT significa que los colaboradores no enfrentan problemas de compatibilidad de licencias al combinar su código con otras bibliotecas populares.

Elija Apache 2.0 cuando:

• Su investigación involucra algoritmos novedosos con exposición a patentes
• Desea una subvención de patente explícita para proteger a los usuarios intermedios
• Está construyendo un proyecto comunitario donde los contribuyentes pueden tener patentes relevantes

Elija GPL cuando:

• Debe garantizar que las modificaciones permanezcan de código abierto
• Su código es un marco o biblioteca donde la gestión de dependencias aguas abajo importa
• prioriza la aplicación de la apertura sobre la máxima adopción

Mandatos de financiador

Los financiadores de investigación esperan cada vez más prácticas de licenciamiento específicas. Ignorar estos requisitos crea el riesgo de cumplimiento después de la publicación.

NASA — SPD-41A

La política de datos de software de la NASA 41A (SPD-41A) requiere licencias permisivas de código abierto para todo el software desarrollado por proyectos. Las licencias patentadas o disponibles en la fuente generalmente se prohibieron para el código creado bajo la financiación de la NASA. Esto hace que la elección de licencias sea un requisito de cumplimiento, no solo una preferencia estratégica, para los equipos de investigación financiados por la NASA.

NIH — Política de código abierto

La Guía de Mejores Prácticas de los Institutos Nacionales de Salud (NIH) hacia las licencias públicas de código abierto. Si bien los NIH no exigen una licencia específica, su política de código abierto y su guía de software como SHA alientan enfáticamente los términos permisivos de código abierto para el software desarrollado con fondos de NIH.

Horizonte Europa

El Consejo Europeo de Investigación y las expectativas de financiación de Horizon Europe esperan explícitamente licencias permisivas alineadas a la feria para el software de investigación. Katz y sus colegas documentan cómo evolucionó esta política en rondas de financiación recientes y cómo los equipos de investigación europeos deben alinear sus decisiones de concesión de licencias con principios justos (https://open-research-europe.ec.europa.eu/articles/5-199).

Guías institucionales de RDM

Muchas universidades tienen políticas formales de gestión de datos de investigación (RDM) que abordan las licencias de software. La Guía de Max Planck RDM proporciona orientación práctica sobre la selección de licencias para software de investigación (https://rdm.mpdl.mpg.de/2023/05/02/how-to-select-a-license-for-research-software/), mientras que KU Leuven ofrece una lista de verificación explícita para la alineación justa Licencias (https://www.kuleuven.be/rdm/en/guidance/fair-research-software).

Orientación práctica: Si no está seguro de las expectativas de licencia de su financiador, consulte los términos y condiciones de su subvención o pregunte a su oficina de investigación. La mayoría de las políticas de financiador se publican públicamente y se pueden verificar antes de la publicación.

Licencia de datos frente a código

Una de las fuentes más comunes de confusión en el software de investigación es la relación entre las licencias de datos y las licencias de software. Los investigadores frecuentemente aplican la misma licencia a ambos, creando desajustes legales.

Creative Commons no funciona para el código

Las licencias de Creative Commons (CC) se diseñaron para datos, publicaciones y contenido educativo. Carecen de términos críticos que requiere la licencia de software:

• Términos de distribución de código fuente
• Términos de distribución binaria ejecutables
• Términos de enlace de la biblioteca
• Cláusulas de represalia de patente

Creative Commons recomienda explícitamente no usar licencias CC para software. Aplicar CC-BY o CC-BY-SA al código crea una ambigüedad legal en lugar de claridad.

Es posible que necesite dos licencias

Para proyectos de investigación que incluyen datos y código, el enfoque correcto es a menudo dos licencias separadas:

• Licencia CC para datos: CC-BY 4.0 para conjuntos de datos y publicaciones
• Licencia OSS para código: MIT, Apache 2.0 o GPL para software

https://www.rug.nl/digital-competence-centre/research-data/archive-and-publi sh/how-to-work-with-dataversenl/chooseing-a-licence-for-your-dataset?lang=es Proporciona orientación explícita sobre esta distinción para los equipos de investigación que gestionan tanto conjuntos de datos como software.

ejemplo práctico

Un proyecto que publica un solucionador numérico (código) junto con la salida de simulación (datos) debe:

1. Incluya LICENSE.mit para el código de solucionador (licencia MIT)
2. incluir LICENSE.cc-by-4.0 o similar para los archivos de datos
3. Documente ambas licencias en el repositorio Léame

Consideraciones de IP institucional

Antes de publicar el código bajo cualquier licencia de código abierto, debe verificar la política de propiedad intelectual (IP) institucional. Esta es la trampa administrativa más común para los investigadores académicos.

Oficinas de Transferencia de Tecnología Universitaria

La mayoría de las universidades consideran que el código de investigación es una propiedad intelectual institucional. Una Oficina de Transferencia Tecnológica (TTO) o una oficina equivalente generalmente posee los derechos de autor en el código escrito por los empleados como parte de sus funciones. La liberación de dicho código bajo una licencia de código abierto sin la aprobación de TTO puede constituir una violación de IP.

contratos de trabajo

Muchos contratos de empleo académico contienen cláusulas IP que especifican quién es el propietario de la investigación. Los miembros de la facultad pueden tener más flexibilidad que los investigadores postdoctorales o el personal de investigación. Verifique sus términos de contrato específicos.

Restricciones de la Agencia de Financiamiento

Algunas agencias de financiación imponen restricciones de licencia que van más allá de las propias expectativas de licencia de la agencia. Por ejemplo, ciertos programas DARPA o DOE pueden especificar familias de licencias particulares o exigir términos relacionados con la patente.

Pasos prácticos

1. Contacte con su oficina de transferencia tecnológica antes de publicar cualquier código bajo una licencia de código abierto
2. Revise su contrato de trabajo para conocer las cláusulas de propiedad de propiedad intelectual
3. Consulta los términos de la subvención para las restricciones de licencia
4. Aprobación institucional del documento en su repositorio o documentación

Próximos pasos prácticos

Si tiene código para publicar o código ya publicado sin licencia, aquí hay un plan de acción práctico:

antes de publicar

1. Aclare su intención de licencia — use el marco de decisión anterior (sección 2)
2. Verificar cumplimiento institucional — Comuníquese con su oficina de transferencias tecnológicas
3. Consulte los requisitos de financiador — Revise los términos de las subvenciones para las expectativas de licencias
4. Seleccione la licencia — use choosealicecense.com como guía

Después de seleccionar una licencia

1. Descargue el texto de la licencia de la fuente oficial (p. ej., choolalicences.com para MIT, Apache, BSD; fsf.org para GPL)
2. Crear un archivo de licencia en la raíz del repositorio con el texto de licencia exacto
3. Nombra el archivo consistentemente — usa LICENSE.mit, LICENSE.apache o LICENSE.gpl para mayor claridad
4. Agregar aviso de derechos de autor — El texto de la licencia generalmente incluye un marcador de posición para el año de derechos de autor y el nombre del autor. Rellene esto.
5. Documento en README — Indique la licencia utilizada, vincule el archivo de licencia y explique cómo otros pueden usar el código

Si ya tienes el código publicado

1. Agregar un archivo de licencia inmediatamente: incluso si el código no tenía licencia previamente, agregar una licencia es una corrección directa
2. Actualizar la documentación del repositorio — Aclarar los términos de licencia para los usuarios existentes
3. Notificar a los usuarios existentes — Si el código tiene usuarios, comunique los nuevos términos de licencia

Resumen

Elegir una licencia de código abierto para el software de investigación no es un detalle administrativo menor: es una decisión estratégica que afecta a quién puede usar su trabajo, cómo pueden usarlo y si su código cumple con los mandatos del financiador. El panorama es estable y está bien documentado: las licencias permisivas (MIT, BSD, Apache 2.0) permiten la máxima adopción, mientras que las licencias CopyLeft (GPL) garantizan la apertura descendente.

Para la mayoría de los códigos de investigación, el MIT es la opción recomendada debido a su simplicidad, amplia compatibilidad y adopción dominante (65% de los proyectos con licencia). Elija Apache 2.0 cuando la exposición de patentes sea relevante, y GPL cuando necesite garantizar que el código descendente permanecerá de código abierto.

Siempre verifique la política de propiedad intelectual institucional antes de aplicar cualquier licencia, distinga claramente entre licencias de datos (CC) y licencias de software (MIT, Apache, GPL) y asegúrese de cumplir con los requisitos del financiador. El concepto erróneo más grande, ese código sin licencia, es reutilizable libremente, es la razón fundamental por la que cada equipo de investigación debe elegir y publicar una licencia explícitamente.

Guías relacionadas

Si está interesado en extender sus prácticas de software de investigación más allá de las licencias, estas guías relacionadas brindan cobertura complementaria:

• Software científico de código abierto Sostenibilidad: modelos de financiación — Cubre la financiación Estrategias para la sostenibilidad del software de investigación, incluidas subvenciones, apoyo institucional y asociaciones de la industria. un compañero natural de las decisiones de concesión de licencias.
• construir comunidades de software de investigación sostenible — explora el desarrollo de la comunidad Prácticas, incorporación de colaboradores y modelos de gobernanza para proyectos de software de investigación. La concesión de licencias es un componente de la construcción de la comunidad.
• Flujos de trabajo de reproducibilidad más allá de los contenedores: versionado de datos y seguimiento de procedencias: cubre el control de versiones de datos, el seguimiento de procedencia y las prácticas de reproducibilidad que complementan las licencias de código abierto para flujos de trabajo de investigación completos.
• Prácticas de publicación reproducibles para los resultados de simulación: el Marco de cinco pilares: detalla el marco de cinco pilares para publicaciones científicas reproducibles, que incluye consideraciones de accesibilidad y licencia del código.

Lista de verificación: su selección de licencia en 5 minutos

1. ¿Qué quieres que hagan los demás? permisivo (MIT/BSD) para la máxima adopción; Apache 2.0 para protección de patentes; GPL para la apertura forzada
2. ¿Su institución requiere aprobación? Comuníquese con Tech Transfer Office antes de publicar
3. ¿Tiene su financiador requisitos? Verifique la NASA SPD-41A, Alineación de la Feria Horizon Europa, Expectativas de NIH
4. ¿También está publicando datos? Use CC para los datos; Usar OSS para el código
5. ¿Es el archivo de licencia en la raíz del repositorio? Agréguelo inmediatamente si falta

Siga esta lista de verificación antes de publicar cualquier código de investigación. Cubre el cumplimiento esencial y las consideraciones estratégicas que protegen tanto a usted como a sus usuarios.

Si está creando un software de investigación para una adopción más amplia, considere nuestra guía sobre construir comunidades de software de investigación sostenible, que cubre la incorporación de colaboradores, los modelos de gobernanza y las prácticas comunitarias que complementan las buenas decisiones de licencia.

Este artículo proporciona orientación educativa sobre licencias de código abierto para software de investigación. No constituye asesoramiento legal. Siempre consulte a la oficina de transferencia de tecnología de su institución y al asesor legal para cumplir con los requisitos de licencia específicos y las políticas de propiedad intelectual.