Imaginen que se han embarcado en el desarrollo de una nueva aplicación informática, un proyecto que promete ser un éxito. Tras meses de trabajo, el equipo de desarrolladores está a punto de concluir el producto: ya parece estar listo para su lanzamiento. Están revisando los detalles finales, y alguien lanza una pregunta aparentemente inocente, pero crucial al fin y al cabo: ¿lo vamos a poder monetizar?
Pongámonos en contexto: desarrollar software hoy en día es un proceso que, inevitablemente, implica la integración de librerías de terceros: carece de sentido reinventar la rueda cuando ya existen soluciones sólidas y estables en el mercado, sobradamente probadas. Hacer uso de frameworks o líneas de código ajenos es una práctica común y eficiente, pero requiere un cuidadoso manejo de las licencias que los acompañan, incluyendo las grandes olvidadas: las de “software libre”. Las hay de varios tipos y, como veremos, la elección de unas u otras puede generar un impacto significativo en la posterior explotación del nuestro producto. Especialmente si buscamos comercializarlo… o atraer inversiones.
El software libre se distribuye bajo licencias que permiten utilizar, modificar y redistribuir el código libremente: de ahí que también se conozca como “de código abierto”. Sin embargo, existen multitud de modalidades de textos legales que, en la práctica, dan lugar a implicaciones muy distintas: de ahí que comprender sus diferencias se vuelva fundamental, comenzando por la distinción entre las dos grandes familias de licencias open source: las permisivas y las restrictivas, no siempre compatibles entre sí.
- Las licencias permisivas, como la MIT o la BSD, conceden mayor libertad al usuario en el uso del código. Por lo general, permiten integrar su contenido en desarrollos propios, crear una nueva versión e, incluso, integrarlo en un proyecto comercial con pocas restricciones. A menudo, basta con incorporar una referencia a la licencia en cuestión; si bien, en algunos casos, debemos publicar los cambios realizados sobre el código original.
- Por su parte, las licencias restrictivas, como la GNU GPL, imponen requisitos más severos. Al utilizar librerías distribuidas bajo uno de estos acuerdos, podríamos estar obligados a liberar el código fuente de nuestro software en términos similares; lo que permitiría a cualquiera acceder a su contenido, modificarlo y reutilizarlo bajo esas mismas reglas. Aunque esta filosofía es coherente con los principios del software libre y ha dado lugar a no pocos negocios exitosos, puede chocar frontalmente con los intereses comerciales de una empresa que busca mantener en secreto su propiedad intelectual… ¡o atraer inversores!
Pongámonos en el caso de una start-up tecnológica: fondos y business angels, por ejemplo, querrán asegurarse de que su software no está supeditado a restricciones que puedan limitar el retorno de su inversión. Un mal manejo de las licencias open source podría no solo ralentizar la comercialización, sino también hacer que pierdan oportunidades de entrada de capital.
Algo similar podría ocurrir si desarrollamos programas a medida para terceros. Las cesiones de derechos de propiedad intelectual llevan aparejada una garantía de explotación pacífica del software, es decir, de que el cliente pueda utilizarlo sin temor a problemas legales. Si incorporamos código con una licencia restrictiva, sin ser plenamente conscientes de sus términos y condiciones, podemos limitar la capacidad del cliente para explotar el software comercialmente o para integrarlo en otros desarrollos propietarios, o incluso enfrentarnos a posibles demandas en el futuro. Como ven, no se trata de una cuestión trivial: de ahí que resulte crucial conocer las implicaciones jurídicas de las licencias open source que incorporemos a nuestros desarrollos y saber si encajan con nuestro modelo de negocio, para evitar sorpresas desagradables y garantizar que alcanzamos las expectativas de clientes e inversores.
Es evidente que cualquier empresa desea ver su software finalizado, cubriendo las necesidades de los usuarios y, cómo no, generando beneficios. Pero para que este aparente éxito no se convierta en una desagradable sorpresa, es imprescindible prestar atención a las librerías de software libre que se utilicen en el proceso de desarrollo. De ahí que recomendemos que, desde la fase inicial del proyecto, tanto el equipo de desarrollo interno como los colaboradores externos tengan directrices claras sobre los tipos de licencias a los que deben ceñirse: definir este aspecto desde el principio y verificar que se respetan estas directrices nos permitirá asegurar, ya no solo que el código que tan cuidadosamente han elaborado funcione bien, sino que también esté libre de restricciones legales que puedan comprometer nuestro modelo de negocio.
En definitiva, mi consejo es claro: antes de lanzar su próximo producto al mercado, asegúrense de documentar bien las licencias detrás de cada línea de código, ¡y de conocer sus implicaciones! Es un pequeño paso adicional en el proceso de desarrollo, ¡pero podría ahorrarles muchos problemas en el futuro!
Si han instalado en su empresa un sistema biométrico para controlar el acceso de los trabajadores, agárrense, porque vienen curvas: la Agencia Española de Protección de Datos (AEPD) acaba de publicar una guía que pone en entredicho la utilización de estas tecnologías, apartándose del criterio que mantenía hasta ahora. Justificar el uso de la huella dactilar o del reconocimiento facial para fichar se complica enormemente, y la viabilidad económica de las empresas dedicadas a fabricar o instalar estas soluciones pende de un hilo.
Pongámonos en antecedentes: el control de jornada a través de sistemas biométricos fue analizado por nuestro Tribunal Supremo en su sentencia de 2 de julio de 2007 (rec. 5017/2003), que sostuvo que no se trataba de una medida excesiva, dado que la ley permite a los empleadores supervisar el cumplimiento horario de los trabajadores y el recurso a esta tecnología no estaba limitado por norma alguna. De ahí que concluyese que su uso era legítimo, zanjando así toda discusión sobre este particular hasta la aprobación del Reglamento General de Protección de Datos (2016). La introducción, por esta norma, de los datos biométricos como “categoría especial”, cuando se utilizan para identificar de manera unívoca a una persona, parecía dificultar el uso de estas soluciones en el ámbito laboral; pero la AEPD abrió la puerta a su utilización mediante una hábil utilización del lenguaje, diferenciando entre “identificación” y “autenticación”:
“Sin embargo, y con carácter general, los datos biométricos únicamente tendrán la consideración de categoría especial de datos en los supuestos en que se sometan a tratamiento técnico dirigido a la identificación biométrica (uno-a-varios) y no en el caso de verificación/autenticación biométrica (uno-a-uno)”.
Aplicando la lógica anterior, los sistemas de control de acceso se limitarían a “verificar” los rasgos de un trabajador, ya identificado previamente; y por tanto, no nos encontraríamos ante un uso de datos “especiales”, y la doctrina del Tribunal Supremo seguiría siendo plenamente válida.
Esta interpretación parecía pacífica, pero llegado mayo de 2022, el Comité Europeo de Protección de Datos publicó unas directrices (aprobadas en abril de 2023) que daban al traste con esta teoría. Les dejo el párrafo (la traducción es mía):
“Si bien ambas funciones -autenticación e identificación- son distintas, las dos se refieren al tratamiento de datos biométricos relacionados con una persona física identificada o identificable y, por lo tanto, constituyen un tratamiento de datos personales, y más concretamente, un tratamiento de categorías especiales de datos personales”.
A raíz de estas directrices, la Agencia comenzó a recoger cable: ya en su informe jurídico 98/2022 advirtió de que, de confirmarse esta interpretación, se vería abocada a revisar su criterio, para adecuarlo al mantenido por el Comité… y la recientemente publicada guía no hace sino confirmar este anuncio.
En esencia, este nuevo documento advierte del alto riesgo que conlleva la utilización de este tipo de sistemas desde la perspectiva de la privacidad, y confirma que “incluye categorías especiales de datos”. Ello supone que su uso, de entrada, esté prohibido, salvo en aquellos casos específicamente previstos en el artículo 9 del RGPD; y la Agencia, tras analizar varios de estos supuestos, llega a una conclusión clara: resulta prácticamente imposible superar el requisito de necesidad establecido para realizar estos tratamientos, aun contando con el consentimiento de los trabajadores. Su lógica es sencilla: si existen alternativas menos intrusivas que permitan controlar el horario (como el uso de tarjetas inteligentes o certificados digitales), debemos optar por ellas; y si sospechamos que puede existir fraude, aboga por la “intervención humana” para prevenirlo, aunque suponga un coste mucho más elevado. Ojo al trabalenguas:
“Al no ser necesario el tratamiento de datos biométricos, no se estaría cumpliendo con lo establecido en el art. 5.1.c del RGPD, y como se explicará más adelante en el capítulo VIII de este documento, al ser un tratamiento de alto riesgo, no cumpliría por tanto el requisito de “necesidad” que le impone el art. 5.1 y 35.7.b. Si el tratamiento es de alto riesgo, además de ser necesario, tiene que demostrarse la evaluación positiva de necesidad (art. 35.7.b del RGPD); que en este caso no se cumpliría, precisamente por esa falta de necesidad”.
Por tanto, salvo en aquellos casos en que se pueda demostrar por parte del empresario la imperiosa necesidad de adoptar esta medida, la utilización de esta tecnología debe ser descartada; y ya les adelanto que, a la vista del contenido de la Guía, justificar esta necesidad se antoja extraordinariamente complicado.
Una alternativa sería emplear, como base de legitimación, las leyes que permiten al empresario “adoptar las medidas que estime más oportunas de vigilancia y control para verificar el cumplimiento por el trabajador de sus obligaciones y deberes laborales”; pero la Agencia, con su cambio de criterio, considera ahora que el ordenamiento no ampara el uso de datos biométricos en este contexto… lo que nos lleva a una simple dicotomía: o se modifica el marco jurídico (sea reformando las leyes, sea por la vía de los convenios colectivos), o el uso de sistemas de fichaje con huella dactilar o reconocimiento facial será, simplemente, ilegal.
Si se preguntan por el margen que tienen para adaptarse a esta nueva guía, me temo que la respuesta es clara: a diferencia de lo ocurrido con las cookies, aquí no hay un plazo de gracia. Si siguen usando estos sistemas, asumen el riesgo de ser sancionados. Así de simple.
Para concluir, permítanme un comentario en relación con las empresas proveedoras de soluciones de control biométrico: me preocupa enormemente que un cambio de criterio en una simple guía, sin más valor legal que el interpretativo, sin memoria económica y sin dar previamente audiencia a los afectados, mande a todo un sector “a escardar cebollinos”. Es algo sobre lo que nuestras autoridades deberían reflexionar, ¿no creen?
(0)
