Psicofonías

Sobre cultura libre

Con motivo de mi participación en una mesa redonda (mañana, martes 17 de diciembre) en las primeras Jornadas de Ciencias Sociales y Humanidades Digitales de la Universidad de Granada, me han pasado una preguntas como precalentamiento, para que vaya mostrando mi postura.

Tendré el honor de compartir mesa con Javier Ruiz y Salvador del Barrio, mesa que se organizará a modo de "Documental forum": Veremos un documental sobre Google Books y, después, charlaremos sobre cultura, digitalización de contenidos, oportunidades y peligros del entorno digital y derechos de autor.

Las preguntas están respondidas un poco a tiralínea, pero cero que definen bastante bien lo que pienso de estos temas, así que las pongo por aquí:

1) Perfil personal incluyendo referencia a la visión propia del tema y a los proyectos que se desarrollan.

Técnico en la Oficina de Software Libre. Partidario del Copyleft y la Cultura Libre como receptor y como productor de contenidos.

2) Una vez el texto se libera del soporte papel ¿qué posibilidades se ofrecen? ¿Representan papel vs soporte digital modelos llamados a excluirse?

Cuando las cultura se libera del soporte físico se libera de las limitaciones asociadas a este. Conceptos como los costes de reproducción o transmisión descienden hasta prácticamente cero. La cultura es un ejemplo clásico de "economía de la abundancia", opuesto a los clásicos mercados donde la escasez en la mercancía es la que domina las dinámicas de precios y, por tanto, la facilidad o dificultad de acceso a esa mercancía.

El conocimiento lo es independientemente del soporte. El cine no mató al teatro, la televisión no mató al cine, ni el vídeo mató a la televisión.

La irrupción de nuevos soportes como los libros en formatos digitales está significando un duro golpe para un concreto modelo de negocio en la industria cultural y del entretenimiento (pero no necesariamente para cualquier posible modelo de negocio en esa industria). A cambio de ello, está facilitando el acceso al conocimiento y la participación en la cultura a una cantidad antes inimaginable de personas.

¿significará esto el fin del libro-objeto en papel? No a corto o medio plazo, pero sí que significará cambio de paradigma en cuanto al libro como mercancía, quizás como objeto de lujo o como respaldo de la información digital.

3) ¿De qué forman deberían replantearse los derechos de autor en la era de Internet (copyright, licencias abiertas)?

En el "mundo electrónico" (como opuesto a las limitaciones del "mundo atómico"), un contexto en el que se ha superado la economía de la escasez que mencionaba antes, los limitantes legales como patentes, copyright, etc, crean una escasez artificial y actúan como barreras generadoras de monopolios de acceso al conocimiento.

Estos monopolios son controlados por las empresas que detentan esos derechos, sustrayendo el control de la cultura (ahora convertida en simple mercado) tanto a autores/creadores como a lectores/espectadores, en una suerte de "fetichismo de la mercancía digital".

Los nuevos modelos de licencias abiertas, como Creative Commons, retornan el control de la obra al autor, que puede determinar personalmente qué usos permite de su obra sin secuestrarla de su público ni su contexto cultural.

Esto redunda en el retorno a una cultura abierta y libre con posibilidad de reutilización y producción de obras derivadas, en la que desaparece la división artificial que la industria había dibujado entre "productores de cultura" y "consumidores de cultura".

4) ¿Qué riesgos enfrentamos ante los grandes monopolios de la información (Google, Facebook, etc.)? ¿De qué manera pueden protegerse los ciudadanos?

Estos monopolios crecientes son una señal de alarma y un ejemplo claro de los peligros del copyright y las limitaciones a la difusión de la cultura. Como hemos visto, un mercado de grandes empresas que detenta los derechos legales de la cultura-como-mercancía no sólo limita el acceso a esta, si no que actúa como un bloqueo ahogando el flujo de información y conocimiento que es. al fin y al cabo, la cultura.

Por si esta fuera poco, no sólo la difusión de la cultura está limitada, si no que cualquier decisión que el autor pudiera tomar sobre su propia obra está limitada o directamente coartada por el interés de esos monopolios. No deja de ser irónico si tenemos en cuenta que las leyes de Propiedad Intelectual fueron ideadas para proteger a los autores del control por parte de los editores.

5) Propuestas para desarrollar en la Universidad de Granada y en el proyecto GrinUGR en este tema.

Por ejemplo: Formar en el uso y necesidad de las herramientas de una cultura libre y abierta. Incentivar la liberación y difusión de contenidos. Catalogar y divulgar las obras liberadas en la universidad.

2013-12-11 10:09:08

En el momento de publicar esto, la fecha es exactamente la del título.

Pues eso, una fecha curiosa.

Ciclo de vida de una noticia en twitter

• Ocurre algo
• Alguien se queja de ese algo en twitter
• Alguien más también se queja de ese algo en twitter
• Alguien propone un hashtag de twitter para quejarse de ese algo
• Alguien se queja en twitter de los que sólo se quejan en twitter
• Alguien se queja en twitter de los que sólo se quejan en twitter de los que se quejan en twitter de... ...me he perdido
• Alguien dice en twitter que alguien debería hacer algo
• Alguien en twitter responde que no se puede hacer nada
• Alguien más continúa quejándose de ese algo en twitter
• Alguien hace chistes sobre ese algo en twitter
• Alguien protesta por twitter diciendo que no es tema para hacer chistes
• Alguien dice en twitter que está a favor de ese algo
• Alguien se enfrenta en twitter al que dice estar a favor de ese algo
• Se monta un flamewar en twitter sobre ese algo
• Se empieza a olvidar en twitter ese algo
• Alguien en twitter continúa quejándose de los que sólo saben quejarse en twitter
• Ocurre otro algo

Pi Mondrian

Del mismo modo que me atreví a hacer una incursión en el mundo de la literatura, ahora me he atrevido con el de la pintura.

Y, del mismo modo que entonces, he vuelto a hacer trampas.

Si cuando quise escribir hice un programa para que escribiera por mí, ahora, en lugar de pintar un cuadro, he escrito un programa que pinta cuadros.

Concretamente se trata de un programa en python que usa los dígitos de Pi (extrayéndolos de un archivo) para generar cuadros "al estilo" de Piet Mondrian. Dicho esto, es evidente que el programa no podía llamarse de otro modo que PiMondrian.py

El algoritmo de generación funciona recursivamente, primero dividiendo el lienzo en dos rectángulos, luego dividiendo cada uno de ellos en otros dos, y así sucesivamente, tantas veces como se le haya indicado (en principio, hay cinco "generaciones" de rectángulos).

Para ello, en cada división, va extrayendo dígitos de Pi de tres en tres.

El primero de cada grupo de tres es usado para decidir en qué posición se colocará la línea divisoria. Por ejemplo, si el dígito es 3, la división se coloca a 3/10 de la distancia total (si el dígito es 0, se asigna toda la distancia, lo que crea una duplicidad redundante que no es muy relevante para nuestro quehacer artístico).

Los otros dos dígitos de la terna extraída se usan para decidir el color de cada uno de los nuevos rectángulos.

Para la elección de los colores se sigue un criterio observacional, por el que el más usado por Mondrian es el blanco y el menos usado el amarillo. De este modo, el programa tiene una tabla que asigna colores según esta receta:

0,1,2	Blanco
3,4	Rojo
5,6	Azul
7,8	Negro
9	Amarillo

Por supuesto, se trata de otro experimento (bastante simplón) de arte autogenerado. Al contrario que el programa que generó mi popular e interesante libro "Los diez mil primeros dígitos decimales de Pi", este es totalmente determinista y no deja nada al azar. Cada vez que se ejecute con los mismos parámetros dará lugar al mismo cuadro o conjunto de cuadros.

Un detalle importante de todo este proceso es que cada "generación" así creada es un cuadro por derecho propio. De hecho, si se llama al programa con el parámetro "generation", pintará todas las generaciones de cuadros, no solo la última.

Mucho más interesante es usar el parámetro "gallery" (que no es compatible con el anterior), que genera toda una galería de cuadros (por defecto crea una veintena de ellos). Pi Mondrian no es un programa que pinta un cuadro, sino que es un artista virtual y autónomo completo, que puede crear, sin ayuda humana, una infinidad de ellos.

De este modo, siempre estarás preparado para cuando tu galerista de cabecera te venga pidiendo una exposición.

Naturalmente, el programa está distribuido como software libre con una licencia GPL y puede descargarse en su repositorio de Github

Cómo liberar software

Hace algún tiempo estaba yo soltando un rollo sobre compatibilidades entre licencias de software y alguien me dijo (más o menos): "Vale. Pero sin follones ni líos: Supongamos que yo he hecho un programa y quiero liberarlo. ¿Qué hago?".

Liberar un software puede llegar a ser tremendamente complicado e incluso, a veces, literalmente imposible. A menudo la cosa se complica por desacuerdos entre los autores, o con la empresa para la que trabajan, o líos legales con las distintas licencias que pueda tener un programa complejo...

Pero, en la mayoría de los casos, cuando dices "He hecho este programa y quiero liberarlo" es algo muy fácil, simple y rápido. De modo que, en adelante, supondremos que eres el autor del software y que no estás usando librerías ni código de otros autores.

Paso 1 Elegir Licencia:

Hay un montón de licencias libres para elegir, cada una de ellas con unas características propias. Algunas licencias son compatibles con unas pero con otras no. Si usas librerías o parte del código de otros, o si tu programa es una modificación del de otro, tendrás que usar su misma licencia o una licencia compatible con la suya. Si usas código de varias fuentes con licencias distintas, necesitarás encontrar una licencia compatible con todas ellas (y eso puede llegar a ser un lío tremendo en el mejor de los casos, o incluso imposible en el peor).

Pero sigamos suponiendo que todo el código es tuyo y no dependes de las licencias de otros. Entonces puedes elegir la licencia que quieras. Personalmente, te recomiendo que uses la licencia GPL. Es una licencia libre que permite todos los usos de tu software (incluso comerciales), permite redistribuirlo, modificarlo y crear software derivado, pero exige que todo ese software derivado se distribuya con esa misma licencia GPL. Esto es importante porque, de este modo, todas las mejoras, modificaciones o software derivado que hagan los demás de tu código también tendrán que ser libre (a esto, concretamente, es a lo que se llama "Copyleft"). Es también la licencia libre más usada y, de hecho, la que usa Linux.

Una vez elegida la licencia, tendremos que indicarla en cada uno de los archivos del código fuente. Veamos cómo.

Paso 2: Copyright.

Sólo la persona (o personas, si son varias) que tiene el copyright de un programa puede liberarlo. En principio, esa persona (o personas) es el autor (o autores) de ese programa.

Así que lo primero que tienes que poner en la cabecera de tu programa es un anota diciendo quién eres y que que tienes el Copyright, con algo parecido a esto:

Copyright 2013 Allan Psicobyte.

(si hubiera más de un autor se pondría una línea como esa por cada uno de ellos)

Después de la nota de copyright se pone un pequeño texto que indique concretamente la licencia que estamos usando. Suele haber un texto estándar para cada una de ellas, y en el caso de la GPL es este:

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.

Paso 3: Archivo con la licencia

Además de poner el texto con copyright y licencia en cada uno de los archivos del código fuente, es conveniente acompañarlo con otro archivo que contenga el texto completo de la licencia. Por tradición, ese archivo es de texto plano y se llama README (así, en mayúsculas y sin extensión) o, mejor, LICENSE. El texto de la licencia, en el caso de ola GPL, se puede copiar de la versión que hay en la página del proyecto GNU (tal cual, sin modificar nada).

Paso 4: Publicar el código:

Lo siguiente es poner todo esto en algún lugar público al que se pueda acceder. Lo puedes poner para descargar como un archivo comprimido en tu página personal, usar tu propio servidor FTP o el método que prefieras pero, lo más recomendable con diferencia, es usar alguno de los muchos repositorios de Software Libre o forjas que existen. Estos sitios te permiten fundir el proceso de desarrollo, producción y distribución en uno sólo, y suelen estar dotados de herramientas muy útiles.

Hay muchos diferentes y, dependiendo del sistema de control de versiones que uses (y, si no usas ninguno, deberías hacerlo), preferirás uno u otro. Sourceforge, por ejemplo, es un clásico que usa subversion, aunque últimamente el que está pegando fuerte es github, que usa git y tiene un montón de herramientas de tipo "red social" que sirven de mucha ayuda.

Además, siempre que distribuyas el programa deberá ir acompañado del código fuente o, en su defecto, de un enlace o texto indicado cómo conseguirlo.

Por último, dependiendo de cómo sea tu programa, es una buena idea incluir algún aviso sobre la licencia en la documentación, la ayuda (el clásico "Acerca de..."), el manual, etc.

Y con esto, ya eres un programador de Software Libre. Enhorabuena.

(Publico este texto simultáneamente en mi blog y en el de la Oficina de Software Libre de la Universidad de Granada)