viernes, 26 de noviembre de 2010

Lo bueno y lo malo de la comunidad

Aunque el debate en curso sobre el futuro de Java y OpenOffice no debería sorprender, el hecho de que los desarrolladores se han dejado de ser capturado en esta posición, para empezar se debe licencias. El - la razón? La comunidad ha sobreestimado el poder de software incluso con licencias de software libre - para proteger sus derechos, y optó por no tomar ventaja de otras herramientas que pueden.

Sí, restrictivas licencias hoy que garantizan los derechos de gran alcance, pero esos derechos no son más fuerte que la capacidad de sus dueños para hacerlos valer. Colocación de defensa dependencia de un todo en un instrumento jurídico único puede hacer que no tiene sentido más que confiar en un sistema de armas único. ¿Por qué? Porque es muy fácil que se adelanten a un enemigo con un variado armamento más. Y desde la adquisición de Oracle de Sun, las defensas tradicionales de los desarrolladores de código abierto han sido tan efectivo como-Mundial de Francia después de la Primera Guerra Línea Maginot .
Como los acontecimientos recientes han demostrado, los poderes de los desarrolladores son limitados en comparación con el poder de una compañía Fortune 500, como Oracle, cuando la sociedad no le importa si los desarrolladores independientes de seguir apoyando los proyectos que lo adquirió. Lo que los desarrolladores se están dando cuenta es que la acción basada en las opciones de licencia y diversos grandes grupos de contribuyentes código son difíciles de llevar a cabo, y no necesariamente muy atractivo.

Esta realización fue resumido algunos días atrás y en un comentario publicado por Bob Lee a una entrada de blog en Coleburne de Weblog Stephen relativas a las candidaturas a la Comunidad Proceso de Java (JCP) del Comité Ejecutivo, que controla lo que puede y no puede formar parte de futuras versiones de Java. Mientras que el PCJ anfitriones de un proceso abierto, el Comité Ejecutivo debe aprobar los cambios a la definición de Java y nuevas características añadidas a la misma, y Oracle tiene el derecho a controlar tres de los cinco asientos del Comité Ejecutivo. Bob decía en parte:

Cerraron Java y prohibida implementaciones independientes. Tenían el pastel y se lo comió, también. Java no sería tan exitoso como lo es hoy si no fuera un estándar abierto. Ciertamente, no han contribuido. Ahora, estoy en esta posición incómoda en la que han invertido demasiado para dejar solo. Tengo que sentarme y esperar Oracle hace lo correcto. Me culpo.

A los fines de mi argumento (y de Bob), que no viene al caso ya sea real nominados de Oracle para el Comité Ejecutivo de la JCP se sincera e independiente, inconscientemente afectado por su propio interés comercial, o abiertamente que operan a la entera disposición de Oracle y de llamadas. El punto central es que Oracle tiene el derecho a elegir entre las alternativas, ya sea ahora o en el futuro.

Hoy en día, los desarrolladores tienen sólo dos defensas: al tenedor de un proyecto, o, si una empresa controla un proyecto sobrepasa sus límites, hacer valer sus derechos legales bajo la licencia bajo la cual los desarrolladores hicieron sus contribuciones de código.

Pero se bifurcan un proyecto implica esfuerzo, incertidumbre, retraso y riesgo (como contribuyentes a OpenOffice.org están experimentando ahora). Y si una licencia de software libre ha sido violado, ¿dónde están los recursos que venir de hacer valer los derechos de un desarrollador? Es cierto que hay varias organizaciones no lucrativas dispuestos a hacer valer esos derechos. Sin embargo, una empresa como Oracle tiene los recursos para gastar más que todos en la corte, el público ausente o detrás de las escenas de las contribuciones de otras grandes corporaciones.

Al final del día, lo sensible única defensa para los desarrolladores contra el abandono o la subversión de un proyecto no es llegar a ser vulnerables a los riesgos para empezar. La ironía es que los medios para hacerlo están disponibles, y es hora de que los desarrolladores comenzaron a tomar ventaja de ellas.

Esbocé los pocos medios hace unas semanas, cuando un grupo de desarrolladores de OpenOffice se separó para formar el Open Document Foundation. La lección central es que los desarrolladores de fuente abierta, como abierta a los desarrolladores estándar, debe insistir en que un patrocinador corporativo creado una entidad jurídica independiente para albergar un proyecto (o encontrar una, fundación independiente existente para alojar el proyecto) si desea que los integrantes de la comunidad para contribuir con su tiempo y su código. Que la entidad debe estar regulada por un Consejo de Administración u otro órgano que no está controlada por la empresa patrocinador (ver mis críticas y recomendaciones aquí sobre la forma de no crear dicha organización).

Un proyecto independiente de acogida sólo no posee el derecho de controlar la dirección futura del código del proyecto, sino también la marca en el nombre de ese código. De esta manera, si el patrocinador decide ejercer su derecho al tenedor el código del proyecto, debe hacerlo con un nombre diferente. Richard Stallman se dio cuenta del poder de hace décadas, la propiedad, cuando se formó la Free Software Foundation para tener los derechos de autor y la marca en el software GNU, proporcionando un único punto de control para hacer valer los derechos de todos los contribuyentes en el código caso de que los términos de la GPL con el que fue licenciado fueron violados.

Para mantener esos defensas es simple, barata y rápida de lograr. Mi sugerencia a la comunidad es insistir en que las empresas patrocinadoras o crear un proyecto como una entidad jurídica independiente, o poner en marcha un nuevo proyecto (con su propio consejo de administración) bajo el ala jurídica de una entidad independiente que, antes de que se comprometen a participar. De lo contrario, los titulares de derechos de la comunidad seguirá siendo vulnerable a los errores que nunca hubieran imaginado, y que podrían haberse evitado fácilmente.

No hay comentarios:

Publicar un comentario