| 1 |
125 |
guanucolui |
% ******************************* Thesis Appendix B ********************************
|
| 2 |
|
|
|
| 3 |
309 |
guanucolui |
\chapter{Licencias}
|
| 4 |
|
|
\label{appendix:lic}
|
| 5 |
125 |
guanucolui |
|
| 6 |
|
|
|
| 7 |
299 |
guanucolui |
\ifpdf
|
| 8 |
|
|
\graphicspath{{Appendix2/Figs/Raster/}{Appendix2/Figs/PDF/}{Appendix2/Figs/}}
|
| 9 |
|
|
\else
|
| 10 |
|
|
\graphicspath{{Appendix2/Figs/Vector/}{Appendix2/Figs/}}
|
| 11 |
|
|
\fi
|
| 12 |
125 |
guanucolui |
|
| 13 |
309 |
guanucolui |
\section{Software Libre y Código Abierto}
|
| 14 |
125 |
guanucolui |
|
| 15 |
309 |
guanucolui |
El \textit{software libre}, o en inglés \textit{free software}, ofrece
|
| 16 |
|
|
al usuario la libertad para ejecutarlo, copiarlo, modificarlo y
|
| 17 |
|
|
distribuirlo. Las características que tiene que cumplir el software
|
| 18 |
|
|
la Fundación para el Software Libre (FSF)~\cite{Etiqueta07}. La FSF
|
| 19 |
|
|
fue fundada por Richard Stallman en 1985 para promover la libertad del
|
| 20 |
|
|
usuario y defender los derechos de todo software
|
| 21 |
|
|
libre~\cite{Etiqueta14}. En particular, el proyecto GNU es patronizado
|
| 22 |
|
|
por la FSF. El software libre permite al usuario el ejercicio de
|
| 23 |
|
|
cuatro libertades básicas a saber:
|
| 24 |
299 |
guanucolui |
|
| 25 |
309 |
guanucolui |
\begin{itemize}
|
| 26 |
|
|
\item \textit{Libertad 0}: El software \textit{libre} puede estudiarse y adaptarse a las necesidades de quién lo use. Esta
|
| 27 |
|
|
libertad requiere acceso al código fuente y tiene la ventaja de por
|
| 28 |
|
|
ejemplo permitir descubrir funciones ocultas o saber como se realiza
|
| 29 |
|
|
determinada tarea. Además, al poder adaptar el programa a las
|
| 30 |
|
|
necesidades del usuario se pueden suprimir partes que no sean de
|
| 31 |
|
|
interés, agregar otras partes que considere importantes, copiar
|
| 32 |
|
|
una parte que realiza una tarea y/o asignarla a otro programa.
|
| 33 |
|
|
\item \textit{Libertad 1}: El software, sus copias y las
|
| 34 |
|
|
modificaciones se pueden distribuir libremente. Esto significa que
|
| 35 |
|
|
se posee la libertad de redistribuir el programa ya sea gratis o con
|
| 36 |
|
|
algún costo.
|
| 37 |
|
|
\item \textit{Libertad 2}: Es posible mejorarlo y hacer pública esas
|
| 38 |
|
|
mejoras. La libertad de hacer un programa mejor, implica que se
|
| 39 |
|
|
puede hacer menores los requerimientos de hardware para funcionar,
|
| 40 |
|
|
que tenga mayores prestaciones, que sus requerimientos no sean tan
|
| 41 |
|
|
altos, que tenga menos errores. El poder liberar las mejoras al
|
| 42 |
|
|
público quiere decir que si se realiza una mejora que permita un
|
| 43 |
|
|
requerimiento menor de hardware, o que haga que ocupe menos espacio,
|
| 44 |
|
|
se puede redistribuir ese programa mejorado o simplemente proponer
|
| 45 |
|
|
la mejora en lugar público (un foro de noticias, una lista de
|
| 46 |
|
|
correo, un sitio web, un FTP, un canal de chat).
|
| 47 |
|
|
\item \textit{Libertad 3}: El usuario al poseer el código fuente tiene
|
| 48 |
|
|
poder de decisión, ya que podrá elegir quién puede modificar los
|
| 49 |
|
|
programas que ha adquirido para mejorarlos (o bien mejorarlos el
|
| 50 |
|
|
mismo). Es decir, esto permite que no exista un monopolio, porque en
|
| 51 |
|
|
el caso de que un software sea discontinuado el usuario podrá,
|
| 52 |
|
|
elegir a un desarrollador para continuar utilizando el software que
|
| 53 |
|
|
fue discontinuado. Además el usuario no estará completamente a
|
| 54 |
|
|
merced de tener que renovar su hardware y software constantemente
|
| 55 |
|
|
según ocurre a menudo con las políticas de las empresas que producen
|
| 56 |
|
|
software privativo y también será libre de vender o redistribuir
|
| 57 |
|
|
software libre.
|
| 58 |
|
|
\end{itemize}
|
| 59 |
299 |
guanucolui |
|
| 60 |
309 |
guanucolui |
Cabe destacar que las libertades 1 y 3 tienen como prerrequisito que
|
| 61 |
|
|
se tenga acceso al código fuente. La libertad 2 hace referencia a la
|
| 62 |
|
|
libertad de modificar y redistribuir el software libremente licenciado
|
| 63 |
|
|
bajo algún tipo de licencia de software libre que beneficie a la
|
| 64 |
|
|
comunidad.
|
| 65 |
|
|
|
| 66 |
|
|
|
| 67 |
|
|
El término \textit{free} posee en inglés el doble significado
|
| 68 |
|
|
de ``gratuidad'' y ``libertad'' del software dependiendo del
|
| 69 |
|
|
contexto. Por tal motivo se comenzó a utilizar
|
| 70 |
|
|
en 1998 el término \textit{Código Abierto}, o en inglés ``Open
|
| 71 |
|
|
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.
|
| 72 |
|
|
Desde el punto de vista de una ``traducción
|
| 73 |
|
|
estrictamente literal'', el significado textual de ``código abierto''
|
| 74 |
|
|
es que ``se puede examinar el código fuente'', por lo que puede
|
| 75 |
|
|
interpretarse como un término más débil y flexible que el del
|
| 76 |
|
|
\textit{software libre}.
|
| 77 |
|
|
|
| 78 |
|
|
La definición oficial de \textit{código abierto} se encuentra en el
|
| 79 |
|
|
documento Open Source Definition (OSD) publicado por Open
|
| 80 |
|
|
Source Initiative (OSI). El OSI es un movimiento diferente al
|
| 81 |
|
|
movimiento del software libre que, aunque es incompatible con este
|
| 82 |
|
|
último desde el punto de vista filosófico, es completamente
|
| 83 |
|
|
equivalente desde el punto de vista práctico. El propósito de
|
| 84 |
|
|
establecer una definición oficial de software de \textit{código
|
| 85 |
|
|
abierto} es asegurar que los programas distribuidos con ``Licencia
|
| 86 |
|
|
de código abierto'' estarán disponibles para su continua revisión y
|
| 87 |
|
|
mejora. Brindando además a los usuarios la posibilidad de adaptarlo a
|
| 88 |
|
|
sus necesidades y corregir errores rápidamente.
|
| 89 |
|
|
|
| 90 |
|
|
La principal diferencia entre los términos \textit{código abierto} y
|
| 91 |
|
|
\textit{libre} es que éste último tiene en cuenta los aspectos éticos
|
| 92 |
|
|
y filosóficos de la libertad mientras que el \textit{código abierto}
|
| 93 |
|
|
se basa únicamente en los aspectos técnicos. En un intento por unir
|
| 94 |
|
|
los mencionados términos, que se refieren a conceptos semejantes, se
|
| 95 |
|
|
intentó extender el uso del termino Free and Open Source Software
|
| 96 |
|
|
(FOSS) el cual se utiliza para referirse al software que se adhiere al
|
| 97 |
|
|
OSD y FSF.
|
| 98 |
|
|
|
| 99 |
|
|
\section{Licencias de Software Libre}
|
| 100 |
|
|
|
| 101 |
|
|
Mediante la \textit{licencia} un autor permite el uso de su creación a
|
| 102 |
|
|
otras personas. Es decir que la licencia es el instrumento que regula
|
| 103 |
|
|
la forma en que el usuario puede utilizar el software. Pueden existir
|
| 104 |
|
|
tantas licencias como acuerdos concretos se den entre el autor y el
|
| 105 |
|
|
licenciatario. Desde el punto de vista del software \textit{libre},
|
| 106 |
|
|
existen distintas variantes del concepto o grupos de licencias:
|
| 107 |
|
|
|
| 108 |
|
|
\begin {itemize}
|
| 109 |
|
|
\item \textit{General Public License (GNU GPL)}: Es la licencia más
|
| 110 |
|
|
usada, garantiza a los usuarios finales (personas, organizaciones,
|
| 111 |
|
|
compañías) la libertad de usar, estudiar, compartir (copiar) y
|
| 112 |
|
|
modificar el software. Su propósito es declarar que el software
|
| 113 |
|
|
cubierto por esta licencia es software libre y protegerlo de
|
| 114 |
|
|
intentos de apropiación. Esta licencia fue creada originalmente por Richard
|
| 115 |
|
|
Stallman para el proyecto GNU (GNU project). Su finalidad es proteger los derechos de
|
| 116 |
|
|
los usuarios finales (usar, compartir, estudiar, modificar). Esta es
|
| 117 |
|
|
la primera licencia copyleft para uso general. Copyleft significa
|
| 118 |
|
|
que los trabajos derivados sólo pueden distribuirse bajo los
|
| 119 |
|
|
términos de la misma licencia. Bajo esta filosofía, la licencia GPL
|
| 120 |
|
|
garantiza a los destinatarios de un programa los derechos-libertades
|
| 121 |
|
|
reunidos en la definición de software libre y usa copyleft para
|
| 122 |
|
|
asegurar que el software está protegido cada vez que el trabajo es
|
| 123 |
|
|
distribuido, modificado o ampliado.
|
| 124 |
|
|
|
| 125 |
|
|
El software bajo licencia GPL puede aplicarse bajo todos los
|
| 126 |
|
|
propósitos. Esto incluye los propósitos comerciales e incluso el uso
|
| 127 |
|
|
como herramienta de creación de software propietario. En uso
|
| 128 |
|
|
puramente privativo o interno, sin venta ni distribución, no es
|
| 129 |
|
|
necesario hacer publico el código fuente para los usuarios. Sólo si
|
| 130 |
|
|
un programa utiliza fragmentos de código GPL y el programa es
|
| 131 |
|
|
distribuido, el código fuente en su totalidad debe estar disponible
|
| 132 |
|
|
bajo la misma licencia. Lo mencionado es independiente de la
|
| 133 |
|
|
plataforma utilizada.
|
| 134 |
|
|
|
| 135 |
|
|
Los usuarios o compañías que distribuyen sus trabajos bajo licencias
|
| 136 |
|
|
GPL pueden hacerlo gratuitamente o cobrar por ellos. En particular,
|
| 137 |
|
|
la GPL establece explícitamente que las obras GPL se puede vender a
|
| 138 |
|
|
cualquier precio. Esto se deriva de la FSF, la cual argumenta que no
|
| 139 |
|
|
se debe restringir la distribución comercial del software incluyendo
|
| 140 |
|
|
la redistribución. La FSF permite al público crear nuevas licencias
|
| 141 |
|
|
basadas en la GPL siempre y cuando las licencias derivadas no
|
| 142 |
|
|
utilicen GPL sin permiso. Sin embargo, esto último no se recomienda
|
| 143 |
|
|
ya que tal licencia puede ser incompatible con la GPL.
|
| 144 |
|
|
|
| 145 |
|
|
|
| 146 |
|
|
\item \textit{Lesser General Public License (GNU LGPL)}: La licencia
|
| 147 |
|
|
LGPL de software fue creada por la FSF para tener derechos menos
|
| 148 |
|
|
restrictivos que GPL. Garantiza la libertad de compartir y modificar
|
| 149 |
|
|
el software cubierto por ella y asegura que el software es libre
|
| 150 |
|
|
para todos sus usuarios. Esta licencia permisiva se aplica a
|
| 151 |
|
|
cualquier programa o trabajo que contenga una nota puesta por el
|
| 152 |
|
|
propietario de los derechos del trabajo en la cual se establece que
|
| 153 |
|
|
su trabajo puede distribuirse bajo los términos de está. El
|
| 154 |
|
|
termino ``programa'', utilizado en lo subsecuente, se refiere a
|
| 155 |
|
|
cualquier programa o trabajo original. Por otro lado, el ``trabajo
|
| 156 |
|
|
basado en el programa'' se refiere al programa o cualquier trabajo
|
| 157 |
|
|
derivado del mismo bajo la ley de derechos de autor. Esto es, un
|
| 158 |
|
|
trabajo que contenga el programa o alguna porción de él, ya sea
|
| 159 |
|
|
íntegra o con modificaciones o traducciones a otros idiomas. Otras
|
| 160 |
|
|
actividades que no sean copia, distribución o modificación no están
|
| 161 |
|
|
cubiertas en esta licencia y están fuera de su alcance. El acto de
|
| 162 |
|
|
ejecutar el programa no está restringido y la salida de información
|
| 163 |
|
|
del programa está cubierta sólo si su contenido constituye un
|
| 164 |
|
|
trabajo basado en el programa, es independiente de si fue resultado
|
| 165 |
|
|
de ejecutar el programa. Si esto es cierto o no depende de la
|
| 166 |
|
|
función del programa. En resumen, si se tiene un programa que
|
| 167 |
|
|
utiliza fragmentos de código LGPL no es necesario liberar el código
|
| 168 |
|
|
de dicho programa.
|
| 169 |
|
|
|
| 170 |
|
|
\item \textit{Berkeley Software Distribution (BSD)}: La licencia BSD se denomina de esta forma porque se utiliza en gran cantidad del
|
| 171 |
|
|
software distribuido junto a los sistemas operativos BSD. Es una
|
| 172 |
|
|
licencia de software libre permisiva que tiene menos restricciones
|
| 173 |
|
|
en comparación con otras como la GPL. La licencia BSD, al contrario
|
| 174 |
|
|
que la GPL, permite el uso del código fuente en software no
|
| 175 |
|
|
libre. El autor, bajo tal licencia, mantiene la protección de
|
| 176 |
|
|
copyright únicamente para la renuncia de garantía y para requerir la
|
| 177 |
|
|
adecuada atribución de la autoría en trabajos derivados. Sin
|
| 178 |
|
|
embargo, permite la libre redistribución y modificación, incluso si
|
| 179 |
|
|
dichos trabajos tienen propietario. Esta licencia asegura verdadero
|
| 180 |
|
|
software libre, en el sentido que el usuario tiene libertad
|
| 181 |
|
|
ilimitada con respecto al software.
|
| 182 |
|
|
\end {itemize}
|
| 183 |
|
|
|
| 184 |
|
|
\section{Desarrollos de Código Abierto}
|
| 185 |
|
|
|
| 186 |
|
|
Tras la adopción creciente de software de código abierto en la década
|
| 187 |
|
|
del 90, la organización OSI propuso que el software \textit{libre},
|
| 188 |
|
|
como fue conocido en ese entonces, tenía un lugar en la industria
|
| 189 |
|
|
comercial. El éxito del modelo sorprendió a muchas personas y demostró
|
| 190 |
|
|
que era un modelo de desarrollo viable. El aumento en la popularidad y
|
| 191 |
|
|
utilidad de Internet proporciono el inicio para las grandes
|
| 192 |
|
|
comunidades de código abierto.
|
| 193 |
|
|
|
| 194 |
|
|
Con el éxito del software \textit{libre} como GNU/Linux, Servidor HTTP
|
| 195 |
|
|
Apache, Mozilla Firefox y OpenOffice.org, muchas empresas
|
| 196 |
|
|
comenzaron a interactuar con la comunidad del software
|
| 197 |
|
|
\textit{libre}. Esto trajo aparejado una nueva dificultad a la hora de
|
| 198 |
|
|
elegir las licencias de software libre y en la selección de qué
|
| 199 |
|
|
software se liberará. Un ejemplo de una relativamente exitosa entrada
|
| 200 |
|
|
a la comunidad del software libre fue que ``Sun Microsystems'' liberó
|
| 201 |
|
|
StarOffice como OpenOffice.org bajo la GNU LGPL. Esto fue muy bien
|
| 202 |
|
|
recibido por la comunidad de software \textit{libre} que no tenía una
|
| 203 |
|
|
suite ofimática madura en ese momento. Un ejemplo de una entrada más
|
| 204 |
|
|
difícil para la comunidad del software libre es el de Real Networks,
|
| 205 |
|
|
qué escribió su propia licencia, y puso en libertad sólo una parte de
|
| 206 |
|
|
su suite de software. En particular, el códec de los programas
|
| 207 |
|
|
informáticos necesarios para ver archivos Real Video, no fue puesto en
|
| 208 |
|
|
libertad.
|
| 209 |
|
|
|
| 210 |
|
|
El sitio web \textit{OpenCores} con sus comienzos en el año 2000,
|
| 211 |
|
|
proporciona un sitio para la comunidad de hardware de código abierto.
|
| 212 |
|
|
Fue una de las primeras comunidades de desarrollo de hardware y
|
| 213 |
|
|
actualmente la más grande, con más de cien mil usuarios y cerca de mil
|
| 214 |
|
|
proyectos. El principal objetivo de OpenCores es diseñar y publicar
|
| 215 |
|
|
diseños de núcleos bajo una licencia de hardware de código abierto
|
| 216 |
|
|
siguiendo el modelo de Licencia LGPL usada para el software.
|
| 217 |
|
|
|
| 218 |
|
|
\subsection{Código abierto en la industria}
|
| 219 |
|
|
|
| 220 |
|
|
Actualmente exciten un gran número de aplicaciones de código
|
| 221 |
|
|
abierto. Por ejemplo se dispone de software multimedia, productividad
|
| 222 |
|
|
de oficina, herramientas de gráficos, sistemas operativos y de
|
| 223 |
|
|
comunicaciones. Los gobiernos y las grandes empresas están
|
| 224 |
|
|
aprovechando cada vez más el software de código abierto que existe y
|
| 225 |
|
|
se están convirtiendo en importantes contribuyentes a los proyectos
|
| 226 |
|
|
del software que adoptan. Las tendencias recientes han hecho mucho
|
| 227 |
|
|
para disipar la imagen de solitarios desarrolladores de código abierto
|
| 228 |
|
|
como los únicos contribuyentes de trabajos. Al estar las entidades
|
| 229 |
|
|
comerciales aumentando la adopción y utilización de los proyectos de
|
| 230 |
|
|
software libre, se están convirtiendo en los contribuyentes más
|
| 231 |
|
|
frecuentes. Actualmente el kernel de Linux tiene la mayor parte de sus
|
| 232 |
|
|
contribuciones de código proveniente de entidades comerciales. Esto se
|
| 233 |
|
|
debe en gran parte a que están trabajando con el núcleo Linux en sus
|
| 234 |
|
|
productos o porque desean asegurar el soporte de su hardware en el
|
| 235 |
|
|
kernel. Entre dichas empresas se pueden mencionar a Intel, IBM y
|
| 236 |
|
|
AMD. Lo mismo pasa para proyectos como Apache y MySQL.
|
| 237 |
|
|
|
| 238 |
|
|
La gran cantidad de software de código abierto disponible ofrece la
|
| 239 |
|
|
adopción de licencias FOSS con la posibilidad de elegir entre: la
|
| 240 |
|
|
publicación del trabajo derivado, el desarrollo de una solución
|
| 241 |
|
|
interna o la compra de una solución propietaria manteniendo el código
|
| 242 |
|
|
en privado.
|
| 243 |
|
|
|
| 244 |
|
|
Las entidades comerciales interesadas en mantener sus plataformas en
|
| 245 |
|
|
buenas condiciones son en gran parte las que ofrecen mayor soporte y
|
| 246 |
|
|
desarrollo a herramientas de programación como el compilador GCC y
|
| 247 |
|
|
binutils del proyecto GNU. El desarrollo de las herramientas de
|
| 248 |
|
|
software de código abierto es impulsado por GNU brindando soporte a
|
| 249 |
|
|
diferentes plataformas con el fin de fomentar el uso de un
|
| 250 |
|
|
compilador-optimizador de clase global, que atraiga a desarrolladores
|
| 251 |
|
|
entregando herramientas que funcionen en diferentes arquitecturas.
|
| 252 |
|
|
|
| 253 |
|
|
El aumento del uso comercial del software de código abierto trae como
|
| 254 |
|
|
consecuencia que las empresas aporten recursos a estos proyectos, disminuyendo por consiguiente el desarrollo y mantenimiento de sus
|
| 255 |
|
|
propios conjuntos de compiladores y herramientas. Por ejemplo en el
|
| 256 |
|
|
caso del GCC. Uno de los objetivos del código abierto es proporcionar
|
| 257 |
|
|
una base de software donde los desarrolladores se encuentren cómodos
|
| 258 |
|
|
para adoptarlo. Esto se debe al aumento del software existente
|
| 259 |
|
|
producto de la publicación de trabajos derivados, lo que evita la
|
| 260 |
|
|
tarea de empezar a desarrollar desde cero o comprar una solución
|
| 261 |
|
|
propietaria. Estas son solo algunas de las motivaciones para la
|
| 262 |
|
|
adopción y contribución de código abierto, pero podrían ser muchas más
|
| 263 |
|
|
y variadas dependiendo de la funcionalidad del proyecto.
|
| 264 |
|
|
|
| 265 |
|
|
Para las entidades comerciales la motivación de desarrollar código
|
| 266 |
|
|
abierto proviene de cobrar por servicios extras al
|
| 267 |
|
|
proyecto. Normalmente se requiere de conocimientos técnicos y
|
| 268 |
|
|
experiencia para implementar y/o personalizar un proyecto en
|
| 269 |
|
|
particular. Las empresas que adoptan y mantienen desarrollos de código
|
| 270 |
|
|
abierto no tiene el costo de regalías o licencias, solo el de
|
| 271 |
|
|
conocimiento necesarios para hacerlo.
|
| 272 |
|
|
|
| 273 |
|
|
A pesar de que el software de código abierto no es tradicionalmente un
|
| 274 |
|
|
generador continuo de productos innovadores, no se opone a la
|
| 275 |
|
|
estrategia de desarrollo elegida para una tecnología
|
| 276 |
|
|
innovadora. Cualquier diseño innovador de código abierto suele tener
|
| 277 |
|
|
retornos valiosos para la inversión requerida. Es una opción
|
| 278 |
|
|
interesante para los desarrolladores empezar con una base que les
|
| 279 |
|
|
ahorre tiempo y les permita competir frente a implementaciones
|
| 280 |
|
|
propietarias, además de proporcionar soporte técnico a
|
| 281 |
|
|
largo plazo para una aplicación.
|
| 282 |
|
|
|
| 283 |
|
|
Cuando el ciclo de vida de un producto llega a su fin, liberar el
|
| 284 |
|
|
código fuente permite a otros desarrolladores aportar conocimiento
|
| 285 |
|
|
brindando soluciones a problemas derivados de las actualizaciones
|
| 286 |
|
|
inevitable de las plataformas.
|
| 287 |
|
|
|
| 288 |
|
|
Esta breve mirada a la situación actual de código abierto ha indicado
|
| 289 |
|
|
que el mismo se ha convertido en una fuerza a tener en cuenta en el
|
| 290 |
|
|
mundo del software. Sin embargo, este no es el caso en la actualidad
|
| 291 |
|
|
para el desarrollo de hardware de código abierto.
|
| 292 |
|
|
|
| 293 |
|
|
\subsection{Desventajas de la adopción del código abierto en software}
|
| 294 |
|
|
|
| 295 |
|
|
Son muchos los que no están de acuerdo con el desarrollo de código
|
| 296 |
|
|
abierto en la actualidad a pesar del gran aumento en su popularidad y
|
| 297 |
|
|
uso. El software o hardware privativo puede ser desplazado del mercado
|
| 298 |
|
|
por una alternativa no privativa, sin costo. Los que obviamente van a
|
| 299 |
|
|
estar en desacuerdo son las entidades que se encuentren amenazadas por
|
| 300 |
|
|
una alternativa lo suficientemente innovadora que provoque una
|
| 301 |
|
|
disminución en sus ganancias. Una alternativa para los desarrolladores
|
| 302 |
|
|
menos favorecidos es mejorar el código abierto existente el cual
|
| 303 |
|
|
generalmente no es suficientemente innovador. Esto les permite
|
| 304 |
|
|
competir con cualquier producto del mercado al mismo tiempo que
|
| 305 |
|
|
adquieren conocimientos, ahorran tiempo y desarrollan un
|
| 306 |
|
|
negocio. Además, tal mejora contribuye a mejorar el proyecto original.
|
| 307 |
|
|
|
| 308 |
|
|
El inconveniente de mostrar el código del proyecto mejorado es que los
|
| 309 |
|
|
desarrolladores exponen sus técnicas innovadoras. Sin embargo, esto se
|
| 310 |
|
|
compensado por la reducción de la inversión en el desarrollo de su
|
| 311 |
|
|
producto. Por otro lado, la mejora introducida en el proyecto de
|
| 312 |
|
|
código abierto atrae a otros contribuyentes a trabajar en él.
|
| 313 |
|
|
|
| 314 |
|
|
Las implementaciones de código abierto varían en calidad y
|
| 315 |
|
|
funcionalidad dependiendo de la colaboración de los
|
| 316 |
|
|
desarrolladores. No hay dudas de que hay software de código abierto de
|
| 317 |
|
|
gran utilidad. Sin embargo, no debe ser visto sólo como un producto
|
| 318 |
|
|
innovador sino también como un paso en el camino hacia el avance
|
| 319 |
|
|
tecnológico.
|
| 320 |
|
|
|
| 321 |
|
|
\section{Código Libre para Hardware}
|
| 322 |
|
|
|
| 323 |
|
|
El OpenRisc y otros IP publicados en OpenCore no sólo muestran el
|
| 324 |
|
|
estado del proyecto sino que también permiten a los desarrolladores
|
| 325 |
|
|
poder continuar el desarrollo de los núcleos. La aceptación de los
|
| 326 |
|
|
proyectos de código abierto en RTL por parte de las entidades
|
| 327 |
|
|
comerciales de IP no es la misma que para el desarrollo de software de
|
| 328 |
|
|
código abierto.
|
| 329 |
|
|
|
| 330 |
|
|
El problema en la implementación de los proyectos de hardware de
|
| 331 |
|
|
código abierto es que la falta de herramientas de ``Entorno de
|
| 332 |
|
|
Desarrollo Integrado'' (IDE) es inaceptable para desarrollos de ASIC
|
| 333 |
|
|
dado el elevado costo de corregir errores. Para brindar una solución
|
| 334 |
|
|
a este problema se tendría que incluir dicha herramienta junto con el
|
| 335 |
|
|
core. Las herramientas que se encuentran disponibles en la industria
|
| 336 |
|
|
tienen un elevado precio y pueden variar de acuerdo al proveedor. Esto
|
| 337 |
|
|
representa un gran obstáculo para la entrada al mercado de los
|
| 338 |
|
|
desarrolladores de IP.
|
| 339 |
|
|
|
| 340 |
|
|
La falta de alternativas libres en EDA de código abierto limita al
|
| 341 |
|
|
desarrollo de núcleos de código abierto. Esto se debe en parte a que
|
| 342 |
|
|
la tecnología utilizada para el desarrollo de hardware se considera
|
| 343 |
|
|
secreto industrial y esto limita el desarrollo de herramientas
|
| 344 |
|
|
libres. Por tal motivo, actualmente, para minimizar el riesgo las
|
| 345 |
|
|
implementaciones basadas en hardware de código abierto se realizan en
|
| 346 |
|
|
dispositivos como FPGA donde generalmente se pueden hacer cambios del
|
| 347 |
|
|
código RTL a un menor costo.
|
| 348 |
|
|
|
| 349 |
|
|
|
| 350 |
|
|
\subsection{Problema para implementar y desarrollar hardware de código abierto}
|
| 351 |
|
|
|
| 352 |
|
|
La necesidad de una plataforma donde implementar el diseño de hardware
|
| 353 |
|
|
y la falta de herramientas de desarrollo libres son un gran obstáculo
|
| 354 |
|
|
que no enfrenta el software de código abierto. Estas plataformas se
|
| 355 |
|
|
comercializan por empresas de hardware ofreciendo herramientas de
|
| 356 |
|
|
compilación, simulación, síntesis y descarga para sus FPGA. La
|
| 357 |
|
|
complejidad de las herramientas de diseño y la pronunciada curva de
|
| 358 |
|
|
aprendizaje perjudica a los principiantes.
|
| 359 |
|
|
|
| 360 |
|
|
Otra dificultad a la hora de realizar un diseño para FPGA es que el
|
| 361 |
|
|
mismo se debe describir a un nivel de abstracción muy bajo. Para
|
| 362 |
|
|
lograr un resultado ``útil'' se requiere por lo general un gran
|
| 363 |
|
|
trabajo que atraviese varios niveles de abstracción para poder
|
| 364 |
|
|
utilizarlo cómodamente en una computadora.
|
| 365 |
|
|
|
| 366 |
|
|
Como ejemplo de una aplicación en hardware podría ser el desarrollo de
|
| 367 |
|
|
un core que realice transacciones de I/O de un sensor. Dicho core
|
| 368 |
|
|
podría proporcionar información a una aplicación que controle la
|
| 369 |
|
|
temperatura en un espacio determinado. Esto requeriría el desarrollo y
|
| 370 |
|
|
prueba del modelo de hardware y la implementación en FPGA. Por
|
| 371 |
|
|
ejemplo, sea un microprocesador el que se encuentra corriendo sobre la
|
| 372 |
|
|
FPGA, el cual brinda los servicios de red a través de un sistema
|
| 373 |
|
|
operativo de tiempo real (RTOS). Este módulo personalizado debería
|
| 374 |
|
|
requerir el desarrollo de una capa de software, lo que significa la
|
| 375 |
|
|
necesidad de un driver para que permita al sistema operativo en tiempo
|
| 376 |
|
|
real interactuar con el periférico, haciendo una abstracción del
|
| 377 |
|
|
hardware y proporcionando una interfaz para usarlo. El sistema
|
| 378 |
|
|
operativo en tiempo real se conecta con la aplicación que se ejecuta
|
| 379 |
|
|
en el microprocesador de la FPGA para proporcionan lo datos a través
|
| 380 |
|
|
del enlace de red. De esta forma, los datos de este sensor se
|
| 381 |
|
|
encontrarán disponibles para la aplicación de nivel superior. Este es
|
| 382 |
|
|
sólo un ejemplo en el cual el diseñador posiblemente haya seleccionado
|
| 383 |
|
|
una solución que utilice un bus estándar. Sin embargo, existen algunos
|
| 384 |
|
|
casos donde el diseñador desarrolla nuevos cores de interfaces o
|
| 385 |
|
|
controladores en FPGA para proveer acceso a sistemas heredados
|
| 386 |
|
|
(legacy) o nuevos buses estándar, donde vale destacar el trabajo extra
|
| 387 |
|
|
requerido al escribir código RTL que provea la interfaz física. Viendo
|
| 388 |
|
|
la cantidad de desarrollo y pruebas requeridas para poner en práctica
|
| 389 |
|
|
estas soluciones, es fácil sentirse abrumado por la cantidad de
|
| 390 |
|
|
trabajo necesario para completar una tarea tan aparentemente trivial.
|
| 391 |
|
|
|
| 392 |
|
|
Al comparar esto último con la implementación de software de código
|
| 393 |
|
|
abierto. En el segundo, simplemente se descarga el código fuente, se
|
| 394 |
|
|
lo compila, se lo ejecuta y se lo prueba todo usando la misma
|
| 395 |
|
|
plataforma. Hay una gran ventaja en la facilidad con que se accede la
|
| 396 |
|
|
plataforma de desarrollo (el host) y las herramientas de
|
| 397 |
|
|
desarrollo son mucho más simples (gcc, make en el sistema
|
| 398 |
|
|
host). Además, las pruebas son más cortas y más fáciles (se
|
| 399 |
|
|
ejecutan en el equipo host a través de un shell).
|
| 400 |
|
|
|
| 401 |
|
|
|
| 402 |
|
|
A medida que se incremente la cantidad de proyectos de hardware de código
|
| 403 |
|
|
abierto y disminuya la complejidad de las herramientas de desarrollo
|
| 404 |
|
|
es de esperar que se superen los obstáculos mencionados. Las barreras
|
| 405 |
|
|
iniciales a las que se enfrentó el software de código abierto parecían
|
| 406 |
|
|
igual de complicadas de superar. Es de esperar que con el tiempo y el
|
| 407 |
|
|
aumento de participantes, el hardware de código abierto alcance el
|
| 408 |
|
|
mismo éxito. En ese momento, los diseños serán tan grandes que no
|
| 409 |
|
|
cabrán en los dispositivos programables actuales. La reconfiguración
|
| 410 |
|
|
será un elemento imprescindible. Las fronteras entre el hardware y el
|
| 411 |
|
|
software se harán cada vez más difusas.
|
| 412 |
|
|
|
| 413 |
|
|
\section{Licencias de Hardware}
|
| 414 |
|
|
|
| 415 |
|
|
Una cuestión que queda por resolver es la concesión de licencias
|
| 416 |
|
|
para el diseño de hardware de código abierto. Por ejemplo, el proyecto
|
| 417 |
|
|
OpenRISC utiliza licencias públicas del proyecto GNU. Sin embargo,
|
| 418 |
|
|
estas se refieren específicamente a software y no se sabe bien que se
|
| 419 |
|
|
aplica al hardware. El sitio web del proyecto GNU contiene una sección
|
| 420 |
|
|
con preguntas frecuentes (FAQ) que afirma lo siguiente.
|
| 421 |
|
|
|
| 422 |
|
|
\textit{Cualquier material que puede ser licenciado con derechos de
|
| 423 |
|
|
autor puede ser licenciado bajo la GPL}.
|
| 424 |
|
|
|
| 425 |
|
|
|
| 426 |
|
|
Una indicación de la naciente idea del desarrollo de hardware de
|
| 427 |
|
|
código abierto proviene de la publicación reciente (febrero de 2011)
|
| 428 |
|
|
de un conjunto de principios para los participantes de la comunidad de
|
| 429 |
|
|
hardware de código abierto. El siguiente es el código abierto Hardware
|
| 430 |
|
|
(OSHW) Declaración de Principios 1.0 de FreedomDefined.org. Estas
|
| 431 |
|
|
publicaciones proporcionan un punto de referencia para saber si el
|
| 432 |
|
|
diseño puede estar bajo licencia de ``hardware de código abierto''.
|
| 433 |
|
|
|
| 434 |
|
|
Cualquier licencia de hardware de código abierto se puede utilizar
|
| 435 |
|
|
para restringir (o en este caso, para no restringir) los planos de un
|
| 436 |
|
|
diseño, pero no el uso del dispositivo fabricado. Estos son conceptos
|
| 437 |
|
|
que ya se encuentran a menudo en las licencias de software de código
|
| 438 |
|
|
abierto, pero de nuevo, no es tan claro como se aplica para el diseño
|
| 439 |
|
|
del hardware de código abierto.
|
| 440 |
|
|
|
| 441 |
|
|
Una de las primeras licencias de hardware de código abierto es la
|
| 442 |
|
|
Amateur Packet Radio Licencia Open Hardware Tucson (TAPR OHL). Los
|
| 443 |
|
|
autores de TAPR OHL identifican el problema con las licencias de
|
| 444 |
|
|
software existentes. En las mismas, los derechos de autor protegen la
|
| 445 |
|
|
documentación de copias, modificaciones y distribuciones, pero esto
|
| 446 |
|
|
tiene poco que ver con el derecho de hacer, distribuir o usar un
|
| 447 |
|
|
producto basado en la documentación~\cite{Etiqueta12}. En
|
| 448 |
|
|
consecuencia, la TAPR OHL esta siendo adoptada por varios aficionados
|
| 449 |
|
|
y empresas comerciales.
|
| 450 |
|
|
|
| 451 |
|
|
En general, las licencias actuales de hardware de código abierto han
|
| 452 |
|
|
recibido críticas del OSI, entre otras cosas, por la adopción de un
|
| 453 |
|
|
significado diferente de la palabra
|
| 454 |
|
|
``distribución''~\cite{Etiqueta13}. Sin embargo, es de esperar que en
|
| 455 |
|
|
el futuro próximo surjan licencias alternativas de hardware de código
|
| 456 |
|
|
abierto que resuelvan las ambigüedades presentes en las licencias
|
| 457 |
|
|
actuales.
|
| 458 |
|
|
|
| 459 |
|
|
%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.
|
| 460 |
|
|
|
| 461 |
|
|
|
