Software cerrado ¿software libre? O No te metas con mi cucu

+1
+6
-1

Las 4 libertades del software libre:

  • La libertad de ejecutar el programa para cualquier propósito (libertad 0).
  • La libertad de estudiar cómo funciona el programa, y cambiarlo para que haga lo que usted quiera (libertad 1). El acceso al código fuente es una condición necesaria para ello.
  • La libertad de redistribuir copias para ayudar a su prójimo (libertad 2).
  • La libertad de distribuir copias de sus versiones modificadas a terceros (libertad 3). Esto le permite ofrecer a toda la comunidad la oportunidad de beneficiarse de las modificaciones. El acceso al código fuente es una condición necesaria para ello.

(fuente: http://www.gnu.org/philosophy/free-sw.es.html)

Hablando del sistema operativo Android de Google, es sabido que está catalogado como software libre, y sin embargo una buena parte de las comunidades de desarrollo de software libre, se resisten a considerarlo así.

La razón es que durante todo el tiempo del desarrollo de cada nueva versión, el total del código se mantiene cerrado y secreto. Así que durante todo este tiempo no cumple con ninguna de las 4 libertades.

Incluso una vez que está terminado, el código es proporcionado en forma privada y selectiva, y median para ello sendos acuerdos de confidencialidad entre Google y aquellos que reciben los fuentes, principalmente los fabricantes de dispositivos que incluirán en sus futuros productos a la nueva versión, aunque también puede ofrecerse a otros, como por ejemplo desarrolladores de aplicaciones para Android, o miembros de la prensa especializada.

Es hasta el momento en que Google decide hacer la presentación oficial de cada nueva versión, que se abre el código a cualquiera que quiera consultarlo, copiarlo, modificarlo, redistribuirlo e incluso alterarlo.

Así un software que es completamente privativo durante su desarrollo, termina por convertirse en software libre, tan pronto como Google y sus socios están listos para comenzar la comercialización de los gadgets Android.

Esto, que por supuesto no contraviene ni en una coma con las licencias de software libre, ya que además hay que entender que eso que se va a liberar no existe aún en realidad. Pero sí contraviene los usos y las costumbres (normas) del desarrollo del software libre, y como decía uno de mis profesores del bachillerato: La Norma es Ley.

De esta forma Google se comporta como cualquier otra empresa. Tomemos por ejemplo a la industria automotriz, donde el desarrollo de cada uno de los aspectos de cada nuevo vehículo es un secreto celosamente guardado. Pero el mismo día que se pone a la venta, no hay nada que te impida pasar por uno a la agencia distribuidora y llevártelo a tu taller e investigarlo, desarmarlo, entenderlo, modificarlo, copiarlo e inclusive revenderlo. De hecho todas los fabricantes automotrices tienen acuerdos de cooperación con esos tan famosos (por la tv) talleres de modificaciones especiales. Y que decir de las conocidísimas copias chinas. Eso sí, dice el dicho que el que pega primero, pega dos veces.

Por el contrario las comunidades de software libre, comienzan muchas veces de la discusión de una idea, o de un desarrollo embrionario de lo que se pretende hacer (el caso de linux es emblemático), y desde ese primer momento todo el código que se está generando cumple con las 4 libertades (incluso aquel que será desechado al final).

Así las comunidades no consideran a Android software verdaderamente libre, en tanto que los fabricantes si lo hacen y además se hacen de pingües ganancias por este hecho. De cualquier modo el comentario mas generalizado entre los miembros de las comunidades es: ¿Qué otra cosa se podía esperar de Google?

¿Pero que sucede cuando es una de las distribuciones GNU/Linux la que sigue pautas de comportamiento similares? Me refiero por supuesto a Ubuntu, que está desarrollando las partes esenciales de su nueva y próxima tecnología en forma un tanto parecida.

Al parecer, a diferencia de Google, Canonical no está manteniendo en secreto el código que está creando, sin embargo no está admitiendo código de nadie que no sea parte del proyecto de desarrollo designado. Traducido: Puedes ver, oler, tocar, jugar, cambiar, pero nada de lo que hagas me concierne, incluso si descubres la ecuación del universo. Yo seguiré por mi propio camino y de acuerdo a mis procedimientos y metas.

Lo que en realidad convierte a los proyectos de Canonical en algo casi tan cerrado como lo que hace Google, puesto que nada le impide dar giros de timón en cualquier instante, e incluso presentar algo completamente distinto a lo que se ha estado viendo durante el desarrollo, si así conviene a sus intereses.

No es mi intención criticar, ni mucho menos reprobar este modo de actuar, mi único propósito es clarificar el porqué de la tormenta en el mundo de software libre con las decisiones de Ubuntu – Canonical.

Este proceder tiene ventajas para Canonical, que no debemos olvidar tiene como objetivo principal el ser un éxito comercial.

Estos métodos cerrados le permiten establecer pautas de comportamiento, cadenas jerárquicas, distribución de responsabilidades, requerir tiempos de entrega, realizar pruebas de campo, mantener una alta expectativa y por encima de todo, si se han hecho de los servicios de personal calificado: cumplir con la creación del producto en la forma prevista. En resumidas cuentas un control total.

Por el contrario las comunidades de software libre, con su sistema meritocrático, suelen tener de todo, excepto sentido del tiempo. Existen en Youtube una serie de vídeos que muestran como ha sido el desarrollo de algunos proyectos de software libre, en este momento recuerdo uno sobre Lazarus, aunque he visto al menos otros dos.

Algo que queda claro de estos vídeos, es que muestran como la actividad de las comunidades tiene un comportamiento sinusoidal, es decir tiene subidas y bajadas bastante evidentes. Esto debido a la disponibilidad de los programadores, que debemos recordar, la gran mayoría son voluntarios, y en consecuencia, a pesar de toda su voluntad y buenas intensiones, solamente le pueden dedicar a los desarrollos comunitarios una parte de su tiempo y durante un periodo finito; hay que mantenerse, formar una familia, desarrollarse laboralmente y otras nimiedades de la vida cotidiana.

Además el sistema en sí es lento, debido a que siempre hay que lograr un consenso entre los miembros de la comunidad, lo que puede llevar a fricciones (y de hecho lo hace) entre sus integrantes. Un ejemplo muy claro de esto último ha sido el reciente fork de Webkit (Blink), al que la mayoría de los especialistas coinciden en achacar a las continuas y crecientes discrepancias entre Apple y Google, dos de los mayores contribuidores de este proyecto de software libre, del que se dice había (hay) mas de 7 repositorios con código. Ya se podrá entender la enorme dificultad que significaría unir todos estos esfuerzos disímbolos en un solo proyecto coherente.

¿Cuál modelo es el correcto? Yo no tengo una respuesta, cada uno tiene sus virtudes y sus fallas. Lo que es un hecho incontrovertible es que los productos finales de ambos sistemas son software libre y por el momento con eso me quedo. ¿Y que tiene ver el cucu en todo esto? Dale un vistazo al vídeo y forma tu propia opinión.

http://www.youtube.com/watch?v=EU5J2zJoNB4

Comentarios

Imagen de ivisdrek

Hola @gato2707:

Una diferencia fundamental entre tocar el cucu en la industria de la automoción y hacerlo dentro del software libre es lo anecdótico que le resulta a los fabricantes de coches que alguien, de forma aislada, cucurice un coche o una serie limitada de los mismos y decida sacar rentabilidad (limitada) de su trabajo. Otro gallo cantaría si fuera posible cucurizar un coche y luego darle a un botón y tener la posibilidad de comercializar miles o millones de coches cucurizados. A los dos minutos los gobiernos sacarían leyes draconianas anticucu...

Dicho esto, yo, por mi forma de pensar personalísima, simpatizo más con los proyectos de software libre abiertos y democráticos, sin secretismos comerciales (y por eso últimamente vengo siendo tan crítico con Canonical). No obstante, entiendo cuando a estos movimientos se les achaca una excesiva dispersión, poca concreción y falta de una idea clara que se lleve a término en plazos determinados, etc. La clave la has apuntado tú mismo: en su mayoría estamos hablando de proyectos en los que colaboran desarrolladores en sus ratos libres. No hay más que decir.

De modo que, según creo, la única manera de suplir estas carencias del software libre es hacer con que se "profesionalice". Una vía muy interesante, que cada vez cobra más importancia y puede ser la tabla de salvación para este tipo de proyectos, es el crowdfunding. Me remito al caso reciente de OpenShot. Creo que esta fórmula resuelve dos problemas de una tacada. Uno, por supuesto, es la financiación. Pero también hay que tener en cuenta que el intento de captación de fondos mediante esta fórmula obliga a los promotores y desarrolladores del proyecto en cuestión a concretar sus objetivos en términos muy estrictos. Y esto por sí sólo ya es muy positivo.

El crowdfunding todavía está en una fase muy incipiente, pero, ojo, crece como la espuma. Ojalá llegue un día a generalizarse (eso significaría una toma de conciencia importante por parte de mucha gente).

Por cierto, anímense todos a colaborar con vuestros proyectos de software libre favoritos. Una pequeña contribución bastará.

____________________________

https://eljardindelexilio.wordpress.com/

Imagen de Goyo

Android no es completamente privativo durante su desarrollo, ni siquiera un poco privativo o parcialmente privativo, porque no se publica en esa fase.

Todo el software pasa por una etapa más o menos larga en la que no está disponible más que para un número reducido de personas. Durante esta etapa no es libre ni privativo, es simplemente software no publicado. La mayor parte, con gran diferencia, de todo el software que se escribe y se usa, se queda para siempre en esa etapa y no llega a publicarse nunca.

La forma de desarrollar depende de las personas y organizaciones que participan y lo que va bien para unos no va bien para otros. Y cuando las personas y las organizaciones cambian también puede cambiar el modelo de desarrollo, como hemos visto en más de una ocasión.

Canonical se ha mostrado muy torpe a la hora de colaborar con otros equipos de desarrollo, así que tal vez sea mejor para todos que se concentren en hacer las cosas a su manera, al menos mientras no aprendan a hacerlo de otra. De ese modo cumplen mejor sus objetivos y distraen menos a los demás. Google no tiene demasiados motivos para buscar colaboración. Sun logró mantener el control sobre OpenOffice, pero Oracle no pudo (o no le interesó).

Igualmente el código desarrollado por Google o Canonical podría cobrar nueva vida en otras manos si estas organizaciones flojearan o simplemente hubiera suficiente interés fuera de ellas. Para que esto pueda suceder lo importante no es el modelo de desarrollo sino el modelo de licenciamiento.

Hablando del control férreo del desarrollo, introducir cualquier cambio no trivial en Python es más difícil que conseguir audiencia con el Papa. Hacerlo en SQLite o Fossil puede ser algo más fácil... siempre que al Dr. Hipp le cuadre. Naturalmente hay muchos forks, públicos y privados (no necesariamente privativos), de SQlite y de Fossil, con características no bendecidas por Hipp. Más de siete, desde luego, sin que nadie se lleve las manos a la cabeza.

LibreOffice por el contrario sigue un modelo democrático y comunitario y ahora tienen un calendario estricto de liberaciones que no tenían cuando estaban bajo el control de una gran corporación y yo diría que lo están haciendo mejor que antes, más deprisa, con más calidad y con una visión más clara. Quantum GIS es otro proyecto de estilo democrático, desarrollado por voluntarios y empleados de diversas organizaciones en perfecta armonía, y lleva un ritmo realmente espectacular.

Nota quejumbrosa:
Te has molestado en poner un enlace al video del cucu y no a esos videos tan interesantes sobre el desarrollo de software libre. Mala elección a mi modo de ver. Para compensar pondré yo uno precioso sobre el desarrollo de Python:
http://www.youtube.com/watch?v=cNBtDstOTmA
También los hay de android, gcc, grass, quantum gis, evolution y muchos otros.

Imagen de PPamaterasu

Algo que nunca me ha gustado del sotware libre es que el hecho de liberar el codigo lo vuelve practicamente gratuito. Y es muy feo que se relacione los gratuito con software libre.

Un modelo de comercio interesante seria no liberar el codigo para todo el mundo. mas bien establecer un tipo de comercio de software libre que incluya el codigo fuente. Me hago entender?

Digamos que a Canonical se le da la gana de competir con Adobe creando una "Ubuntu Artist Suite" profesional para dibujantes y pintores digitales. Podrian vender la suite no se...por 500 dolares, y que junto con la descarga se incluya una carpeta con el codigo fuente entero del programa. Asi que aquellos que quieran modificar el codigo tendrian que comprar la suite. Y por supuesto, esto no significa que el programa sea cerrado.

Me parece que el desarrollo de Android siempre ha ido por buen camino. Google no puede darse el gustazo de liberar el codigo desde el inicio para que venga otro y haga un Android aun mejor. El objetivo de Google es hacer dinero despues de todo, no?

"Solo con vivir las personas lastiman a otras sin darse cuenta, mientras la humanidad exista el odio existirá, la paz verdadera no puede existir en este mundo maldito"

Imagen de Goyo

Digamos que a Canonical se le da la gana de competir con Adobe creando una "Ubuntu Artist Suite" profesional para dibujantes y pintores digitales. Podrian vender la suite no se...por 500 dolares, y que junto con la descarga se incluya una carpeta con el codigo fuente entero del programa. Asi que aquellos que quieran modificar el codigo tendrian que comprar la suite. Y por supuesto, esto no significa que el programa sea cerrado.

Por supuesto, eso significa que no sería software libre ni open source según las definiciones habituales, por lo tanto sería software privativo (= no libre). No sé si sería o no "software cerrado" porque nadie se ha preocupado nunca de definir lo que es eso (o yo no me he enterado).

Imagen de Goyo

Esa respuesta mía es una idiotez, desde luego. Es perfectamente posible distribuir el software libre del modo que describes y de hecho RedHat sin ir más lejos lo hace más o menos así. Naturalmente eso no impide que Centos distribuya ese mismo código gratuitamente.