Analisis de Licencias y Seguridad de los distintos lenguajes de programación 🟡③
- ¿Por qué Python es la elección ideal para desarrollar en el ecosistema completo de MetsuOS? 🟡③
- De Software Libre, Licencias y Filosofías en entornos VUCA 🟡③
OJO WIP
Introducción
Elegir un lenguaje de programación no es solo una decisión técnica: las licencias determinan qué puedes hacer legalmente con el código y la seguridad inherente del lenguaje condiciona la probabilidad de introducir vulnerabilidades graves.
Tabla comparativa resumida
| Lenguaje | Versión (nov 2025) | Licencia principal | ¿Uso comercial cerrado? | ¿Copyleft fuerte? | Seguridad de memoria (2025) | Ejemplos de adopción crítica |
|---|---|---|---|---|---|---|
| Ada | Ada 2022 | GPL con excepción / propietaria (AdaCore) | Sí (pago) | No | ★★★★★ | Defensa, aviación, espacio, ferrocarril |
| Rust | 1.82 | MIT + Apache 2.0 | Sí | No | ★★★★★ | Microsoft, Google, AWS, Android, Linux kernel |
| Go | 1.23 | BSD-3-Clause | Sí | No | ★★★★☆ | Kubernetes, Docker, Cloudflare |
| C# | 13 (.NET 9) | MIT (runtime) / Reference (compilador) | Sí | No | ★★★★☆ | Enterprise Windows, Unity |
| Java | 23 (LTS 21) | GPL-2 con Classpath Exception (OpenJDK) | Sí | No | ★★★★☆ | Banca, Android legacy, servidores enterprise |
| Swift | 5.10 | Apache 2.0 | Sí | No | ★★★★☆ | Apple ecosystem |
| Kotlin | 2.0 | Apache 2.0 | Sí | No | ★★★★☆ | Android oficial, backend |
| Zig | 0.13.0 | MIT | Sí | No | ★★★★☆ | Proyectos embebidos, reemplazo de C |
| Haskell | GHC 9.10 | BSD-3 | Sí | No | ★★★★★ | Jane Street, defensa |
| Erlang / Elixir | OTP 27 / 1.17 | Apache 2.0 | Sí | No | ★★★★★ | WhatsApp, telecom 99.9999999 % |
| C | C23 | Varía (GCC GPL, Clang Apache, MSVC prop.) | Sí | No | ★☆☆☆☆ | Kernel Linux, firmware |
| C++ | C++23 | Igual que C | Sí | No | ★★☆☆☆ | Juegos, finanzas de alta frecuencia, automoción |
| JavaScript/TS | ES2025 / TS 5.6 | MIT/BSD/MPL | Sí | No | ★★☆☆☆ | Web (inevitable) |
| Python | 3.13 | PSF (~BSD) | Sí | No | ★★★☆☆ | Data science, DevOps |
| PHP | 8.3 → 8.4 | PHP License | Sí | No | ★★☆☆☆ | WordPress, Laravel |
Análisis detallado por categorías
1. Lenguajes con seguridad demostrable o casi demostrable
- Rust, Ada/SPARK y Erlang/Elixir son los únicos que en 2025 pueden presumir de haber eliminado clases enteras de errores (data races, use-after-free, desbordamientos de búfer) sin sacrificar rendimiento.
- Rust es el más adoptado en nuevos proyectos de sistemas (Linux 6.11 ya tiene drivers en Rust, Microsoft reescribe partes del kernel de Windows).
2. Lenguajes memory-safe con GC
Go, Java, C#, Swift y Kotlin ofrecen seguridad de memoria por defecto y son la opción dominante en cloud, móvil y enterprise. La mayor parte de las vulnerabilidades actuales en estos ecosistemas provienen de dependencias (Log4j2, etc.), no del lenguaje en sí.
3. Lenguajes legacy de alto riesgo
C y C++ siguen siendo responsables del ≈70 % de las vulnerabilidades críticas de memoria en 2024-2025 según los informes de Microsoft y Google. La UE (Cyber Resilience Act 2024-2025) y la Casa Blanca (2024) recomiendan explícitamente evitarlos en nuevos desarrollos críticos.
Referencias bibliográficas que apoyan este análisis
- White House Office of the National Cyber Director (2024). «Technical report on memory safety» 🟡③🌐
-
- [ENISA Threat Landscape 2024 🟡③🌐](https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024](https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024) .- Identifica siete amenazas principales (como ransomware, DDoS y ataques a la cadena de suministro), analiza más de 11.000 incidentes reportados y destaca el aumento de ataques patrocinados por estados a software open-source, incluyendo casos como el backdoor en XZ Utils. Incluye análisis de vulnerabilidades (más de 19.700 identificadas) y medidas de mitigación.
- Keynote: Rust in the Linux Kernel, Why? - Greg Kroah-Hartman 🟡③🌐 . – Charla keynote de Greg Kroah-Hartman, mantenedor principal del kernel Linux y fellow de la Linux Foundation, grabada en noviembre de 2025. Explica las razones para integrar Rust en el kernel, avances en el soporte experimental, beneficios en seguridad de memoria y roadmap futuro, incluyendo integración con drivers existentes. Duración: 25 minutos, canal oficial de la Linux Foundation.
- National Security Agency (NSA) (2023). «Software Memory Safety» 🟡③🌐
- Rust Foundation Security Initiative (2025). «2024 Security Report» 🟡③🌐
- AdaCore & NVIDIA (2025). «Proving Safety at Scale: SPARK, RISC-V, and NVIDIA’s Security Strategy» 🟡③🌐 . – Artículo de AdaCore publicado en noviembre de 2025, enfocado en la aplicación de SPARK para probar la ausencia de fallos en sistemas críticos como firmware de centros de datos y dispositivos embebidos. Incluye discusiones sobre adopción práctica (no 100% en SPARK, sino en módulos clave), integración con C/ensamblador, y beneficios en prevención de exploits de memoria. Menciona colaboraciones con NVIDIA para ISO-26262 en automoción.
Referencias que matizan o refutan parcialmente algunas afirmaciones
- Cui, M. et al. (2024). «Fearless Unsafe: A More User-friendly Document for Unsafe Rust Programming Based on Refined Safety Properties» 🟡③🌐 . – Análisis extendido de todos los CVEs de Rust hasta enero de 2024 (419 en total), categorizando sus causas raíz en propiedades de seguridad y confirmando que todos los memory safety bugs violan reglas en bloques unsafe. Propone herramientas como un plugin para rust-analyzer para asistir en la escritura segura de unsafe code.
- Memarian et al. (2016-2024). «C memory model formalisation» 🟡③🌐 .– demuestra que, con herramientas modernas (CHERI, Cerberus), C puede ser casi tan seguro como Rust en hardware específico.
- Netguru (2025). «Golang vs Rust: Which Language Wins for Backend in 2025?» 🟡③🌐](https://www.netguru.com/blog/golang-vs-rust) . – Comparación detallada que argumenta que Go puede ser más seguro en producción para servicios backend escalables gracias a su simplicidad (bounds checking y type switches integrados), reduciendo errores humanos en equipos grandes, a diferencia de la complejidad de Rust; incluye benchmarks de performance y casos reales.
- Google Security Blog (2024). «Safer with Google: Advancing Memory Safety» 🟡③🌐](https://security.googleblog.com/2024/10/safer-with-google-advancing-memory.html) . – Artículo oficial que defiende que lenguajes como Kotlin y Swift (junto a Java y Go) alcanzan niveles similares de memory safety en la práctica para Android y servidores, con interoperabilidad gradual en lugar de rewrites totales, reduciendo vulnerabilidades en un 68% sin abandonar ecosistemas existentes.
- InfoQ (2024). «Netflix Adopts Virtual Threads: a Case Study on Performance and Pitfalls» 🟡③🌐](https://www.infoq.com/news/2024/08/netflix-performance-case-study/) . – Caso real del equipo de Netflix sobre el uso de Java 21 en servicios críticos de streaming (2800+ microservicios), donde mantienen operaciones sin problemas graves mediante aislamiento (virtual threads y ZGC para GC eficiente), sandboxing en contenedores y monitoreo, evitando pausas que causen timeouts en producción.
Con este conjunto de fuentes (todas verificadas y accesibles en noviembre de 2025) queda claro que la tendencia es inequívoca hacia lenguajes memory-safe, pero también que la transición total llevará décadas y que existen estrategias válidas para seguir usando C/C++/Java de forma razonablemente segura en contextos específicos.
One More Thing

¡Desbloquea el poder de MetsuOS y descubre que la privacidad y la seguridad son la clave para desencadenar tu verdadero potencial en línea!
Contenido registrado en Safe Creative
¡Usa el código de promocional 7ZYM4Z y ahorrate unos eurillos en tu suscripcion de Safe Creative!
MetsuOS Needs You!
Apoyanos en este proyecto difundiendolo en tus redes, o mejor, haznos una donación a la cuenta paypal para poder dedicar más tiempo y recursos a el. No olvides comentarnos que parete te interesa más junto con tu donación.
En este momento, además de mantener los servicios, estoy centrado en crear la siguiente iteración del software que me permite hacer todo esto y creando una biblioteca personal física para poder contrastar contenido.
Sobre el sistema de validez de un contenido en MetsuOS
Empezando a incorporar los niveles de validación de un contenido (también llamada sabiduría o niveles de conocimiento) ⚫🔴 🟡 🟢 🔵⚪ ¿Qué són?
- ⚫① - Dark1 - Conocimiento en Bruto. Modo Cuñao, hablo pero no puedo respaldarlo.
- 🔴② - Rojo2 - Conocimiento Impulsivo, pasional, "lo mio es lo correcto".
- 🟡③ - Yellow3 - Conocimiento Crítico: se comienza a explorar el hecho de que pueda haber otras perspectivas.
- 🟢④ - Green4 - Conocimiento Natural: Surge al comprender la naturaleza de la realidad y del ser humano en una materia.
- 🔵⑤ - Blue5 - Conocimiento Científico: Supone la suma de las fases anteriores aplicando el rigor de lo descubierto por la ciencia hasta ahora, sin caer en la -anticientífica- "opinión científica/opinión de expertos".
- ⚪⑥ - Light6 Conocimiento Consolidado: Se alcanza al integrar todo lo anterior desde una perspectiva empática y asumiendo una verdad probabilística dinámica dependiente del contexto.
Sobre la categorización de los tipos de conocimiento
- Conocimiento Gnoseológico: ⚫① 🔴② 🟡③ 🟢④
- Conocimiento Epistemológico: 🔵⑤
- Conocimiento Metsukeológico: ⚪⑥
La Metsukeología (de Metsuke vision global y logos conocimiento) es la ciencia que estudia el conocimiento como un conjunto potencial de conocimiento del que podemos obtener, procesar o percibir partes concretas dentro de un marco contextual específico, y cuyo contexto general real está muy por encima de lo que somos capaces, como especie, de percibir, procesar e integrar de forma completa (definición en progreso).
La Metsucología (de Metsu aniquilación - en este contexto en forma de colapso - , logos conocimiento) es la ciencia que estudia como extraemos verdades percibidas - colapsadas - como conocimiento desde nuestra perspectiva real (tanto epistemológico como gnoseológico) al tomar una parte específica del conocimiento metsukeológico potencial enmarcado en un contexto concreto, obligando a colapsar el conocimiento potencial en conocimiento específico (definición en progreso).
Mas sobre el contexto
DISCLAIMER: Mi consideración de anticientífico respecto al consenso científico es una hipotesis de trabajo propia, que supone que toda asignación de validez, incluso aquella derivada de la conclusión por acumulación de evidencia NO debe ser supeditada a debate, ni acuerdo, debe ser algo probabilistico sin intervención del ego humano. Podría estar equivocado y, en este punto, es donde se aplicaría entonces ese mismo consenso que ahora considero no valido (incluso dañino)
Existen indicadores para algunas cuestiones adicoinales como los siguientes:
- 🌐 - Contenido Externo sobre cuya validez/validación no tenemos control (usualmente enlaces que salen de #MetsuOS)
- ⚖️ - Analisis
- ⚖️📚 - Análisis Bibligráfico
- ⚖️🔬 - Análisis Científico
- ⚖️🏛️ - Análisis Estructural
- ⚖️🧠 - Análisis Filosófico
- 📖 - Referencia
- 📖📚 - Referencia Bibliográfica / Libro
- 📖🔬- Referencia Científica / Paper
- 📖🏛️ - Referencia Estructural
- 📖🧠 - Referencia Filosófica
- 🔍️- Paradigma
Cuando hablamos de un contenido que incluye un texto que hace referencia a otro.
- 🔴②-🌐🟡③ - Nivel del contenido del documento Rojo2, nivel del contenido externo del que habla el documento Yellow3.
- 🔴②-⚖️📚 🔴② - Nivel del contenido del documento Rojo2, en base a análisis bibliográfico nivel Rojo2
También aplicaremos el Sistema de fiabilidad de fuentes y credibilidad de contenidos de la OTAN 🔴②, este sistema incluye una valoración de la fiabilidad de la fuente de A a F (siendo A la de mayor fiabilidad) y una varloración de credibilidad del contenido de 1 a 6 (siendo 1 la mayor credibilidad).
En MetsuOS la agregaremos al final uniendo amos valores como si fuera una coordenada. Por ejemplo: ⚫①-D4 o 🟡③-B2. Esto ayudarña a contextualizar la información sobre la solidez del conocimiento al que se hace referencia en cada momento.
Hay que tener en cuenta que, cuando hay elementos subjetivos o parcialmente subjetivos, el punto de referencia seré yo mismo. Quizá más adelante pueda objetivizar esto más (seria lo deseable), pero en tanto no tenga herramientas que me lo permitan, debo ceñirme al principio de honestidar intelectual, y esperar que mis sesgos dañen lo menos posible la información (en parte este es el nudo gordiano que pretendo resolver, y por ello es dificil resolverlo a priori).
Así de forma resumida, podríamos decir que esta definición es nivel 🔴② (Rojo2 xD) ¿Crees que me dejo algo? Si es así por favor ayudame a mejorarlo contactándome a través de X (Twitter) en mi cuenta, @metsuke 🌐
Consulta la versión completa de la descripcion en ⚫🔴🟡🟢🔵⚪ (🔴②) Un poco más de detalle
- Información IA: Generado asistido por IA (Grok-4, Raul Carrillo aka Metsuke). Supervisado por Humano.
- Ultima Modificación: 2025-11-27 20:28:12.471000+00:00
- Versión Documento: 0.2.11