1
0
mirror of git://projects.qi-hardware.com/nn-usb-fpga.git synced 2025-01-10 08:50:14 +02:00
nn-usb-fpga/course/.docs/book/commons.tex.backup

368 lines
45 KiB
Plaintext
Raw Normal View History

2010-09-13 03:57:04 +03:00
\chapter{Copyleft HW/SW y el Conocimiento Como Bien Com<6F>n}
\label{ch:common}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% El conocimiento como bien com<6F>n %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introducci<63>n}
Es indudable que el desarrollo tecnol<6F>gico de un pa<70>s se encuentra ligado al mejoramiento de la calidad de vida de sus habitantes, y que para que un pa<70>s en v<>a de desarrollo se realice una transferencia tecnol<6F>gica (y de conocimientos asociados a la tecnolog<6F>a que se transfiere) exitosa que permita desarrollar productos similares, pero ajustados al contexto socio-econ<6F>mico local, es necesario que el pa<70>s cuente con la capacidad de absorber las habilidades, t<>cnicas, informaci<63>n y organizaci<63>n asociadas a dicha tecnolog<6F>a. Esta absorci<63>n de conocimientos debe ser realizada por un gran n<>mero de personas para que la transferencia tenga un impacto significativo en la sociedad, este conocimiento debe ser considerado como un bien p<>blico, y como tal, el acceso a <20>l, debe ser un derecho y por lo tanto, la sociedad debe garantizar los mecanismos de difusi<73>n para que llegue a los sectores de la sociedad interesados en <20>l. De igual forma, es un deber, de los sectores que utilizan este bien com<6F>n contribuir a su difusi<73>n, actualizaci<63>n, mejoramiento, y crecimiento.
Un bien com<6F>n es un recurso compartido que es vulnerable a dilemas sociales, es el resultado de interacciones entre personas y recursos, las cuales pueden ser positivas o negativas. El concepto de bien com<6F>n esta asociado a la \textit{libertad de expresi<73>n}, \textit{libre acceso} y \textit{autogobierno}
El conocimiento en este trabajo se refiere a las ideas intangibles, informaci<63>n y datos de todo tipo en que el conocimiento es expresado u obtenido, como todo tipo de entendimiento adquirido a trav<61>s de la experiencia o estudio ya sea propio, cient<6E>fico, acad<61>mico o no acad<61>mico. El conocimiento puede ser visto como una mercanc<6E>a y como una fuerza constitutiva de la sociedad lo que evidencia la naturaleza compleja de este recurso, adicionalmente, la adqusici<63>n y descubrimiento de conocimiento es un proceso social y personal. \textit{El descubrimiento de conocimiento es un bien com<6F>n y un tesoro que dejamoa a futuras generaciones y el reto de nuestra generaci<63>n es en mantener los caminos del descubrimiento abiertos}.
El acceso al conocimiento debe garantizarse sin restricci<63>n alguna a las personas interesadas, al considerar el conocimiento como un producto comercial se limita su difusi<73>n favoreciendo a un grupo de la poblaci<63>n, lo cual es inaceptable, ya que representa una forma de discriminaci<63>n. En nuestro pais, el acceso a la informaci<63>n ha ido aumentando gracias a la aparici<63>n de Internet y a la gran cantidad de proyectos existentes que buscan difundir todo tipo de conocimientos. Sin embargo, para poder asimilar este conocimiento se requieren ciertas habilidades que se adquieren despu<70>s de un procesos de ense<73>anza formal. En Colombia el acceso a la educaci<63>n superior de calidad es limitado, la cobertura de las Universidades p<>blicas est<73> limitada por la inversi<73>n del estado, y como pudimos ver anteriormente, en nuestro pa<70>s la preocupaci<63>n actual es la seguridad y no la educaci<63>n. Por lo tanto, hacer del conocimiento un bien com<6F>n requiere la intervenci<63>n de diferentes sectores que garanticen y regulen el acceso, generen, clasifiquen y administren la forma en la que se expresa el conocimiento.
La diferencia entre esta propuesta y las existentes promovidas por los organismos gubernamentales, es el <20>nfasis en la transferencia y difusi<73>n del conocimiento, del \textit{saber hacer}, muchas pol<6F>ticas existentes se enfocan en la compra de equipo, lo que, como se vi<76> antes no es el canal m<>s eficiente para la transferencia tecnol<6F>gica. Nuestros esfuerzos est<73>n enfocados a crear un conocimiento b<>sico en la Concepci<63>n, Dise<73>o, Implementaci<63>n y Dise<73>o de Sistemas Embebidos. Este conocimiento es el resultado de a<>os de experimentaci<63>n e investigaci<63>n en el <20>rea, al ser colocado a disposici<63>n de usuarios interesados, se aumentan las posibilidades de difusi<73>n, ya que ya se realiz<69> un trabajo previo de "adaptaci<63>n" a las condiciones de la plataforma tecnol<6F>gica local y al contexto econ<6F>mico y social. En la actualidad existen instituciones educativas que proporcionan conocimientos similares pero no tienen la profundidad del presente estudio y limitan el acceso a esta informaci<63>n cobrando altos precios para acceder a ella.
En este cap<61>tulo estudiaremos las licencias \textit{Creative Commons} una nueva forma de licenciamiento que permite asignar diferentes "permisos" de utilizaci<63>n a un determinado trabajo y puede ser utilizadas tanto en Software como en Hardware. Exploraremos el movimiento de Software Libre y C<>digo Abierto (FOSS) y como este contribuye a la transferencia tecnol<6F>gica y como millones de usuarios a lo largo y ancho del mundo trabajan de forma conjunta para difundir, actualizar, mejorar, y aumentar las aplicaciones disponibles. Adicionalmente se presenta una propuesta a la creaci<63>n de un movimiento que funcione con pol<6F>ticas similares pero centrado en el Desarrollo Hardware.
\section{El Conocimiento Como Bien Com<6F>n}
El an<61>lisis del conocimiento como bien com<6F>n tiene sus bases en el estudio de recursos naturales compartidos (agua, bosques, fauna, flora). El recurso puede ser peque<75>o y ser utilizado por un grupo reducido (El televisor familiar), puede ser de nivel comunitario (campos de juego, bibliotecas, paruqes etc) o pueden tener naturaleza internacional y mundial (oceanos, atm<74>sfera, internet, conocimiento cient<6E>fico, etc), puden ser delimitados (la librer<65>a comunitaria), transfronterizos (El rio Amazonas, Internet, vida salvaje migratoria, etc) o sin l<>mites claros (el conocimiento, la capa de ozono, etc). Adicionalmnete, existe una diferencia entre el bien com<6F>n como un recurso o sistema de recursos y el bien com<6F>n como un r<>gimen de derechos de propiedad\cite{EO90}. El conocimiento posee caracter<65>sticas que lo diferencian de los recursos naturales, mientras muchos bienes comunes ven comprometido su sostenimiento a medida que aumenta el n<>mero de usuarios, el objetivo de utilizar el conocimiento como bien com<6F>n es lograr su m<>xima difusi<73>n. El beneficio asociado al acceso a la informaci<63>n depende de la calidad de esta, a mayor calidad mayor el beneficio.
El conocimiento, al igual que otros bienes comunes es utilizado de forma conjunta y es manejado por grupos de diversos intereses y tama<6D>os. Para que este recurso sea <20>til se requiere una infra-estructura que permita su difusi<73>n, actualizaci<63>n, mejoramiento, realimentaci<63>n y crecimiento. Pero como administrar un recurso intangible y distribuido como el conocimiento? Como coordinar acciones de miembros que se encuentran localizados en diferentes puntos geogr<67>ficos?
Como coordinar acciones de miles de usuarios para garantizar un recurso <20>til y sostenible? Como convertir este conocimiento en motor de Desarrollo y crecimiento empresarial? Estas preguntas ser<65>n respondidas a lo largo de este cap<61>tulo.
\subsection{Auto-Gobierno}
Ostrom \cite{Ost00} argumenta que la forma m<>s eficiente de administrar un bien com<6F>n es el auto-gobierno ejercido por beneficiarios de dicho recurso. Si estos beneficiarios son conscientes de la importancia de un uso eficiente y racionado que garantice la existencia de este bien y toda acci<63>n o decisi<73>n que se haga es formulada pensando en el beneficio com<6F>n se crear<61>n normas que garantizan el beneficio de todos los usuarios y la sostenibilidad del recurso. El auto-gobierno requiere acciones colectivas que "emergen cuando se requiere el esfuerzo de dos o m<>s individuos para cumplir con una meta" \cite{ST92}. Otro aspecto importante de las acciones colectivas es que son voluntarias por parte de los individuos \cite{MMDG04}. El autogobierno requiere de la acci<63>n combinada de conociminto y voluntad unido a normas institucionales consistentes.
Ostrom \cite{EO92} y Baland and Platteau \cite{J.B96}, consideran que los atributos necesarios para que un recurso tenga una probabilidad alta de crear asociaciones de autogobierno son:
\begin{itemize}
\item Posibilidad de mejoramiento: El recurso no se encuentra en un punto tal que sea in<69>til crear una organizaci<63>n alrededor de <20>l.
\item Indicadores: Disponibilidad de indicadores confiables y v<>lidos sobre la condici<63>n del recurso.
\item Predictibilidad: El flujo de unidades de recurso es relativamente predecible.
\item El recurso es lo suficientemente peque<75>o, teniendo en cuenta las tecnolog<6F>as de comunicaci<63>n utilizadas, para que los usuarios pueden tener un conocimiento preciso de los l<>mites externos y de los micro-ambientes internos.
\end{itemize}
Y los atributos de los usuarios del recurso son:
\begin{itemize}
\item Prominencia: Los usuarios dependen del recurso para una parte importante de su sostenimiento.
\item Entendimiento com<6F>n: Conocimiento sobre el funcionamiento del sistema y como acciones individuales afectan a los dem<65>s y al sistema.
\item Baja Tasa de Descuento: Para obtener un mayor beneficio a futuro se deben mantener tasas bajas de descuento del recurso.
\item Confianza y Reciprocidad: Los usuarios del recurso conf<6E>an en que los dem<65>s mantendr<64>n las promesas y se relacionar<61>n entre ellos con reciprocidad.
\item Autonom<6F>a: Los usuarios pueden determinar reglas sin la intervenci<63>n de autoridades externas
\item Experiencia Previa en Organizaci<63>n y Liderazgo Local: Los usuarios poseen habilidades m<>nimas de organizaci<63>n y liderazgo a trav<61>s de la participaci<63>n en otras asociaciones locales o eprendiendo de organizaciones en grupos cercanos.
\end{itemize}
De los anteriores atributos podemos deducir que para que pueda emerger un auto-gobierno asociado a un recurso debe existir un excelente canal de comunicaci<63>n entre los usuarios de dicho recurso y que todos ellos deben conocer y aceptar una serie de normas (creadas por ellos mismos) que fueron formuladas pensando en el beneficio com<6F>n, un grupo de estas normas debe establecer mecanismos de resoluci<63>n de conflictos, esto es vital ya que toda la organizaci<63>n se basa en la confianza mutua y no puede permitirse que las relaciones entre los usuarios se deteriore. Adicionalmente se requiere de miembros que tengan claro que el <20>xito de sus acciones y el sostenimiento del recurso depende de sus acciones, las cuales deben realizarse teniendo en cuenta el beneficio com<6F>n. El conocimiento no se ve afectado por la sustracci<63>n (uso) del mismo, todo lo contrario, el objetivo es obtener el m<>ximo n<>mero de usuasrios, sin embargo, este conocimiento puede llegar a ser obsoleto r<>pidamente, (en especial en el <20>rea de la Electr<74>nica digital) y por lo tanto inservible, para que esto no suceda se requiere de la actualizaci<63>n de este conocimiento para que refleje el estado actual en un <20>rea determinada.
\subsubsection{Ecuaci<63>n Costo Beneficio de Ostrom}
La pregunta que trata de responder Ostrom en su estudio es como emerge el auto-gobierno? \cite{Ost00} Para contestar esto formula una ecuaci<63>n que describe el an<61>lisis costo-beneficio que un individuo realiza para participar en un gobierno comunal:
\begin{lstlisting}[]
D < C (C1 + C2 + C3)
\end{lstlisting}
Donde ($D$) es el incentivo al cambio y compara los beneficios de utilizar las reglas tradicionales (BO) frente a los beneficios de utilizar un nuevo grupo de reglas basadas en un gobierno comunal (BN)
\begin{lstlisting}
D = BN - BO
\end{lstlisting}
C1 costo anticipado asociado a la transici<63>n.
C2 el costo de corto plazo para adoptar y apropiar las nuevas estrategias.
C3 Costos de largo plazo: mantenimiento, monitoreo y auto-gobierno.
Para que se realice el cambio el incentivo al cambio debe ser mayor que los costos asociados a el.
\begin{lstlisting}
BN - BO > C
BN > BO + C
\end{lstlisting}
Complejidades adicionales resultan de la interacci<63>n entre sub-grupos de usuarios, esta ecuaci<63>n puede ser diferente para cada participante, por lo que es normal encontrar coaliciones y acciones.
En la actualidad obervamos que grandes multinacionales como Nokia, Motorola o Google, est<73>n participando y promoviendo el desarrollo de productos y aplicaciones \cite{Mot} \cite{And} \cite{Mae} con la participaci<63>n de la comunidad, lo que representa un giro de 180 grados en la pol<6F>ticas lideradas por multinacionales como Microsoft y Aple en las que todas sus creaciones est<73>n protegidas por licencias, acuerdos comerciales y contratos de exclusividad que restringen la participaci<63>n en su desarrollo y aseguran el monopolio de los resultados de sus investigaciones. El movimiento de Software Libre \cite{FSF} hizo posible este cambio, proporcionando herramientas de desarrollo y facilidades para que cualquier persona alrededor del mundo pudiera realizar sus propias aplicaciones, gracias a esto se han creado aplicaciones como el servidor Web Apache, el explorador Mozilla el sistema operativo Linux, aplicaciones como gimp, openoffice, librer<65>as como ncurses, Qt y entornos de trabajo como xfce, gnome y KDE. El trabajo realizado por miles de programadores para llegar a este estado ha sido enorme, y por esta raz<61>n los grandes multinacionales est<73>n poniendo sus ojos en estas iniciativas ya que les representa un gran ahorro de dinero, es decir, el costo de participar en estas iniciativas es mucho menor que el beneficio obtenido por participar en ellas.
\subsubsection{Principios de Dise<73>o}
El primer paso para gobernar un bien com<6F>n es la identificaci<63>n de los principios de dise<73>o de un recurso com<6F>n robusto de larga duraci<63>n. Ostrom \cite{EO90} despu<70>s de dirigir un gran n<>mero de estudios emp<6D>ricos sobre gobernancia de recursos de bienes com<6F>nes. Encontr<74> una serir de principios de dise<73>o que hacen que el recurso sea sostenible a lo largo del tiempo. Los principales son:
\begin{itemize}
\item Fronteras claramente definidas
\item Las reglas deben reflajar necesidades y condiciones locales.
\item Los individuos sujetos a estas reglas pueden modificar y participar en la elaboraci<63>n de estas reglas.
\item Las autoridades externas deben respetar el derecho de los miembros de la comunidad a cear sus propias reglas.
\item Debe establecerse un sistema de seguimiento propio.
\item Disponibilidad de un sistema gradual de sanciones.
\item Acceso por parte de miembros de la comunidad a mecanismos de resoluci<63>n de conflictos de bajo costo.
\item Las actividades de apropiaci<63>n, suministro, monitoreo y sanci<63>n deben ser organizadas en estructuras anidadas con m<>ltiples capas de actividades
\end{itemize}
Es importante mencionar que no existe una combinaci<63>n de principios que garantice el <20>xito, es necesario probar con este set para identificar los principios generales que deben incluir los sistemas robustos. Estos ocho factores fueron encontrados en la mayor<6F>a de las instituciones analizadas en cientos de estudios y constituyen un buen punto de partida para comenzar esta investigaci<63>n. Estos ocho puntos se encuentran fuertemente relacionados con los atributos que requiere un recurso y un usario de este recurso para que pueda emerger un auto-gobierno y buscan que todos los participantes tengan pleno conocimiento de las reglas que monitorean, regulan, fijan y controlan las actividades de los miembros.
\subsubsection{Movimiento FOSS}
Es interesante consoiderar como este pensamiento aplica a proyectos de C<>digo Abierto. El Software no es un recurso t<>pico, porque no es sustraible, no existe un costo si un usuario decide usarlo o no. Sin embargo, es un bien com<6F>n, ya que es un recurso comunal que prospera o decae gracias a la contribuci<63>n de sus miembros. Los participantes de este tipo de recurso es el grupo de contribuidores potenciales, en lugar del grupo de posibles propietarios. Un aporte de un usuario a mejorar el proyecto se traduce en un beneficio colectivo. Los contribuyentes pueden ser empresas que pagan a una persona para que adicione una nueva caracter<65>stica, sin embargo, ellos pueden decidir no compartir estos cambios para tener una ventaja competitiva. En la actualidad observamos las tendeencias de multinacionales como Nokia o Motorola a participar, crear y promover proyectos de Software Libre, desde el punto de vista comercial resulta mpas rentable utilizar harramientas que han sido desarrolladas, probadas, y depuradas por miles de usuarios calificados que pagar a un grupo de decenas de desarrolladores para trabajar en sistemos propietarios.
En los proyectos de C<>digo Abierto puede utilizarse una variaci<63>n modificada de la ecuaci<63>n de Ostrom \cite{AC09}:
\begin{lstlisting}
BC > BN + C
\end{lstlisting}
Donde $BC$ es el beneficio a contribuir, y debe superar el costo de contribuir $C$ m<>s el beneficio de no contribuir $BN$. La comunidad del Software Libre ha creado un grupo de normas e instituciones muy sofisticadas alrededor de esta ecuaci<63>n dando como resultado uno de los estructuras auto-gobernadas m<>s exitosas. Los trabajos de la comunidad de Software Libre hacen que $C$ sea cada vez m<>s peque<75>o, proporcionando:
\begin{itemize}
\item Herramientas de programaci<63>n, depuraci<63>n y librer<65>as que facilitan el desarrollo de nuevas aplicaciones o mejoras a las ya existentes.
\item Listas de discusi<73>n en donde los creadores de estas herramientas responden preguntas, y buscan en conjunto soluciones a problemas espec<65>ficos
\item Sistemas de control de versiones y protocolos de comunicaci<63>n.
\item Bases de datos de soluci<63>n de problemas asociadas a las listas de discusi<73>n.
\item Tutoriales, documentaci<63>n, libros disponibles on-line.
\end{itemize}
Para contribuyentes no comerciales el costo de no contribuir es cero, pero, para contribuyentes comerciales $BN$ puede resultar muy grande, ya que pagar una n<>mina de programadores para que dise<73>en un sistema propio desde cero es mucho m<>s costoso (en tiempo y en dinero) que pagar a pocos programadores pra utilizar y modificar proyectos ya existentes. La licencia m<>s utilizada en los proyectos de Software Libre es la GPL, la cual, aunque no cubre todos los posibles tipos de uso, impone fuertes sanciones (escarnio p<>blico y consecuencias legales) cuando se utiliza y mejora un proyecto, pero no se comparten estos cambios con la comunidad. M<>s adelante estudiaremos el movimiento FOSS del cual se puede aprender mucho para crear nuestra versi<73>n de \textit{Hadrware Copyleft}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% FOSS %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{FOSS}
Como se mencion<6F> anteriormente, el movimiento FOSS es la estructura auto-gobernada m<>s exitosa y ser<65> tomada como referencia en el desarrollo de nuestra iniciativa de Hardware Copyleft. Su principal innovaci<63>n radica en un nuevo esquema de licencias unido a herramientas de colaboraci<63>n basadas en Internet, lo que se cnvirti<74> en una nueva forma de bien com<6F>n, donde los miembros de forma colectiva generan un buen com<6F>n el \textit{software}. El desaf<61>o de FOSS es realizar \textit{acciones colectivas para crear y mantener este bien p<>blico}. A diferencia de la creencia popular, en este movimiento existen derechos de autor (\textit{copyright}) y propiedad, sin embargo, algunos individuos involucrados en el proyecto, poseen derechos legales sobre el c<>dico (recurso), tienen control sobre las nuevas versiones del software y pueden excluir a otros que aportan c<>digo a las nuevas distribuciones.
Los miembros del movimiento FOSS usualmente son programadores (y usuarios finales de software) que contribuyen (ya sea voluntariamente, o que se les pague para hacerlo) para producir un software bajo la licencia FOSS. La "situaci<63>n de acci<63>n" que estos programadores encaran es, si en alg<6C>n momento, vale la pena contribuir al desarrollo de este software. La interaci<63>n de programadores trabajando de forma conjunta en Internet puede ser visto como un resultado que puede cambiar en el tiempo. Schweik y Semenov \cite{SAS03} identificaron tres estados de este tipo de bien com<6F>n, una fase inicial, seguida por un estado de apertura y un estado m<>s maduro de gran crecimiento (en t<>rminos de usuarios y participaci<63>n), estabilizaci<63>n donde el n<>mero de participantes (normalmente peque<75>o) no var<61>a, o el protecto se estanca y muere (sin participantes). Para que un proyecto sea exitoso, no es necesaria la participaci<63>n de un gran n<>mero de programadores, es frecuente encontrar grupos peque<75>os de programadores con un gran n<>mero de usuarios. La clave del <20>xito est<73> en la disponibilidad de un programador para contribuir al esfuerzo colectivo de por lo menos un peque<75>o grupo de actores que producen y mantienen el software.
En la Figura \ref{framework_foss} se ilustra el marco definido por Ostrom y Hess \cite{CHEO06} para analizar el conocimiento como bien com<6F>n, aplicado al movimiento FOSS. Como se mencion<6F> anteriormente, el razgo que diferencia este movimiento es la utilizaci<63>n de una forma de licenciamiento especial. Richard Stallman \cite{Wikb}, a mediados de los 80 inici<63> un proyecto para desarrollar un sistema operativo abierto/libre basado en \textit{unix} llamado \textit{GNU} (GNU is Not unix).
\subsubsection{Reglas En Uso}
Stallman \cite{Sta99} sostiene que las propiedades digitales del software hacen posible considerarlo como un bien p<>blico, proporcionando a sus usuarios \textit{la libertad} de utilizarlo, distribuirlo y modificarlo. Esta filosf<73>a se basa en cuatro libertades que encarnan el principio \textit{copyleft}:
\begin{itemize}
\item Libertad de ejecutar el software para cualquier prop<6F>sito.
\item Libertad de estudiar como funciona el programa, y cambiarlo para hacer lo que se desee. El acceso al c<>digo fuente es una condici<63>n para esto.
\item Libertad para re-distribuir copias.
\item Libertad para distribuir copias de versiones modificadas. Lo que permite que la comunidad se beneficie de estos cambios. El acceso al c<>digo fuente es una condici<63>n para esto.
\end{itemize}
Esta filosof<6F>a permite que los conocimientos y habilidades que el programador posee puedan ser transferidas a programadores, empresas, instituciones acad<61>micas y sociedades, ya sea en forma de producto o como herramienta de ense<73>anza. Esta actividad representa un proceso de Transferencia Tecnol<6F>gica, en la que el que suministra la tecnolog<6F>a proporciona todos los medios para que el receptor pueda abosrverla y transformarla para satisfacer necesidades en su entorno social. Adicionalmente, Stallman ide<64> una forma de trabajar con las leyes de derechos de autor que proporciona una alternativa al licenciamiento tradicional. Las grandes multinacionales como Microsoft o Apple limitan el n<>mero de usuarios por licencia y hacen distribuciones de archivos binarios compilados en forma de ejecutables. El software con licencia \textit{copyleft} estipula que cualquier modificaci<63>n que se le realice adquiere los principios de licenciamiento del software original. La licencia \textit{GPL}\footnote{http://www.gnu.org/licenses/licenses.html} (GNU General Public License) fue creada para implementar estos principios.
\begin{figure}[H]
\begin{center} \includegraphics[scale=.6]{./images/framework_foss.png} \end{center}
\caption{Marco para analizar el conocimiento como bien com<6F>n aplicado al movimiento FOSS: Modificaci<63>n de: \cite{CHEO06} p<>g 46} \label{framework_foss}
\end{figure}
El proyecto de \textit{c<>digo abierto} liderado por Bruce Perens y Eric Raymond, utiliza las propiedades de la licencia GPL adicionando un grupo de \textit{derechos morales} dirigidos a conservar el trabajo del autor en su forma original, con el f<>n de conservar su autor<6F>a. Existe un gran n<>mero de variaciones de licenciamiento \footnote{http://www.opensource.org/licenses/alphabetical} para proyectos de Software Libre, lo que indica que al momento de licenciar un software el autor debe determinar que derechos retener y cuales regalar \cite{CMS06}. Las innovaciones del licenciamiento \textit{copyleft} constituyen las \textit{reglas en uso} que motivan a los programadores a participar en el movimiento FOSS, y establecen las bases de un r<>gimen de propiedad com<6F>n.
La clave para mantener un bien com<6F>n es la estructura de gobernanza de dicho recurso, el movimiento FOSS es un experimento en marcha, en dondes se prueba una mezcla imperfecta de liderazgo, mecanismos informales de coordinaci<63>n, normas impl<70>citas y expl<70>citas junto con estructuras de gobernanza formal que evolucionan de tal forma que han logrado mantener unido este sistema tan camplejo \cite{Web04}. Aunque no existe literatura que estudie las estructuras de gobernanza en el movimiento FOSS, algunas observaciones a los proyectos existentes en la actualidad indican que estas estructuras podr<64>an incluir:
\begin{itemize}
\item Priorizaci<63>n de caracter<65>sticas a incluir en nuevas versiones del software.
\item Definici<63>n de Reglas y procedimientos para evaluar y escoger nuevos aportes para que hagan parte de las nuevas versiones.
\item Definici<63>n de Reglas y procedimientos para detectar y corregir errores en el software.
\item Asignaci<63>n y administraci<63>n de tareas.
\item Asistencia en la resoluci<63>n de disputas entre miembros del equipo.
\end{itemize}
Estas reglas var<61>an dependiendo del estado del proyecto, ya que, las actividades que se deben realizar en cada etapa son diferentes, en la etapa inicial, se establece la comunidad de programadores que definen las especificaciones del software, por lo que las tarea m<>s importante son el reclutamiento de programadores y la definci<63>n de una estructura flexible para el software. Cuando el proyecto alcanza una determinada madurez, lo importante es a<>adir funcionalidades y corregir errores.
\subsubsection{Atributos de la Comunidad}
La comunidad FOSS esta compuesta por usuarios y programadores voluntarios motivados por intereses tecnol<6F>gicos, sociopol<6F>ticos, econ<6F>micos y acad<61>micos. Desde el punto de vista tecnol<6F>gico, resulta m<>s efectivo en tiempo y en dinero, participar en un proyecto conjunto para la realizaci<63>n de una aplicaci<63>n que satisface una determinada necesidad. La principal motivaci<63>n sociopol<6F>tica es la creencia por parte del programador en la filosof<6F>a del movimiento, en lalucha contra el monopolio del software, adicionalmente, para que el proyecto permenezca durante mucho tiempo, es necesario que sea atractivo para vincular el mayor n<>mero de participantes y de esta forma sobrevivir en el futuro. Las motivaciones econ<6F>micas y acad<61>micas pueden ser consideradas en forma conjunta ya que al participar en estos proyectos, los miembros adquieren o mejoran sus habilidades de programaci<63>n ya sea revisando, leyendo y entendiendo el c<>digo existente o sometiendo a la revisi<73>n de los dem<65>s miembros sus contribuciones. Por otro lado, esta participaci<63>n puede verse como una vitrina en donde el programador muestra sus capacidades y puede ser contactado por empresas para establecer relaciones comerciales. En los dos casos la participaci<63>n es una forma de inversi<73>n y una forma de ganar experiencia y reputaci<63>n \cite{VWJ+03}.
En proyectos con un gran n<>mero de personas asociadas, solo un peque<75>o porcentaje de ellos realizan la mayor parte del trabajo. En la actualidad muchas empresas est<73>n participando de forma activa en estos proyectos, aportando programadores pagados para que contribuyan con el desarrollo y mejoramiento del softeare. Un estudio realizado a 25 firmas participantes en el proyecto FOSS \textit{Linux Operating System} \cite{GGR02} indica que la tercera parte de los programadores encuestados son pagados por sus empleadores para participar, y que su motivaci<63>n a participar es el interes propio en estandarizaci<63>n, disminuci<63>n de costos, estrategias para debilitar a la competencia y esfuerzos para hacer sus productos compatibles con los productos derivados del movimiento FOSS.
\subsubsection{Atributos F<>sicos}
Existen tres categor<6F>as \cite{CMS06} en FOSS que pueden ser consideradas como atributos f<>sicos:
\begin{enumerate}
\item La utilidad del Software: Como vimos anteriormente, para que una persona participe en una actividad relacionada con el bien com<6F>n, el costo por no hacerlo debe ser mayor que el beneficio por participar, es decir, el software debe representar una utilidad grande para que valga la pena participar en el proyecto.
\item El dise<73>o o la estructura del software. Un c<>digo limpio (optimizado, documentado y <20>ptimo) y modularizado permite el trabajo en paralelo, lo que reduce el tiempo de depuraci<63>n y el requerido para implementar nuevas caracter<65>sticas.
\item La infraestructura que hace posible coordinar y administrar la colaboraci<63>n y la producci<63>n: El uso de Internet para soportar herramientas de control de versiones (como \textit{svn}, \textit{cvs} y \textit{git}) y la comunicaci<63>n v<>a listas de discusi<73>n hace posible coordinar de forma eficiente los esfuerzos de cooperaci<63>n. Permitiendo:
\begin{itemize}
\item Almacenar versiones de software.
\item La descarga de m<>dulos.
\item La adici<63>n de Nuevas contribuciones y la protecci<63>n del c<>digo existente.
\item Generar un historial donde se documentan los cambios realizados a lo largo del tiempo.
\item Analizar funciones para identificar diferencias entre versiones.
\item Informar a los miembros del equipo cambios en los m<>dulos del proyecto.
\end{itemize}
\end{enumerate}
Esta infraestructura trabaja junto con las reglas-en-uso establecidas para proporcionar procesos que direccionen nuevos trabajos, un sistema para recibir y revisar contribuciones de nuevos m<>dulos que pueden ser incluidos en futuras versiones.
En conclusi<73>n, los proyectos FOSS evolucionan en el tiempo como resultado de la configuraci<63>n de sus reglas-en-uso, atributos de la comunidad y atributos f<>sicos relacionados con la estructura del software para hacer f<>cil la colaboraci<63>n y herramientas efectivas para coordinaci<63>n de equipos y manejo de contenido.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% Copy Left %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Propiedad Intelectual y Licencias}
Para utilizar el paradigma colaborativo del movimiento FOSS para adaptarlo a cualquier forma de propiedad intelectual (incluyendo la creaci<63>n de hardware) es necesario ampliar el t<>rmino \textit{copyleft} de Stallman. El primer en esta direcci<63>n fu<66> dado por el mismo Stallman al desarrollar la licencia GFDL (GNU Free Documentation License) aplicable a todo tipo de documentaci<63>n t<>cnica, guias de usuario, tutoriales, etc. Esta licencia gobierna el uso, modificaci<63>n y distribuci<63>n de la documentaci<63>n del software GNU, especificando las secciones del documento que no puden ser modificadas (tales como autor, aviso de derechos de autor), los t<>rminos de distribuci<63>n.
\subsection{Licencias Creative Commons}
Creative Commons \footnote{http://creativecommons.org/} organizaci<63>n no gubernamental sin <20>nimo de lucro ha desarrollado una serie de licencias basadas en principios similares a los de Stallman y que puden ser aplicadas a trabajos realizados en m<>sica, arte, video, texto y notas de clase. Estas licencias permiten que el autor de un trabajo conserve la propiedad intelectual (los derechos asociados a esta) pero posibilitando su copia y distribuci<63>n, con la <20>nica condici<63>n de dar cr<63>ditos al autor \cite{CCb}. Se puede elegir diferentes permisos dependiendo de los deseos del autor, para definir dichos permisos CreativeCommons proporciona una serie de preguntas que buscan determinar los derechos que se desean conservar y los que desean liberar. Las preguntas claves son: 1) Los lectores pueden copiar y distribuir su trabajo libremente? 2) Es permitido a los usuarios crear trabajos derivados del contenido digital? Si es permitido, estas modificaciones deben tener la misma licencia que el trabajo original (esquema de licencia viral), o deben ser distribuidos bajo un esquema de licencias diferente? 3) Es necesario atribuir el trabajo al autor original?. Estas preguntas son la base para definir un esquema de licencias modular.
Existen cuatro bloques constructivos para las licencias Creative Commons estos son:
\begin{itemize}
\item \textit{Atribuci<63>n} (\textbf{BY}): Se permite la distribuci<63>n pero se debe dar cr<63>dito al autor.
\item \textit{No comercial} (\textbf{NC}): Se permite la distribuci<63>n del trabajo sin fines comerciales, si se desea utilizar este trabajo para obtener dinero es necesaria una autorizaci<63>n del autor
\item \textit{No a trabajos derivados} (\textbf{ND}): Permite la copia y la distribuci<63>n del trabajo original sin modificaciones.
\item \textit{Compartir de la misma forma} (\textbf{SA}): Exige que todo trabajo derivado del uso de proyectos que con este esquema de licencias deben tener la misma licencia de los trabajos originales.
\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%% COPY LEFT HW %%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Hardware Copyleft}
En esta secci<63>n se relizar<61> la definici<63>n del t<>rmino \textit{hardware copyleft} como una extensi<73>n del proyecto \textit{FOSS}. Una de las hip<69>tesis manejadas durante el desarrollo de este trabajo es que el conocimiento debe ser considerado como un bien com<6F>n y que los usuarios de este recurso deben utilizarlo de tal forma que se beneficie la comunidad asociada a dicho recurso. Como estrategia para obtener una transferencia tecnol<6F>gica y de conocimientos exitosa a la academia y a la industria electr<74>nica nacional (en el <20>rea de sistemas digitales) se utilizar<61> el principio del conocimiento como bien com<6F>n para crear una comunidad que utilice como recurso inicial el trabajo generado en este proyecto.
Los dispositivos digitales modernos poseen dos grandes componentes, el hardware que proporciona recursos como capacidad de c<>mputo, capacidad de almacenamiento, medios de comunicaci<63>n e interfaz con otros dispositivos y con el mundo real; y el software implementa una determinada funcionalidad utilizando los recursos hardware. Normalmente estos dispositivos est<73>n dise<73>ados para ejecutar una funci<63>n <20>nica, por lo que el componente hardware se encuentra optimizado (funcionalidad, tama<6D>o, consumo de potencia, costos) para la ejecuci<63>n de dicha tarea. Como se mencion<6F> anteriormente existe un movimiento muy fuerte (FOSS) que proporciona una gran variedad de herramientas para la implementaci<63>n del componente software. Sin embargo, hasta el momento no existe un movimiento similar dirigido al desarrollo del componente hardware. Mi hip<69>tesis es que un movimiento de hardware abierto permitir<69> el desarrollo de la industria electr<74>nica local permitiendo la transferencia exitosa de tecnolog<6F>a y conocimientos en el <20>rea de dise<73>o de sistemas embebidos.
Haciendo una analog<6F>a con el movimiento FOSS, la iniciativa \textit{hardware copyleft} permitir<69>a el uso, distribuci<63>n, y modificaci<63>n de proyectos hardware existentes. La acci<63>n de modificaci<63>n se origina por una necesidad que se debe satisfacer, implica un entendimiento del principio de funcionamiento y del proceso de fabricaci<63>n asociados al proyecto original. Lo anterior cumple con la definici<63>n de transferencia tecnol<6F>gica exitosa: ``\cite{Mo94} El problema de transfencia de conocimiento (o know-how) sobre un n<>mero de aspectos (que incluyen el conocimiento) sobre como funciona un determinado sistema, como operarlo y desarrollar sus aplicaciones, como mantenerlo y si es necesario, como producir sus componentes y montar un sistema similar. La transferencia tecnol<6F>gica se considera exitosa cuando los receptores de la tecnolog<6F>a asimilan los conceptos anteriores para suplir sus necesidades locales''.
El reto en la definici<63>n del concepto de \textit{hardware copyleft} radica en la naturaleza del componente hardware, a diferencia del software donde solo es necesario descargar el c<>digo fuente y las herramientas de compilaci<63>n para modificar un proyecto existente ; los proyectos hardware involucran procesos de fabricaci<63>n, montaje y pruebas que tienen asociados unos costos que var<61>an dependiendo de la tecnolog<6F>a utilizada (ASIC, PCB). Este costo representa un factor que afecta a los potenciales miembros de la comunidad, en el peor de los casos predefiniendo sus perfiles o limitando el acceso. Por este motivo, se debe considerar el impacto del factor econ<6F>mico en la formaci<63>n de la comunidad, definiendo las caracter<65>sticas que deben poseer estos proyectos para minimizar el costo asociado.
\subsection{Atributos de la Comunidad}
El <20>xito de la iniciativa \textit{FOSS} se debe en parte a la gran comunidad que comparte la ideolog<6F>a del software libre \cite{RS07},sus miembros buscan: satisfacer necesidades propias \cite{JK00}, aprendizaje \cite{HIH02}, reputaci<63>n dentro y fuera de la comunidad, asociaci<63>n e identidad \cite{GH03}, diversi<73>n y creatividad \cite{RAG+02}. Para que la propuesta \textit{hardware copyleft} sea una realidad, es importante identificar los motivos por los cuales estos individuos se unen a este tipo de comunidades y como las diferentes formas de gobierno afectan su participaci<63>n, y como esta experiencia exitos puede ser utilizada en nuestro movimiento.
Un estudio reciente, realizado sobre diferentes comunidades software \cite{SS06} \cite{KBCR10} revela que la raz<61>n inicial para la participaci<63>n es la necesidad de cambios, alteraciones o asistencia a proyectos existentes, su resultado se resumen en la tabla \ref{participation}. A pesar de que los costos de contribuci<63>n son relativamente altos en t<>rminos de tiempo y esfuerzo, muchos programadores se unen a esta comunidad buscando:
\begin{itemize}
\item \textit{Reciprocidad.} Una gran cantidad de los participantes en los proyectos software que fueron consultados en este estudio expresaban la necesidad de que la reciprocidad sea parte de las normas de la comunidad. Una gran parte de proyectos son liberados con el prop<6F>sito de suplir una necesidad, ya sea por la inexistencia de una herramienta que realice ciertas funciones o para reemplazar una comercial, sus autores buscan con esto que otras personas liberen sus trabajos para que puedan ser utilizados por la comunidad.
\item \textit{Mejoras.} Someter el c<>digo a la inspecci<63>n de miles de programadores ayuda a depurar y limpiar el c<>digo, adicionalmente se logra aumentar su funcionalidad y se aumenta el n<>mero de usuarios. Sin el apoyo de la comunidad estas mejoras tomar<61>an mucho tiempo o en algunos casos nunca se realizar<61>an.
\item \textit{Contribuci<63>n con la escritura de c<>digo fuente.} Algunos de los miembros de estas comunidades son empleados de compa<70><61>as que utilizan resultados de estos proyectos en sus productos comerciales, y dentro de sus intereses est<73> incluir en las distribuciones oficiales funcionalidades creadas por ellos.
\item \textit{Motivos profesionales.} Razones como reputaci<63>n, desarrollo de habilidades tienen una importancia relativamente baja en la creaci<63>n y contribuci<63>n de c<>digo. La mayor<6F>a expresa que su participaci<63>n busca conocimiento espec<65>fico del proyecto y no para adquirir habilidades espec<65>ficas; al trabajar con programadores m<>s experimentados se agudizan o expanden ciertas habilidades.
\item \textit{Disfrute y Entretenimiento} Un gran porcentaje de los participantes con mayor tiempo de permanencia manifiestan que esta actividad les proporciona un pasatiempo desafiante; curiosamente este tipo de participantes superan en n<>mero a los que se participan para suplir necesidades.
\end{itemize}
\begin{center}
\begin{table}[H]
\begin{tabular}{|m{1.8cm}|p{3cm}|p{3cm}|p{2.5cm}|p{2.5cm}|} \hline
\textbf{Motivo para crear} & \textbf{Motivo para contribuir} & \textbf{Nivel de participaci<63>n} & \textbf{No. relativo de participantes} & \textbf{Conocimiento del c<>digo y estructura} \\ \hline
\multirow{5}{*}[-2cm]{\textbf{\textit{Necesidad}}}
& Reciprocidad; normas & Bajo & Alto & Limitado al <20>rea del problema inicial \\\cline{2-5}
& Mejoras futuras & Variable, depende de la necesidad & Moderada & En el <20>rea del problema \\\cline{2-5}
& Deseo de integrar
c<>digo propio en el
c<>digo fuente & Moderado a alto & Bajo & Variable \\\cline{2-5}
& Motivos profesionales & Bajo & Muy bajo & variable \\\cline{2-5}
& No contribuye & Muy bajo & NA & Limitado al <20>rea del problema inicial \\ \hline
\textbf{\textit{Diversi<73>n y disfrute}}
& Realimentaci<63>n & Alto & Bajo & Comienza en un <20>rea determinada, y se expande \\ \hline
\end{tabular}
\caption{Motivaci<63>n de la participaci<63>n de desarrolladores en proyectos de softawre libre. Fuente \cite{SS06} } \label{compet_4}
\end{table}
\end{center}
Este estudio concluye que muchos miembros de estas comunidades ingresan para suplir necesidades, pero muchos de ellos continuan creando c<>digo porque disfrutan programar. Estos \textit{aficionados} realizan un papel muy importante dentro de la comunidad encarg<72>ndose de tareas como mejora de la plataforma tecnol<6F>gica, re-escribiendo secciones de c<>digo, documentandolo, respondiendo preguntas, preservar o mejorar la arquitectura. Otros consideran que la reciprocidad es vital para la contribuci<63>n de c<>digo a la comunidad y que la forma de gobierno afecta dram<61>ticamente la participaci<63>n de programadores voluntarios.
\begin{center}
\begin{table}[H]
\begin{tabular}{|m{2.8cm}|c|} \hline
\textbf{Mecanismos de Gobierno} & \textbf{Motivo para contribuir} \\\hline
\multicolumn{2}{|c|} {Toma de decisiones} \\\hline
\multirow{3}{*}[-2cm]{\textit{Control del C<>digo}
& Disminuye la \\\hline
\end{tabular}
\end{table}
\end{center}
\subsection{Atributos F<>sicos}
\subsection{ECB\_AT91, ECBOT, ECB\_BFIN} Plataformas realizadas para adquirir experiencia en el dise<73>o de sistemas embebidos
detectar las habilidades que se necesitan para realizar el proceso
\subsection{Proyecto Qi-Hardware}
% whatever form or technol-
% ogy the land-use model utilizes (e.g., a computer program, a statistical
% script, and so on), it should be placed under some license that allows the
% free copying of the model, requires the model ?source? to be readable,
% and permits the development of new derivative components of the model
% or other products related to the model. In some instances, the
% model developers might decide to make all related products (e.g., the
% model modules, their documentation, data, and even theoretical papers)
% fall under these conditions. However, there will be situations where more
% restrictive licensing is warranted. For instance, empirical papers describ-
% ing a particular application of a model would probably be licensed with
% a ?no derivative work? component, because these types of papers report
% findings from a particular study at a particular time.
%
% INTERNET INTERNET
% Clearly, the Internet, as a technological advance, is as important a
% ?structural change? to the way scientific advances are communicated and
% collaborated on as was the printing press. Digital storage has become so
% cheap that many treat the saving of a file on a hard disk as nearly cost-
% less. Advances like the web and e-mail software have greatly reduced the
% costs or skills required to access information on the Internet. Over the
% last five to ten years, the Internet has moved from a domain utilized pri-
% marily by high-skilled computer scientists, engineers, or others in the
% high-tech industries, to a system utilized by scientists and scholars in all
% disciplines. We are now in a shake-up period where traditional organi-
% zations chartered with the management of scientific information (e.g.,
% libraries, publishers) are developing new organizational models and mis-
% sions built around computer database and connectivity issues (see, for
% example, chapters 4 and 11 in this book). This environment, where
% digital files can be copied and transferred globally in an instant and at
% very little cost, makes it much easier to treat information or knowledge
% as a global public good. But as other contributors to this book describe,
% these advances in technology are directly at odds with other societal
% trends and developments in intellectual copyright law that are pushing
% to treat information and other digital products as private goods for mon-
% etary gain (see chapters 5 and 7).
%
% To promote the argument made in the opening paragraph of this
% chapter?that the collaborative ideals and principles applied in FOSS
% projects are potentially applicable to any collaboration built around
% intellectual property?I first provide an overview and summary of the
% FOSS software ?movement? and describe some critical project compo-
% nents. I use the Institutional Analysis and Development Framework
% described in chapter 3 to help guide the description of these projects.
% Next, I provide more detail on the argument that the FOSS collabora-
% tive principles and approaches can extend more broadly to scientific
% research in general. At this juncture, I introduce the more recent inno-
% vation of ?open-content? licensing. Using a short example in the scien-
% tific field of land-use change modeling, I then provide a discussion of
% some critical issues that will need to be addressed in order to transfer
% the collaborative principles of FOSS software commons to scientific-
% commons endeavors.