URL
https://opencores.org/ocsvn/phr/phr/trunk
Subversion Repositories phr
[/] [phr/] [trunk/] [doc/] [informe-tesis/] [phd-thesis-template-master/] [Appendix2/] [appendix2.tex] - Rev 442
Go to most recent revision | Compare with Previous | Blame | View Log
% ******************************* Thesis Appendix B ******************************** \chapter{Licencias} \label{appendix:lic} \ifpdf \graphicspath{{Appendix2/Figs/Raster/}{Appendix2/Figs/PDF/}{Appendix2/Figs/}} \else \graphicspath{{Appendix2/Figs/Vector/}{Appendix2/Figs/}} \fi \section{Software Libre y Código Abierto} El \textit{software libre}, o en inglés \textit{free software}, ofrece al usuario la libertad para ejecutarlo, copiarlo, modificarlo y distribuirlo. Las características que tiene que cumplir el software la Fundación para el Software Libre (FSF)~\cite{Etiqueta07}. La FSF fue fundada por Richard Stallman en 1985 para promover la libertad del usuario y defender los derechos de todo software libre~\cite{Etiqueta14}. En particular, el proyecto GNU es patronizado por la FSF. El software libre permite al usuario el ejercicio de cuatro libertades básicas a saber: \begin{itemize} \item \textit{Libertad 0}: El software \textit{libre} puede estudiarse y adaptarse a las necesidades de quién lo use. Esta libertad requiere acceso al código fuente y tiene la ventaja de por ejemplo permitir descubrir funciones ocultas o saber como se realiza determinada tarea. Además, al poder adaptar el programa a las necesidades del usuario se pueden suprimir partes que no sean de interés, agregar otras partes que considere importantes, copiar una parte que realiza una tarea y/o asignarla a otro programa. \item \textit{Libertad 1}: El software, sus copias y las modificaciones se pueden distribuir libremente. Esto significa que se posee la libertad de redistribuir el programa ya sea gratis o con algún costo. \item \textit{Libertad 2}: Es posible mejorarlo y hacer pública esas mejoras. La libertad de hacer un programa mejor, implica que se puede hacer menores los requerimientos de hardware para funcionar, que tenga mayores prestaciones, que sus requerimientos no sean tan altos, que tenga menos errores. El poder liberar las mejoras al público quiere decir que si se realiza una mejora que permita un requerimiento menor de hardware, o que haga que ocupe menos espacio, se puede redistribuir ese programa mejorado o simplemente proponer la mejora en lugar público (un foro de noticias, una lista de correo, un sitio web, un FTP, un canal de chat). \item \textit{Libertad 3}: El usuario al poseer el código fuente tiene poder de decisión, ya que podrá elegir quién puede modificar los programas que ha adquirido para mejorarlos (o bien mejorarlos el mismo). Es decir, esto permite que no exista un monopolio, porque en el caso de que un software sea discontinuado el usuario podrá, elegir a un desarrollador para continuar utilizando el software que fue discontinuado. Además el usuario no estará completamente a merced de tener que renovar su hardware y software constantemente según ocurre a menudo con las políticas de las empresas que producen software privativo y también será libre de vender o redistribuir software libre. \end{itemize} Cabe destacar que las libertades 1 y 3 tienen como prerrequisito que se tenga acceso al código fuente. La libertad 2 hace referencia a la libertad de modificar y redistribuir el software libremente licenciado bajo algún tipo de licencia de software libre que beneficie a la comunidad. El término \textit{free} posee en inglés el doble significado de ``gratuidad'' y ``libertad'' del software dependiendo del contexto. Por tal motivo se comenzó a utilizar en 1998 el término \textit{Código Abierto}, o en inglés ``Open Source'' para intentar aclarar que la palabra libre, se refiere a la libertad y no al precio. Este software de \textit{Código Abierto} permite a las personas usar y modificar el software, compatibilizarlo con otros sistemas operativos o arquitecturas de hardware, compartirlo con otras personas y comercializarlo. Desde el punto de vista de una ``traducción estrictamente literal'', el significado textual de ``código abierto'' es que ``se puede examinar el código fuente'', por lo que puede interpretarse como un término más débil y flexible que el del \textit{software libre}. La definición oficial de \textit{código abierto} se encuentra en el documento Open Source Definition (OSD) publicado por Open Source Initiative (OSI). El OSI es un movimiento diferente al movimiento del software libre que, aunque es incompatible con este último desde el punto de vista filosófico, es completamente equivalente desde el punto de vista práctico. El propósito de establecer una definición oficial de software de \textit{código abierto} es asegurar que los programas distribuidos con ``Licencia de código abierto'' estarán disponibles para su continua revisión y mejora. Brindando además a los usuarios la posibilidad de adaptarlo a sus necesidades y corregir errores rápidamente. La principal diferencia entre los términos \textit{código abierto} y \textit{libre} es que éste último tiene en cuenta los aspectos éticos y filosóficos de la libertad mientras que el \textit{código abierto} se basa únicamente en los aspectos técnicos. En un intento por unir los mencionados términos, que se refieren a conceptos semejantes, se intentó extender el uso del termino Free and Open Source Software (FOSS) el cual se utiliza para referirse al software que se adhiere al OSD y FSF. \section{Licencias de Software Libre} Mediante la \textit{licencia} un autor permite el uso de su creación a otras personas. Es decir que la licencia es el instrumento que regula la forma en que el usuario puede utilizar el software. Pueden existir tantas licencias como acuerdos concretos se den entre el autor y el licenciatario. Desde el punto de vista del software \textit{libre}, existen distintas variantes del concepto o grupos de licencias: \begin {itemize} \item \textit{General Public License (GNU GPL)}: Es la licencia más usada, garantiza a los usuarios finales (personas, organizaciones, compañías) la libertad de usar, estudiar, compartir (copiar) y modificar el software. Su propósito es declarar que el software cubierto por esta licencia es software libre y protegerlo de intentos de apropiación. Esta licencia fue creada originalmente por Richard Stallman para el proyecto GNU (GNU project). Su finalidad es proteger los derechos de los usuarios finales (usar, compartir, estudiar, modificar). Esta es la primera licencia copyleft para uso general. Copyleft significa que los trabajos derivados sólo pueden distribuirse bajo los términos de la misma licencia. Bajo esta filosofía, la licencia GPL garantiza a los destinatarios de un programa los derechos-libertades reunidos en la definición de software libre y usa copyleft para asegurar que el software está protegido cada vez que el trabajo es distribuido, modificado o ampliado. El software bajo licencia GPL puede aplicarse bajo todos los propósitos. Esto incluye los propósitos comerciales e incluso el uso como herramienta de creación de software propietario. En uso puramente privativo o interno, sin venta ni distribución, no es necesario hacer publico el código fuente para los usuarios. Sólo si un programa utiliza fragmentos de código GPL y el programa es distribuido, el código fuente en su totalidad debe estar disponible bajo la misma licencia. Lo mencionado es independiente de la plataforma utilizada. Los usuarios o compañías que distribuyen sus trabajos bajo licencias GPL pueden hacerlo gratuitamente o cobrar por ellos. En particular, la GPL establece explícitamente que las obras GPL se puede vender a cualquier precio. Esto se deriva de la FSF, la cual argumenta que no se debe restringir la distribución comercial del software incluyendo la redistribución. La FSF permite al público crear nuevas licencias basadas en la GPL siempre y cuando las licencias derivadas no utilicen GPL sin permiso. Sin embargo, esto último no se recomienda ya que tal licencia puede ser incompatible con la GPL. \item \textit{Lesser General Public License (GNU LGPL)}: La licencia LGPL de software fue creada por la FSF para tener derechos menos restrictivos que GPL. Garantiza la libertad de compartir y modificar el software cubierto por ella y asegura que el software es libre para todos sus usuarios. Esta licencia permisiva se aplica a cualquier programa o trabajo que contenga una nota puesta por el propietario de los derechos del trabajo en la cual se establece que su trabajo puede distribuirse bajo los términos de está. El termino ``programa'', utilizado en lo subsecuente, se refiere a cualquier programa o trabajo original. Por otro lado, el ``trabajo basado en el programa'' se refiere al programa o cualquier trabajo derivado del mismo bajo la ley de derechos de autor. Esto es, un trabajo que contenga el programa o alguna porción de él, ya sea íntegra o con modificaciones o traducciones a otros idiomas. Otras actividades que no sean copia, distribución o modificación no están cubiertas en esta licencia y están fuera de su alcance. El acto de ejecutar el programa no está restringido y la salida de información del programa está cubierta sólo si su contenido constituye un trabajo basado en el programa, es independiente de si fue resultado de ejecutar el programa. Si esto es cierto o no depende de la función del programa. En resumen, si se tiene un programa que utiliza fragmentos de código LGPL no es necesario liberar el código de dicho programa. \item \textit{Berkeley Software Distribution (BSD)}: La licencia BSD se denomina de esta forma porque se utiliza en gran cantidad del software distribuido junto a los sistemas operativos BSD. Es una licencia de software libre permisiva que tiene menos restricciones en comparación con otras como la GPL. La licencia BSD, al contrario que la GPL, permite el uso del código fuente en software no libre. El autor, bajo tal licencia, mantiene la protección de copyright únicamente para la renuncia de garantía y para requerir la adecuada atribución de la autoría en trabajos derivados. Sin embargo, permite la libre redistribución y modificación, incluso si dichos trabajos tienen propietario. Esta licencia asegura verdadero software libre, en el sentido que el usuario tiene libertad ilimitada con respecto al software. \end {itemize} \section{Desarrollos de Código Abierto} Tras la adopción creciente de software de código abierto en la década del 90, la organización OSI propuso que el software \textit{libre}, como fue conocido en ese entonces, tenía un lugar en la industria comercial. El éxito del modelo sorprendió a muchas personas y demostró que era un modelo de desarrollo viable. El aumento en la popularidad y utilidad de Internet proporciono el inicio para las grandes comunidades de código abierto. Con el éxito del software \textit{libre} como GNU/Linux, Servidor HTTP Apache, Mozilla Firefox y OpenOffice.org, muchas empresas comenzaron a interactuar con la comunidad del software \textit{libre}. Esto trajo aparejado una nueva dificultad a la hora de elegir las licencias de software libre y en la selección de qué software se liberará. Un ejemplo de una relativamente exitosa entrada a la comunidad del software libre fue que ``Sun Microsystems'' liberó StarOffice como OpenOffice.org bajo la GNU LGPL. Esto fue muy bien recibido por la comunidad de software \textit{libre} que no tenía una suite ofimática madura en ese momento. Un ejemplo de una entrada más difícil para la comunidad del software libre es el de Real Networks, qué escribió su propia licencia, y puso en libertad sólo una parte de su suite de software. En particular, el códec de los programas informáticos necesarios para ver archivos Real Video, no fue puesto en libertad. El sitio web \textit{OpenCores} con sus comienzos en el año 2000, proporciona un sitio para la comunidad de hardware de código abierto. Fue una de las primeras comunidades de desarrollo de hardware y actualmente la más grande, con más de cien mil usuarios y cerca de mil proyectos. El principal objetivo de OpenCores es diseñar y publicar diseños de núcleos bajo una licencia de hardware de código abierto siguiendo el modelo de Licencia LGPL usada para el software. \subsection{Código abierto en la industria} Actualmente exciten un gran número de aplicaciones de código abierto. Por ejemplo se dispone de software multimedia, productividad de oficina, herramientas de gráficos, sistemas operativos y de comunicaciones. Los gobiernos y las grandes empresas están aprovechando cada vez más el software de código abierto que existe y se están convirtiendo en importantes contribuyentes a los proyectos del software que adoptan. Las tendencias recientes han hecho mucho para disipar la imagen de solitarios desarrolladores de código abierto como los únicos contribuyentes de trabajos. Al estar las entidades comerciales aumentando la adopción y utilización de los proyectos de software libre, se están convirtiendo en los contribuyentes más frecuentes. Actualmente el kernel de Linux tiene la mayor parte de sus contribuciones de código proveniente de entidades comerciales. Esto se debe en gran parte a que están trabajando con el núcleo Linux en sus productos o porque desean asegurar el soporte de su hardware en el kernel. Entre dichas empresas se pueden mencionar a Intel, IBM y AMD. Lo mismo pasa para proyectos como Apache y MySQL. La gran cantidad de software de código abierto disponible ofrece la adopción de licencias FOSS con la posibilidad de elegir entre: la publicación del trabajo derivado, el desarrollo de una solución interna o la compra de una solución propietaria manteniendo el código en privado. Las entidades comerciales interesadas en mantener sus plataformas en buenas condiciones son en gran parte las que ofrecen mayor soporte y desarrollo a herramientas de programación como el compilador GCC y binutils del proyecto GNU. El desarrollo de las herramientas de software de código abierto es impulsado por GNU brindando soporte a diferentes plataformas con el fin de fomentar el uso de un compilador-optimizador de clase global, que atraiga a desarrolladores entregando herramientas que funcionen en diferentes arquitecturas. El aumento del uso comercial del software de código abierto trae como consecuencia que las empresas aporten recursos a estos proyectos, disminuyendo por consiguiente el desarrollo y mantenimiento de sus propios conjuntos de compiladores y herramientas. Por ejemplo en el caso del GCC. Uno de los objetivos del código abierto es proporcionar una base de software donde los desarrolladores se encuentren cómodos para adoptarlo. Esto se debe al aumento del software existente producto de la publicación de trabajos derivados, lo que evita la tarea de empezar a desarrollar desde cero o comprar una solución propietaria. Estas son solo algunas de las motivaciones para la adopción y contribución de código abierto, pero podrían ser muchas más y variadas dependiendo de la funcionalidad del proyecto. Para las entidades comerciales la motivación de desarrollar código abierto proviene de cobrar por servicios extras al proyecto. Normalmente se requiere de conocimientos técnicos y experiencia para implementar y/o personalizar un proyecto en particular. Las empresas que adoptan y mantienen desarrollos de código abierto no tiene el costo de regalías o licencias, solo el de conocimiento necesarios para hacerlo. A pesar de que el software de código abierto no es tradicionalmente un generador continuo de productos innovadores, no se opone a la estrategia de desarrollo elegida para una tecnología innovadora. Cualquier diseño innovador de código abierto suele tener retornos valiosos para la inversión requerida. Es una opción interesante para los desarrolladores empezar con una base que les ahorre tiempo y les permita competir frente a implementaciones propietarias, además de proporcionar soporte técnico a largo plazo para una aplicación. Cuando el ciclo de vida de un producto llega a su fin, liberar el código fuente permite a otros desarrolladores aportar conocimiento brindando soluciones a problemas derivados de las actualizaciones inevitable de las plataformas. Esta breve mirada a la situación actual de código abierto ha indicado que el mismo se ha convertido en una fuerza a tener en cuenta en el mundo del software. Sin embargo, este no es el caso en la actualidad para el desarrollo de hardware de código abierto. \subsection{Desventajas de la adopción del código abierto en software} Son muchos los que no están de acuerdo con el desarrollo de código abierto en la actualidad a pesar del gran aumento en su popularidad y uso. El software o hardware privativo puede ser desplazado del mercado por una alternativa no privativa, sin costo. Los que obviamente van a estar en desacuerdo son las entidades que se encuentren amenazadas por una alternativa lo suficientemente innovadora que provoque una disminución en sus ganancias. Una alternativa para los desarrolladores menos favorecidos es mejorar el código abierto existente el cual generalmente no es suficientemente innovador. Esto les permite competir con cualquier producto del mercado al mismo tiempo que adquieren conocimientos, ahorran tiempo y desarrollan un negocio. Además, tal mejora contribuye a mejorar el proyecto original. El inconveniente de mostrar el código del proyecto mejorado es que los desarrolladores exponen sus técnicas innovadoras. Sin embargo, esto se compensado por la reducción de la inversión en el desarrollo de su producto. Por otro lado, la mejora introducida en el proyecto de código abierto atrae a otros contribuyentes a trabajar en él. Las implementaciones de código abierto varían en calidad y funcionalidad dependiendo de la colaboración de los desarrolladores. No hay dudas de que hay software de código abierto de gran utilidad. Sin embargo, no debe ser visto sólo como un producto innovador sino también como un paso en el camino hacia el avance tecnológico. \section{Código Libre para Hardware} El OpenRisc y otros IP publicados en OpenCore no sólo muestran el estado del proyecto sino que también permiten a los desarrolladores poder continuar el desarrollo de los núcleos. La aceptación de los proyectos de código abierto en RTL por parte de las entidades comerciales de IP no es la misma que para el desarrollo de software de código abierto. El problema en la implementación de los proyectos de hardware de código abierto es que la falta de herramientas de ``Entorno de Desarrollo Integrado'' (IDE) es inaceptable para desarrollos de ASIC dado el elevado costo de corregir errores. Para brindar una solución a este problema se tendría que incluir dicha herramienta junto con el core. Las herramientas que se encuentran disponibles en la industria tienen un elevado precio y pueden variar de acuerdo al proveedor. Esto representa un gran obstáculo para la entrada al mercado de los desarrolladores de IP. La falta de alternativas libres en EDA de código abierto limita al desarrollo de núcleos de código abierto. Esto se debe en parte a que la tecnología utilizada para el desarrollo de hardware se considera secreto industrial y esto limita el desarrollo de herramientas libres. Por tal motivo, actualmente, para minimizar el riesgo las implementaciones basadas en hardware de código abierto se realizan en dispositivos como FPGA donde generalmente se pueden hacer cambios del código RTL a un menor costo. \subsection{Problema para implementar y desarrollar hardware de código abierto} La necesidad de una plataforma donde implementar el diseño de hardware y la falta de herramientas de desarrollo libres son un gran obstáculo que no enfrenta el software de código abierto. Estas plataformas se comercializan por empresas de hardware ofreciendo herramientas de compilación, simulación, síntesis y descarga para sus FPGA. La complejidad de las herramientas de diseño y la pronunciada curva de aprendizaje perjudica a los principiantes. Otra dificultad a la hora de realizar un diseño para FPGA es que el mismo se debe describir a un nivel de abstracción muy bajo. Para lograr un resultado ``útil'' se requiere por lo general un gran trabajo que atraviese varios niveles de abstracción para poder utilizarlo cómodamente en una computadora. Como ejemplo de una aplicación en hardware podría ser el desarrollo de un core que realice transacciones de I/O de un sensor. Dicho core podría proporcionar información a una aplicación que controle la temperatura en un espacio determinado. Esto requeriría el desarrollo y prueba del modelo de hardware y la implementación en FPGA. Por ejemplo, sea un microprocesador el que se encuentra corriendo sobre la FPGA, el cual brinda los servicios de red a través de un sistema operativo de tiempo real (RTOS). Este módulo personalizado debería requerir el desarrollo de una capa de software, lo que significa la necesidad de un driver para que permita al sistema operativo en tiempo real interactuar con el periférico, haciendo una abstracción del hardware y proporcionando una interfaz para usarlo. El sistema operativo en tiempo real se conecta con la aplicación que se ejecuta en el microprocesador de la FPGA para proporcionan lo datos a través del enlace de red. De esta forma, los datos de este sensor se encontrarán disponibles para la aplicación de nivel superior. Este es sólo un ejemplo en el cual el diseñador posiblemente haya seleccionado una solución que utilice un bus estándar. Sin embargo, existen algunos casos donde el diseñador desarrolla nuevos cores de interfaces o controladores en FPGA para proveer acceso a sistemas heredados (legacy) o nuevos buses estándar, donde vale destacar el trabajo extra requerido al escribir código RTL que provea la interfaz física. Viendo la cantidad de desarrollo y pruebas requeridas para poner en práctica estas soluciones, es fácil sentirse abrumado por la cantidad de trabajo necesario para completar una tarea tan aparentemente trivial. Al comparar esto último con la implementación de software de código abierto. En el segundo, simplemente se descarga el código fuente, se lo compila, se lo ejecuta y se lo prueba todo usando la misma plataforma. Hay una gran ventaja en la facilidad con que se accede la plataforma de desarrollo (el host) y las herramientas de desarrollo son mucho más simples (gcc, make en el sistema host). Además, las pruebas son más cortas y más fáciles (se ejecutan en el equipo host a través de un shell). A medida que se incremente la cantidad de proyectos de hardware de código abierto y disminuya la complejidad de las herramientas de desarrollo es de esperar que se superen los obstáculos mencionados. Las barreras iniciales a las que se enfrentó el software de código abierto parecían igual de complicadas de superar. Es de esperar que con el tiempo y el aumento de participantes, el hardware de código abierto alcance el mismo éxito. En ese momento, los diseños serán tan grandes que no cabrán en los dispositivos programables actuales. La reconfiguración será un elemento imprescindible. Las fronteras entre el hardware y el software se harán cada vez más difusas. \section{Licencias de Hardware} Una cuestión que queda por resolver es la concesión de licencias para el diseño de hardware de código abierto. Por ejemplo, el proyecto OpenRISC utiliza licencias públicas del proyecto GNU. Sin embargo, estas se refieren específicamente a software y no se sabe bien que se aplica al hardware. El sitio web del proyecto GNU contiene una sección con preguntas frecuentes (FAQ) que afirma lo siguiente. \textit{Cualquier material que puede ser licenciado con derechos de autor puede ser licenciado bajo la GPL}. Una indicación de la naciente idea del desarrollo de hardware de código abierto proviene de la publicación reciente (febrero de 2011) de un conjunto de principios para los participantes de la comunidad de hardware de código abierto. El siguiente es el código abierto Hardware (OSHW) Declaración de Principios 1.0 de FreedomDefined.org. Estas publicaciones proporcionan un punto de referencia para saber si el diseño puede estar bajo licencia de ``hardware de código abierto''. Cualquier licencia de hardware de código abierto se puede utilizar para restringir (o en este caso, para no restringir) los planos de un diseño, pero no el uso del dispositivo fabricado. Estos son conceptos que ya se encuentran a menudo en las licencias de software de código abierto, pero de nuevo, no es tan claro como se aplica para el diseño del hardware de código abierto. Una de las primeras licencias de hardware de código abierto es la Amateur Packet Radio Licencia Open Hardware Tucson (TAPR OHL). Los autores de TAPR OHL identifican el problema con las licencias de software existentes. En las mismas, los derechos de autor protegen la documentación de copias, modificaciones y distribuciones, pero esto tiene poco que ver con el derecho de hacer, distribuir o usar un producto basado en la documentación~\cite{Etiqueta12}. En consecuencia, la TAPR OHL esta siendo adoptada por varios aficionados y empresas comerciales. En general, las licencias actuales de hardware de código abierto han recibido críticas del OSI, entre otras cosas, por la adopción de un significado diferente de la palabra ``distribución''~\cite{Etiqueta13}. Sin embargo, es de esperar que en el futuro próximo surjan licencias alternativas de hardware de código abierto que resuelvan las ambigüedades presentes en las licencias actuales. %Conclusión!!Trabajar con un sistema final bajo licencias de hardware siguiendo el modelo de la Licencia LGPL para el software. Estamos comprometidos con el ideal de libre disposición, de libre uso y hardware de código abierto reutilizable.
Go to most recent revision | Compare with Previous | Blame | View Log