368 lines
45 KiB
Plaintext
368 lines
45 KiB
Plaintext
\chapter{Copyleft HW/SW y el Conocimiento Como Bien Común}
|
|
\label{ch:common}
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%% El conocimiento como bien común %%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
\section{Introducción}
|
|
|
|
Es indudable que el desarrollo tecnológico de un país se encuentra ligado al mejoramiento de la calidad de vida de sus habitantes, y que para que un país en vía de desarrollo se realice una transferencia tecnológica (y de conocimientos asociados a la tecnología que se transfiere) exitosa que permita desarrollar productos similares, pero ajustados al contexto socio-económico local, es necesario que el país cuente con la capacidad de absorber las habilidades, técnicas, información y organización asociadas a dicha tecnología. Esta absorció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 él, debe ser un derecho y por lo tanto, la sociedad debe garantizar los mecanismos de difusión para que llegue a los sectores de la sociedad interesados en él. De igual forma, es un deber, de los sectores que utilizan este bien común contribuir a su difusión, actualización, mejoramiento, y crecimiento.
|
|
|
|
Un bien comú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ún esta asociado a la \textit{libertad de expresión}, \textit{libre acceso} y \textit{autogobierno}
|
|
|
|
El conocimiento en este trabajo se refiere a las ideas intangibles, información y datos de todo tipo en que el conocimiento es expresado u obtenido, como todo tipo de entendimiento adquirido a través de la experiencia o estudio ya sea propio, científico, académico o no académico. El conocimiento puede ser visto como una mercancía y como una fuerza constitutiva de la sociedad lo que evidencia la naturaleza compleja de este recurso, adicionalmente, la adqusición y descubrimiento de conocimiento es un proceso social y personal. \textit{El descubrimiento de conocimiento es un bien común y un tesoro que dejamoa a futuras generaciones y el reto de nuestra generación es en mantener los caminos del descubrimiento abiertos}.
|
|
|
|
El acceso al conocimiento debe garantizarse sin restricción alguna a las personas interesadas, al considerar el conocimiento como un producto comercial se limita su difusión favoreciendo a un grupo de la población, lo cual es inaceptable, ya que representa una forma de discriminación. En nuestro pais, el acceso a la información ha ido aumentando gracias a la aparició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és de un procesos de enseñanza formal. En Colombia el acceso a la educación superior de calidad es limitado, la cobertura de las Universidades públicas está limitada por la inversión del estado, y como pudimos ver anteriormente, en nuestro país la preocupación actual es la seguridad y no la educación. Por lo tanto, hacer del conocimiento un bien común requiere la intervenció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 énfasis en la transferencia y difusión del conocimiento, del \textit{saber hacer}, muchas políticas existentes se enfocan en la compra de equipo, lo que, como se vió antes no es el canal más eficiente para la transferencia tecnológica. Nuestros esfuerzos están enfocados a crear un conocimiento básico en la Concepción, Diseño, Implementación y Diseño de Sistemas Embebidos. Este conocimiento es el resultado de años de experimentación e investigación en el área, al ser colocado a disposición de usuarios interesados, se aumentan las posibilidades de difusión, ya que ya se realizó un trabajo previo de "adaptación" a las condiciones de la plataforma tecnológica local y al contexto econó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ón cobrando altos precios para acceder a ella.
|
|
|
|
En este capítulo estudiaremos las licencias \textit{Creative Commons} una nueva forma de licenciamiento que permite asignar diferentes "permisos" de utilizació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ó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ón de un movimiento que funcione con políticas similares pero centrado en el Desarrollo Hardware.
|
|
|
|
|
|
\section{El Conocimiento Como Bien Común}
|
|
El análisis del conocimiento como bien común tiene sus bases en el estudio de recursos naturales compartidos (agua, bosques, fauna, flora). El recurso puede ser pequeñ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ósfera, internet, conocimiento científico, etc), puden ser delimitados (la librerí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ún como un recurso o sistema de recursos y el bien común como un régimen de derechos de propiedad\cite{EO90}. El conocimiento posee caracterí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ún es lograr su máxima difusión. El beneficio asociado al acceso a la informació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ños. Para que este recurso sea útil se requiere una infra-estructura que permita su difusión, actualización, mejoramiento, realimentació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áficos?
|
|
Como coordinar acciones de miles de usuarios para garantizar un recurso útil y sostenible? Como convertir este conocimiento en motor de Desarrollo y crecimiento empresarial? Estas preguntas serán respondidas a lo largo de este capítulo.
|
|
|
|
\subsection{Auto-Gobierno}
|
|
|
|
Ostrom \cite{Ost00} argumenta que la forma más eficiente de administrar un bien comú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ón o decisión que se haga es formulada pensando en el beneficio común se creará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ó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útil crear una organización alrededor de él.
|
|
\item Indicadores: Disponibilidad de indicadores confiables y válidos sobre la condición del recurso.
|
|
\item Predictibilidad: El flujo de unidades de recurso es relativamente predecible.
|
|
\item El recurso es lo suficientemente pequeño, teniendo en cuenta las tecnologías de comunicació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ún: Conocimiento sobre el funcionamiento del sistema y como acciones individuales afectan a los demá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ían en que los demás mantendrán las promesas y se relacionarán entre ellos con reciprocidad.
|
|
\item Autonomía: Los usuarios pueden determinar reglas sin la intervención de autoridades externas
|
|
\item Experiencia Previa en Organización y Liderazgo Local: Los usuarios poseen habilidades mínimas de organización y liderazgo a través de la participació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ó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ún, un grupo de estas normas debe establecer mecanismos de resolución de conflictos, esto es vital ya que toda la organizació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 éxito de sus acciones y el sostenimiento del recurso depende de sus acciones, las cuales deben realizarse teniendo en cuenta el beneficio común. El conocimiento no se ve afectado por la sustracció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 área de la Electrónica digital) y por lo tanto inservible, para que esto no suceda se requiere de la actualización de este conocimiento para que refleje el estado actual en un área determinada.
|
|
|
|
\subsubsection{Ecuació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ón que describe el aná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ó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ón entre sub-grupos de usuarios, esta ecuació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án participando y promoviendo el desarrollo de productos y aplicaciones \cite{Mot} \cite{And} \cite{Mae} con la participación de la comunidad, lo que representa un giro de 180 grados en la políticas lideradas por multinacionales como Microsoft y Aple en las que todas sus creaciones están protegidas por licencias, acuerdos comerciales y contratos de exclusividad que restringen la participació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í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ón los grandes multinacionales está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ño}
|
|
|
|
El primer paso para gobernar un bien común es la identificación de los principios de diseño de un recurso común robusto de larga duración. Ostrom \cite{EO90} después de dirigir un gran número de estudios empíricos sobre gobernancia de recursos de bienes comúnes. Encontró una serir de principios de diseñ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ó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ón de conflictos de bajo costo.
|
|
\item Las actividades de apropiación, suministro, monitoreo y sanción deben ser organizadas en estructuras anidadas con múltiples capas de actividades
|
|
\end{itemize}
|
|
|
|
Es importante mencionar que no existe una combinación de principios que garantice el é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ía de las instituciones analizadas en cientos de estudios y constituyen un buen punto de partida para comenzar esta investigació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ún, ya que es un recurso comunal que prospera o decae gracias a la contribució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í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ón modificada de la ecuació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ó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ño, proporcionando:
|
|
|
|
|
|
\begin{itemize}
|
|
\item Herramientas de programación, depuración y librerías que facilitan el desarrollo de nuevas aplicaciones o mejoras a las ya existentes.
|
|
\item Listas de discusión en donde los creadores de estas herramientas responden preguntas, y buscan en conjunto soluciones a problemas específicos
|
|
\item Sistemas de control de versiones y protocolos de comunicación.
|
|
\item Bases de datos de solución de problemas asociadas a las listas de discusión.
|
|
\item Tutoriales, documentació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ñ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ón de \textit{Hadrware Copyleft}
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%% FOSS %%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\section{FOSS}
|
|
|
|
Como se mencionó anteriormente, el movimiento FOSS es la estructura auto-gobernada más exitosa y será tomada como referencia en el desarrollo de nuestra iniciativa de Hardware Copyleft. Su principal innovación radica en un nuevo esquema de licencias unido a herramientas de colaboración basadas en Internet, lo que se cnvirtió en una nueva forma de bien común, donde los miembros de forma colectiva generan un buen común el \textit{software}. El desafí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ón de acción" que estos programadores encaran es, si en algún momento, vale la pena contribuir al desarrollo de este software. La interació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ú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ón), estabilización donde el número de participantes (normalmente pequeño) no varía, o el protecto se estanca y muere (sin participantes). Para que un proyecto sea exitoso, no es necesaria la participación de un gran número de programadores, es frecuente encontrar grupos pequeños de programadores con un gran número de usuarios. La clave del éxito está en la disponibilidad de un programador para contribuir al esfuerzo colectivo de por lo menos un pequeñ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ún, aplicado al movimiento FOSS. Como se mencionó anteriormente, el razgo que diferencia este movimiento es la utilización de una forma de licenciamiento especial. Richard Stallman \cite{Wikb}, a mediados de los 80 inició 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ía se basa en cuatro libertades que encarnan el principio \textit{copyleft}:
|
|
|
|
\begin{itemize}
|
|
\item Libertad de ejecutar el software para cualquier propó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ó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ón para esto.
|
|
\end{itemize}
|
|
|
|
Esta filosofía permite que los conocimientos y habilidades que el programador posee puedan ser transferidas a programadores, empresas, instituciones académicas y sociedades, ya sea en forma de producto o como herramienta de enseñanza. Esta actividad representa un proceso de Transferencia Tecnológica, en la que el que suministra la tecnología proporciona todos los medios para que el receptor pueda abosrverla y transformarla para satisfacer necesidades en su entorno social. Adicionalmente, Stallman ideó 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ó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ún aplicado al movimiento FOSS: Modificació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í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ún.
|
|
|
|
La clave para mantener un bien comú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ón, normas implícitas y explí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ían incluir:
|
|
|
|
\begin{itemize}
|
|
\item Priorización de características a incluir en nuevas versiones del software.
|
|
\item Definición de Reglas y procedimientos para evaluar y escoger nuevos aportes para que hagan parte de las nuevas versiones.
|
|
\item Definición de Reglas y procedimientos para detectar y corregir errores en el software.
|
|
\item Asignación y administración de tareas.
|
|
\item Asistencia en la resolución de disputas entre miembros del equipo.
|
|
\end{itemize}
|
|
|
|
Estas reglas varí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ó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ógicos, sociopolíticos, económicos y académicos. Desde el punto de vista tecnológico, resulta más efectivo en tiempo y en dinero, participar en un proyecto conjunto para la realización de una aplicación que satisface una determinada necesidad. La principal motivación sociopolítica es la creencia por parte del programador en la filosofí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ómicas y académicas pueden ser consideradas en forma conjunta ya que al participar en estos proyectos, los miembros adquieren o mejoran sus habilidades de programación ya sea revisando, leyendo y entendiendo el código existente o sometiendo a la revisión de los demás miembros sus contribuciones. Por otro lado, esta participació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ón es una forma de inversión y una forma de ganar experiencia y reputación \cite{VWJ+03}.
|
|
|
|
En proyectos con un gran número de personas asociadas, solo un pequeño porcentaje de ellos realizan la mayor parte del trabajo. En la actualidad muchas empresas está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ón a participar es el interes propio en estandarización, disminució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í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ú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ño o la estructura del software. Un código limpio (optimizado, documentado y óptimo) y modularizado permite el trabajo en paralelo, lo que reduce el tiempo de depuración y el requerido para implementar nuevas características.
|
|
\item La infraestructura que hace posible coordinar y administrar la colaboración y la producción: El uso de Internet para soportar herramientas de control de versiones (como \textit{svn}, \textit{cvs} y \textit{git}) y la comunicación vía listas de discusión hace posible coordinar de forma eficiente los esfuerzos de cooperación. Permitiendo:
|
|
\begin{itemize}
|
|
\item Almacenar versiones de software.
|
|
\item La descarga de módulos.
|
|
\item La adición de Nuevas contribuciones y la protecció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ón, los proyectos FOSS evolucionan en el tiempo como resultado de la configuració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ón y herramientas efectivas para coordinació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ón de hardware) es necesario ampliar el término \textit{copyleft} de Stallman. El primer en esta dirección fué dado por el mismo Stallman al desarrollar la licencia GFDL (GNU Free Documentation License) aplicable a todo tipo de documentación técnica, guias de usuario, tutoriales, etc. Esta licencia gobierna el uso, modificación y distribución de la documentació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ón.
|
|
|
|
|
|
\subsection{Licencias Creative Commons}
|
|
|
|
Creative Commons \footnote{http://creativecommons.org/} organización no gubernamental sin á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ón, con la única condición de dar cré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ón} (\textbf{BY}): Se permite la distribución pero se debe dar crédito al autor.
|
|
\item \textit{No comercial} (\textbf{NC}): Se permite la distribución del trabajo sin fines comerciales, si se desea utilizar este trabajo para obtener dinero es necesaria una autorización del autor
|
|
\item \textit{No a trabajos derivados} (\textbf{ND}): Permite la copia y la distribució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ón se relizará la definición del término \textit{hardware copyleft} como una extensión del proyecto \textit{FOSS}. Una de las hipótesis manejadas durante el desarrollo de este trabajo es que el conocimiento debe ser considerado como un bien comú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ógica y de conocimientos exitosa a la academia y a la industria electrónica nacional (en el área de sistemas digitales) se utilizará el principio del conocimiento como bien comú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ó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án diseñados para ejecutar una función única, por lo que el componente hardware se encuentra optimizado (funcionalidad, tamaño, consumo de potencia, costos) para la ejecución de dicha tarea. Como se mencionó anteriormente existe un movimiento muy fuerte (FOSS) que proporciona una gran variedad de herramientas para la implementación del componente software. Sin embargo, hasta el momento no existe un movimiento similar dirigido al desarrollo del componente hardware. Mi hipótesis es que un movimiento de hardware abierto permitirá el desarrollo de la industria electrónica local permitiendo la transferencia exitosa de tecnología y conocimientos en el área de diseño de sistemas embebidos.
|
|
|
|
Haciendo una analogía con el movimiento FOSS, la iniciativa \textit{hardware copyleft} permitiría el uso, distribución, y modificación de proyectos hardware existentes. La acción de modificación se origina por una necesidad que se debe satisfacer, implica un entendimiento del principio de funcionamiento y del proceso de fabricación asociados al proyecto original. Lo anterior cumple con la definición de transferencia tecnoló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ógica se considera exitosa cuando los receptores de la tecnología asimilan los conceptos anteriores para suplir sus necesidades locales''.
|
|
|
|
El reto en la definició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ón para modificar un proyecto existente ; los proyectos hardware involucran procesos de fabricación, montaje y pruebas que tienen asociados unos costos que varían dependiendo de la tecnologí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ómico en la formación de la comunidad, definiendo las características que deben poseer estos proyectos para minimizar el costo asociado.
|
|
|
|
|
|
\subsection{Atributos de la Comunidad}
|
|
|
|
El éxito de la iniciativa \textit{FOSS} se debe en parte a la gran comunidad que comparte la ideología del software libre \cite{RS07},sus miembros buscan: satisfacer necesidades propias \cite{JK00}, aprendizaje \cite{HIH02}, reputación dentro y fuera de la comunidad, asociación e identidad \cite{GH03}, diversió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ó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ón inicial para la participació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ó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ó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ó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ían mucho tiempo o en algunos casos nunca se realizarían.
|
|
|
|
\item \textit{Contribución con la escritura de código fuente.} Algunos de los miembros de estas comunidades son empleados de compañías que utilizan resultados de estos proyectos en sus productos comerciales, y dentro de sus intereses está incluir en las distribuciones oficiales funcionalidades creadas por ellos.
|
|
|
|
\item \textit{Motivos profesionales.} Razones como reputación, desarrollo de habilidades tienen una importancia relativamente baja en la creación y contribución de código. La mayoría expresa que su participación busca conocimiento específico del proyecto y no para adquirir habilidades especí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ó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 área del problema inicial \\\cline{2-5}
|
|
& Mejoras futuras & Variable, depende de la necesidad & Moderada & En el á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 área del problema inicial \\ \hline
|
|
\textbf{\textit{Diversión y disfrute}}
|
|
& Realimentación & Alto & Bajo & Comienza en un área determinada, y se expande \\ \hline
|
|
\end{tabular}
|
|
\caption{Motivación de la participació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ándose de tareas como mejora de la plataforma tecnoló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ón de código a la comunidad y que la forma de gobierno afecta dramáticamente la participació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ñ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.
|
|
|
|
|
|
|
|
|
|
|