585 - XZ, OpenSource y una serie de catastróficas desdichas
Sobre la vulnerabilidad que afectó a #xz y el #opensource . Que implicaciones tiene y otras cuestiones que es necesario aclarar sobre el opensource
Como seguro que has escuchado o visto en innumerables sitios, hace unos días se descubrió una vulnerabilidad que afectaba al paquete XZ. Sin ebargo, no me quiero centrar tanto en la vulnerabilidad que se pudo llegar a distribuir, sino en precisamente, la errónea idea que existe en torno al OpenSource, y si esto realmente afectó a la credibilidad del mismo. Así, aquí vamos en un nuevo episodio sobre XZ, OpenSource y una serie de catastróficas desdichas.
XZ, OpenSource y una serie de catastróficas desdichas
Algunas definiciones.
Antes de entrar en debatir sobre el OpenSource y sobre esta vulnerabilidad, quiero dejar claros dos conceptos.
Sobre el término malvado
El término «malvado» se utiliza para describir a alguien o algo que es perjudicial, dañino o malicioso. Una persona malvada es alguien que actúa con intención de causar daño o sufrimiento a otros, por lo general sin sentir remordimiento o culpa.
Sobre el OpenSource
Open source no solo significa acceso al código fuente. Los términos de distribución del software de código abierto deben cumplir con los siguientes criterios:
- Redistribución libre.La licencia no debe restringir a ninguna parte la venta o el regalo del software como parte de una distribución de software agregado que contenga programas de varias fuentes diferentes. La licencia no debe requerir una regalía o cualquier otro cargo por dicha venta.
- Código fuente. El programa debe incluir el código fuente y debe permitir su distribución en forma de código fuente y compilada. Si algún tipo de producto no se distribuye con el código fuente, debe existir un medio bien publicitado para obtener el código fuente a un costo de reproducción razonable, preferiblemente mediante descarga por Internet sin cargo. El código fuente debe ser la forma preferida en que un programador modificaría el programa. El código fuente deliberadamente obfuscado no está permitido. Las formas intermedias como el resultado de un preprocesador o un traductor no están permitidas.
- Obras derivadas. La licencia debe permitir modificaciones y obras derivadas y debe permitir que se distribuyan bajo los mismos términos que la licencia del software original.
- Integridad del código fuente del autor. La licencia puede restringir la distribución del código fuente en forma modificada solo si la licencia permite la distribución de «archivos de parches» con el código fuente para fines de modificación del programa en el momento de la construcción. La licencia debe permitir explícitamente la distribución de software construido a partir de código fuente modificado. La licencia puede exigir que las obras derivadas lleven un nombre o número de versión diferente del software original.
- No discriminación contra personas o grupos. La licencia no debe discriminar a ninguna persona o grupo de personas.
- No discriminación contra campos de actividad. La licencia no debe restringir a nadie el uso del programa en un campo específico de actividad. Por ejemplo, no debe restringir el programa para ser utilizado en un negocio o para ser utilizado en la investigación genética.
- Distribución de la licencia. Los derechos adjuntos al programa deben aplicarse a todos a quienes se redistribuya el programa sin la necesidad de ejecutar una licencia adicional por esas partes.
- La licencia no debe ser específica de un producto. Los derechos adjuntos al programa no deben depender del programa que forme parte de una determinada distribución de software. Si el programa se extrae de esa distribución y se utiliza o distribuye dentro de los términos de la licencia del programa, todas las partes a las que se vuelva a distribuir deben tener los mismos derechos que los que se otorgan en conjunto con la distribución original del software.
- La licencia no debe restringir otro software. La licencia no debe imponer restricciones a otros software que se distribuyan junto con el software con licencia. Por ejemplo, la licencia no debe exigir que todos los demás programas distribuidos en el mismo medio deben ser software de código abierto.
- La licencia debe ser neutral en cuanto a la tecnología. Ninguna disposición de la licencia puede estar condicionada a ninguna tecnología o interfaz individual.
Si te das cuenta entre estos criterios o principios, en ningún lugar se habla de seguridad o protección del OpenSource, en todo caso se tienen que cumplir estas condiciones.
Sobre el malvado
Como he indicado en las definiciones, una persona malvada es alguien que actúa con intención de causar daño a otros. Así, la persona que introdujo esta puerta trasera fue claramente una persona malvada, dado que lo hizo con la intención de provocar un daño.
Si bien, finalmente esta puerta trasera no llegó a los usuarios finales, lo cierto es que si que se ha provocado un daño, dado que actualmente, se he menoscabado la reputación del OpenSource.
Pero quería introducir la definición de malvado, porque personas malvadas hay en todas partes. Una persona malvada puede actuar tanto en el código OpenSource como en código privativo. Con un pequeño pero importante detalle, en el caso del código privativo hay un importante componente que puede corromper fácilmente a una persona para llevarla al lado oscuro, el dinero… ya sabes aquello de follow the money.
Por otro lado, cualquier desarrollador no puede entrar directamente a c
El término «malvado» se utiliza para describir a alguien o algo que es perjudicial, dañino o malicioso. Una persona malvada es alguien que actúa con intención de causar daño o sufrimiento a otros, por lo general sin sentir remordimiento o culpa.
Porque se colabora en el OpenSource
Hay personas que colaboran en proyectos OpenSource por diversas razones, entre ellas, el deseo de mejorar sus habilidades profesionales, especialmente en inglés y en gestión de proyectos.
Otras personas se sienten atraídas por la buena documentación y las prácticas de desarrollo que encuentran en estos proyectos. La colaboración en OpenSource también ofrece la oportunidad de trabajar en equipo, conocer a personas interesantes y aportar ideas y soluciones a la comunidad.
Además, colaborar en proyectos OpenSource puede ser una forma de enseñar y aprender de otros, así como de descubrir nuevas ideas y sentirse útil al contribuir al mundo.
Para empezar a colaborar en un proyecto OpenSource, se recomienda buscar un proyecto que se ajuste a tus intereses y habilidades, familiarizarse con él y comenzar a aportar ideas y trabajo, ya sea como usuario, diseñador, desarrollador, traductor o miembro de la comunidad.
Existen diversos tipos de colaboración y cada persona puede aportar de acuerdo con sus fortalezas y disponibilidad de tiempo.
Es importante tener en cuenta que colaborar en proyectos OpenSource requiere esfuerzo y paciencia, ya que puede ser complicado realizar contribuciones en librerías populares y lidiar con revisiones y cambios solicitados. Sin embargo, las recompensas en términos de experiencia, aprendizaje y conexiones son significativas y valen la pena el esfuerzo. Además, colaborar en OpenSource fomenta valores importantes como la seguridad, la colaboración y la transparencia, lo que beneficia tanto a los colaboradores como a la sociedad en general.
Ventajas del OpenSource
Las ventajas del OpenSource incluyen menor coste que el software propietario, mayor flexibilidad para adaptación y personalización, transparencia, colaboración abierta, alta calidad del software debido a la disponibilidad del código fuente, innovación constante, participación de la comunidad, y la posibilidad de aprender y adquirir experiencia al trabajar con código creado por otros.
Desventajas del OpenSource
Las desventajas del software libre y OpenSource incluyen la falta de garantías, la ausencia de soporte oficial, la necesidad de contar con personal capacitado para el manejo y desarrollo, la menor cantidad de herramientas disponibles en comparación con el software propietario, y la posibilidad de encontrar software incompleto o con menor calidad. Además, el software libre puede tener una curva de aprendizaje más pronunciada y requerir un mayor esfuerzo de adaptación.
Sobre el parasitismo
Otra de las cuestiones que he escuchando y leído en innumerables ocasiones es sobre el parasistismo del software privativo hacia el OpenSource. Y esto es un error de concepto. No puede existir, por definición parasitismo, en cuanto que el OpenSource se cede libremente. No hay un aprovechamiento, ni cuestiones similares.
Si un desarrollador quiere que su código no sea utilizado por un tercero, simplemente lo que tiene que hacer es buscar otro modelo que no sea el del OpenSource. Sin embargo, los seres humanos, como de costumbre lo queremos todo. Queremos el reconocimiento que nos da el OpenSource, por un lado, y por otro, queremos una compensación económica u otro tipo de compensación, que no sea la del reconocimiento.
Más información,
Yo considero que hay parasitismo cuando una empresa usa multitud de bibliotecas o software libre sin aportar nada a la comunidad, es decir: sin hacer donaciones, liberar código de mejora, etc… creo que es una cuestión de ética: si recibes, deberías dar.
Por ejemplo, TimeShift es un excelente software para mí y me ha salvado literalmente la vida en muchas ocasiones, mi aportación ha sido hacer una donación y agradecer al autor el que lo haya liberado.