Página principal |
PARA TENER EN CUENTA
1.- Recensión: Roadmap for Open ICT Ecosystems. The Berkman Center for Internet & Society at Harvard University, with the support of IBM Corporation and Oracle, 2007 Texto completo: http://cyber.law.harvard.edu/epolicy/roadmap.pdf Mientras la potencia transformadora de la tecnología es fuente de grandes expectativas y desafíos, la apertura (openess) en ecosistemas de TIC se constituye en un factor catalizador para alcanzar niveles sin precedentes de competitividad, innovación, desarrollo social y oportunidades de mercado. El Berkman Center for Internet & Society de la Harvard University; con el apoyo de IBM Corporation y de Oracle, patrocinó la elaboración del Mapa de Ruta para Ecosistemas Abiertos de TIC, cuyos propósitos centrales son: a) proporcionar -a formuladores de políticas, actores e interesados de la industria y de la sociedad civil- una herramienta de uso fácil para entender qué son los ecosistemas abiertos de TIC, por qué adoptarlos y cómo desarrollarlos, y b) inducir un cambio en la visión, gestión e innovación en ecosistemas de TIC. Para ello, el equipo de trabajo debió reunir perspectivas globales, conocimientos empíricos y experiencias directas en actividades como desarrollo de arquitecturas TIC, establecimiento de políticas gubernamentales y estudio de tendencias tecnológicas globales. Con tal finalidad, en febrero de 2005 se constituyó el Grupo de ePolicy Abierta (Open ePolicy Group), fundado y dirigido por Jeff Kaplan, con miembros de todas las regiones del mundo, para compartir visiones de gobiernos, compañías y organizaciones en la vanguardia de la tecnología global. En el actual escenario de apertura, globalización, Internet y flujos masivos de información que transforman nuestras economías, comunidades y vidas personales, se intensifica la presión sobre gobiernos y negocios para cubrir las demandas emergentes de servicios cliente-céntricos y de información en tiempo real. Para responder a las crecientes presiones, las agencias gubernamentales deben ser más eficientes y las economías e industrias deben tornarse más innovadoras y competitivas. Casi por necesidad, se desarrolla una nueva apertura que abre la oportunidad de alcanzar niveles inéditos de eficacia, estandardización y flexibilidad para propulsar la transformación de gobiernos y negocios. La creciente concreción del concepto de “apertura”, que sintetiza creatividad, colaboración, conectividad, acceso y transparencia, está revolucionando las formas de comunicamos, conectamos y competir. Asimismo induce un replanteo de los ecosistemas TIC, de las estrategias de re-ingeniería gubernamental, de reformulación de modelos comerciales y de provisión de servicios a la medida de las necesidades particulares de los ciudadanos. El Mapa de Ruta apunta a: a) inducir una clara visión de que la evolución hacia ecosistemas abiertos de TIC es decisiva e imprescindible para lograr transformaciones sustanciales en la gestión de lo más diversos sectores de actividad gubernamental, social, productiva y comercial, b) difundir un sistema coherente de principios, de buenas prácticas y de estudios de caso que puedan ayudar a crear y a sostener ecosistemas abiertos de TIC, y c) ayudar a quienes deciden a comprender mejor los ecosistemas TIC abiertos y a asegurar que sus procesos decisorios se desarrollen en contextos más transparentes y colaborativos. El Mapa de Ruta define a un ecosistema TIC como abierto cuando es capaz de incorporar y sustentar interoperabilidad, desarrollo colaborativo y transparencia, permitiendo crear aplicaciones de TIC flexibles y orientadas al servicio, que pueden operar de modo independiente y recombinarse, de manera eficiente y efectiva, para responder a necesidades cambiantes. La construcción de un ecosistema abierto de TIC –con sus tecnologías y su ambiente de estándares, gestión, relaciones entre actores, marco legal y macroeconómico, investigación y desarrollo- debe cimentarse en los siguientes principios rectores: Interoperable: permitir, mediante estándares abiertos, el intercambio, la reutilización y la interpretación de datos a través de arquitecturas diversas. Usuario-Céntrico: priorizar servicios que satisfagan exigencias del usuario por encima de las restricciones de hardware y software. Colaborativo: permitir a gobiernos, industria y otros actores crear, desarrollar y mantener comunidades de interesados que puedan aunar fuerzas, solucionar problemas comunes, innovar y construir sobre lo existente. Sostenible: aunar equilibrio y resiliencia en la gestión de cuestiones organizativas, técnicas, financieras y legales para que el ecosistema prospere y se desarrolle. Flexible: adaptarse de manera transparente y rápida a nueva información, tecnología, protocolos y relaciones, e integrarlas legítimamente en los procesos. El Mapa de Ruta considera que un estándar es abierto cuando cumple con las siguientes características: a) no puede ser controlado por ninguna persona o entidad interesada, sino por el conjunto; b) desarrollado y gestionado en un proceso transparente y abierto a todas las partes interesadas; c) independiente de la plataforma, neutral al vendedor y usable en múltiples implementaciones; d) publicado de manera abierta, incluyendo especificaciones y material de apoyo; e) disponible sin licencias o a un coste mínimo y sus eventuales restricciones son razonables y no discriminatorias; y f) aprobado con el debido proceso por estricto consenso entre los participantes. Los estándares abiertos son formulados por organizaciones y consorcios como Internet Engineering Task Force (IETF), World Wide Web Consortium (W3C) y Organization for the Advancement of Structured Information Standards (OASIS), así como por cuerpos formales de estandarización, tales como el American National Standards Institute (ANSI) y el International Organization for Standardization (ISO). Para dichas organizaciones, la apertura permite que cualquier parte interesada aporte a las propuestas, lo que facilita las decisiones consensuadas. Los procesos de formulación de estándares abiertos no requieren necesariamente la intervención de gobiernos, pero en ningún caso éstos pueden ser excluidos, pudiendo participar -como cualquier parte interesada- en procesos controlados por la comunidad. Los estándares abiertos no necesariamente implican software con código fuente abierto. Sin embargo, los estándares abiertos y los códigos abiertos comparten un terreno común: ambos resultan de un proceso colaborativo orientado a la comunidad, en el cual cualquier persona puede contribuir y tener acceso al producto final, ya sea a especificaciones del estándar o al código fuente. Por otra parte, se verifica una relación de complementariedad y sinergia en la implementación de un estándar abierto en fuente abierta. (Reseñó José Luis Tesoro, Jul. 2009)
2.- Oferta de software: taxonomía usada en este Boletín Una revisión de la literatura relativa a modelos de oferta de software permite apreciar cierta ambigüedad en las tipologías de software (propietario, libre, de código abierto, gratuito, entre otras). En este número del Boletín se ha optado por distinguir -en función de las facultades asignadas al usuario- tres tipos de software: a. software privativo, donde el usuario tiene como única facultad la utilización del producto tal como se lo ofrece el proveedor; sin poder adaptarlo a sus necesidades, ni modificarlo, ni redistribuirlo. Este tipo de software no siempre tiene un precio por licencia. Como bien sabemos, muchas empresas de software privativo permiten, por razones diversas, el uso gratuito de ciertas versiones de sus productos, pero siempre bajo una licencia privativa. b. software de código abierto, en que el proveedor provee al usuario acceso al código fuente con la facultad de revisarlo y, en algunos casos -con la autorización pertinente- de proceder a determinadas adecuaciones a sus necesidades específicas. Un software de este tipo puede ser privativo. c. software libre, el creador lo pone a disposición de la comunidad con código abierto, reconociendo al usuario las siguientes “libertades”: i) usarlo con cualquier propósito, ii) estudiar cómo funciona, modificarlo y adaptarlo a sus propias necesidades, iii) distribuir copias, y iv) mejorarlo y hacer públicas esas mejoras. Con base en esta tipología, sugerimos: b. No confundir software libre con software de código abierto, dado que el software libre es un movimiento social, mientras que el segundo es una metodología de desarrollo y provisión. c. No usar la categoría software propietario, dado que es imprecisa (ya que todo software tiene un propietario). Resulta más preciso distinguir entre software libre y software privativo, lo cual deja claro que las licencias del último tipo privan al usuario del conjunto de “libertades” que el software libre le reconoce. (reseñó José Luis Tesoro)
3.- El software libre en el Gobierno Federal de Brasil El software libre es una opción estratégica del Gobierno Federal Brasileño porque reduce costos, amplia la concurrencia, genera empleos y desarrolla el conocimiento y la inteligencia del país en esa área. Una de las principales iniciativas es la del “Portal do Software Público Brasileiro” (www.softwarepublico.gov.br) que inauguró un nuevo modelo de licenciamiento y de gestión de soluciones desarrolladas en la Administración Pública. Lanzado hace más de dos años, el portal congrega hoy a más de 40 mil usuarios y 22 soluciones libres, auxiliando a los órganos públicos de todas las esferas y poderes, empresas y sociedad civil en el desarrollo compartido de software. La mayor parte de las autoridades gubernamentales brasileñas coinciden en continuar apostando al software libre como una oportunidad colectiva para impulsar y potenciar la innovación tecnológica como país soberano. Por ejemplo, durante el 10º Foro Internacional de Software Libre (FISL10) realizado en Porto Alegre entre el 24 y 27 de Junio de 2009, el primer mandatario Luiz Inácio “Lula” da Silva reafirmó al software libre como política de Estado expresando, entre otros conceptos: “(…) Ahora que el plato está hecho, es muy fácil que lo comamos. Pero hacer ese plato no fue fácil. Recuerdo la primera reunión que hicimos en la Granja do Torto, en la que yo no entendía absolutamente nada del lenguaje que hablaba esta gente y había una tensión enorme entre aquellos que defendían la adopción de Brasil del Software Libre y aquellos que creían que nosotros debíamos hacer las mismas cosas de siempre, mantenernos de la misma forma, comprando, pagando por la inteligencia de otros. Y gracias a Dios, prevaleció en nuestro país la cuestión y la decisión del Software Libre. Teníamos que elegir: o íbamos a la cocina a preparar el plato que iríamos a comer, con los condimentos que nosotros le queríamos poner para darle un gusto brasileño a la comida, o íbamos a comernos aquello que Microsoft quería vendernos. Prevaleció, sencillamente, la idea de libertad. Quisiera contarles aquí algo: por qué prevaleció, en mi cabeza, la idea del Software Libre. (…) Cuando cayó el muro de Berlín, me puse contento porque permitiría que la juventud pudiese repensar y escribir cosas nuevas, crear nuevas teorías, porque parecía que todo estaba ya construido y que nada más podría ser diferente. El Software Libre es un poco de eso, o sea, es darles a las personas la oportunidad de hacer cosas nuevas, de crear cosas nuevas, de valorizar la individualidad de las personas. Porque no hay nada que garantice más la libertad que si uno garantiza la libertad individual, que las personas permitan aflorar su creatividad, su inteligencia, sobre todo en un país nuevo como Brasil, cuyo pueblo posiblemente sea, sin ningún menosprecio a otros pueblos, el de mayor creatividad en el siglo XXI. Bueno, pienso que nuestro gobierno ya ha hecho mucho, pero que se podría haber hecho más. (…) La maquinaria pública es algo complicada; está llena de vicios, de normas, que vienen desde la época del Imperio. Para ir cambiando esas cosas, un burócrata tiene un manual, y el manual solo dice lo que se puede y lo que no se puede. Si le muestras algo nuevo, está prohibido. Él no es capaz de decir “bueno, tenemos algo nuevo por acá, voy a tratar de intermediar”, ¡no!; él sólo te dice qué se puede o qué no se puede. Y todo eso tomó tiempo para que el gobierno empezara a crear las condiciones para llegar al nivel al cual llegamos (…) el Software Libre es una posibilidad para reinventar cosas que necesiten ser reinventadas. ¿Qué hace falta? Oportunidad. Estén seguros de algo, compañeros, que en este gobierno está prohibido prohibir. (…) Porque este país aun se está encontrando consigo mismo, porque durante siglos fuimos tratados como ciudadanos de tercera clase, teníamos que pedir permiso para hacer las cosas, solamente podíamos hacer las cosas que los Estados Unidos o Europa nos permitieran. Ahora nuestra autoestima está alta. Aprendimos a confiar en nosotros mismos. Estamos descubriendo que podemos hacer las cosas. Estamos descubriendo que nadie es más que nosotros. Pueden ser iguales, pero no mejores, no tienen más creatividad que nosotros. ¡¡Lo que necesitamos es la oportunidad!!”.
4.- Recensión: Enter-IE (2207): Modelo económico del software, Noviembre 2007 Informe de ENTER IE cuyo propósito es mostrar, a través del análisis de datos empíricos, las fortalezas y debilidades de los dos modelos de negocio que hoy conviven en el mercado del software: software privativo y software libre. Comienza resaltando las características económicas de la producción de software: a) costes fijos elevados y “hundidos” en diseño y desarrollo, b) costes marginales prácticamente nulos en réplica y distribución, c) economías de escala, y d) altos niveles de riesgo. Señala que el valor de un producto de software deriva de su utilidad intrínseca; es decir, qué hace, con qué calidad y qué efecto positivo genera su uso. Pero, además, existe un efecto de red: el tamaño del parque de usuarios de un determinado software incrementa las oportunidades de utilizarlo, así como la calidad esperable del mantenimiento (reparación de errores o fallas), de la actualización (crecientes capacidades para afrontar nuevas necesidades) y del apoyo técnico; aumentando así su valor real y percibido. Expresa que uno de los mitos más extendidos es que el sub-sector del software comercial es un oligopolio de facto, mientras que un análisis comparativo muestra que –en relación a otros sectores- exhibe una concentración de nivel medio. 4.1.- Los modelos de negocio: software privativo y software libre En esta sección sintetizaremos las características y las evidencias empíricas presentadas en el informe acerca de las fortalezas y debilidades de los dos modelos de negocio dominantes en el mercado: el de Software Privativo (en adelante SP) y el de Software Libre (en adelante SL). a.- Derechos de propiedad sobre los desarrollos: los oferentes de SP preservan los derechos de propiedad sobre sus diseños y desarrollos, lo que resulta -a través de la explotación comercial- en una rentabilidad que incentiva la inversión, la investigación y la innovación. Por el contrario, en el SL todos los desarrollos están abiertos para su utilización, modificación, adaptación y difusión. b.- Móviles e intereses: los oferentes de SP tienen una nítida vocación comercial, mientras que los de SL exhiben orientaciones menos claras, ligadas a intereses propios de los desarrolladores (por ejemplo: prestigio dentro de la comunidad de creadores de software) más que intereses mercantiles. c.- Herramientas de coordinación: los oferentes de SP tienen al mercado como ámbito de coordinación entre oferta y demanda de sus productos, mientras que una tendencia frecuente entre los oferentes de SL es el ejercicio de una ambigua coordinación autónoma. d.- Orientación para el desarrollo del software: de acuerdo con su vocación comercial, los oferentes de SP procuran satisfacer las necesidades y preferencias de clientes y usuarios, mientras que los oferentes de SL suelen asignar prioridad a intereses personales de los desarrolladores, aun en detrimento de características fundamentales para el usuario final. e.- Motor de la innovación: Los oferentes de SP procuran innovar para obtener beneficios económicos, gracias a los derechos de propiedad. En los oferentes de SL pesan en mayor medida los intereses personales de los desarrolladores. f.- Costo de uso: Los defensores de SL difunden la creencia de que el SL es menos costoso que el SP. Ello resulta de una comparación que sólo incorpora el coste de las licencias, dejando de lado los costes vinculados a la adopción, utilización y mantenimiento de SL -tales como consultoría y asistencia técnica, modificación de hardware y software, entrenamiento de personal especializado y de personal de la organización, aplicaciones compatibles con el nuevo sistema- los cuales, analizados en un escenario de medio o largo plazo, suelen ser mucho más elevados que el coste de las licencias por SP. g.- Revisión del software: Los productos de SL, dada la apertura del código fuente, son revisados por un número mayor de individuos, pero de manera descoordinada, en función de los focos de atención de cada programador. Los productos de SP son sometidos, en general, a revisiones más ordenadas, estructuradas y sistemáticas. h.- Corrección de fallos: Los procesos de corrección de fallos son más rápidos con SL, ya que al disponer de acceso al código fuente, los programadores pueden realizar directamente correcciones. En el caso del SP, las correcciones son más lentas puesto que, tras la detección de los fallos y su comunicación al propietario, éste debe acometer las modificaciones y difundirlas en el mercado. Sin embargo, las garantías de compatibilidad del software corregido en diferentes entornos de hardware son mayores en el caso del SP, puesto que el proceso está centralizado y existe riesgo comercial en caso de no proveer una solución satisfactoria. i.- Adaptación a requerimientos particulares: Comúnmente se señala que el SL, dada la posibilidad de modificar el código fuente, es más adaptable que el SP. Sin embargo, es exigua la fracción de usuarios que disponen de expertos capaces como para beneficiarse de la adaptabilidad. j.- Sencillez y usabilidad: Por razones de mercado, los oferentes de SP asignan alta prioridad a la sencillez y usabilidad de sus productos en beneficio del usuario-cliente final, así como a la provisión de la documentación relacionada con las características y el uso del producto. Los oferentes de SL manifiestan comúnmente ciertas deficiencias en estos aspectos. k.- Estandarización de los productos: El SP exhibe una alta estandarización y ausencia de fragmentaciones, lo que facilita la compatibilidad en diferentes entornos de hardware y garantiza la disponibilidad de drivers y actualizaciones regulares. En el SL, donde las mejoras, versiones y actualizaciones de programas se realizan de forma descentralizada, se corre el riesgo de que se generen versiones de programas no compatibles entre sí. l.- Aplicaciones compatibles: El campo del SP presenta una enorme gama de aplicaciones compatibles, así como la garantía de que dichas aplicaciones funcionarán correctamente en diferentes configuraciones de hardware. m.- Expansión del conocimiento: Se señala que el SL promueve la expansión del conocimiento dentro de la comunidad de especialistas, como fruto de la ausencia de derechos de propiedad y de la posibilidad de acceder al código fuente. Sin embargo, también se señala que, precisamente por la ausencia de derechos de propiedad, el SL puede desembocar en desincentivos a la producción del conocimiento que se materializa en el software. n.- Distinción profesional: El SL permite que los ingenieros y programadores sean reconocidos –en función de sus contribuciones- dentro de la comunidad de software. Al no existir incentivos económicos expresos, ese reconocimiento es, en muchos casos, la motivación central para el desarrollo. o.- Compensación económica: Respecto de la compensación económica directa de los ingenieros y programadores, por el tiempo y esfuerzo dedicados a la creación, el SP tiene neta ventaja sobre el SL. 4.2.- Los modelos de negocio y las administraciones públicas En esta sección se reseñan los argumentos con los que promotores y defensores del modelo SL reclaman a las administraciones públicas una preferencia por el SL, así como las respectivas refutaciones señaladas en el informe: a.- Movilización de la economía y generación de empleo: Se afirma que la administración pública debe privilegiar al SL porque es más efectivo para movilizar la economía y generar empleo. Sin embargo, la realidad muestra que el SP desempeña un relevante papel como impulsor del crecimiento económico y motor de productividad. Por otra parte, varios estudios ponen de manifiesto la significación del efecto multiplicador del SP tanto en términos de empleo como de facturación. El informe exhibe datos sobre empleo asociado a la creación, venta, distribución, mantenimiento o prestación de servicios relacionados con SP, así como la cantidad de unidades monetarias que reciben los diversos actores por cada unidad que factura el proveedor. b.- Estímulo de la competencia: Se sostiene que el apoyo de la administración pública al SL permite estimular la competencia en el mercado, al ofrecer oportunidades a nuevos actores para desarrollar sus productos. Al respecto, cabe señalar que la manera más efectiva en que la administración pública puede estimular la competencia es eligiendo el mejor producto de software, de acuerdo a criterios objetivos basados en sus necesidades y en el coste. Por otro lado, la evidencia empírica muestra que en el mercado del software ya existe competencia y que el SL goza ya de elevadas cuotas de mercado en aquellos ámbitos en los que exhibe mayor competitividad, sin necesidad de intervenciones de la administración pública. c.- Apoyo a la industria nacional: Se señala que el apoyo de la administración pública al SL permite un desarrollo de la industria nacional que no resultaría factible sin protección. Además de que este principio resulta difícil de compatibilizar con el de defensa de la competencia, cabe tener en cuenta que, con el argumento de proteger temporalmente a la industria nacional, se cometen graves errores al eliminar incentivos para el desarrollo de capacidades competitivas, en detrimento de la calidad del servicio al ciudadano. d.- Promoción de la innovación: Se sostiene que, al apoyar al SL, la administración pública promueve la innovación. Sin embargo, hasta la fecha y salvo escasas excepciones, la actividad fundamental de los creadores de SL ha sido desarrollar versiones gratuitas de SP que ya estaba en el mercado. La realidad del mercado indica que la gran mayoría de las ideas innovadoras se desarrollan en SP, con el motor permanente de la rentabilidad económica. e.- Motivaciones ideológicas: Se sostiene que el optar por el SL libera a la administración pública de la cautividad respecto de las estrategias comerciales de las corporaciones multinacionales líderes en SP, en beneficio de la soberanía y la seguridad nacional, la libertad de los ciudadanos y la democracia. El informe señala que esta idea resulta -cuanto menos- paradójica, ya que los mecanismos del mercado han facilitado y permitido ejercer la defensa de las libertades a todos los agentes. Por otra parte, el hecho de que un proveedor sea multinacional implica: i) que sus productos son aceptados por usuarios de diversos países, y ii) que sería sumamente elevada la pérdida de reputación que podría experimentar en caso de trato deficiente a una administración pública, por tratarse de contratos con alta visibilidad internacional. f.- Protección de la información: Se sostiene que la administración pública, como depositaria de información de propiedad pública debe adoptar SL porque éste, a través del acceso al código fuente, provee una mayor seguridad e inhibe la eventual inserción de código “espía”. Sin embargo, no están claros los incentivos que tendrían los productores de SP para enmascarar en sus programas procedimientos para obtener información de forma ilícita, debido al coste en reputación y económico que deberían soportar en caso de revelarse un hecho de esas características. 4.3.- Los roles de las administraciones públicas Las administraciones públicas desempeñan un doble rol en relación al software: a) como usuarias, y b) como formuladoras de criterios orientadores para guiar las decisiones de selección. Como usuarias, deben tomar decisiones fundadas sobre la elección de los productos de software que utilizarán. Dichas decisiones, que en el ámbito empresarial se adoptan naturalmente con un criterio de comparación de costes y beneficios, no siempre se adoptan de manera análoga en el ámbito público. En algunos casos se pretende favorecer al SL con iniciativas que van mucho más allá de los terrenos técnicos y económicos, para sustentarse en argumentos políticos cuestionables o falaces. Del análisis anterior surge que no existen fallos de mercado del software que justifiquen una intervención en defensa, protección y promoción del SL por parte de las administraciones públicas. Las administraciones públicas deben tomar sus decisiones de selección de software de acuerdo con principios de neutralidad tecnológica y racionalidad económica, con base en un análisis riguroso de los costes y beneficios de cada opción. Para ello es necesario plantear un escenario de medio y largo plazo que permita ponderar el mejor uso posible de los recursos destinados a cubrir las necesidades de software, procurando obtener el mayor valor por el dinero invertido (value for money). En ese marco, no cabe ningún planteamiento, de naturaleza ideológica o de otro tipo, que deje al margen a ninguna opción de software, sino que todas las opciones han de ser tenidas en cuenta y valoradas con los mismos criterios, con una posición pragmática. Las administraciones públicas deben adoptar el principio de neutralidad tecnológica no sólo en su condición de usuarias de productos de software, sino también en su papel de generadoras de legislación, evitando intervenir por medio de preferencias o requisitos de contratación pública que discriminen a un modelo en favor de otro. 4.4.- Experiencias internacionales de promoción pública del SL En los últimos años los promotores del SL han logrado llamar la atención de gobernantes y responsables de numerosos países, incidiendo en algunas administraciones públicas para: a) adquirir indiscriminadamente SL, y b) formular iniciativas legislativas para promoverlo. Resulta llamativo que la mayor parte de dichas iniciativas responda a motivaciones ideológicas, careciendo del respaldo de estudios económicos que muestren la superioridad, técnica y económica, del SL frente a las alternativas ofrecidas por el mercado. 4.5.- Conclusiones En el sector software conviven hoy dos modelos de negocio claramente diferenciados, el del SP y el de SL. Si bien ambos presentan ventajas e inconvenientes, en general se constata la existencia de un conjunto de mitos en torno al SL -como opción más barata, segura y fiable que el SP- que no se verifican en el plano empírico. Numerosos estudios muestran que, tanto a nivel micro como macroeconómico, el SP ofrece resultados generalmente superiores a los del SL, sobre todo porque el primero alinea los intereses de productores y consumidores. La reacción de los defensores del SL ha sido, cuanto menos, curiosa. En vez de centrarse en atender las necesidades y deseos de los usuarios finales (los clientes), han actuado a modo de lobby buscando una protección pública bajo la cual desarrollar su expansión. La vía elegida ha sido denunciar falazmente la existencia de fallos de mercado que provocan una gran concentración en el sector. Sin embargo, no existen fallos en el mercado de software que justifiquen una intervención en defensa, protección y promoción del SL por parte de las administraciones públicas. En los casos en que se ha actuado de esa forma se han empleado argumentos dudosos o directamente falsos. El consenso internacional ha definido -de facto- como buenas prácticas en la selección de software los principios de “obtención del mayor valor por el dinero invertido” (value for money) y de neutralidad tecnológica. Con esa base, el informe concluye señalando que las administraciones públicas deben evitar dejarse llevar por el entusiasmo o las presiones de los promotores y defensores del SL. (Reseñó José Luis Tesoro, Jul. 2009) |
