URL
https://opencores.org/ocsvn/phr/phr/trunk
Subversion Repositories phr
Compare Revisions
- This comparison shows the changes necessary to convert path
/phr
- from Rev 308 to Rev 309
- ↔ Reverse comparison
Rev 308 → Rev 309
/trunk/doc/informe-tesis/phd-thesis-template-master/Appendix2/appendix2.tex
1,7 → 1,7
% ******************************* Thesis Appendix B ******************************** |
|
\chapter{Esquemáticos} |
\label{appendix:sche} |
\chapter{Licencias} |
\label{appendix:lic} |
|
|
\ifpdf |
10,19 → 10,452
\graphicspath{{Appendix2/Figs/Vector/}{Appendix2/Figs/}} |
\fi |
|
En sucesivas páginas se muestran los esquemáticos completos para las tres placas utilizadas en el proyecto. Las hojas aparecen en el mismo orden del siguiente listado que explica brevemente cada esquemático: |
\section{Software Libre y Código Abierto} |
|
\begin{description} |
\item [PHRboard.sch] Muestra el chip FPGA y la conexión de sus pines. |
\item [PHRboard\_power.sch] Muestra la red de capacitores de desacople y bypass. |
\item [PHRboard\_IOports.sch] En esta hoja se describen mayormente los perífericos de la placa PHR. |
\item [OOCD\_placa.sch] Es la placa \emph{OOCDLink} encargada de la comunicación con la PC. |
\item [S3Proto\_Power.sch] Es la placa \emph{S3Power} que provee la energía para el resto de los circuitos. |
\end{description} |
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: |
|
\includepdf[landscape=true]{./img/sche/PHRboard.pdf} |
\includepdf[landscape=true]{./img/sche/PHRboard-Power.pdf} |
\includepdf[landscape=true]{./img/sche/PHRboard-IOports.pdf} |
\includepdf[landscape=true]{./img/sche/OOCD_placa.pdf} |
\includepdf[landscape=true]{./img/sche/S3Proto_Power.pdf} |
\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. |
|
|
/trunk/doc/informe-tesis/phd-thesis-template-master/Appendix3/appendix2.tex
5,9 → 5,9
|
|
\ifpdf |
\graphicspath{{Appendix2/Figs/Raster/}{Appendix2/Figs/PDF/}{Appendix2/Figs/}} |
\graphicspath{{Appendix3/Figs/Raster/}{Appendix3/Figs/PDF/}{Appendix3/Figs/}} |
\else |
\graphicspath{{Appendix2/Figs/Vector/}{Appendix2/Figs/}} |
\graphicspath{{Appendix3/Figs/Vector/}{Appendix3/Figs/}} |
\fi |
|
En sucesivas páginas se muestran los esquemáticos completos para las tres placas utilizadas en el proyecto. Las hojas aparecen en el mismo orden del siguiente listado que explica brevemente cada esquemático: |
/trunk/doc/informe-tesis/phd-thesis-template-master/References/references.bib
327,5 → 327,45
year={2013}, |
} |
|
|
% ------------------------------------------------------------------------ |
% Referencias Apéndice 2 |
% ------------------------------------------------------------------------ |
|
@MISC{Etiqueta07, |
author = {Free Software Foundation}, |
title = {The Free Software Definition - GNU Project - Free Software Foundation(FSF)}, |
month = May, |
year = {2010}, |
howpublished={\url{http://www.gnu.org/philosophy/free-sw.html}}, |
note = {Accedido: 2014-05-20} |
} |
|
@MISC{Etiqueta14, |
author = {Free Software Foundation}, |
title = {Free software is a matter of liberty, not price - Free Software Foundation - working together for free software}, |
month = May, |
year = {2010}, |
howpublished={\url{http://www.fsf.org/about/}}, |
note = {Accedido: 2014-05-20} |
} |
|
@MISC{Etiqueta12, |
author = {TAPR}, |
title = {The TAPR Open Hardware License}, |
month = May, |
year = {2011}, |
howpublished={\url{http://www.tapr.org/ohl.html}}, |
note = {Accedido: 2014-05-20} |
} |
|
@MISC{Etiqueta13, |
author = {Ars Technica}, |
title = {TAPR introduces open-source hardware license, OSI skeptical}, |
month = May, |
year = {2011}, |
howpublished={\url{http://arstechnica.com/old/content/2007/02/8911.ars}}, |
note = {Accedido: 2014-05-20} |
} |
|
|
/trunk/doc/informe-tesis/phd-thesis-template-master/thesis.tex
188,6 → 188,7
|
\include{Appendix1/appendix1} |
\include{Appendix2/appendix2} |
\include{Appendix3/appendix2} |
%\include{ProyectosOpenHW/ProyectosOpenHW} |
|
\end{appendices} |