OpenCores
URL https://opencores.org/ocsvn/phr/phr/trunk

Subversion Repositories phr

Compare Revisions

  • This comparison shows the changes necessary to convert path 
    /phr/trunk/doc
    from Rev 308 to Rev 309
    ↔ Reverse comparison
  •

Rev 308 → Rev 309

/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.
 
 
/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:
/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}
}
 
 
/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}

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.