Índice general

1. Copyleft HW/SW y el Conocimiento Como Bien Común 3 1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. El Conocimiento Como Bien Común . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1. Auto-Gobierno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. FOSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Propiedad Intelectual y Licencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.4.1. Licencias Creative Commons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.5. Hardware Copyleft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5.1. Atributos de la Comunidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.5.2. Atributos Físicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.5.3. ECB AT91, ECBOT, ECB BFIN . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.5.4. Proyecto Qi-Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2 Sistemas Embebidos

Capítulo 1

Copyleft HW/SW y el Conocimiento Como Bien Común

1.1. 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 libertad de expresión, libre acceso y 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. 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 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 .^{a}daptació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 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.

1.2. 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[1]. 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.

1.2.1. Auto-Gobierno

Ostrom [2] 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 .^{em}ergen cuando se requiere el esfuerzo de dos o más individuos para cumplir con una meta”[3]. Otro aspecto importante de las acciones colectivas es que son voluntarias por parte de los individuos [4]. El autogobierno requiere de la acción combinada de conociminto y voluntad unido a normas institucionales consistentes.

Ostrom [5] y Baland and Platteau [6], consideran que los atributos necesarios para que un recurso tenga una probabilidad alta de crear asociaciones de autogobierno son:

Posibilidad de mejoramiento: El recurso no se encuentra en un punto tal que sea inútil crear una organización alrededor de él.

Indicadores: Disponibilidad de indicadores confiables y válidos sobre la condición del recurso.

Predictibilidad: El flujo de unidades de recurso es relativamente predecible.

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.

Y los atributos de los usuarios del recurso son:

Prominencia: Los usuarios dependen del recurso para una parte importante de su sostenimiento.

Entendimiento común: Conocimiento sobre el funcionamiento del sistema y como acciones individuales afectan a los demás y al sistema.

Baja Tasa de Descuento: Para obtener un mayor beneficio a futuro se deben mantener tasas bajas de descuento del recurso.

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.

Autonomía: Los usuarios pueden determinar reglas sin la intervención de autoridades externas

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.

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.

Ecuación Costo Beneficio de Ostrom

La pregunta que trata de responder Ostrom en su estudio es como emerge el auto-gobierno? [2] Para contestar esto formula una ecuación que describe el análisis costo-beneficio que un individuo realiza para participar en un gobierno comunal:

D < C (C1 + C2 + C3)

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)

D = BN − BO

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.

BN − BO > C
BN > BO + C

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 [7] [8] [9] 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 [10] 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.

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 [1] 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:

Fronteras claramente definidas Las reglas deben reflajar necesidades y condiciones locales.

Los individuos sujetos a estas reglas pueden modificar y participar en la elaboración de estas reglas.

Las autoridades externas deben respetar el derecho de los miembros de la comunidad a cear sus propias reglas.

Debe establecerse un sistema de seguimiento propio.

Disponibilidad de un sistema gradual de sanciones.

Acceso por parte de miembros de la comunidad a mecanismos de resolución de conflictos de bajo costo.

Las actividades de apropiación, suministro, monitoreo y sanción deben ser organizadas en estructuras anidadas con múltiples capas de actividades

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.

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 [11]:

BC > BN + C

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:

Herramientas de programación, depuración y librerías que facilitan el desarrollo de nuevas aplicaciones o mejoras a las ya existentes.

Listas de discusión en donde los creadores de estas herramientas responden preguntas, y buscan en conjunto soluciones a problemas específicos

Sistemas de control de versiones y protocolos de comunicación.

Bases de datos de solución de problemas asociadas a las listas de discusión.

Tutoriales, documentación, libros disponibles on-line.

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 Hadrware Copyleft

1.3. 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 software. El desafío de FOSS es realizar acciones colectivas para crear y mantener este bien público. A diferencia de la creencia popular, en este movimiento existen derechos de autor (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 [12] 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 1.1 se ilustra el marco definido por Ostrom y Hess [13] 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 [14], a mediados de los 80 inició un proyecto para desarrollar un sistema operativo abierto/libre basado en unix llamado GNU (GNU is Not unix).

Reglas En Uso

Stallman [15] sostiene que las propiedades digitales del software hacen posible considerarlo como un bien público, proporcionando a sus usuarios la libertad de utilizarlo, distribuirlo y modificarlo. Esta filosfía se basa en cuatro libertades que encarnan el principio copyleft:

Libertad de ejecutar el software para cualquier propósito.

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.

Libertad para re-distribuir copias.

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.

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 copyleft estipula que cualquier modificación que se le realice adquiere los principios de licenciamiento del software original. La licencia GPL^{1} (GNU General Public License) fue creada para implementar estos principios.

Figura 1.1: Marco para analizar el conocimiento como bien común aplicado al movimiento FOSS: Modificación de: [13] pág 46

El proyecto de código abierto liderado por Bruce Perens y Eric Raymond, utiliza las propiedades de la licencia GPL adicionando un grupo de 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 2 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 [16]. Las innovaciones del licenciamiento copyleft constituyen las 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 [17]. 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:

1http://www.gnu.org/licenses/licenses.html

2http://www.opensource.org/licenses/alphabetical

Priorización de características a incluir en nuevas versiones del software.

Definición de Reglas y procedimientos para evaluar y escoger nuevos aportes para que hagan parte de las nuevas versiones.

Definición de Reglas y procedimientos para detectar y corregir errores en el software.

Asignación y administración de tareas.

Asistencia en la resolución de disputas entre miembros del equipo.

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.

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 [18].

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 Linux Operating System [19] 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.

Atributos Físicos

Existen tres categorías [16] en FOSS que pueden ser consideradas como atributos físicos:

1. 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.

2. 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.

3. 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 svn, cvs y git) y la comunicación vía listas de discusión hace posible coordinar de forma eficiente los esfuerzos de cooperación. Permitiendo:

Almacenar versiones de software.

La descarga de módulos.

La adición de Nuevas contribuciones y la protección del código existente.

Generar un historial donde se documentan los cambios realizados a lo largo del tiempo.

Analizar funciones para identificar diferencias entre versiones.

Informar a los miembros del equipo cambios en los módulos del proyecto.

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.

1.4. 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 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.

1.4.1. Licencias Creative Commons

Creative Commons^{3} 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 [20]. 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?

3http://creativecommons.org/

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:

Atribución (BY): Se permite la distribución pero se debe dar crédito al autor.

No comercial (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

No a trabajos derivados (ND): Permite la copia y la distribución del trabajo original sin modificaciones.

Compartir de la misma forma (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.

1.5. Hardware Copyleft

En esta sección se relizará la definición del término hardware copyleft como una extensión del proyecto 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 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: “[21] 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 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.

1.5.1. Atributos de la Comunidad

El éxito de la iniciativa FOSS se debe en parte a la gran comunidad que comparte la ideología del software libre [22],sus miembros buscan: satisfacer necesidades propias [23], aprendizaje [24], reputación dentro y fuera de la comunidad, asociación e identidad [25], diversión y creatividad [26]. Para que la propuesta 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 [27] [28] 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 ??. 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:

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.

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.

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.

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.

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. Estos 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, documentando el código, respondiendo preguntas, preservar o mejorar la arquitectura.

1.5.2. Atributos Físicos

1.5.3. 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

1.5.4. Proyecto Qi-Hardware

Bibliografía

[1] Elinor Ostrom. Governing the Commons: The Evolution of Institutions for Collective Action (Political Economy of Institutions and Decisions) (Paperback). Cambridge University Press, November 1990.

[2] Elinor Ostrom. Reformulating the Commons. Swiss Political Science Review, Volume 6, Number 1, 2000.

[3] Sandler Todd. Collective Action: Theory and Applications. Ann Arbor: University of Michigan Press, 1992.

[4] Ruth Meinzen-Dick, Monica Di Gregorio, and Nancy McCarthy. Methods for Studying Collective Action in Rural Development. CAPRi Working Paper, no. 33. International Food Policy Research Institute, 2033 K Street, N.W., Washington, DC 20006. http://www.capri.cgiar.org/pdf/capriwp33.pd, 2004.

[5] E. OSTROM. The Rudments of a theory of the Origins, Survival, and Performance of Common-Property Institutions. BROMLEY, D.W. et al. (eds.) Making the Commons Work: Theory, Practice, and Policy. San Francisco, CA: ICS Press, 1992.

[6] J .M. BALAND and J.P. PLATTEAU. Halting Degradation of Natural Resources. Is There a Role for Rural Communities? Oxford: Clarendon Press, 1996.

[7] Motorola. MOTODEV Project. URL: http://developer.motorola.com/platforms/mobile-linux/.

[8] Google. Android Project. URL: http://www.android.com/.

[9] Nokia. Maemo Project. URL: http://www.maemo.org/.

[10] Free Software Foundation.  GNU General Public License.  URL:

http://www.gnu.org/copyleft/gpl.html.

[11] A. Cortesi.  Elinor Ostrom, the commons problem and Open Source.  URL:

http://corte.si/posts/opensource/ostrom/index.html, 2009.

[12] C. M Schweik and A. Semenov. The Institutional Design of ’Open Source’ Programming: Implications for Addressing Complex Public Policy and Management Problems. URL: http://www.firstmonday.org/issues/issue8 1/schweik/, 2003.

[13] Charlotte Hess and Elinor Ostrom, editors. Understanding Knowledge as a Commons: From Theory to Practice. The MIT Press, December 2006.

[14] Wikipedia. Richard Stallman. URL: http://es.wikipedia.org/wiki/Richard Stallman.

[15] R. M. Stallman. The GNU Operating System and the Free Software Movement Voices from the Open Source Revolution. O’Reilly and Associates, 1999.

[16] Charles M. Schweik. Understanding Knowledge as a Commons: From Theory to Practice, chapter Free/Open-Source Software as a Framework for Establishing Commons in Science. The MIT Press, 2006.

[17] S. Weber. The Success of Open Source. Harvard University Press, 2004.

[18] Van Wendel, R. Joode, J. A. de Bruijn, and M. J. G. van Eeten. Protecting the Virtual Commons: Self-Organizing Open Source and Free Software Communities and Innovative Intellectual Property Regimes. Asser Press, 2003.

[19] R. A. Ghosh, G. Robles, and R. Glott. Free/Libre and Open Source Software: Survey and Study. Technical report University of Maastricht, The Netherlands: International Institute of Infonomics. URL: http://www.infonomics.nl/FLOSS/report/index.htm, 2002.

[20] Creative Commons. Licencias Creative Commons. URL: http://creativecommons.org/licenses., 2004.

[21] M. odedra-straub. The Myths and Illusions of Technology Transfer. IFIP World Congress Proceedings, August 1994.

[22] R. Stallman. Philosophy of the GNU project. URL: http://www.gnu.org/philosophy/, 2007.

[23] J. Kuan.  Open source software as consumer integration into production.  URL:

http://hdl.handle.net/2038/1113, 2000.

[24] Hann I. H. Delayed Returns to Open Source Participation: An Empirical Analysis of the Apache HTTP Server Project. Workshop on Open Source Software: Economics, Law and Policy, Toulouse, France., 2002.

[25] G. Hertel. Motivation of software developers in Open Source projects: an Internet-based survey of contributors to the Linux kernel. Research Policy In Open Source Software Development, Vol. 32, No. 7, 2003.

[26] R. A. Ghosh, R. Glott, B. Krieger, and G. robles. Free/Libre and Open Source Software: Survey and Study. Deliverable D18: FINAL REPORT, 2002.

[27] S. Shah. Motivation, Governance, and the Viality of Hybrid Forms in Open Source Software Development. Management Science, July 2006.

[28] Kerstin Balka, Christina Raasch, and Cornelius Herstatt. Open Source Innovation: A study of openness and community expectations. DIME Conference, Milano, 2010.