Ad valorem y las licencias para desarrollo

Fotografía de KOBU Agency publicada en Unsplash

Dos-mil-veintiuno. No el ocaso de una gran pandemia, ni la aurora que avecina un «breakthrough» para la humanidad. Sí una época de tiempos convulsos; en el plano político — global —, todo se muestra como un caluroso verano Z/Acc donde los procesos de estancamiento se asimilan a procesos termodinámicos que se ven pronunciados por la variable de la temperatura, i.e., en analogía a conflictos que no llevan a nada y que articulan paralización e inmovilización hacia temas de extrema urgencia para el género humano y las demás especies (como el calentamiento global). O que, para colmo de una visión neorrenacentista de muchos filósofos y científicos del momento, reafirman cero enfoques hacía el futuro (también con el pesar de todos los “X”/Acc más esquizofrénicos). Paréntesis: China parece ser otro caso. Pero en esas aguas no me sumerjo. Fin del párrafo pesimista. 

En dos-mil-veintiuno estoy aprendiendo cosas nuevas. Es más, nunca en mis recuerdos me había sentido tan feliz de generar conciencia sobre nuevos conocimientos. Quizás ahora he encontrado punto de convergencia entre varias disciplinas que, de lejos, y salvo por las matemáticas de algunas de ellas, serían ciertamente disímiles entre sí: desarrollo de software, Mecánica de los Medios Continuos, Aprendizaje Automático (a.k.a Machine Learning), y leyes de propiedad. No hablaré aquí de mecánica de materiales avanzada, matemáticas o inteligencia artificial. Es la primera entrada en mucho tiempo y tendré precaución de no dejarme ir. 

Algo que no aprendí en mi carrera como ingeniero, o como maestro en ciencias, fue el desarrollo de software comercial en forma de interfaces gráficas de usuario. Es más, vivía en la burbuja de Matlab y dentro del culto a FORTRAN (por ser un lenguaje muy eficiente). Es decir, los procesos de generación de valor de mi trabajo y pasatiempos se limitaban al cómputo y visualización de datos en consola, y no más. Además, fui entrenado en uso de software propietario, como ANSYS APDL o Abaqus para el análisis de sistemas mecánicos, o sistemas CAD como NX y SolidWorks (el cual extraño). También en aquellos para adquisición de datos experimentales o de procesos, o para el cómputo y la estimación de escenarios de fallas estructurales en elementos de maquinaria avanzada. Porque la realidad es que es muy difícil  hacer desarrollo tecnológico con software libre (como ejemplo véanse los softwares para procesar modelos de elementos finitos).

Pero durante mi doctorado todo cambió. Cabalmente no fui enteramente entrenado en herramientas específicas, sino en metodologías de investigación y en modelos para comprender la física de un sistema. El único entrenamiento que recibí en software provino del uso de una plataforma para la creación de modelos de Aprendizaje Automático, el cual me abrió las puertas al mundo del desarrollo con la programación profesional como pasillo inmediato toda vez que crucé las mismas. Debo decir que, sí anteriormente creía tener nociones de programación, con esa capacitación caí en cuenta del error en el que estaba. Fin de los párrafos de contexto.

Tengo cerca de tres años aprendiendo a desarrollar y escribir programas en distintos lenguajes de programación. Este tiempo he usado mayormente dos en específico: C++ y Python. Me ahorraré detalles de lo que pienso de ambos y sólo diré que me han sentado genial para el desarrollo de lógica y trabajos científicos que hasta ya he publicado. Pero lo cierto es que, tras este tiempo, me he decidido por fin a desarrollar software propio. Ideas hay, pero he encontrado que para armar una buena plataforma, lo más importante hasta el momento es, inexorablemente, el medio. 

Hasta hace tiempo desconocía qué tan importante son las licencias para desarrollar software. Es decir, qué tan relevantes son los permisos de ciertas librerías para el desarrollo rápido de una aplicación. Sí, en ese oscurantismo vivía y no necesariamente por completa ignorancia, sino porque hasta el momento para mí no era algo enteramente obligatorio o de relevancia en mi trabajo y profesión. 

Las licencias de uso de software pueden minar y destruir esfuerzos toda vez que se planea o se hace una aplicación. Existen licencias que sin más te permiten usar código para tus desarrollos y otras que restringen completamente su uso. Incluso están aquellas que imponen que tu código deba hacerse público en aras de preservar una comunidad y ecosistemas de desarrollo abierto. Con nada de esto tengo problema alguno. Más aún, depende del propósito y el contexto, estoy de acuerdo en que algunos códigos deban ser libres (como aquellos que surgen gracias al fondeo público de una investigación). 

Con lo que no estoy de acuerdo es con el mal marketing y las malas intenciones de algunos autores que promueven cursos, libros y capacitaciones en el uso de una librería que termina por ser de licencia restrictiva (nótese que aquí no he mencionado nombre de librería/licencia alguna, y que menos lo haré hacía algún autor). Lo que quisiese apuntar es hacia la mala práctica que existe en la publicidad de material para capacitación en herramientas que al final terminan por no ser usadas y o no completamente explotadas por el público al que se dirigen. Y esto es, al parecer, el pan del día dentro del mundo del desarrollo de software, pues resulta que se venden y promocionan materiales para el uso de librerías que, en el propósito del desarrollo comercial y/o privado, restringen a los individuos de ser dueños de sus propias creaciones. Enfatizo: no estoy en desacuerdo con las licencias. Quizás es justo restringir el uso de ciertas librerías así como de algún software. Yo lo haría y es el motivo que inspiró esta entrada. 

Esto último viene a ser, entonces, una especie de impuesto al emprendedor y al desarrollador (ad valorem), pues para terminar por crear una plataforma/aplicación/código propietario, se le impone o bien que se pague la cuota del uso de una librería de terceros (pago de licencia), o contribuir bona fide a la comunidad. Desde luego esto es justo. Pero sí no se tiene la intención de hacer un gasto extra y, además, sí se toma en cuenta el costo de aprendizaje —que usualmente es a cargo del emprendedor—, y el tiempo de desarrollo fuera de toda labor asalariada, entonces lo mejor es indagar, antes de todo inicio, cuál es la mejor opción que permita ser dueño de la obra que se planea poner en marcha. Mi opinión es que uno debe informarse incluso antes de comprar material de capacitación o de invertir tiempo de estudio en alguna librería para propósito de desarrollo de software. Porque opciones existen, y hay licencias que permiten el uso comercial sin siquiera mención o citación al código de terceros o de la comunidad que le creó. 

Inicio el párrafo optimista: la segunda intención de la entrada es retomar escritura del blog. La primera es hacer uso de esta plataforma para compartir mi experiencia. Actualmente estoy desarrollando una aplicación de la que no puedo dar mucho detalle, pues planeo hacerla comercial, pero me he encontrado el problema aquí mencionado, así que me hizo bien hacer uso del teclado para comunicarlo sin tantos tecnicismos o detalles (como nombres, referencias o demás). Más aún, tras estudiar e investigar el tema en cuestión, estoy satisfecho en que, sea por hobbie, proyecto por fondeo público, o propósito comercial, existen las licencias de uso y las librerías adecuadas para cada caso. Quizás la tecnología es diferente para cada cual, pero hay mucho ahí en la red con que construir y crear valor de algún tipo. 

¿Te ha pasado algo similar? ¿También eres desarrollador o te gusta programar? Déjame tu comentario. Me encantaría conocer tu opinión, historia o perspectiva sobre el tema. 

En fin, espero regresar con una nueva entrada pronto. En este año que es el dos-mil-veintiuno, —2021 —. 

Saludos, 

Alejandro.