Luego de un largo descanso, de hecho demasiado largo, he decidido regresar a estas líneas teniendo como disparador el asunto del "Código Orgánico de la Economía Social de los Conocimientos la Creatividad y la Innovación", mejor conocido como Código Ingenios, el cual al tiempo de escribir esta entrada se encuentra en su fase de Consulta Prelegislativa.
En forma general, este Código se enfoca en el Conocimiento como un bien capaz de generar desarrollo en el país. En realidad su ámbito es bastante amplio y abarca conocimientos que incluyen saberes ancestrales, diversidad biológica, obras literarias, software, hardware, etc. Es relevante para este blog, pues se relaciona estrechamente con la innovación, la tecnología y el desarrollo.
En macro tiene aspectos muy interesantes, que lo hacen atractivo desde el punto de vista del desarrollo y el conocimiento, y sin duda tiene una gran ideología. Sin embargo, a nivel de definiciones de hardware y software que es el campo que compete a este blog, no tiene un respaldo sólido, llegando a resultar ambiguo, confuso y carente de verdaderos criterios técnicos.
Recorrer artículo por artículo y hacer observaciones puntuales resulta demasiado largo y aburrido para un blog, así que voy a agrupar sus deficinencias en siete ideas principales:
- Intenta realizar definiciones de software y hardware que resultan bastante limitadas, estáticas, monolíticas, incapaces de adaptarse a la evolución y ritmo de desarrollo de las tecnologías de la información y comunicación.
- Intenta establecer esquemas de licenciamiento enfocados en la creatividad, pero su contenido presenta mucha ambigüedad y ligereza, y no toma en cuenta que en todo el mundo existen esquemas de licenciamiento completamente funcionales y maduros, y aun así en constante evolución, y que abarcan toda actividad de desarrollo de software, sea este privativo o libre. Software libre no significa gratuito (Free as freedom, not as free beer!).
- Intenta establecer derechos para desarrolladores como si se tratase de una obra literaria, sin tomar en cuenta que el software como producto final no es la "obra" de una sola persona, sino de un equipo de trabajo en el que se pueden involucrar desarrolladores independientes, empresas, software con diferentes tipos de licencias, algoritmos de diferentes fuentes y módulos "prefabricados" que dispondrán de licencias propias.
- Intenta imponer el uso de software libre de una manera forzada. Sin duda el software libre genera una gran oportunidad de desarrollo, pero vale recordar que también tiene sus propios modelos de negocios y desarrollo que deben ser explorados y explotados. Además, por principio, si el software es libre no puede ser obligatorio. Los intentos por imponer lo libre resultan en fracasos como en su momento sucedió con el middleware Ginga en ISDBT.
- El hecho de no establecer esquemas de licenciamiento claros y compatibles con los esquemas que ya existen y se respetan en todo el mundo, aísla severamente al software desarrollado en el Ecuador y anula su potencial de internacionalización y exportación. Si queremos software exportable, debe cumplir los esquemas de licenciamiento que se respetan en todo el mundo, libres o privativos. No se puede exportar software pirata con la bandera de software libre.
- Puede llegar a ser atentatorio contra el software privativo. Defender el software libre no implica atacar al privado. El software libre actualmente no necesita que se lo lleve de la mano ni a empujones; simplemente hay que fomentar su competencia con el privativo y dejarlo avanzar. Una vez más, vale recordar que tanto el software libre como el privativo tienen sus propios modelos de negocio.
- El Código habla de softwre libre y privativo como de blanco y negro, cuando en realidad existe una compleja gama de esquemas intermedios interrelacionados por diferentes conexiones que permiten y restringen su utilización a diferentes niveles. El software como producto final puede ser una compleja mezcla de esquemas de licenciamiento.
Para ejemplificar, si el software privativo no es permitido, los
desarrolladores no podrán utilizar JAVA, pues este lenguaje tiene una
licencia restrictiva, la Oracle Binary Code License, en la que se
restringe explícitamente cualquier actividad de ingeniería inversa y
análisis o modificación de su fuente. Sin embargo, cualquier
desarrollador lo puede utilizar en forma libre para desarrollar su
propio software, el que puede tener licencias restrictivas o libres
dependiendo de su criterio. Entonces, tenemos un componente restrictivo,
el lenguaje de programación, y un componente que puede ser libre, el
programa desarrollado. Desafortunadamente, si se sigue al pie de la
letra, el Código Ingenios no es compatible con este tipo de desarrollo.
Ahora
bien, hay quienes dirán, si Java es software privativo dejamos de
utilizarlo y podremos emplear lenguajes con licencias libres. Esta
parte es en realidad la más compleja, pues hablar de software libre no
significa que sea gratuito y que no tenga licencia. Por el contrario, el
software libre tiene un complejo esquema de licencias que va desde las
altamente permisivas hasta las altamente restrictivas. El siguiente diagrama muestra de forma básica los esquemas de licenciamiento
libre.
Las flechas indican la "ruta de compatibilidad", así por ejemplo
si se realiza un desarrollo con un paquete licenciado con Apache 2.0 y
otro con LGPLv2.1+, el resultado debe ser licenciado con LGPLv3, caso
contrario se están infringiendo las licencias de los paquetes
utilizados. El software desarrollado sin estas consideraciones puede
tener problemas para ser comercializado, principalmente para la
exportación.
En conclusión, lo que realmente debería importar en el país para fomentar el desarrollo y la industria del software es que se entiendan con claridad y que se respeten los esquemas de licenciamiento que ya existen en todo el mundo. Todo software, libre o privativo, incluyendo los lenguajes de programación, tiene asociada una licencia en la que se establecen con claridad sus permisos y restricciones. No hay más que entenderlas y respetarlas, no es necesario redefinirlas ni inventar términos forzados. Tampoco es viable que las instituciones del estado obliguen a utilizar software libre sin comprender bien sus implicaciones y sus alcances.
El intento por redefinir el software del Código Ingenios resulta por tanto un esfuerzo innecesario.
