PUBLICACIONES

Know how

Análisis jurisprudencial. Códigos fuente y Open Source

26 Nov, 2020

I.- Introducción.

 

Dedicamos este estudio y análisis jurisprudencial del código fuente y las licencias Open Source.

Se configura como la II parte del artículo relacionado “Regulación de los algoritmos y códigos fuente”.

¿De quién es la propiedad de dicha app o programa? ¿Cómo se regulan códigos fuente? ¿Existe jurisprudencia sobre ello? ¿hay obligación a entregarlos a nuestros clinetes o, por el contrario forman parte esencial de la actividad y deberían adquirirlos?

El código fuente se adquiere por una empresa o start-up para ser transformado a fin de dedicarse a una finalidad para la que no estaba previsto (no va a destinarse a uso interno de la empresa sino que va a venderse a terceros). Es por ello que debemos observar algunas cuestiones como la procedencia de las licencias del código fuente, si son 100% propiedad del vendedor o resultan ser secuencias Open Source.

¿Qué es por tanto una secuencia Open Source o OSS?

A lo largo de este artículo daremos respuesta a estas y otras preguntas.

II. Titularidad del derecho de explotación de una obra.

Si en algo estamos equivocados es en pensar en que el derecho de autor se adquiere registrándolo en el oportuno registro de la Propiedad intelectual/industrial.

La propiedad intelectual de una obra literaria, artística o científica corresponde al autor por el solo hecho de su creación (Art. 1 y 97 TRLPI):

  1. Será considerado autor del programa de ordenador la persona o grupo de personas naturales que lo hayan creado, o la persona jurídica que sea contemplada como titular de los derechos de autor en los casos expresamente previstos por esta Ley.
  2. Cuando se trate de una obra colectiva tendrá la consideración de autor, salvo pacto en contrario, la persona natural o jurídica que la edite y divulgue bajo su nombre.
  3. Los derechos de autor sobre un programa de ordenador que sea resultado unitario de la colaboración entre varios autores serán propiedad común y corresponderán a todos éstos en la proporción que determinen.
  4. Cuando un trabajador asalariado cree un programa de ordenador, en el ejercicio de las funciones que le han sido confiadas o siguiendo las instrucciones de su empresario, la titularidad de los derechos de explotación correspondientes al programa de ordenador así creado, tanto el programa fuente como el programa objeto, corresponderán, exclusivamente, al empresario, salvo pacto en contrario.
  5. La protección se concederá a todas las personas naturales y jurídicas que cumplan los requisitos establecidos en esta Ley para la protección de los derechos de autor.

La protección recae sobre la expresión de una idea, no sobre la idea, una idea no es registrable, no es patentable.

El objeto de la protección es la forma de plasmar la idea, su estructura, configuración u ordenación de la misma (según cita jurisprudencia STS 21 Junio 2007).

Podemos diferenciar en este punto lo relativo a las:

Obra en colaboración.

Art 97.3:

Los derechos de autor sobre un programa de ordenador que sea resultado unitario de la colaboración entre varios autores serán propiedad común y corresponderán a todos éstos en la proporción que determinen”.

 

Obra colectiva.

97.2:

“Se considera obra colectiva la creada por la iniciativa y bajo la coordinación de una persona natural o jurídica que la edita y divulga bajo su nombre. Cuando se trate de una obra colectiva tendrá la consideración de autor, salvo pacto en contrario, la persona natural o jurídica que la edite y divulgue bajo su nombre”.

 

Diferencia entre venta y licencia

Con mucha frecuencia leo clausulados de contratos en los que se refleja que se desarrollan programas de software sobre los que se cede la “licencia de uso” a un tercero. Sin embargo, otras veces se habla de “compraventa del código fuente” para realizar modificaciones o alteraciones para comercializarlo a otras partes.

 

Los términos “venta” y “licencia” no significan lo mismo.

Mientras que, cuando licenciamos un producto, lo que estamos haciendo es ceder simplemente eso, no cedemos ninguno de los derechos de propiedad intelectual que nos asisten (como por ejemplo; los derechos de explotación, modificación, alteración, comercialización, difusión, etc…).

 

Cuando hablamos de “Compraventa”, se vede o adquiere un todo, es decir, se ceden los derechos de propiedad intelectual de manera que el comprador puede alterar el código fuente o programa y revenderlo a terceros con total libertad.

En los casos de licencia de uso:

En primer lugar, si somos los licenciantes, aconsejo pactar una cláusula de responsabilidad limitada al doble (por ejemplo) de la cantidad abonada por el comprador por los servicios. De esta forma nos estamos protegiendo frente reclamaciones por injerencias en la propiedad intelectual realizadas por terceros.

 

Salvo que el programa o código fuente sea nuestro al 100%, debemos asegurarnos de que los códigos que revendemos pertenecen al autor en su totalidad. Hasta que eso no sucede o, por el motivo que fuere, no se ha pactado con nuestro proveedor, debemos limitar al máximo la responsabilidad para con nuestro cliente.

 

En segundo lugar, cuando operamos como licenciantes, estableceremos clausulas sobre los términos y condiciones de uso que delimiten los derechos de propiedad intelectual, dejando claro qué funciones y derechos tiene cada parte.

 

En tercer lugar, se presta mucho a debate si debemos entregar el código fuente a nuestro cliente, y para ello podemos diferenciar si se trata de:

Adquisición de un código personalizado para un caso concreto, hecho “ad hoc”:

En cuyo caso, deberemos entregar el código fuente para futuras modificaciones o personalizaciones (customizar el código a sus necesidades concretas). En caso de que no entreguemos nuestro código fuente por miedo a futuras réplicas no autorizadas, tendremos que formalizar un acuerdo Escrow:

Escrow, es un acuerdo por el cual el desarrollador de un software/código fuente se compromete a depositar dicho ante un tercero, un tercero interpuesto o tercero de confianza, un  agente escrow. El depósito también podría realizarse vía blockchain, al ser un registro que funciona como prueba de cotejo, sin actuar terceros interpuestos tradicionales. Este depósito clásico se realiza para garantizar el uso pacífico de un determinado código fuente, de manera que nuestro cliente puede recurrir a él en caso de necesidad, avería, incidencia, y no pueda localizarnos por cualquier motivo (o no podamos atender de forma urgente a su petición).

De esta forma también evitamos reclamaciones debidas a vicios ocultos en el programa vendido o daños causados por la no tenencia de este código para reparar averías o incidencias que pueden derivar en daños para la compañía.

El contrato de Escrow se rige por la libertad de pactos (1255 Código Civil) y deberá contener las siguientes cláusulas:

  • Depósito de los códigos fuente.
  • Verificación.
  • Quien soporta los costes
  • Evidencia de la existencia de los supuestos de retirada.
  • Procedimiento de retirada.
  • Condiciones de mantenimiento del código fuente.
  • Soporte de jurisprudencia; STS 4811/2014

Se debe de ceder la propiedad intelectual del mismo, por medio de un acuerdo de cesión de derechos y podremos comercializarlo bajo las premisas que hayamos reflejado en el contrato.

En los contratos de licencia o compraventa se suele pactar la exclusividad, es decir, que el propietario o creador no podría comercializarlo o mejorarlo. (Ejemplo; esto es algo que realicé con la app de estiba para Gobierno vasco. Se firmó un acuerdo de compraventa y cesión de derechos a favor de la Administración para que, de esta manera, pudieran comercializarlo y distribuirlo).

Sin  embargo, cuando adquirimos la licencia de ese producto, la propiedad sigue en manos de su creador, según las condiciones que se acuerden en el contrato de licencia, normalmente más restrictivo que una venta.

En una licencia de uso lo que compramos es el uso de un producto ya realizado, estandarizado. Por ello, en primer lugar, hemos de definir muy bien en qué términos vamos a negociar la adquisición del código fuente; licencia o compraventa, y su clausulado correspondiente.

Escenarios planteados respecto al Código fuente:

El código fuente es objeto de propiedad intelectual regulada en el Texto Refundido de la Ley de Propiedad Intelectual (Real Decreto Legislativo 1/1996, de 12 de abril).

Como ya hemos visto, el código fuente es una parte del programa de ordenador y pertenece como el resto de las partes a su autor sin necesidad de acciones por su parte, sin mediar registro alguno para poder ser reconocido como tal.

 

Primer escenario:

Una empresa licencia un producto, programa o app de forma estándar. Es decir, no está hecho a medida ni ad hoz para nadie, es simplemente un producto comercializado bajo la misma forma.

 

Segundo escenario:

Una empresa licencia o vende un producto que supone una customización a los deseos o necesidades del cliente, para adaptarlo a una operación muy concreta que necesita más desarrollo que lo meramente estandarizado.

Puede ser que nuestro cliente, este que adquiere los productos nos solicite el código fuente para hacer modificaciones.

 

¿Tenemos obligación de entregárselo?

 

1. Cuando se venden licencias de uso de tipo End-User Licence Agreement (EULA), se incluyen clausulados completos sobre condiciones de uso y propiedad intelectual, de forma que no se entrega código fuente alguno.

Esta cuestión ha sido motivo de debate por la jurisprudencia como la Sentencia de la Sala Primera del Tribunal Supremo17 de mayo de 2003 (núm. 492/2003) en la que se debate sobre la obligación de la entrega del código fuente para realizar modificaciones para adaptarlo a las necesidades del usuario y actualizarlo.

 

2. Se venden o licencian productos personalizados para un fin concreto.

Hemos de decir que rara vez existen clausulados que indiquen de quien es la propiedad intelectual o se fijen garantías, limitaciones u otras regulaciones.

La Sentencia de la Audiencia Provincial de Valencia de 13 de marzo de 2006 (núm. 164/2006) concluye puntos necesarios:

  1. Que es fundamental especificar en los contratos de licencia o compra si el código fuente se entrega o no.
  2. Que en función del tipo de desarrollo (estandarizado o ad hoc) podemos estar obligados a la entrega del código o no.
  3. Por regla general no se entrega y se suele establecer en el contrato que “constituye el instrumento empresarial para la creación de las páginas web”.
  4. Ha de estarse a lo pactado entre las partes en dichos contratos, aunque puede interpretarse que dependiendo la naturaleza del negocio exista obligación de entrega o no.

Como conclusión añadiré que, para obtener el código fuente en caso de oposición, la jurisprudencia apoya la entrega cuando el producto es “hecho a medida”, en este caso deben entregar el código fuente y definir en el contrato las cuestiones de propiedad intelectual.

En los casos de entrega de productos hechos “a medida”, se cita que procede la entrega del código fuente al “cliente” porque “hay que tener presente que el programa informático objeto de autos, no se refiere a un producto estándar, sino que ha sido un programa individualizado y además sobredimensionado; lo que pretenden hacer los demandados no es una reproducción del mismo, sino de una modificación para adaptarlo a las necesidades del usuario que encargó el programa de ordenador.

 

Los requisitos para ello son simples;

  1. Los reconvinientes deberán ser los legítimos usuarios del programa.
  2. Que las alteraciones que se realicen sobre el mismo sean necesarias para su uso, por ejemplo, adaptación, corrección, puesta a punto.

La necesidad puede evidenciarse en que, de no adquirirlo, se deba obtener otro por distinto proveedor por no haberles entregado los códigos fuente de su programa individualizado y no haber podido hacer las correcciones o mejoras para poder operar con normalidad.

Debemos recoger en un contrato, más sencillo o más complejo, pero en el que queden definidas estas cuestiones que posteriormente pueden dar lugar a conflictos.

En el caso de desarrollos a medida, en lugar de una entrega inmediata del código fuente, se puede pactar su depósito en un tercero de confianza mediante la firma de un “contrato de Escrow”, de forma que el código es recuperable por el cliente en los casos en los que el desarrollador desaparezca o se encuentre en posición de no poder garantizar el mantenimiento o el soporte de dicho desarrollo.

Los términos del contrato deberán ser claros para no entrar en juego otras reglas de interpretación de los mismos (Sentencia de la Audiencia Provincial de Málaga de 26 de diciembre de 2014 (núm. 910/2014)

De aplicación lo dispuesto en art. 1281 del Código civil:

Si los términos de un contrato son claros y no dejan duda sobre la intención de los contratantes se estará al sentido literal de sus cláusulas.

Si las palabras parecieren contrarias a la intención evidente de los contratantes, prevalecerá ésta sobre aquéllas.

 

III. Open Source y código abierto.

Pero, ¿Y si no existe contrato y el código fuente es Open Source o Código abierto? ¿Puedo comercializarlo?

Pues debemos realizar una auditoría del código fuente para ver si es Open Source y si tienen alguna restricción.

Podemos decir que por regla general, el 80% del contenido de código fuente es Open Source por eso recomiendo fijar o exigir en un contrato, el desglose de lo que realmente se está adquiriendo, por ser la mayoría obtenido de bibliotecas Open Source con algunas limitaciones como no poderlo vender a título onerosos a terceros (es decir, tú debes adquirirlo gratis pero tampoco puedes venderlo a precio).

Hay que distinguir entre Software libre (4 libertades) y Open Source:

 

Software Libre:

La libertad de ejecutar el programa como se desee, con cualquier propósito (libertad 0).

La libertad de estudiar cómo funciona el programa, y cambiarlo para que haga lo que usted quiera (libertad 1). El acceso al código fuente es una condición necesaria para ello.

La libertad de redistribuir copias (libertad 2).

La libertad de distribuir copias de sus versiones modificadas a terceros (libertad 3).

Open source Software.

La estructura es similar al anterior, de hecho se permite el acceso al código fuente,

Derecho a modificar.

Derecho a redistribuir.

 

Las licencias OSS son, en su mayoría, también licencias libres, y viceversa.

Debemos distinguir si ostentan los llamados copyleft débil, por medio de los cuales libremente pueden comercializarse con la mera mención a su autor.

Exigencia de cumplimiento de condiciones licencia OSS

No tenemos jurisprudencia sobre este punto en España, pero si en Alemania:

Corte Regional de Hamburgo, caso Netfilters, en el que se condena por violación de licencia de códigos Open Source y no cumplir los requisitos de su licencia, condenándose a costas y daños morales.

El titular de esos códigos Open Source podrá iniciar acciones contra las personas que infrinjan las condiciones de la licencia, para exigir su cumplimiento y en su caso reclamar una indemnización. Si adquirimos un programa en Open Source y nuestro vendedor no cumple estos requisitos nos arriesgamos que un juez decrete una medida cautelar por la que nosotros no podremos utilizar el código ni tampoco los terceros a los que se lo hemos revendido con el consecuente agravio legal y posible cuantiosas indemnizaciones sobre nosotros.

 

Garantía

Las licencias OSS excluyen cualquier garantía con la formula “AS IS” (“tal cual”), y proporcionan el software “sin garantía alguna”. El producto se entrega tal cual es, sin responsabilidad.

En el caso español, el proveedor siempre deberá responder por haber causado daños corporales o la muerte de una persona, y no podrá limitar sus responsabilidades en casos de dolo.

 

Consejos finales y buenas prácticas

Cláusulas necesarias a incluir en los contratos de venta de código fuente:

  • Entrega y aceptación
  • Garantía
  • Propiedad intelectual
  • Limitación de responsabilidad
  • Duración del desarrollo de la aplicación
  • Penalizaciones por retraso del desarrollador en las fechas de entrega
  • Gestión de cambios
  • Colaboración y seguimiento del proyecto
  • Protección de datos de carácter personal (Privacy by design)
  • Aportaciones de las partes

 

Mejores prácticas uso OSS:

Si la empresa utiliza códigos fuente de tipo Open Source, que os puedo decir que en torno al 80% los utilizan, debemos tener en cuenta una serie de buenas prácticas respecto a ellos:

  • Revisar el uso interno de OSS, tanto explícito como implícito (dispositivos, tecnologías de terceros).
  • Definir, distribuir y mantener actualizada una política de uso y gestión de licencias OSS.
  • Formar al personal relevante (responsables y gestores de TI, de innovación, de costes) en aspectos tanto técnicos como organizativos y legales.
  • Determinar la posición e integración del OSS en el proceso y estrategia de negocio.
  • Establecer un proceso de revisión y aprobación, liderado por un equipo mixto de abogados y técnicos.
  • Establecer procedimientos adecuados para la adquisición de OSS: obligaciones mínimas exigibles en contratos, revisión de proveedores, modelos de contrato.
  • Prestar atención a operaciones corporativas (fusiones, adquisiciones, ventas).
  • Tener claras las reglas para participar en la comunidad (quién, cuándo, y cómo, y determinar qué se puede compartir y que no).

 

Revisión de los acuerdos de licencia de uso

 

  • Determinar en todo momento a quien pertenecen los derechos de propiedad intelectual.
  • Establecer cláusulas de limitación para el caso de violación de los derechos de las licencias Open Source.
  • Delimitar si se entrega el código fuente o no, que dependerá de si el código fuente o programa se entrega personalizado o “ad hoc” o estandarizado.
  • Nos pueden condenar a cubrir daños ocasionados cuando no entregamos el código fuente y existe un daño o perjuicio por necesitar realizar correcciones.
  • Formalizar acuerdos Escrow con terceros de confianza.

Publicaciones relacionadas

¡Nos vamos rumbo a USA y Alemania!

Iniciamos nueva trayectoria extranjera para la transformación digital de la cadena de suministro. Ofrecemos una entrevista a una de las revistas más prestigiosas de la zona.

Tokenización de mercancía: Usos en la cadena de suministro

La tokenización de activos permite venderlos por medio de la tecnología blockchain. Una tecnología que presenta muchas ventajas en la cadena de suministro al dotar de representación digital a un producto.

¿La identidad soberana, evitará el edadismo laboral? Aplicaciones blockchain innovadoras.

Estos sistemas de identidad digital o soberana podrían suponer que en los procesos de selección del personal se elimine la discriminación por edad o “edadismo”. Descubre cómo beneficiarían al futuro de la privacidad de nuestros datos.

¿Cómo vender inmuebles en blockchain sin problemas legales?

¿Podemos vender o transmitir bienes muebles e inmuebles por medio de blockchain? ¿Podemos hacerlo de manera más sencilla, rápida, con menos coste y burocracia que el sistema tradicional? La respuesta es sí.  Por lo tanto, si te interesa conocer las ventajas, sigue...

El edadismo laboral y su solución con blockchain. La ID soberana

El edadismo laboral y su solución por medio de la Identidad soberana de blockchain. ¿Qué es la identidad digital y soberana? ¿Qué diferencias existen y qué utilidades tienen?
Un podcast con el que podrás escuchar los conceptos básicos técnicos y jurídicos.

¿Qué podemos hacer (y qué no) cuando vendemos en redes sociales?

Cuando organizamos una campaña de marketing en redes sociales nos olvidamos de algunos aspectos importantes a tener en cuenta para no tener problemas legales.
Descúbrelos todos en 3 minutos con este artículo que resume las obligaciones en publicidad, protección de datos y políticas de uso.

¿Cumple tu página web con la normativa? Reportaje corporativo

¿Cumple tu página web con las previsiones del RGPD y la LSSI? Existen todavía muchos fallos en los que caemos a la hora de redactar nuestros avisos legales. ¿Te apetece conocer los fallos comunes que casi siempre cometemos?

¿Para qué es útil firmar un contrato de transporte? Un micro relato para reflexionar.

Con este micro relato aprenderás algunas ventajas muy útiles de firmar un contrato de transporte, tanto para cargadores como transportistas.
Conceptos como carta de porte electrónica, paralizaciones, subidas de gasóleo, órdenes de carga, cobran mucho sentido habiendo un contrato escrito.

¿VUCA ha terminado? Bienvenido BANI, las nuevas organizaciones ágiles de la nueva generación.

La transformación digital pasa por la creación previa de empresas ágiles y adaptadas en cultura, procesos y estructura al mundo BANI.
La transformación de la toma de decisiones, estilo de liderazgo y forma de organizar el trabajo, serán los nuevos pasos al éxito.

Sino queda satisfecho, le devolvemos su dinero… no es una garantía, sino obligación legal.

Los 5 errores más comunes que se comenten legalmente hablando las páginas web y Ecommerce.

Consejos legales poco conocidos pero no todos cumplidos y que pueden sernos de utilidad tanto si somos comerciantes o consumidores.

Su autora, Eva María Hernández, exime cualquier responsabilidad que pueda originarse en  cuanto a la integridad, la exactitud y la actualización de los textos, contenido y modelos aportados en sus estándares.

El contenido de estos artículos es fundamentalmente informativo y didáctico. No reemplaza ni sustituye al consejo personalizado, y en ningún caso se debe considerar sustitutivo o alternativo de las legislaciones y normativas ni del consejo profesional en cada caso individualizado. Los artículos funcionan como ejemplo que deberá adaptarse a cada caso concreto.

Limitación de responsabilidad: salvo que lo disponga expresa e imperativamente la ley aplicable, en ningún caso la autora será responsable por cualesquiera daños resultantes, generales o especiales (incluido el  daño emergente y el lucro cesante), fortuitos o causales, directos o indirectos, producidos  en conexión con sus publicaciones, incluso si la autora  hubiera sido informada de la posibilidad de tales daños.