Subversion Repositories phr

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.