Llegamos a ustedes gracias a:



Reportajes y análisis

Cuidado con los costos ocultos

[31/10/2011] El atractivo del software libre y de código abierto es innegable -después de todo, ¿quién no quiere tomar ventaja del dinero de otros para desarrollar un producto de software o plataforma que de otro modo requeriría llevar mucho más tiempo, recursos de programación dedicados y costo significativo?
De hecho, a juzgar por el crecimiento explosivo de las iniciativas de software libre y de código abierto (FOSS), las organizaciones están alineadas como los seguidores del flautista de Hamelin para tomar ventaja de los productos por los que no tienen que pagar, y que pueden ser objeto de un uso inmediato. O, por lo menos, tan pronto como los desarrolladores de la empresa puedan conseguir el código base y personalizar el paquete para las necesidades de la misma.
¿Y alguien mencionó tal vez la necesidad de ver si hay algún costo de mantenimiento, restricciones de licencia, riesgos de seguridad, o si la adopción del código abierto podría tener un impacto sobre la propiedad intelectual de la empresa? Los costos ocultos, problemas de licencias y otros riesgos pueden crear obstáculos inesperados a las empresas comerciales.
Percepción vs Realidad: "Libre" y "Abierta" - con pocas ataduras
El caso de negocio para el software de código abierto, a primera vista, puede parecer convincente. Encontrar una aplicación de código abierto que se asemeje a las necesidades de una empresa, puede ser como descubrir un tesoro escondido. Pero la realidad es que la parte "libre" del software libre a menudo significa solo "para descarga gratuita", mientras que los costos de implementación de la aplicación o plataforma de hecho, pueden ser sustanciales. Y "abierto" está sujeto a interpretación, en términos de que la aparentemente simple licencia puede llegar a ser difíciles de interpretar legalmente.
El concepto general del modelo de licenciamiento es permitir el uso, modificación y redistribución libre del código fuente desarrollado -o modificado- bajo la licencia, siempre y cuando cualquier trabajo derivado se publique bajo la misma licencia, con los mismos avisos, derechos y acceso al código fuente. La Open Source Initiative (OSI), institución sin fines de lucro grupo para la defensa del software de código abierto, ha establecido los requisitos específicos que se deben alcanzar para el cumplimiento de las industrias respaldadas por la Open Source Definition (OSD).
         
Un número de licencias han sido aprobadas por la OSI en su proceso de revisión. Estas incluyen nombres conocidos y siglas como BSD, Apache, CPAL, GPL, MIT y muchas otras. Sin embargo, hay un número indeterminado de licencias que no han sido aprobadas en el proceso de revisión de licencia OSI, ya sea por incumplimiento de la OSD, o tal vez simplemente porque el proveedor no suscribió el proceso de aprobación. En cualquier caso, las condiciones de licencia varían considerablemente de una a otra. Algunos proveedores de software juegan rápido y pierden con las reglas abofeteando una etiqueta de "código abierto" en el software, que en realidad resulta ser una versión "libre para descargar y utilizar" de un software propietario que no puede ser alterado o distribuido. Todo está en las letras pequeñas, y aquí es donde el primer principio importante de la gestión de riesgo del código abierto entra en juego.
1. Entienda la licencia y cualquier restricción
Casi todos los desarrolladores de código abierto conservan los derechos de autor de su trabajo. Por lo tanto, por definición, las licencias de código abierto tienen un alcance limitado y la plena propiedad no puede ser reclamada por otras personas, excepto en circunstancias tales como una fusión o adquisición de los negocios del titular de los derechos de autor, donde se haría una transferencia legal por contrato de los derechos de propiedad. La regla que limita los derechos de propiedad se aplica en casi todas las licencias de código abierto, no importa qué tanto se haya modificado el código por otros desarrolladores.
Las licencias adjuntas a los proyectos de código abierto también pueden estar restringidas por el uso. Existe una tendencia creciente de la industria por restringir la CE (Community Edition o edición comunitaria) de un producto de código abierto para un pequeño subconjunto de usuarios, tal vez definido por un único dominio, servidor, o para uso exclusivamente académico. El objetivo evidente de estas restricciones es reservar la CE para una base de usuarios muy reducida, mientras se conduce a la mayoría de los usuarios comerciales hacia la oferta de código cerrado.
La mejor manera de evitar problemas de licencias es de leer y entender todos los términos y restricciones de la licencia antes de la implementación del producto. Si los términos de licencia no parecen claros, puede ser conveniente recurrir a un dictamen legal.
2. Entienda el modelo de negocio de código abierto
Los creadores de software de código abierto tienden a ser tipos altruistas por naturaleza, y pueden contribuir con miles de horas a un proyecto, a veces ganando menos del salario mínimo (si se les paga a todos), solo por el hecho de donar software para el bien común. Pero hay que tener en cuenta que la mayoría de estos talentosos desarrolladores aspiran, al menos eventualmente, a beneficiarse de algún modo de su trabajo. El modelo de ganancia puede llevarse a cabo de muchas maneras. El camino principal de las ganancias es a través de la venta de soporte de software y personalización, y la conducción de los clientes hacia la versión comercial, cerrada, del producto.
Esto explica por qué la versión de código abierto de algunos productos puede ofrecer complejas rutinas de instalación, documentación confusa o incompleta, y un soporte técnico tan incoherente o indiferente, que hace que los usuarios noten rápidamente de que si necesitan ayuda real tendrán que pagar. Un vendedor de software libre, en lugar de proporcionar respuestas útiles para apoyar a las preguntas, informa -sin vergüenza- a los usuarios desafortunados que les puede ayudar por un precio inicial de solo 80 dólares.
Los proyectos de código abierto en marcha más grandes, por lo general tienen una base de clientes comerciales lo suficientemente adecuados para evitar la necesidad de trucos tales, pero incluso con un producto de código abierto creado, cuando la aplicación o actualización hacen caer su servidor Web y usted necesita ayuda inmediata, si no cuenta con un plan pagado de soportes, usted está sólo. Esto significa que los adoptantes de software libre deben tener sus propios expertos en la materia, a veces con salarios fuertes o altas tarifas por hora. Como resultado, algunas empresas han adoptado políticas estrictas contra el uso de la versión comunitaria de cualquier producto de software, optando en su lugar por la red de seguridad y el costo predecible que proporcionan los planes de soporte comercial del proveedor.
Las organizaciones que adoptan los productos FOSS a menudo descubren la necesidad de personalizar el software para satisfacer necesidades específicas o para cumplir con las políticas de la empresa. Para sistemas bien establecidos de gestión de contenido como Drupal, Joomla o Word Press, el añadido de páginas y el cambio de aspecto general de la aplicación pueden ser fácilmente realizados por un usuario con pocos o ningún conocimiento de programación. Sin embargo, una vez que las necesidades van más allá de la personalización de las interfases incorporadas proporcionadas por el proveedor, suelen ser necesarios conocimientos avanzados de programación para hacer cambios. Si los programadores que son parte del personal no están al día con una aplicación de código abierto en particular, la organización se encuentra frente a los costos de la curva de aprendizaje y adaptación, lo que resulta en un gasto y retrasos adicionales.
3. Factor de riesgos de seguridad
Los informes evidencian los agujeros de seguridad en proyectos de código abierto casi a diario, algunos de ellos muy graves. Los factores que aumentan los riesgos de seguridad con el código abierto son:
* El código fuente está disponible para que los piratas informáticos lo analicen y exploten, lo que aumenta la superficie de ataque del producto
* Las vulnerabilidades reportadas por los usuarios en los foros públicos de soporte también están abiertos al escrutinio y la explotación
* Los usuarios que instalan software libre usando las opciones por defecto, con frecuencia no aplican las medidas de seguridad, incluso rudimentarias, tales como cambiar la contraseña por defecto o eliminar el directorio de instalación que puede apuntar a la base de datos sensibles o a la red de información
* Debido al desarrollo de la comunidad de los proyectos de código abierto, los terceros mal seleccionados pueden ser autorizados a presentar complementos o incluso hacer cambios a la base del código de producción, ocultando virus o rootkits que se pueden diseminar rápidamente, e infectar los sistemas de muchos clientes antes de que el proveedor pueda descubrir y solucionar el problema
* La versión CE de un producto FOSS no ofrece ninguna garantía en cuanto a la oportunidad o adecuación de los parches de seguridad, o a cualquier otro recurso para los clientes en el extremo receptor de una explotación.
Para ser justos, ningún software es liberado completamente libre de vulnerabilidades de seguridad, y los vendedores de software libre por lo general se apresuran a tapar los agujeros tan pronto como se descubren. Sin embargo, es importante tener en cuenta el aumento de los riesgos en el proceso de toma de decisiones, y tomar medidas para cerrar la mayor cantidad de agujeros de seguridad como sea posible al cambiar los directorios de instalación por defecto y las contraseñas, endureciendo e incluso aislando contenidos de código abierto, y repitiendo el mismo proceso para cualquiera de los componentes de base de datos. Si seguimos estos pasos no se produce una base de código que cumpla con las políticas corporativas de seguridad, y puede que tenga que cambiarse a una licencia comercial cerrada.
4. Tenga cuidado con las posibles repercusiones sobre la propiedad intelectual
El Nº. 4 en esta lista, que se refiere a analizar el impacto de los productos de software libre sobre la propiedad intelectual puede, de hecho, pesar como la consideración Nº 1 para quienes toman decisiones en las empresas. "Se trata de los derechos de autor", señala el experto independiente en propiedad intelectual y abogado, Jill Bowman. "La incorporación de código abierto puede afectar dramáticamente el valor de la propiedad intelectual y puede disminuir o destruir el valor del producto que incorpora código abierto". Entre los obstáculos legales que cita están:
* Las licencias de código abierto escritas coloquialmente, con la intención original de darles claridad, en realidad pueden ser más difíciles de interpretar legalmente.
* La realización de la diligencia debida y la genealogía del seguimiento es más difícil en una base de código que puede contener múltiples autores y licencias de código abierto.
* Las licencias de código abierto plantean serias cuestiones legales acerca de cómo y bajo qué términos, o incluso si, las licencias pueden ser asignadas.
* Dificultad en la determinación de la compatibilidad de las licencias múltiples contenidas en un solo producto, y asegurarse que la licencia de salida no expresa más que la licencia de entrada.
"Es realmente una cuestión de elegir la licencia adecuada de código abierto", añade Bowman. "La compra de una licencia comercial puede resolver muchas de las cuestiones legales".
A pesar de sus desafíos, FOSS ha demostrado ofrecer beneficios sustanciales para las organizaciones bajo una gran variedad de modelos de negocio. La clave para la gestión del código abierto es explorar a fondo no solo los beneficios, sino también los riesgos y costos ocultos, preferentemente antes de comprometer tiempo y recursos para abrir iniciativas de código.
Susan Perschke, Network World