Barrapunto

No aspiro a talibán ortográfico ni mucho menos pero alguien ha cometido un pequeño error, 'hace' debería ser sustituído por 'hacer'.

Pues eso, que liberar código no requiere rellenar formularios ni contratar al bufete de abogados Fulano, Mengano, Zutano y Perengano. Basta con ponerlo una página web de la empresa indicando claramente "este programa se distribuye bajo la licencia Tal y Cual". Ojo con cagadas como liberar código ajeno.

Ya se ve que la empresa es seria y decide asignar al becario la gestión de su propiedad intelectual que, en una empresa de software es como el 100% de su capital. En fin, también estoy seguro que el becario, en busca de un hipotético puesto de trabajo realizará una labor sin precedentes.

Un becario por definición es alguien que está en la empresa para aprender, y al que sólo se le puede exigir su presencia e interés. La responsabilidad viene con el sueldo, así que olvídate del asunto y que lo haga alguien que cobre por ello. Si piensas que por "perder el culo" por servir a la empresa te van a contratar, olvídate, por experiencia mía y de mis compañeros esto no suele ser habitual.Es más, suelen contratar a los más incopetentes, sobre todo si está buena(conozco un par de casos).

¡Que la noticia dice EE.UU.! ¡El paraíso de Microsoft! (no me tachen de offtopic, a saber qué significa esa palabra que no aparece en el diccionario :P )

En el país donde *todo* lo controlan, parece ser que no les gusta cuando alguien *ajeno* controla por ellos.

De todas formas, espero que sigamos siendo tan *borregos* como siempre (copiamos todo de los EE.UU.) así, por fin, podré decir que nuestros gobiernos han echo algo bueno por la gente (en relación con la informática).

Venga, va.

• Para liberar el código, salvo que sean aplicaciones realmente grandes y se necesite "maquillarlas" un poco, basta con cambiarle la licencia. Para elegir una puedes mirar las aprobadas por la OSI [opensource.org].
• Luego, si quiere "publicidad" que envíen una nota a Barrapunto o sitios similares (aunque las notas de prensa no se suelen publicar tal cual).
• No hay muchos organismos oficionales de software libre. En el caso de Linux, está Linux International [li.org], pero es para usuarios. Luego está el Open Source Development Labs [osdl.org]. En España, tenemos la Asociación de Empresas de Software Libre [aesli.org]. No sé si habrá alguna asociación de Linux embebido. Sin embargo, pertenecer a estas asociaciones no da ningún privilegio o derecho preferente en cuanto al software libre en general.
• La mejor publicidad es hacer algo realmente innovador, crear una comunidad tras ello y que lo use mucha gente.

En realidad, que yo sepa, no existe ninguna vía oficial para liberar el código. Técnicamente es suficiente con poner disponible el código fuente del mismo bajo una licencia que permita su modificación, y redistribución.

Para saber qué pasos conviene dar, y cuál de las múltiples licencias existentes usar, antes de nada es preciso pensar qué es lo que a la empresa le interesa al dar este paso.

Lo más probable es que la posible liberación del código sea por un motivo publicitario (en cuyo caso lo interesante sería publicitarlo de alguna forma), o bien por motivos económicos, pretendiendo crear una comunidad que sirva para probar y mejorar el software. En este segundo caso podría ser interesante aportar servicios que sirvan para crear esta comunidad, como listas de correo o foros, un repositorio tipo CVS y cosas así (o bien usar los de terceros, como sourceforge o savannah).

Miry

Uno de los grandes beneficios del software libre es construir una comunidad que pueda aportar algo al proyecto, en lo que E.S. Raymond llama la economía del regalo: tú das y los demás te devuelven otros regalos.

Para ello hay que trabajarse las condiciones para que eso ocurra, con una buena web, documentación, facilidad para enviar parches o participar en el desarrollo, etc...

Todo esto es fundamental si la empresa opta por el software libre como dirección estratégica. Pero lo más importante es ver qué le aporta: - Reutilizar otro código libre sin duplicar esfuerzos
- Intentar formar una comunidad y reforzar la base de código con contribuciones externas.
- Dar servicios basándose en otro código o recibir servicios de otros proveedores.
- Posicionarse en algún campo específico siendo pioneros en ese aspecto en el SL u ofreciendo una solución más interesante o madura...

Es decir... los pasos a seguir dependen mucho de lo que se quiera conseguir... porque si no bastaría con relicenciar el código original con una licencia GPL o similar y ¡a andar!.

Lo primero que tiene que hacer es revisar que lo que intentan licenciar sea 100% de ustedes o al menos tenga una licencia compatible con los otros componentes de software de terceros de los que hace uso su codigo fuente y despues escogan la licencia que mas les convenga

[gnu.org]

Sin embargo, la liberacion de un proyecto requiere preparar todo el mismo para ello.

El primer paso es escoger la licencia sobre la cual se va a liberar. Dicha licencia ha de cumplir los requisitos de la Free Software Foundation [fsf.org] en caso de proyectos libres (ya que hay licencias "Open Source" que no son "Free Software). Un listado esta disponible en esta direccion [fsf.org].

Una vez se ha estudiado la licencia que sera utilizada, ha de aplicarse a todos los ficheros; con ello nos aseguramos que cada vez que alguien abra un fichero vea la licencia del mismo. Ademas, se incluye un archivo LICENSE con una copia integra de la licencia, ya que la misma es bastante mas extensa que el texto situado en los ficheros fuente. Adicionalmente se puede incluir una traduccion oficial. El siguiente punto es preparar la documentacion si la hubiera con una licencia tambien libre si asi se desea. En este caso podemos utilizar las CreativeCommons [creativecommons.org] o bien alguna listada en la web [fsf.org] de la FSF.

Cuando los pasos previos se han finalizado se empaqueta el software en uno o mas formatos (tar.gz, tar.bz2, zip, 7z...). Estos archivos generados seran los que se pongan a disposicion publica para su descarga.

Si el desarrollo del proyecto sera publico se dispone de la opcion de montar un servidor CVS [barrapunto.com] o SVN [tigris.org] o bien utilizar los recursos de sitios como SourceForge [sourceforge.net], BerliOS [berlios.de] o software-libre.org [software-libre.org] (entre otros muchos).

Es mas que recomendable crear al menos 3 listas de correo, que son como siguen:

• proyecto-users: Usuarios en general
• proyecto-devel: Desarrolladores
• proyecto-commits: Commits de CVS o Changesets de SubVersion si el desarrollo es publico.

Antes de lanzar el proyecto al publico se ha de pensar si la empresa dara un soporte oficial gratuito o de pago sobre el desarrollo (respuestas telefonicas\email\foros sobre el API o desarrollo de funcionalidad especifica para determinado cliente, por ejemplo) del mismo y que nivel de implicacion que tendra la empresa en su continuacion (si lo libera y se olvida, si continua su desarrollo publico, si sincroniza su CVS\SVN interno con el externo unicamente...).

Esta es una pequeña lista de tareas que suelen llevarse a cabo, sin embargo cada cual puede liberar su proyecto como le parezca, mientras que indique claramente la licencia.

Siempre me ha sorprendido que nadie hable de los aspectos contables de liberar el codigo. Los desarrollos de una empresa normalmente están contabilizados como activos y figuran en los balances. ¿Cuál es el valor contable de una aplicación con los fuentes libres? ¿Si no és el mismo,... esto quiere decir que la liberación del código implica aflorar perdidas en la cuenta de resultados? ¿Alguien tiene idea del tema?

Puramente por interés estadístico :) ¿el modelo de negocio cual va ser? ¿soporte de los productos? ¿consultoría de implantación/desarrollo/gestión/...? Espero que os vaya bien, y conteis la experiencia conforme suceda. Será interesante para muchas empresas.

Liberad primero algo jugoso, y que penséis que va a tener muchos usuarios y colaboradores. No liberéis muchas cosas de golpe.

Haced la prueba con uno o dos proyectos y volcáos en intentar darle salida, es decir, que la gente de otras organizaciones o empresas que pueda estar interesada se entere y encontrar entre ellos personas que se involucren en mejorar el código y mantenerlo.

El riesgo de liberar un producto es que el esfuerzo no sirva para nada. Si no aparece una comunidad de gente interesada detrás, no lo usarán, no lo mejorarán y no evolucionará.

Pero es verdad que es importante el motivo, la causa por la que decidís liberarlo. Por ejemplo, ¿dónde encajaríais en este "mapa" de gente que desarrolla software libre [ourproject.org]? Hay muchas estrategias según vuestras necesidades.