Introducción

El software libre esta ganando adeptos, día a día, consiguiendo un mayor movimiento en los proyectos de software libre. Este fortalecimiento, esta trayendo tambien una nueva manera de pensar, y programar.
Sin embargo, esta nueva manera de pensar, tambien esta atrayendo a una serie de individuos, que no entenden bien el nuevo modelo, e impiden que crezca más, y se establezca como estandar. Estos participantes del software libre impiden que entre el mundo del software profesional, descalificando todo software que no es libre, olvidando que para que funcione el modelo de software libre deben cumplirse una serie de requisitos (Como bien dice Eric S. Raymond en "El caldero Mágico").
Este documento trata de clarificar aquellos puntos que resultan algo confusos.

Coste del software

Hoy en día, el coste de distribución (copia) de un producto software, es casi nulo, y salvo en muy contadas excepciones, no debe ser tenido en cuenta para evaluar el coste del software, pues la copia en si, no vale practicamente nada. No obstante, el software si tiene un coste, que es el coste de producción, que debe diluirse entre todas las copias que se realizan del mismo, o debe ser compensado por los servicios que genera.
Una de las grandes aportaciones del software libre, sin lugar a dudas, es el abaratamiento de los costes de producción, sin embargo, es un pequeño error considerar que el coste baja a cero, pues sigue teniendo un coste. Uno de los mayores costes de un proyecto libre, es conseguir que la comunidad se sienta implicada en el proyecto en cuestion.

Implicación de los programadores

Como bien indica Eric S Raimon, en "Cultivando la Noosfera", existe una motivación para que los desarrolladores tomen parte en los proyectos libres, unos por puro alturismo, y otros por devolver aquello que toman de la comunidad, y otros pocos, respetando las licencias GNU.
Sin embargo, hay temas importantes, que Raimon no trata en su documento, son de vital importancia, el primero de ellos, es el hecho de que para ser un buen programador, hace falta practica, de hecho, mucha practica, y segun el proyecto en cuestión, tener muchos conocimientos especializados.
Otro factor importante, es la complejidad de los proyectos, hoy en día los proyectos tienden a ser más, y más grandes.
Un último factor a tener en cuenta, del documento de Raimon, es el echo de que trata en exclusiva a los programadores individuales. Un programador puede colaborar mucho con el software libre, pero algo que es obio, es que los programadores no viven del aire.

Primeras Conclusiones

Desgranando lo que ya sabemos, obtenemos lo siguientes factores necesarios para la liberación del código fuente:

• Debe existir una comunidad relativamente grande de gente interesada en el proyecto
• Debe ser un proyecto técnicamente "agradable"
• Los costes de producción deben de ser escasos, o ser de una amplia difusión

Es decir, que para aplicaciones muy verticales, o cuyo coste de producción es extremadamente alto (P Ej: Juegos, o programas de formulación), no tiene sentido a corto plazo la liberación del código. Puede darse el caso de que se libere cierto código una vez ha transcurrido un tiempo en el que se ha amortizado el producto (Como fue el caso del DOOM).

Los programas hechos por instituciones públicas (Universidades, colegios, pagados por el gobierno, etc....), no les influye la rentabilidad, por lo que en su caso concreto, no tendría sentido que los programas que hiciesen fuesen de código cerrado.

Otras consideraciones

En los casos en los que los costes de producción no se amortizan de manera inmediata con los servicios que genere el software producido, se verán abocados a mantener el código fuente cerrado (En especial aquellos proyectos con un coste de mantenimiento elevado), o a hacer una transición paulatina entre la fabricación y la liberación del código fuente.

Tampoco aquellas compañías que desarrollen software podrán permitirse liberar el código fuente, si tienen una competencia muy fuerte y numerosa (Y dicho sea de paso, en estos casos tampoco aporta grandes beneficios el codigo libre, pues los costes ya están reducido al mínimo), pues si bien es una apuesta de futuro, darán pistas a la competencia para que esta incorpore las mejoras de el producto, de modo que perdería competitividad en un mercado duro.

Un claro ejemplo de esto son los programas de gestión en España. En España hay una gran cantidad de productos, cada cual orientado a un segmento del mercado en particular, habiendo decenas de programas para todo ello, por lo que los costes de producción se compensan solo parcialmente con los servicios que se prestan, teniendo que depender en muchos casos de la venta para acabar de amortizar, y para tener beneficios (A algunos lectores les costará entender este concepto, pero lo cierto es que las empresas se crean con el motivo de generar beneficios. Una empresa sin beneficios no tiene sentido que exista). En este sector del mercado, yo no recomendaría que se liberasen los fuentes.

Licencias

El últrimo punto a tratar, es la posible convivencia de código fuente abierto, y código cerrado, que se regula fundamentalmente por las licencias a emplear, por lo que se debe estudiar la licencia que se quiere poner a un programa antes de ponersela.
Como se ha comentado en los puntos expuestos hasta el momento, existen programas que deben, o puede que se mantengan cerrados por motivos comerciales.
Pero no solo existen programas "completos", tambien existen multitud de librerías hechas bajo código fuente abierto, que permiten interconectar ls programas entre si, y qie abaratan los costes de producción de otros programas, pero ¿Bajo que licencia deben publicarse estas librerías?
Mientras que para una aplicación completa recomendaría la GPL, o la MPL, no así para las librerías. La creaciónde librerías facilita el trabajo los programadores, pero un programa cerrado no puede emplear una librería bajo la licencia GPL. Aquellos programas por definición cerrados (P Ej: Los juegos), tendrán un coste de producción superior si no pueden utilizar las librerías desarrolladas, por lo que quien pierde es el usuario. Si una librería solo sirve para realizar programas muy especificos, quizas si convenga el empleo de la licencia GPL, pero la gran baza del software libre es la integración entre aplicaciones, por lo que tampoco estas las liberaría bajo licencia GPL. Personalmente me inclino por la licencia MPL, en lugar de la LGPL, pero la idea es permitir una convivencia y una integración total (Si una empresa con productos cerrados abarata los costes de producción, podría llegar a ganar más con los servicios que con el producto en si, y entonces, liberarlo para que tenga una mayor difusión).
Todas las licencias que he leido están mas o menos bien, pero si hay una licencia que no recomiendo ni para programas ni para librerías es la BSD, pues no tiene la obligación de retorno en caso de que se invierta en el código obtenido.