 Bueno, buenas tardes a todos. Es genial poder estar en una conferencia presidencial después de tantas en línea. Para los que no me conocen, mi nombre es Lina Ceballos y también hago parte de la Free Software Foundation Europe, como mi colega, Alexander, acaba de explicar o la FSF. Somos una organización benéfica que faculta a los usuarios a controlar la tecnología y básicamente creemos que eso es posible con software libre. No solo aparte de la charla del public money, publico de que no se acabara, Alex, nosotros tenemos otras iniciativas. Y hoy vengo a contarles sobre el software de reuse. Ya viene la pesada o gavlarlas de información legal y demás. Pero yo sé que esto es un tema que a muchos desarrolladores y general a muchos usuarios de software libre les genera mucho dolor de cabeza. Y justamente esa fue una de las razones por las que la FSF en el 2017 empezó con la iniciativa de reuse. Reuse, básicamente, lo que busca es hacer y dedicar información legal, hablando de derechos de autor y licencias, en proyectos de software libre de una manera sencilla que sea muy fácil de verificar, que sea legible, tanto para nosotros los humanos. O sea, que si nosotros accedemos a un archivo, un pedazo de código, sabemos bajo qué licencia este pedazo de código está. Y también para las computadoras o las máquinas. Y también busca adaptarse a prácticas ya existentes. Entonces, no estamos nuevamente rimentando la red una y otra vez, sino que estamos adaptando ciertas prácticas que ahora sus proyectos utilizan para indicar esa información. Pero, bueno, entonces, antes de hablar un poco de reuse, quiero que hablemos sobre los errores más comunes que nos hemos encontrado y yo creo que todos nosotros al momento de darle visibilidad a esta información legal. Entonces, la primera es que hay una falta de información sobre licencias y derechos de autor en el código del proyecto en general o de código de terceros. Y esto está conectado al segundo problema, que es que al momento de alguien de reutilizar el código, la persona puede pasar por alto bajo qué licencia este código estaba. Y creo que nosotros todos sabemos que las libertades que otorga el sofá libre se ve en gran medida a las licencias que nosotros escogemos para nuestro proyecto. Y si nosotros tenemos nuestro proyecto bajo una licencia y estamos reutilizando un código que está bajo cualquier otra licencia, no tenemos ni idea, cabe la posibilidad que haya una incompatibilidad de licencias y podamos tener problemas legales. Y creo que nadie aquí quiere tener ningún problema legal. Así que esto es uno de los inconvenientes que existen en el momento. También hay un inconveniente cuando tenemos múltiples licencias y no sabemos cómo indicarlas. Porque creo que aquí también somos, bueno, no sé la verdad cuántos desarrolladores de sofá hay. Bueno, bueno, sabemos que utilizamos ciertas licencias para ciertas partes del proyecto, pero otras utilizan otra. Entonces, también hay un problema cuando hablamos de múltiples licencias y que está muy conectado con la ambigüeda de las licencias. Creo que ya muchas veces, o a mí muchas veces me ha pasado que he visitado un repositorio y un proyecto y me dice que estaba bajo la licencia GPL. No te uní a qué versión. Si es la versión 3 posterior o si es solo la versión 3. Entonces esta ambigüeda también es un poco problemática. Y la última es que hay unas prácticas recomendadas que son contractores. Entonces, hay proyectos que almacenan el texto de la licencia en el archivo Copping. Hay otros que lo almacenan en el archivo Readme. Hay otros que crean un archivo que se llama Licencia. Entonces, es un poco complicado identificar esta información legal dentro del proyecto. Así que por eso, hace el 2017, se empezó a implementar reviews, que básicamente lo que busca es facilitar esta información legal dentro del repositorio. Porque cada archivo del repositorio va a tener un encabezado que va a contener esta información. Con ello, vamos a evitar las bases de datos externas. Entonces, porque vamos a intentar almacenar esta información lo más cerca del código posible. Como ya mencioné, reviews busca que esta información sea elegible por humanos y por máquinas, computadores, et cetera. Y sobre todo, lo que busca es hacer que lidiar con este tema de indicar licencias y derechos de autor sea más sencillo y sobre todo divertido para los desarrolladores de software sin importar el tamaño del proyecto. Porque ya sabemos que hay proyectos muy grandes, con una extensión muy grande. Pero ya les voy a mostrar algunos de las herramientas que tienen reviews para facilitar esto. Entonces, vamos a hablar de los, es muy sencillo. También lo voy a mostrar en el demo que voy a hacer. Y son solo tres pasos. La primera es elegir y proporcionar la licencia o licencias que vamos a utilizar en el proyecto. Voy a ir por cada uno de los pasos, pero ahora lo voy a nombrar. La segunda es añadir información sobre derechos de autor y licencias en cada uno de los archivos del proyecto. Y la tercera es con la ayuda de nuestra herramienta reviews, vamos a verificar que nuestro proyecto siga todas las especificaciones de reviews. Entonces, bueno, vamos para el primero. Vamos a elegir y proporcionar las licencias. Como ya sabemos, depende de cada proyecto que libertades quieren conferir, escogemos la licencia. Y vamos a guardar el texto de esta licencia en un directorio que vamos a crear, que se va a llamar Licenses. Y en este directorio van a estar almacenadas todas las licencias que son utilizadas en el proyecto. No importa si son la licencia de las imágenes, la licencia de las fuentes o del código como tal, todo va a estar almacenado en este directorio. Así que ya no vamos a tener que ir navegando de lado a lado en el proyecto para poder identificar qué licencias están utilizando. Están siendo utilizadas en este proyecto. Y la segunda es que vamos a nombrar el archivo, como aparece en el identificador de licencias de SBDX. SBDX es un proyecto de la lunes foundation. Y pues lo que busca es estandarizar la manera en la que se indica esta información legal. Aquí en el ejemplo, tenemos bueno el proyecto. Tenemos el directorio licenses. Y vemos que en este caso es muy claro que es la licencia GPL3 o posterior. Es un archivo de texto que guardamos, así es como aparece en el identificador de licencias de SBDX. Y ya, entonces, reuse para poder identificar que esta licencia está siendo utilizada en nuestro proyecto. Y nosotros también vamos a poder ganarnos cuenta de que licencia está siendo usada. Aquí es importante notar que reuse no ayuda en temas de incompatibilidad. O sea, todavía no puede identificar si hay incompatibilidad de licencias. Sin embargo, nosotros en la FSF, tenemos un equipo legal que les pueda ayudar a solucionar cualquier problema legal o incompatibilidad de licencias o cualquier cuestión legal que ustedes tengan. Estamos abiertos a guiarlos. Bueno, la segunda es declarar esta información de derechos de autor y licencias en cada uno de los archivos. Entonces, vamos a tener un encabezado al comienzo de cada archivo, que se va a ver cómo se ve en el ejemplo, utilizando la etiqueta para la licencia de SBDX license identifier y también como aparece la licencia en el identificador de SBDX, tal cual con los liones, puntos, etcétera. Para el tema de derechos de autor o de copyright, es un poco más flexible. Se puede usar la etiqueta xbs file copyright text, pero también se puede utilizar solo copyright o solo el símbolo de copyright, porque también sabemos que muchos proyectos ya tienen esta información. Entonces, es todo así que sea mucho más sencillo migrar o convertir o implementar videos. Pero con el tema, con la etiqueta de licencias si solo tenemos la opción de SBDX license identifier. Entonces, básicamente todos los archivos que podemos comentar van a tener un encabezado que se va a ver como aquí en el ejemplo. Entonces, no hay pérdida si vamos a hacer archivos, sabemos que este código, el pedazo de este código está en la gpl3 posterior y que Jane Doe es la autora del archivo, del código. Bueno, yo sé que también se están preguntando, bueno, ¿y qué hacemos con archivos que no podemos comentar? Como imágenes, JSON, archivos binarios, etcétera. Para eso, tenemos dos alternativas. La primera es crear un archivo separado de texto con la información del legal que tenemos. Y la vamos a llamar como se llama el archivo específicamente y se va a terminar en punto license. Como pueden ver en este ejemplo, tenemos una imagen de un gato y lo llamamos exactamente igual, terminó en punto license. Entonces, cualquier persona que accede a este directorio va a poder darse cuenta que hay un archivo específico que indica quién es el autor y bajo qué licencias dan estas imágenes. Y reuse también va a poder identificar que este archivo está bajo esta información legal. La segunda opción que tenemos es el archivo de f5 que este archivo es utilizado para proyectos que son muy grandes, porque, bueno, también sabemos que hay proyectos que tienen mil fotos, mil imágenes. Y crear un archivo por separado y cada uno de estos archivos no solo implicaría un montón de trabajo, sino también que duplicaría el tamaño del proyecto. Entonces, para casos en proyectos que tienen muchos archivos, tenemos la opción del f5 que fue implementado por proyecto Debian. También estamos reutilizando. Y ya básicamente se añade la información. Acá le decimos que todos los archivos del directorio de imágenes están bajo esta información. Entonces, ya no solo reuse, el software va a poder identificar la información dentro de todo este directorio, sino que también nosotros vamos a poder ver que, entonces, todas las imágenes están bajo esta licencia. Es importante notar que, como eso busca declarar esta información masivamente, es importante tener claridad de qué de la información es correcta, porque estamos hablando de mil imágenes y tenemos que estar seguros que las mil imágenes están bajo esta información. Por eso nosotros aconsejamos si el proyecto no es muy grande utilizar un archivo por separado, como el que acabo de explicar. Y el tercero es, básicamente, verificar que nuestro proyecto sigue a las indicaciones de rayos. Acá nos dice que 6 de los 6 archivos tienen esa información y que nuestro proyecto sigue con las indicaciones de rayos. Entonces, ahora me gustaría hacer un ejemplo práctico de cómo funciona rayos. Entonces, aquí tengo un proyecto pequeño que he creado para este ejemplo. Acabamos que esta persona almacena la información de la licencia en copying. Vemos que es la GPL3, pero no sabemos si es la GPL3, only or later. Entonces, vamos a utilizar nuestra herramienta rayos lint que lo que va a hacer va a ser un escaneo del proyecto completo y nos va a decir cómo se ve el proyecto. En este caso, vemos que 0 de los 18 archivos que tenemos incluyen esa información. También nos dice qué archivos tenemos, así que podemos verificar qué tenemos acá. Vemos que tenemos dos imágenes y el resto son archivos normales. Ahora, vamos a utilizar nuestra herramienta de rayos.header. Entonces, el software de rayos va a añadir automáticamente el encabezado de los archivos que yo quiera. Entonces, vamos a rayos.header. Vamos a decir, bueno, a indicar quién es el autor. Lola Pérez es el autor en este caso. También pueden añadir el correo electrónico, pero como no tengo mucho tiempo, voy a evitar añadir esto, pero pueden añadir el correo electrónico. Y vamos a decir, bajo qué licencia está. Entonces, en este caso, el código, todo lo que es de código, lo la sabe que todo mi proyecto está bajo el GPL3, o later. Entonces, vamos a añadirlo tal cual, como parece, en el identificador de licencias. Y ella escribió el código en el 2018, porque si ustedes no indican qué año el rayos va a añadir el año, el presente. Entonces, ella quiere especificar que su código lo empezó a escribir en el año 2018. Vale, entonces ahora le tenemos que decir al software que archivos están bajo esta licencia y esta información, el derecho de autor. Entonces, claro. Mejor? A ver. No, no parece. No puedo. Ahí está, mejor? Mejor? Bueno. Bueno, entonces le decimos que a todos los archivos que están en el directorio bin, que añada esta información. Y también tenemos un archivo acá que nos gustaría también añadir. Entonces, vamos a decirle todos los archivos que están en este directorio también. Entonces, vamos a darle Enter. Y rayos ya nos dice listo. Ya añadí automáticamente el encabezado. Así que si vamos directamente a los archivos, vamos a ver que rayos primero identifica el estilo del archivo y identifica las sintaxis del comentario. Entonces, ya pueden ver que también añadió el año y el autor y nos añadió la licencia. Todos los archivos ya tienen esto. Así que vimos que añadió casi 14 archivos en menos de 10 segundos. Vamos a ver a correr nuevamente. Rayos lint. Y le vamos a decir, nos está diciendo todavía, bueno, ya 13 archivos de los 18 tienen, pero todavía la falta. Entonces, vamos a ir ahora por las imágenes. Rayos también crea este archivo de texto automáticamente si nosotros tener que crearlo manual. Entonces, vamos a correr nuevamente nuestro comando. Resulta que las fotos las tomó Pedro Perez, el hermano de Lola. Y la licencia de las fotos está bajo la CCBY 4.0. Las fotos fueron tomadas en el año 2021. Listo, ya dimos autor, licencia, año. Y la decimos, por favor, añade esta información a todos los archivos que están en el directorio de imágenes. Nos dice, listo, perfecto. Ya añade automáticamente esto. Así que si vamos a cada uno de los archivos, ya vemos que hay un archivo de texto que se creó automáticamente con esta información. Bueno, a ver. Preguntemos la Rayos. ¿Cómo vamos? Todavía nos quedan tres archivos. Nos queda el gitignore, el makefile y el ritme. Voy a dejar el gitignore porque es un archivo significante que ya explicaré también cómo funciona. Pero bueno, vamos a añadir básicamente la misma información de derechos de autor que tiene el resto de código para estos dos archivos. Entonces, el autor Lola Perez, la licencia de la GPL, tres o posterior en el año 2018. Así que, por favor, añadelo al makefile y al ritme. Perfecto, ya también vemos que si vamos al makefile, también identificó que sin taxis utilizar y nos añadió la información automáticamente. Y el gitignore, obviamente, no es susceptible a derechos de autor, pero uno de los principios básicos de reuse es que todos los archivos del proyecto tengan esa información. Así que lo que nosotros recomendamos es ya sea ponerlo bajo la misma licencia que utilizan en el proyecto o ponerlo bajo el dominio público, bajo cualquier Creative Commons, alguna de estas licencias. Así que hagamos esto. Vamos a cambiar aquí un poco la información. Vamos a decir que Lola Perez es el autor de este archivo y vamos a quedarlo bajo la licencia de C01.0. El año no importa. Y le decimos, por favor, incluyelo al gitignore. Así que si ya vamos al gitignore, también vamos a darnos cuenta que también ya tiene L en cabeza. Vamos a correr una vez más nuestro comando reuse lint para ver cómo va nuestro proyecto. Y nos dice, bueno, todavía no sigues todas las especificaciones de reuse, a pesar de que los 18 archivos tienen esta información. ¿Por qué? Porque no tenemos nuestro archivo, nuestro directorio de licencias y no están nombradas con como el identificador de SPDX. Pero para eso, reuse también nos ayuda, no tenemos que meternos a la página de SPDX a descargar el texto, nombrarlo. Entonces le decimos, reuse, download, oh. Descarga todas las licencias que identificas. Acá ustedes pueden notar que reuse no está diciendo él. Puedo identificar estas licencias, pero no están guardadas en ningún lado. Entonces, reuse, download, oh. OK, acá hay un problema con la CCY, con la CC0. OK. Nuevamente, reuse, download, oh. Y ya reuse nos creó no solo el directorio de licencias, sino que también descargo estos tres licencias que tenemos en el repositorio, las nombró como para eso en el identificador de licencias de SPDX. Y ya si escaneamos una vez más nuestro proyecto, nos dice, felicitaciones su proyecto sigue con las indicaciones de reuse. Así que, así, básicamente es como se vería un proyecto que sigue las especificaciones de reuse. Así que ya es muy sencillo ir a licenses. Ya sabemos qué licencias se utilizan. Y si necesitas rehusar parte de este código específico, ya sé que Lola Pérez escribió este código en el 2018 y que está bajo la GPL3 o posterior. Bueno, y entonces ahora, para ir ya terminando, quiero hablar como de los componentes que tiene reuse. Entonces, como ya vimos en este ejemplo, reuse está compuesto de unas prácticas recomendadas, porque buscamos que se vuelve el estándar para los proyectos de software libre para indicar esta información legal. Tenemos el helper tool, que es todos estos comandos y estas herramientas que acabo de utilizar y que pueden ser utilizados en proyectos enormes y que seguro nos va a ahorrar un montón de tiempo. También tenemos un tutorial con FAQ que da respuesta a preguntas desde muy básicas, hasta un poco más complejas, y desde el software como tal de cómo funciona reuse técnicamente, y también preguntas más legales que hacer con múltiples licencias, como indicar cuando tengo tres licencias, etcétera. Así que esto también lo pueden encontrar en nuestra documentación. Entonces, justamente tenemos un API en el que los proyectos que siguen las indicaciones de reuse se pueden registrar y se generará una insignia que se puede colocar en el repositorio. Así, en el futuro, cualquier persona que quiera rehusar o visitar el proyecto puede notar que aparece una insignia que dice reuse compliant. Entonces, eso busca que sea más sencillo determinar o identificar qué proyecto siguen con estas especificaciones. Entonces, para concluir, ¿cuáles son las particularidades de reuse? Entonces, como ya demostré, cada archivo de texto de cada licencia que utilizamos en el proyecto va a estar almacenado en un directorio que se va a llamar licenses. Así que ya no hay pierde. Ya sabemos que allí podemos encontrar todas las licencias que se encuentran en el proyecto. El segundo, como ya también me demostré, es que cada archivo va a contar con esta información. Y tenemos diferentes alternativas para archivos que no podemos comentar. Y por ende, ¿qué va a haber una información inequívica de esa información legal? Porque ya no hay ambigüedad. Ya se puede terminar específicamente bajo qué licencia está cada archivo del repositorio. Y yo sé que se están preguntando, ¿quién ha adoptado reuse? Pues afortunadamente, reuse está tomando bastante fuerza. Ya son más de 800 proyectos registrados en nuestra API registrados. Hay muchos que no se han registrado, así que nos gusta creer que es un poquito más. La mayoría de proyectos que son más de 100 de la iniciativa europea Next Generation Internet que está financiada por la Comisión Europea, estos proyectos también están siguiendo las iniciativas de reuse. En términos de comunidad, KDE, recientemente Curve, también implementó reuse. Así que eso también nos pone muy feliz, porque sabemos la importancia que tiene ese proyecto para la comunidad de sofá libre. En términos ya de empresas, tenemos a Siemens, Huawei, SAP, Life Ray, LF Energy. El kernel del Inux en parte está implementándolo, porque sabemos la magnitud de esto. Y la pregunta es si ustedes y sus proyectos quieren implementar las indicaciones de reuse. Para terminar, pues, bueno, me gustaría comentarlas desde la FACFI y nosotros como estamos ayudando. Bueno, tenemos el software de reuse que, como ya mencioné, es a ver, es sofá libre. Así que estamos recibiendo contribuciones si algunos de ustedes ya está implementando reuse y encuentran algo que pueda mejorar, nosotros estamos más que felices de implementarlo. En FACFI también tenemos una lista de distribución para licencias, para temas de licencias o preguntas más enfocadas en legales. También nuestro equipo legal puede apoyarlos. Y, recientemente, lanzamos Reuse Booster que busca que más proyectos empiecen a implementar reuse. Nos estamos acercando a los proyectos de una manera más cercana, más personal, para entender su workflow, para que sea mucho más sencillo hacer esta transición, porque sabemos que proyectos muy grandes implementar reuse puede parecer como un dolor de cabeza, pero al largo plazo, de seguro, les va a ahorrar mucho tiempo y muchos dolores de cabeza. Y, bueno, ya eso es todo por mi lado. Acá pueden encontrar la página web de Reuse, las listas de distribución, nuestros repositorios en Git. Si tienen alguna pregunta y si no tengo el tiempo de responder en este momento, pues se pueden acercar o nos pueden escribir, mi correo electrónico muy pequeño ahí, pero también está. Y, ya, muchas gracias. No, no, no, todavía no hemos llegado allá. Por eso, por eso decimos que si tienen alguna duda, quieren implementar otra licencia en sus proyectos y no saben si es compatible, nos pueden escribir, tenemos esta lista de distribución en la que podemos resolver esta clase de preguntas más legales. ¿Para qué se le da esa planta o qué es lo importante? ¿Tenemos un plano de tema de distribución en la que hemos distribuido? Eh, bueno, yo hago parte del equipo legal, así que no tengo mucho conocimiento cercano de qué nuevas características están trabajándose para las nuevas versiones de reuse. De seguro este tema es algo que ya se ha tocado. Sin embargo, en nuestro Git, en nuestro repositorio pueden verificar, hay muchos issues abiertos y también muchos full requests abiertos para gente que quiere mejorar el software, que justamente es lo que hace la comunidad de sofá libres a ayudar a que esta clase de proyectos crezcan y mejoren. Así que sí de pronto están interesados en abrir este issue en el repositorio si aún no está. Bienvenido. Gracias.