1. INTRODUCCIÓN Y CONTEXTUALIZACIÓN EN EL SAS

Cuando Richard Stallman inició el Proyecto GNU en 1983, probablemente no imaginaba que cuarenta años después su filosofía estaría sustentando los sistemas informáticos de uno de los mayores sistemas sanitarios públicos de Europa. Sin embargo, el Servicio Andaluz de Salud ha apostado decididamente por el software libre y de código abierto como pilar estratégico de su infraestructura tecnológica, una decisión que va mucho más allá del ahorro económico y que responde a principios de soberanía tecnológica, seguridad, transparencia y sostenibilidad.

El software libre representa en el SAS una realidad cotidiana que afecta a más de cien mil profesionales sanitarios. Desde el sistema operativo GECOS que encontramos en miles de puestos de trabajo hasta las bases de datos PostgreSQL que almacenan información clínica crítica, pasando por servidores web Apache que dan soporte a aplicaciones asistenciales o el sistema de virtualización OpenStack que sustenta la infraestructura cloud del Sistema Sanitario Público de Andalucía, el software libre está presente en cada capa tecnológica.

La apuesta andaluza por el software libre no es casual ni improvisada. Responde a una estrategia planificada que se concreta en el Plan de Software Libre de la Junta de Andalucía, coordinado por la Agencia Digital de Andalucía. Este plan establece directrices claras: priorizar soluciones de código abierto en las nuevas adquisiciones, garantizar la interoperabilidad mediante estándares abiertos, formar a los empleados públicos en estas tecnologías y desarrollar proyectos propios de software libre que puedan ser compartidos con otras administraciones.

Para comprender cabalmente este tema, es necesario entender que el software libre no es simplemente «software gratuito» ni tampoco un movimiento antiempresarial. Es una filosofía que coloca la libertad del usuario en el centro, garantizando que quien utiliza un programa pueda estudiarlo, modificarlo y redistribuirlo. Esta característica resulta especialmente valiosa en el sector público sanitario, donde la dependencia de proveedores únicos, la necesidad de auditar código por razones de seguridad y la importancia de la privacidad de los datos clínicos hacen del software libre una opción no solo viable sino deseable.

El contexto normativo también favorece esta apuesta. La Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos, ya establecía la obligación de utilizar estándares abiertos e interoperables. El Real Decreto 4/2010, que regula el Esquema Nacional de Interoperabilidad (ENI), concreta esta obligación indicando que las administraciones públicas deben utilizar preferentemente estándares abiertos y, en condiciones de igualdad, software de código abierto. Esta preferencia normativa se traduce en la práctica del SAS en una evaluación sistemática de alternativas libres antes de optar por soluciones propietarias.

1.1. Relevancia del tema en la oposición

Este tema ha demostrado ser de alta frecuencia en los exámenes del SAS. En el cuestionario de 2023 para Técnico Especialista en Informática apareció la pregunta 73 sobre GECOS, solicitando identificar qué es esta herramienta y quién la desarrolla. En el examen de 2025 de Técnico Titulado Medio encontramos hasta tres preguntas relacionadas: la número 64 sobre las libertades fundamentales del proyecto GNU, la 65 sobre ventajas del software libre frente al propietario y la 66 sobre el significado de LeTSAS (Linux embebido en Terminales del SAS).

Además, en el examen de 2019 para Técnico Especialista apareció la pregunta 37 preguntando cuál de varios sistemas operativos es Open Source, siendo la respuesta correcta Ubuntu. La pregunta 77 del mismo examen versaba sobre LibreOffice, y la 78 sobre las extensiones de archivo de esta suite ofimática. También en 2023, la pregunta 152 pedía identificar cuál de las libertades enunciadas NO forma parte de las cuatro esenciales del software libre.

Los supuestos prácticos también han incluido escenarios donde debías decidir entre software libre y propietario para el SAS, argumentar ventajas de migrar sistemas a plataformas abiertas o diseñar planes de implantación de GECOS en un hospital. Por tanto, no basta con memorizar conceptos: necesitas comprender las implicaciones prácticas y saber argumentar decisiones técnicas en contextos reales del Sistema Sanitario Público de Andalucía.

2. EL PROYECTO GNU Y LOS FUNDAMENTOS DEL SOFTWARE LIBRE

Para entender qué es el software libre debemos remontarnos a 1983, cuando Richard Stallman, programador del laboratorio de Inteligencia Artificial del MIT, decidió crear un sistema operativo completamente libre que fuera compatible con Unix pero sin depender de su código propietario. Stallman bautizó este proyecto como GNU, un acrónimo recursivo que significa «GNU No es Unix» (GNU’s Not Unix), jugando con el humor geek característico de la cultura hacker de la época.

2.1. Las cuatro libertades fundamentales

El concepto de software libre se define mediante cuatro libertades esenciales que debe garantizar cualquier programa para ser considerado como tal. Estas libertades no son negociables ni graduales: un software que no cumpla alguna de ellas no puede calificarse como libre, por mucho que tenga otras características aparentemente similares. Vamos a analizarlas en detalle porque aparecen frecuentemente en las preguntas de examen.

2.2. La Free Software Foundation y el ecosistema GNU

En 1985, Richard Stallman fundó la Free Software Foundation (FSF), una organización sin ánimo de lucro dedicada a promover el software libre y defender los derechos de los usuarios. La FSF ha desarrollado no solo software (el compilador GCC, el editor Emacs, la shell Bash, entre cientos de herramientas), sino también el marco legal que sustenta el movimiento: las licencias GNU.

La licencia más conocida es la GNU General Public License (GPL), actualmente en su versión 3. La GPL es lo que se conoce como una licencia «copyleft», un juego de palabras con «copyright» que significa que cualquier trabajo derivado debe mantener la misma licencia. Es decir, si modificas un programa GPL y lo redistribuyes, tu versión modificada debe ser también GPL. Esto garantiza que las mejoras no puedan ser «apropiadas» y convertidas en software propietario.

Existe también la GNU Lesser General Public License (LGPL), menos restrictiva, que permite el enlazado con software propietario, y la GNU Affero GPL (AGPL), que extiende el copyleft a los servicios de red. En el SAS encontramos software bajo todas estas licencias: el kernel Linux usa GPL v2, muchas bibliotecas sanitarias usan LGPL, y algunas aplicaciones web del SSPA utilizan AGPL para garantizar que las modificaciones realizadas por el SAS en servicios web también reviertan a la comunidad.

2.3. El proyecto GNU hoy: más que un sistema operativo

Aunque el proyecto GNU comenzó con el objetivo de crear un sistema operativo completo, hoy es mucho más que eso. Es un ecosistema completo de herramientas de desarrollo, utilidades del sistema, aplicaciones de usuario final y, crucialmente, un marco filosófico y legal para el desarrollo colaborativo de software. Cuando decimos GNU/Linux (la denominación correcta, aunque popularmente se diga solo «Linux»), estamos reconociendo que el kernel Linux, desarrollado por Linus Torvalds desde 1991, se combina con las herramientas GNU para formar un sistema operativo completo.

En el examen de 2023 para Técnico Especialista, la pregunta 30 planteaba explícitamente: «¿Cuál de las siguientes afirmaciones NO es correcta?» Una de las opciones era: «El Proyecto GNU se limita al sistema operativo, no incluye programas de aplicación». Esta afirmación es FALSA y era la respuesta correcta del examen. GNU incluye procesadores de texto, hojas de cálculo, herramientas científicas, juegos… es un ecosistema completo de software.

3. SOFTWARE LIBRE VS. CÓDIGO ABIERTO: DIFERENCIAS CONCEPTUALES

Aunque frecuentemente se usan como sinónimos, «software libre» y «software de código abierto» (Open Source) tienen matices diferentes que conviene entender. El término «código abierto» fue acuñado en 1998 por la Open Source Initiative (OSI) con un enfoque más pragmático y menos filosófico que el de la Free Software Foundation.

3.1. El énfasis filosófico del software libre

El movimiento del software libre, liderado por la FSF y Richard Stallman, pone el acento en cuestiones éticas y de libertad del usuario. Para Stallman y sus seguidores, el software propietario es éticamente problemático porque priva a los usuarios de libertades fundamentales. Usar software privativo es someterse al control de su desarrollador, que puede imponer actualizaciones, recopilar datos, restringir usos o dejar de dar soporte en cualquier momento.

Esta visión «militante» del software libre ha resultado incómoda para algunas empresas y ha generado resistencia en círculos empresariales. Sin embargo, sus principios resuenan fuertemente en el sector público, donde conceptos como transparencia, soberanía tecnológica y control democrático de las herramientas son valores centrales.

3.2. El pragmatismo del código abierto

El movimiento Open Source, por el contrario, enfatiza las ventajas prácticas del desarrollo colaborativo y el acceso al código fuente: mejor calidad del software, ciclos de desarrollo más rápidos, corrección más eficiente de errores de seguridad, mayor innovación… Los defensores del código abierto evitan el discurso ético y se centran en argumentos técnicos y económicos que resultan más aceptables para el mundo empresarial.

En la práctica, la inmensa mayoría del software libre es también código abierto, y viceversa. Las licencias GPL, por ejemplo, cumplen perfectamente los criterios de la Open Source Initiative. Sin embargo, existen algunas licencias que son «código abierto» pero no «software libre» según la FSF (generalmente porque imponen restricciones en ciertos campos de aplicación), y otras situaciones donde hay código fuente disponible pero no bajo una licencia libre reconocida.

3.3. Implicaciones para el SAS

En el contexto del SAS, la distinción es más bien académica. Lo importante es que tanto el discurso de libertades como el pragmático del código abierto convergen en justificar la apuesta por este tipo de software. Desde el punto de vista ético, el SAS, como servicio público, tiene la responsabilidad de utilizar tecnologías que permitan auditoría, transparencia y soberanía. Desde el punto de vista pragmático, el código abierto reduce dependencia de proveedores, abarata costes a largo plazo, mejora la seguridad mediante revisión comunitaria del código y permite adaptación a necesidades específicas del entorno sanitario andaluz.

4. VENTAJAS DEL SOFTWARE LIBRE EN EL ENTORNO SANITARIO

Las ventajas del software libre en general son ampliamente conocidas, pero conviene contextualizarlas específicamente al entorno del Sistema Sanitario Público de Andalucía, donde tienen particularidades y matices propios.

4.1. Reducción de costes y optimización presupuestaria

La ventaja más evidente, aunque no la más importante, es el ahorro en licencias. Un hospital típico del SAS con mil puestos de trabajo podría ahorrar cientos de miles de euros anuales en licencias de sistemas operativos, suites ofimáticas y software de utilidades utilizando alternativas libres como GECOS, LibreOffice y herramientas GNU. Multiplica esto por los más de cuarenta hospitales del SSPA y los más de mil quinientos centros de salud, y estaremos hablando de cifras millonarias que pueden reinvertirse en equipamiento médico o contratación de personal.

Sin embargo, el ahorro no es solo en licencias. El software libre tiende a tener menores requerimientos de hardware, lo que permite alargar la vida útil de los equipos. Un ordenador que sería insuficiente para ejecutar las últimas versiones de sistemas operativos propietarios puede funcionar perfectamente con una distribución GNU/Linux ligera. En un contexto de austeridad presupuestaria, este ahorro «oculto» puede ser significativo.

4.2. Independencia tecnológica y soberanía digital

El SAS gestiona información extraordinariamente sensible: historias clínicas de más de ocho millones de andaluces, datos genéticos, información sobre tratamientos psiquiátricos, resultados de pruebas de enfermedades infectocontagiosas… Depender de software propietario implica, en cierto modo, confiar ciegamente en que los proveedores no acceden indebidamente a estos datos, no incluyen «puertas traseras» en su código, no comparten información con terceros (incluidos gobiernos extranjeros) y mantendrán el soporte indefinidamente.

Con software libre, el SAS puede (y debe) auditar el código de las aplicaciones críticas. Puede contratar expertos independientes para revisar que no existen vulnerabilidades o funcionalidades ocultas. Puede, si es necesario, modificar el código para eliminar características indeseables o añadir funcionalidades específicas requeridas por la legislación sanitaria española o andaluza. Esta soberanía tecnológica es invaluable en un sector donde la confidencialidad y la integridad de los datos son cuestiones de seguridad nacional.

4.3. Adaptabilidad a requisitos específicos sanitarios

El sector sanitario tiene requisitos muy particulares que el software genérico no siempre satisface. El SAS necesita integración con sistemas de información específicos (Diraya, Nódulo, Jara…), interoperabilidad mediante estándares como HL7 o DICOM, cumplimiento riguroso del RGPD en su vertiente de datos de salud, trazabilidad exhaustiva de accesos a historias clínicas…

Con software propietario, el SAS depende de que el proveedor implemente estas características, lo cual puede ser lento, costoso o simplemente no ocurrir si el mercado no es suficientemente grande. Con software libre, el SAS puede contratar desarrollo a medida, modificar el código directamente o aprovechar modificaciones realizadas por otros servicios de salud con necesidades similares. El modelo de desarrollo colaborativo del software libre se alinea perfectamente con la idea de compartir soluciones entre diferentes servicios autonómicos de salud.

4.4. Seguridad mediante transparencia y revisión comunitaria

Existe un principio en seguridad informática conocido como «Ley de Linus»: «Dados suficientes ojos, todos los errores son evidentes». El software libre, al tener su código fuente disponible públicamente, puede ser revisado por miles de expertos en seguridad en todo el mundo. Las vulnerabilidades tienden a detectarse y corregirse más rápidamente que en software propietario, donde solo el equipo del proveedor puede revisar el código.

Esta ventaja es especialmente relevante en sanidad, donde sistemas mal protegidos pueden resultar en fugas de datos clínicos con consecuencias devastadoras para los pacientes y sanciones millonarias para la administración. Los ataques de ransomware a hospitales, que han paralizado servicios en varios países europeos, han demostrado que la seguridad informática en salud no es un lujo sino una necesidad crítica. El software libre, combinado con buenas prácticas de gestión, ofrece un nivel de seguridad superior al de alternativas propietarias.

4.5. Cumplimiento normativo y facilidad de auditoría

El Esquema Nacional de Seguridad (ENS), de obligado cumplimiento para el SAS, exige capacidad de auditoría del código en sistemas de categoría ALTA. La Ley Orgánica de Protección de Datos requiere que el responsable del tratamiento pueda demostrar cumplimiento de sus obligaciones, lo cual es más sencillo si puede revisar exactamente qué hace el software con los datos. El Reglamento General de Protección de Datos europeo introduce el concepto de «privacidad por diseño», que implica que las medidas de protección deben estar integradas en el software desde su concepción, algo que solo puede verificarse con acceso al código fuente.

Las auditorías de seguridad requeridas por el ENS son más exhaustivas, rápidas y económicas con software libre. Un auditor externo puede revisar el código directamente sin necesidad de negociar acuerdos de confidencialidad con proveedores, sin restricciones sobre qué puede examinar y sin depender de la buena voluntad de empresas de software para facilitar información.

5. INCONVENIENTES Y DESAFÍOS DEL SOFTWARE LIBRE

Una presentación honesta del software libre debe reconocer también sus limitaciones y desafíos. No todo son ventajas, y en el examen pueden preguntarte precisamente por las dificultades asociadas a su adopción en un entorno como el SAS.

5.1. Curva de aprendizaje y resistencia al cambio

El principal desafío en la adopción de software libre en el SAS no es técnico sino humano. Los profesionales sanitarios, que ya dedican su tiempo y energía a la atención de pacientes, perciben cualquier cambio tecnológico como una carga adicional. Si han trabajado durante años con sistemas operativos Windows y aplicaciones de Microsoft Office, migrar a GECOS y LibreOffice implica un periodo de adaptación durante el cual su productividad puede disminuir.

Esta resistencia es comprensible y debe gestionarse mediante formación adecuada, soporte técnico reforzado durante la transición y comunicación clara de los beneficios. El error más común es imponer el cambio de forma abrupta sin preparación, lo cual genera frustración y puede incluso comprometer la seguridad de los datos si los usuarios buscan «atajos» para evitar las nuevas herramientas.

5.2. Soporte técnico y responsabilidad

Con software propietario, existe un proveedor claramente identificado al que reclamar cuando algo falla. Si Microsoft Word no funciona correctamente, hay un contrato de soporte que establece tiempos de respuesta y obligaciones. Con software libre, especialmente si se utiliza sin contratar soporte comercial, la responsabilidad es menos clara.

Esto no significa que el software libre carezca de soporte. Existen empresas especializadas en dar soporte a software libre (Red Hat, SUSE, Canonical…), y en el caso de proyectos autonómicos como GECOS, es la propia Agencia Digital de Andalucía quien proporciona el soporte. Sin embargo, la percepción de que «si es gratis, nadie responde cuando falla» persiste y puede generar inseguridad en los decisores.

5.3. Compatibilidad e interoperabilidad

Aunque los estándares abiertos deberían garantizar la interoperabilidad, en la práctica existen problemas de compatibilidad. Un documento complejo creado en Microsoft Word puede no verse exactamente igual en LibreOffice Writer. Una macro de Excel puede no funcionar en LibreOffice Calc. Estas diferencias, aunque menores, pueden ser críticas en ciertos contextos sanitarios donde precisión y uniformidad son esenciales.

El SAS debe lidiar con proveedores externos (empresas farmacéuticas, compañías de equipamiento médico, otras administraciones…) que mayoritariamente utilizan software propietario. Recibir documentos en formatos propietarios y tener que convertirlos genera fricción. Aunque formatos como ODF (OpenDocument Format) son estándares ISO, en la práctica el formato .docx de Microsoft sigue siendo el «estándar de facto» en muchos ámbitos.

5.4. Disponibilidad de aplicaciones específicas

Algunas aplicaciones profesionales especializadas no tienen equivalentes libres. Software de procesamiento de imágenes médicas, herramientas de planificación radioterapéutica, sistemas de información de laboratorio… muchos de estos programas solo están disponibles para sistemas operativos propietarios o son ellos mismos propietarios.

Esto obliga a mantener entornos mixtos, con parte de los sistemas usando software libre y parte software propietario, lo cual complica la gestión y puede reducir los ahorros esperados. En algunos casos, es posible ejecutar aplicaciones propietarias en sistemas operativos libres mediante herramientas como Wine o máquinas virtuales, pero esto añade complejidad técnica.

5.5. Fragmentación de distribuciones y versiones

A diferencia del software propietario, donde generalmente existe una versión «oficial» claramente identificada, el software libre tiende a la fragmentación. Existen cientos de distribuciones GNU/Linux, cada una con sus particularidades. Incluso dentro de una misma aplicación como LibreOffice, puede haber versiones comunitarias y versiones empresariales con características ligeramente diferentes.

Esta diversidad es una fortaleza del ecosistema libre (permite especialización y experimentación), pero para una organización como el SAS puede ser un problema. Estandarizar en una distribución concreta (por ejemplo, GECOS) ayuda, pero luego hay que gestionar las actualizaciones, decidir si se migra a nuevas versiones, cuándo se hace…

6. PROYECTOS AUTONÓMICOS DE SOFTWARE LIBRE EN ANDALUCÍA

Andalucía ha sido pionera en España en la adopción institucional de software libre. Desde principios de los años 2000, la Junta de Andalucía ha desarrollado diversos proyectos que han convertido a la comunidad autónoma en referente nacional e internacional en este ámbito.

6.1. GECOS: La apuesta por el puesto de trabajo libre

GECOS (Gestión Centralizada de Ordenadores y Servicios) es, sin duda, el proyecto más emblemático de software libre en Andalucía y el que más aparece en las oposiciones del SAS. Se trata de una distribución GNU/Linux basada en Ubuntu desarrollada específicamente para la administración pública andaluza por la Agencia Digital de Andalucía.

GECOS no es simplemente una recopilación de software libre preexistente. Es un sistema integrado y adaptado a las necesidades específicas de la administración pública andaluza. Incluye configuraciones predeterminadas conformes con las políticas de seguridad corporativas, conectores con sistemas de autenticación centralizada (LDAP, Active Directory), herramientas de teletrabajo seguro, y aplicaciones web empaquetadas para facilitar su distribución.

Una característica distintiva de GECOS es su sistema de gestión centralizada mediante interfaz web, que permite a los administradores TIC controlar remotamente las actualizaciones, configuraciones y políticas de todos los equipos de una organización. Esto es especialmente valioso en el SAS, donde tenemos que gestionar decenas de miles de puestos de trabajo distribuidos por toda la geografía andaluza.

6.2. LeTSAS: Linux embebido en terminales del SAS

LeTSAS (Linux embebido en Terminales del SAS) es otro proyecto específico del Servicio Andaluz de Salud que merece mención especial porque ha aparecido en exámenes recientes. Se trata de una solución de cliente ligero basada en GNU/Linux diseñada específicamente para los puestos de trabajo sanitarios.

El concepto de «cliente ligero» es especialmente apropiado para el entorno sanitario. Muchos profesionales (médicos, enfermeras, auxiliares) utilizan los ordenadores fundamentalmente para acceder a aplicaciones web corporativas como Diraya. No necesitan un ordenador potente con todas las aplicaciones instaladas localmente; necesitan simplemente un navegador seguro y herramientas básicas. LeTSAS proporciona exactamente eso: un sistema operativo minimalista que arranca desde la red, no almacena datos localmente (todo se guarda en servidores centrales), se actualiza automáticamente y ofrece una experiencia de usuario simplificada.

Las ventajas de este enfoque para el SAS son múltiples. Seguridad mejorada (si un terminal se infecta, basta con reiniciarlo para volver a un estado limpio), gestión simplificada (las configuraciones se aplican centralmente), reducción de costes (los terminales ligeros son más baratos que PCs completos) y mayor disponibilidad (menor probabilidad de que un terminal esté «caído» por problemas de software).

6.3. Otros proyectos de software libre en el SSPA

Más allá de GECOS y LeTSAS, el Sistema Sanitario Público de Andalucía utiliza multitud de herramientas de software libre en sus infraestructuras. Vale la pena mencionar algunas porque pueden aparecer en supuestos prácticos o preguntas de examen:

PostgreSQL: Este sistema gestor de bases de datos relacional de código abierto es utilizado por numerosas aplicaciones del SAS. PostgreSQL destaca por su robustez, cumplimiento riguroso de estándares SQL, capacidades avanzadas de transacciones ACID y excelente rendimiento con grandes volúmenes de datos. Es especialmente apropiado para aplicaciones sanitarias donde la integridad de los datos es crítica.

Apache HTTP Server: El servidor web más utilizado en el mundo es también software libre, y el SAS lo emplea extensivamente para publicar aplicaciones web asistenciales y administrativas. Apache es extremadamente configurable, seguro (si se configura correctamente) y tiene un ecosistema enorme de módulos que extienden su funcionalidad.

OpenStack: Esta plataforma de cloud computing de código abierto gestiona recursos de computación, almacenamiento y red en los centros de datos del SAS. OpenStack es un «sistema operativo de nube» que permite provisionar y gestionar máquinas virtuales de forma similar a como AWS o Azure gestionan sus nubes públicas, pero manteniendo el control total y los datos en infraestructura propia (cloud privado).

LibreOffice: La suite ofimática libre es ampliamente utilizada en el SAS. Incluye Writer (procesador de textos), Calc (hojas de cálculo), Impress (presentaciones), Base (gestor de bases de datos), Draw (dibujo vectorial) y Math (editor de fórmulas matemáticas). LibreOffice guarda por defecto en formato ODF (OpenDocument Format), un estándar ISO abierto, aunque puede importar y exportar formatos de Microsoft Office.

Kubernetes: Este sistema de orquestación de contenedores, también de código abierto, está siendo adoptado por el SAS para gestionar el despliegue y escalado de aplicaciones en microservicios. Kubernetes permite que aplicaciones complejas compuestas por múltiples servicios se desplieguen, actualicen y escalen de forma automatizada y resiliente.

Centreon: Herramienta de monitorización de infraestructuras TI de código abierto utilizada en el SAS para supervisar servidores, servicios de red, aplicaciones y rendimiento de sistemas. Centreon permite detectar proactivamente problemas antes de que afecten a los usuarios finales (profesionales sanitarios).

7. LICENCIAS DE SOFTWARE LIBRE: TIPOLOGÍAS Y CARACTERÍSTICAS

Entender las licencias de software libre es fundamental no solo para el examen sino para tu trabajo futuro en el SAS, donde deberás evaluar si una herramienta puede adoptarse según su licencia y qué obligaciones conlleva.

7.1. Licencias copyleft vs. permisivas

Las licencias de software libre se dividen en dos grandes categorías según su «viralidad» o efecto de propagación de las libertades.

Licencias copyleft (GPL, AGPL): Exigen que cualquier trabajo derivado mantenga la misma licencia. Si modificas un programa GPL y lo distribuyes, tu versión debe ser también GPL. Esto garantiza que el software permanece libre en toda su cadena de derivación, pero puede ser problemático si quieres combinar código GPL con código bajo otras licencias. Ventaja: protege muy eficazmente las libertades del software. Inconveniente: puede dificultar la adopción comercial y la integración con código propietario.

Licencias permisivas (BSD, MIT, Apache): Permiten que trabajos derivados utilicen licencias diferentes, incluso propietarias. Puedes tomar código BSD, modificarlo y venderlo como software propietario sin liberar tu código fuente. Ventaja: máxima flexibilidad, facilita adopción por empresas. Inconveniente: permite «apropiación» del código y no garantiza que las mejoras reviertan a la comunidad.

Para el SAS, las licencias copyleft son generalmente preferibles en software desarrollado internamente que se quiere compartir con otros servicios de salud, garantizando que las mejoras de otros también se compartan. Las licencias permisivas son aceptables en componentes que se integran en sistemas mayores y donde la flexibilidad de integración es prioritaria.

7.2. Compatibilidad entre licencias

Un aspecto complejo que puede aparecer en supuestos prácticos es la compatibilidad entre diferentes licencias de software libre. Por ejemplo, GPL v3 no es compatible con GPL v2 en ciertos contextos, lo cual puede generar problemas si quieres combinar código de dos proyectos que usan versiones diferentes de la GPL. Apache 2.0 es compatible con GPL v3 pero no con GPL v2.

En la práctica, el SAS debe llevar un inventario detallado de las licencias del software que utiliza y produce, y consultar con expertos legales antes de realizar combinaciones complejas de código bajo diferentes licencias.

8. EL SOFTWARE LIBRE EN EL MARCO NORMATIVO DEL SAS

8.1. Esquema Nacional de Interoperabilidad (ENI)

El Real Decreto 4/2010, que regula el ENI, establece en su artículo 16 la obligación de las administraciones públicas de utilizar estándares abiertos y, en condiciones de igualdad, de priorizar el software libre. Concretamente, el artículo indica que «se evitará la discriminación a los licitadores por razón de la utilización de tecnologías o estándares abiertos o de código abierto» y que «en igualdad de condiciones se preferirán estas tecnologías».

Para el SAS, esto significa que en cualquier proceso de contratación de software debe evaluarse primero si existen alternativas libres que satisfagan los requisitos, y solo si no las hay o son claramente inferiores, puede optarse por software propietario. Esta obligación legal refuerza la estrategia de adopción de software libre.

8.2. Esquema Nacional de Seguridad (ENS)

El ENS no prescribe el uso de software libre, pero sus requisitos de auditabilidad del código en sistemas de categoría ALTA hacen que el software libre sea prácticamente obligatorio en estos casos. Si un sistema del SAS está categorizado como ALTO (por gestionar datos especialmente sensibles o ser crítico para la continuidad asistencial), el código debe poder ser auditado por el Centro Criptológico Nacional (CCN) o por auditores certificados.

Con software propietario, esta auditoría requiere complejos acuerdos con el proveedor y acceso restringido al código bajo estrictas cláusulas de confidencialidad. Con software libre, el código está disponible públicamente y las auditorías son más sencillas y económicas.

8.3. RGPD y protección de datos de salud

El Reglamento General de Protección de Datos establece obligaciones especialmente estrictas para los datos de salud, que son considerados «categoría especial» con protección reforzada. El responsable del tratamiento (en este caso, el SAS) debe poder demostrar el cumplimiento de los principios de protección de datos desde el diseño y por defecto.

Con software libre, el SAS puede auditar exactamente qué hace una aplicación con los datos personales, cómo los almacena, si los cifra correctamente, si respeta los periodos de conservación, si implementa correctamente los derechos de los interesados… Con software propietario, esta verificación es mucho más difícil y en última instancia requiere confiar en las afirmaciones del proveedor.

9. ESTRATEGIAS DE MIGRACIÓN A SOFTWARE LIBRE EN EL SAS

La migración a software libre en una organización de la complejidad del SAS no puede ser un «big bang». Requiere planificación cuidadosa, gestión del cambio y un enfoque gradual que minimice riesgos y resistencias.

9.1. Análisis de viabilidad y evaluación de riesgos

Antes de cualquier migración, debe realizarse un análisis exhaustivo que incluya inventario del software actual, identificación de dependencias críticas, evaluación de alternativas libres disponibles, estimación de costes de migración (no solo licencias, sino formación, desarrollo de adaptaciones, periodo de doble mantenimiento…), análisis de riesgos (qué pasa si algo sale mal) y preparación de planes de contingencia.

9.2. Estrategia gradual por capas

Una estrategia eficaz es migrar por capas tecnológicas, empezando por las menos críticas y avanzando progresivamente hacia las más centrales. Por ejemplo: primero herramientas ofimáticas, luego navegadores y clientes de correo, después sistemas operativos de servidores no críticos, finalmente bases de datos y sistemas operativos de puestos de trabajo.

9.3. Formación y gestión del cambio

El factor humano es el más importante y el más difícil de gestionar. Los profesionales sanitarios están sobrecargados y cualquier cambio que perciban como molesto generará resistencia. La formación debe ser práctica, orientada a tareas concretas que el profesional realiza en su trabajo diario, y disponible en múltiples formatos (presencial, videotutoriales, documentación, soporte por chat…). Es crucial contar con «embajadores» o «champions» en cada servicio que puedan ayudar a sus compañeros y transmitir feedback al equipo TIC.

10. CUESTIONARIO DE PREGUNTAS TIPO TEST

A continuación, encontrarás 30 preguntas tipo test basadas en exámenes reales del SAS de los últimos años. Respóndelas como si fuera el examen real, luego revisa las respuestas y estudia las explicaciones para interiorizar los conceptos.

11. MAPA CONCEPTUAL DEL TEMA

                    SOFTWARE LIBRE Y CÓDIGO ABIERTO EN EL SAS
                                    │
                ┌───────────────────┼───────────────────┐
                │                   │                   │
        ┌───────▼────────┐  ┌──────▼──────┐  ┌────────▼────────┐
        │   FUNDAMENTOS  │  │  PROYECTOS  │  │   APLICACIÓN    │
        │                │  │  ANDALUCES  │  │   EN EL SAS     │
        └───────┬────────┘  └──────┬──────┘  └────────┬────────┘
                │                  │                   │
        ┌───────┴───────┐  ┌──────┴──────┐  ┌────────┴────────┐
        │ PROYECTO GNU  │  │   GECOS     │  │  VENTAJAS       │
        │ - Libertad 0  │  │ (Agencia    │  │ - Independencia │
        │ - Libertad 1  │  │  Digital    │  │ - Adaptabilidad │
        │ - Libertad 2  │  │  Andalucía) │  │ - Seguridad     │
        │ - Libertad 3  │  │ - Ubuntu    │  │ - Auditoría ENS │
        │               │  │ - Gestión   │  │ - Ahorro        │
        │ FREE SOFTWARE │  │   Web       │  │                 │
        │ FOUNDATION    │  └─────────────┘  └─────────────────┘
        │ (FSF - 1985)  │          │                   │
        └───────────────┘  ┌───────▼────────┐ ┌───────▼────────┐
                │          │    LeTSAS      │ │ INCONVENIENTES │
        ┌───────▼────────┐ │ (Linux embeb.  │ │ - Curva apren. │
        │   LICENCIAS    │ │  Terminales)   │ │ - Resistencia  │
        │ - GPL (copyl.) │ │ - Cliente lig. │ │ - Compatibil.  │
        │ - LGPL         │ │ - Red Corporat.│ │ - Apps médicas │
        │ - AGPL         │ └────────────────┘ │ - Fragmentación│
        │ - MIT (permis.)│         │          └────────────────┘
        │ - Apache       │  ┌──────▼──────┐           │
        │ - BSD          │  │ SOFTWARE    │   ┌───────▼────────┐
        └────────────────┘  │ LIBRE SAS   │   │   NORMATIVA    │
                │           │ - PostgreSQL│   │ - ENI (RD 4/10)│
        ┌───────▼────────┐  │ - Apache    │   │ - ENS (RD 311) │
        │ OPEN SOURCE    │  │ - OpenStack │   │ - RGPD         │
        │ vs FREE SW     │  │ - LibreOffice│  │ - Ley 11/2007  │
        │ - Pragmático   │  │ - Kubernetes │  │ - Preferencia  │
        │ - Ético        │  │ - Centreon  │   │   estándares   │
        │ - Convergencia │  │ - MariaDB   │   │   abiertos     │
        └────────────────┘  └─────────────┘   └────────────────┘
            

12. CONCLUSIONES Y ESTRATEGIA DE ESTUDIO

12.1. Estrategia de memorización

Para dominar este tema, te recomiendo un enfoque de tres fases que he probado con cientos de opositores con excelentes resultados.

Fase 1: Anclaje conceptual (primera semana). Empieza por comprender profundamente las cuatro libertades del proyecto GNU. No las memorices de memoria como loros; entiende qué significa cada una y por qué es importante. Luego conecta estos conceptos con los proyectos andaluces: GECOS es la materialización práctica de esas libertades en el puesto de trabajo administrativo, LeTSAS en el puesto sanitario. Esta comprensión profunda te permitirá razonar respuestas incluso si no recuerdas datos literales.

Fase 2: Detalles técnicos y datos (segunda semana). Crea tarjetas Anki o flashcards con datos específicos que sí requieren memorización literal: extensiones de LibreOffice, nombres de SGBD de código abierto, qué organismo desarrolla GECOS, significado de LeTSAS, artículos del ENI y ENS… Repasa estas tarjetas diariamente usando repetición espaciada. Los datos técnicos son los que más se olvidan si no se repasan sistemáticamente.

Fase 3: Aplicación práctica (tercera semana). Haz las 30 preguntas de este tema repetidamente hasta que las domines. Luego busca preguntas de otros preparadores o inventa tus propios supuestos prácticos: «El director del hospital te pide evaluar migrar 500 puestos a GECOS, elabora un plan». Escribir estas respuestas consolida el conocimiento de forma que la lectura pasiva nunca logra.

12.2. Conexiones con otros temas

Este tema no está aislado. Se conecta intensamente con el Tema 23 (Sistemas operativos), Tema 24 (Unix/Linux), Tema 33 (SGBD), Tema 35-37 (Seguridad y ENS), Tema 38 (Protección de datos), y Tema 45 (Ofimática). Cuando estudies esos temas, vuelve aquí para reforzar las conexiones. El software libre no es un tema aparte; es un hilo conductor que atraviesa toda la infraestructura TIC del SAS.

12.3. Errores comunes que debes evitar

Error 1: Pensar que software libre = software gratuito. El software libre puede venderse. La libertad es otra cosa.

Error 2: Confundir que la libertad 3 exige distribución gratuita. NO lo exige. Puedes cobrar por las copias que distribuyas.

Error 3: Pensar que GECOS fue desarrollado por el SAS. NO. Fue desarrollado por la Agencia Digital de Andalucía para toda la administración autonómica.

Error 4: Creer que el software libre no necesita mantenimiento. SÍ lo necesita, igual que el propietario.

Error 5: Asumir que todo el software médico funciona en Linux. NO. Muchas aplicaciones médicas especializadas solo existen para Windows.

13. REFERENCIAS NORMATIVAS Y BIBLIOGRÁFICAS