Qué le pertenece cuando el sistema está listo: código, datos y dependencia del desarrollador

El sistema está entregado, la factura está pagada, y al cabo de medio año la empresa decide cambiar de desarrollador, y precisamente en ese momento se formula la pregunta que hasta entonces a nadie le parecía urgente: a quién pertenece aquello por lo que se pagó. La respuesta en España sorprende a casi todos los que la oyen por primera vez, porque el pago por el desarrollo no da por sí mismo al cliente los derechos de explotación sobre el programa de ordenador creado, y eso no es un matiz jurídico, sino el régimen que opera cada vez que el contrato no dice otra cosa.

Este artículo trata de lo que le queda a usted en las manos después de la entrega, y no es la misma pregunta que ya hemos visto al comparar un producto estándar con el software a medida. Allí se trataba de qué elegir; aquí se trata de lo que usted tiene en las manos cuando la elección ya está hecha y el sistema funciona. La respuesta se parte en tres: el código y los derechos sobre él, los datos junto con el lugar donde se guardan, y la dependencia de las personas que conocen el sistema.

El autor es una persona; la empresa, solo en los casos previstos

En el sentido de la Ley de Propiedad Intelectual, se considera autor a la persona natural que crea la obra, de modo que los autores son los programadores, los diseñadores y quienes escribieron los textos. Una empresa no es autora por el mero hecho de pagar, pero sí puede ser titular en los casos que la ley prevé: el artículo 5.2, y, para los programas, el 97.1 y el 97.2 si la obra es colectiva. Los programas de ordenador son objeto de propiedad intelectual, como en la Directiva 2009/24/CE, y el derecho nace por el solo hecho de la creación, sin registro y con independencia de que la obra esté terminada.

La propiedad intelectual se divide en dos partes, que la ley española llama derechos morales y derechos de explotación, y en la práctica esa es la división más importante de todo este tema, porque solo una de las dos puede llegar de veras a la empresa. Los derechos de explotación son los que pueden cederse, y en el caso de un programa de ordenador permiten reproducirlo, transformarlo —traducirlo, adaptarlo u otra modificación— y reproducir el resultado, distribuirlo, incluido el alquiler, y comunicarlo públicamente. Los derechos morales permanecen en el autor, son irrenunciables e inalienables, y por eso ningún contrato puede escribir, sin más, que la empresa se convierte en autor, salvo en los casos en que la propia ley ya contempla a una persona jurídica como titular.

Hay otra frontera que se nota poco y puede salir cara. El artículo 97.4, que atribuye al empresario los derechos de explotación del programa creado por un trabajador asalariado, habla solo del programa de ordenador —fuente y objeto—, mientras que para el diseño, la documentación, los textos y las instrucciones rige el artículo 51: a falta de pacto escrito, se presume una cesión exclusiva limitada a la actividad habitual del empresario en el momento de la entrega. En la práctica, dos cosas creadas en un mismo proyecto pueden tener dos titulares distintos, y un contrato que habla solo del software puede dejar el diseño fuera.

De ahí se siguen las primeras consecuencias prácticas, que conviene entender antes que el resto: cuando una empresa encarga un sistema a una agencia, la cadena de derechos tiene al menos dos eslabones, porque primero los programadores son los autores, después la agencia ha adquirido o no de ellos los derechos de explotación, y solo entonces la agencia puede cederle a usted algo. Si falta un eslabón, la agencia promete más de lo que le pertenece, y eso se nota solo cuando alguien empieza a comprobarlo.

El trabajador asalariado y el encargo son dos regímenes distintos

Aquí está el núcleo del artículo, y aquí es donde la intuición lleva por el camino equivocado. El artículo 97.4 dispone que, cuando un trabajador asalariado cree un programa de ordenador en el ejercicio de sus funciones o siguiendo las instrucciones de su empresario, los derechos de explotación del programa fuente y del programa objeto corresponden exclusivamente al empresario, salvo pacto en contrario. Esa es la respuesta española al artículo 2, apartado 3, de la Directiva 2009/24/CE, y se aplica solo a la relación laboral y solo a los programas de ordenador.

En el encargo el régimen es el inverso, y por eso no deben mezclarse los dos casos: la Ley de Propiedad Intelectual no tiene un precepto que atribuya al cliente los derechos de explotación por el mero hecho del pedido y del pago. El contrato de encargo obliga a ejecutar la obra pedida y a entregarla para su uso, pero no dice con una sola palabra que los derechos de explotación pasen al cliente. El contrato de obra del artículo 1544 del Código Civil no dice nada en absoluto sobre propiedad intelectual, porque regula la ejecución y la entrega, no la circulación de los derechos.

Junte ambos y sale la situación en la que cae una empresa típica sin saberlo: el cliente encarga el sistema a una agencia; los programadores son trabajadores asalariados de la agencia, de modo que el artículo 97.4 lleva los derechos de explotación a la agencia; el contrato entre cliente y agencia es un contrato de obra, que no los transmite más allá. El resultado es que el cliente ha pagado por el resultado y ha recibido el resultado, pero los derechos de explotación se han quedado en la agencia, y lo único que el cliente tiene es una licencia de derechos de autor implícita, de contenido poco claro, para usar el sistema para el fin para el que se encargó.

Es un error extendido creer que los derechos sobre un programa de ordenador pertenecen a quien ha encargado y pagado su desarrollo, y la Ley de Propiedad Intelectual no prevé una atribución automática de los derechos de explotación al cliente. El contenido de una licencia meramente implícita sigue sin estar claro, y como eso es lo que dice el texto legal, conviene leerlo tal como está: en este caso, el texto lo confirma.

Recibir los archivos no es recibir los derechos

El segundo supuesto que no resiste una comprobación es que recibir el código decida algo, pero el artículo 56.1 de la Ley de Propiedad Intelectual dispone que el adquirente de la propiedad del soporte al que se haya incorporado la obra no tendrá, por este solo título, ningún derecho de explotación sobre ella. En la práctica eso significa que un archivo con todo el código fuente, el acceso al repositorio e incluso la documentación completa siguen sin ser lo mismo que el derecho a usar ese código, transformarlo y entregarlo a otro desarrollador.

Funciona también en el sentido contrario, y este lado se conoce menos, porque una empresa puede haber adquirido los derechos de explotación con un contrato bien escrito y, aun así, no haber recibido el código fuente, si en el contrato no había una obligación aparte de entregarlo. Una autorización sin el archivo es tan inutilizable como un archivo sin autorización, de modo que el contrato necesita las dos cosas, y son dos puntos autónomos, no un punto que incluye al otro por sí solo.

Cuando los derechos se ceden de forma correcta, la ley pide una cierta precisión, y no es un trámite: los derechos de explotación pueden cederse o licenciarse, y el contrato puede indicar territorio y plazo, pero el artículo 43.2 llena los silencios. Si falta el plazo, la transmisión queda limitada a cinco años; si falta el territorio, al país en el que se realice la cesión; si no se expresan las modalidades, solo a la indispensable para la finalidad del contrato. Una empresa que opera en varios países, o planea hacerlo, tiene un motivo directo para escribir el territorio, y una fórmula sobre una modalidad no abre las demás.

Hay otra sorpresa para la empresa que vive de una licencia implícita y nunca la ha puesto por escrito. La Ley de Propiedad Intelectual no conoce una regla por la que una licencia sin plazo se extinga con un preaviso de seis meses y la renuncia a ese derecho sea nula. Lo más cercano es el artículo 48 bis —revocación por falta de explotación de una cesión exclusiva, a partir de cinco años—, y los programas de ordenador están excluidos. Quien usa el sistema solo sobre un acuerdo no escrito no vive con un preaviso legal de seis meses: vive con la incertidumbre de qué derechos le corresponden, y si hubo una cesión sin plazo, el artículo 43.2 la limita a cinco años.

Los derechos morales y lo que no basta para detener el sistema

En los derechos morales entran la autoría, el nombre, la integridad de la obra y la posibilidad de retirarla del comercio, y todo eso permanece en el autor, porque ninguno de esos elementos puede cederse a otra persona en vida del autor. Para una empresa que ha encargado un sistema, al principio suena amenazador, porque da la impresión de que un antiguo desarrollador podría, en algún momento, exigir que se detenga el sistema.

En la práctica no es un modo fiable de detenerlo, y el motivo no es una reforma de 2023, sino el artículo 100.4: el autor, salvo pacto en contrario, no puede oponerse a que el titular de los derechos de explotación realice o autorice versiones sucesivas ni programas derivados. El derecho a la integridad del artículo 14.4.º permanece, y el derecho a retirar la obra del comercio del 14.6.º no está desactivado para los programas. Un programador anterior no puede, por oponerse a las versiones sucesivas, detener el mantenimiento ordinario ni una reescritura; esa era la parte de los derechos morales que habría sido peligrosa para la empresa.

En la transposición de 2021 hay otra norma favorable a la empresa y que conviene conocer, porque de lo contrario se la puede esperar del lado equivocado. Las reglas sobre remuneración equitativa y el derecho del autor a recibir información sobre la explotación, que en otros tipos de obras permiten volver sobre la retribución, no se aplican a los autores de programas de ordenador: el artículo 47.3 excluye la acción de revisión, y el artículo 75.5 del Real Decreto-ley 24/2021 excluye la obligación de transparencia. Un programador que considere que el sistema ha resultado más valioso de lo esperado no puede, sobre esa base, exigir una retribución adicional.

Lo que queda es la posibilidad de ser nombrado como autor y la protección frente a un uso de la obra que menoscabe el honor o la reputación, y eso es un riesgo considerablemente menor, con el que se puede vivir. Lo importante es no confundir dos cosas: el artículo 100.4 impide al autor oponerse a las versiones sucesivas y a los programas derivados que realice el titular de los derechos de explotación, de modo que esa vía no es un obstáculo, pero la transformación como derecho de explotación sigue exigiendo la autorización de su titular, de modo que, si los derechos de explotación se han quedado en la agencia, una reescritura del sistema sigue necesitando su consentimiento.

Lo que la ley da también sin un buen contrato

Incluso a la empresa que no ha formalizado nada, la ley le da algunas posibilidades, y conviene saber cuáles de ellas el contrato puede quitar y cuáles no. El artículo 100.1 de la Ley de Propiedad Intelectual permite al usuario legítimo reproducir o transformar el programa, incluida la corrección de errores, cuando esos actos sean necesarios para utilizarlo con arreglo a su finalidad propuesta, pero solo a falta de disposición contractual en contrario, de modo que el contrato puede quitar este derecho, y muchos contratos lo hacen.

La copia de seguridad es un caso distinto, y es el único de esta sección que el contrato no puede quitar, porque el artículo 100.2 dispone que la realización de una copia de seguridad por parte de quien tiene derecho a utilizar el programa no podrá impedirse por contrato en cuanto resulte necesaria para dicha utilización, y eso corresponde al artículo 5, apartado 2, de la Directiva 2009/24/CE. El artículo 8 de la directiva dispone, además, que las cláusulas contractuales contrarias al artículo 6 o a las excepciones de los apartados 2 y 3 del artículo 5 son nulas.

Aquí conviene ser precisos, porque la diferencia es fina y fácil de exagerar: para la copia de seguridad la ley dice que no podrá impedirse por contrato, pero en el artículo de la descompilación no hay una frase aparte que declare nulo el contrato contrario, aunque la directiva sí lo dispone. El artículo 104 es una salvaguardia de otras disposiciones, no el artículo 8 de la directiva. Por eso no es correcto escribir que la ley española transpone literalmente el artículo 8; lo correcto es decir que la copia de seguridad no se puede quitar en el contrato y que la directiva, además, declara nulas las cláusulas contrarias a la excepción de descompilación.

La descompilación, a su vez, está permitida de forma estrecha y con condiciones: puede hacerse para obtener la información necesaria para la interoperabilidad de un programa creado de forma independiente, si esa información no se ha puesto previamente a disposición de manera fácil y rápida, la realiza el usuario legítimo o alguien facultado para usar una copia, y la operación se limita a las partes del programa original que la interoperabilidad exige. La información obtenida no puede usarse para otros fines ni para crear un programa sustancialmente similar, y esta vía de salida es útil, pero estrecha, y ninguna empresa quiere que sea la única.

En el sistema hay mucho código que nunca será suyo

Un sistema a medida casi nunca es solo el código que escribió el desarrollador, porque la mayor parte del volumen viene de bibliotecas y de un framework que ya existían. Ese código no se convierte nunca en su propiedad, en ningún contrato, porque usted recibe una licencia de sus autores, y esta diferencia importa precisamente cuando alguien promete ceder todos los derechos sobre el sistema.

Las licencias permisivas no crean un problema, porque piden poco y no limitan cómo puede usarse el sistema terminado en una actividad comercial. La licencia MIT permite usar, copiar, modificar, fusionar, publicar, distribuir y vender, siempre que se conserve el aviso de derechos de autor y la propia licencia, y el software se entrega tal como está, sin garantías, mientras que la licencia Apache 2.0 añade una licencia de patentes expresa y exige marcar los cambios realizados. Ambas son compatibles con un sistema comercial cerrado, la mayor parte de los frameworks actuales es una de las dos, y precisamente por eso esta parte del sistema no suele pedir negociación alguna.

Las licencias copyleft piden atención, no pánico, y es aquí donde más a menudo se cuentan medias verdades, aunque la Free Software Foundation, en su página de preguntas sobre la GPL, escribe con claridad que una empresa que ejecuta un programa GPL modificado en su sitio web no está obligada a publicar el código fuente modificado, porque la obligación copyleft nace al entregar copias a terceros, no al usar el programa en casa. Fabricar y usar varias copias dentro de una misma organización no es distribución, aunque entregar copias a otras organizaciones, incluidos los contratistas para un uso fuera de la empresa, ya lo es.

La excepción es la licencia Affero, y precisamente su cláusula de interacción por red (AGPL §13) es lo que sorprende a la gente, porque si usted modifica el programa y la versión modificada permite a los usuarios comunicarse con ella a distancia a través de una red de ordenadores, entonces hay que ofrecer a esos usuarios la posibilidad de recibir el código fuente correspondiente. Las condiciones son dos y hacen falta las dos: la modificación y la interacción remota de los usuarios, de modo que no es correcto decir que cualquier uso de una licencia Affero exige publicar el código fuente, y no es correcto decir que una sola biblioteca de este tipo somete automáticamente a todo el sistema, porque eso depende de cómo estén conectados los componentes.

El depósito de código fuente ante un tercero y lo que realmente da

El depósito de código fuente (source code escrow) es una solución de tres partes en la que el desarrollador entrega el código a un depositario neutral, y el depositario lo entrega al cliente solo cuando se produce el caso descrito en el contrato; los casos típicos son el concurso, el cese de la actividad o un incumplimiento sustancial de las obligaciones de mantenimiento después de un requerimiento. En España no hay una ley que fije esos casos ni siquiera que los enumere, de modo que aquí rige solo lo que las partes han escrito, y por eso el contrato de depósito hay que leerlo con el mismo cuidado que el propio contrato de desarrollo.

El depósito da exactamente lo que se ha depositado, y solo cuando ocurre lo que está descrito, pero por sí mismo no transmite derechos de explotación, porque de nuevo hay que recordar el artículo 56.1, y no enseña a nadie a hacer funcionar el sistema. La empresa NCC Group, que vende este servicio desde hace décadas, lo admite en sus propios materiales: que el código fuente esté en el depósito es una cosa, y saber compilarlo es otra, y precisamente por eso la misma empresa vende también la verificación del contenido depositado. Es la valoración de una parte interesada, pero es una confesión sobre el punto débil de su servicio principal, y por eso es utilizable.

Los sistemas de hoy tienen además una segunda laguna que no tiene nada que ver con la parte jurídica: si el sistema funciona como servicio sobre la infraestructura del desarrollador, entonces el código fuente sin el entorno de ejecución, la configuración y los datos resuelve la parte menor del problema, porque al destinatario le queda un archivo, no un sistema en marcha. En la práctica se cierra esa laguna completando el depósito con un acuerdo sobre quién se hace cargo del entorno y qué ocurre si las facturas de hosting quedan impagadas, y precisamente esos puntos no suelen aparecer en los formularios tipo del depósito.

Hay también un obstáculo jurídico que no está en la Ley de Propiedad Intelectual, sino en el concurso: en un concurso de acreedores, el material depositado y su entrega pueden entrar en conflicto con el régimen de la masa activa, es decir, precisamente en el caso por el que el depósito se compra con más frecuencia. La consecuencia práctica no es renunciar al depósito, sino no tratarlo como sustituto de una cesión escrita de los derechos y de una entrega regular del código fuente.

Dónde está el repositorio y dónde están los datos

La pregunta de dónde están el código y los datos decide más que la pregunta de a quién pertenecen, porque unos derechos sin acceso son un problema lento. La documentación de GitHub describe con claridad que una organización es una cuenta compartida a la que pertenecen los repositorios, que no se puede entrar como organización, porque cada uno se identifica con una cuenta personal, y que los propietarios de la organización tienen siempre acceso a todos los repositorios; un repositorio puede pertenecer a una cuenta personal o a una organización, y esta elección importa más de lo que parece.

Si el repositorio pertenece a la cuenta personal del desarrollador, el acceso del cliente es solo un acceso de colaborador, que el titular de la cuenta puede quitar en cualquier momento, y, al dejar el proyecto, se lleva también la propia dirección. Si el repositorio pertenece a la organización del cliente, en la que el desarrollador ha sido invitado como miembro, entonces marcharse significa quitar un acceso y nada más, y esa es una de las pocas cosas de este artículo que se puede arreglar en un solo día y sin abogado.

Los datos son una pregunta aparte, y ahí ya no se trata de propiedad intelectual: si el desarrollador trata datos personales por cuenta de usted —es decir, opera el entorno de producción, accede a datos de clientes o de empleados o hace copias de seguridad—, entonces usted es el responsable del tratamiento y el desarrollador es el encargado del tratamiento a efectos del Reglamento general de protección de datos (RGPD). El artículo 28 del Reglamento exige un contrato escrito con puntos concretos: el objeto y la duración del tratamiento, su naturaleza y finalidad, los tipos de datos y las categorías de interesados, y los derechos y obligaciones del responsable.

El trabajo puro de escribir código, sin acceso a datos personales, no activa el artículo 28, de modo que no todo contrato de desarrollo necesita un contrato de encargo de tratamiento. El límite es simple y comprobable: si el desarrollador puede ver datos reales de clientes, entonces hace falta; si el desarrollador trabaja solo con datos de prueba y no ve el entorno de producción, entonces no, y eso mismo es un argumento a favor de que el entorno de prueba esté separado.

Qué obtiene y qué asume al mismo tiempo

La lógica de este artículo ha sido hasta ahora unilateral, así que es honesto nombrar también la otra cara: el control pleno de un sistema a medida no es solo una ganancia, sino también un conjunto de obligaciones que no desaparecen. En un software ya hecho, el mantenimiento, los parches de seguridad y la compatibilidad con entornos nuevos los aporta el fabricante, y eso va en la cuota de suscripción; en un sistema a medida lo aporta todo el titular, es decir, usted, y eso es un gasto directo que aparece cada año, cambie o no algo en el sistema.

Lo segundo que asume es el envejecimiento del sistema, que se acumula en silencio y no se manifiesta de ningún modo mientras nadie lo busque. El sistema se apoya en versiones del lenguaje y del framework para las que los fabricantes fijan plazos de soporte, y, acabados esos plazos, las vulnerabilidades nuevas ya no se parchean, aunque el sistema sigue funcionando exactamente igual que antes y ninguna pantalla avisa. Eso no es una prohibición de hacer funcionar un sistema envejecido, pero es el momento en el que el titular asume el riesgo, y las fechas concretas para PHP y Laravel las hemos reunido en el artículo sobre qué significa elegir PHP y Laravel, así que aquí no las repetimos.

Lo tercero es el mercado, y para una plataforma ya hecha un especialista se encuentra con relativa facilidad, porque se forma y hay varios, mientras que un sistema a medida lo conocen solo quienes lo construyeron, y a un desarrollador nuevo hay que darle tiempo para conocerlo antes de que pueda cambiar algo con seguridad. Eso no significa que una toma de relevo sea imposible, pero significa que cuesta, y ese coste aparece precisamente en el momento en el que la relación con el desarrollador anterior ya se ha acabado.

Por eso la pregunta de qué le pertenece no es un trámite jurídico, sino la pregunta de cuánto costará la siguiente elección. Una empresa con una cesión escrita, el código fuente en su propio repositorio y una lista de los componentes usados puede buscar un desarrollador nuevo en una semana, mientras que una empresa sin todo eso primero averigua qué se le permite hacer, y solo después empieza a buscar, y esa es la diferencia entre una conversación desde una posición y una conversación desde la necesidad.

Qué escribir en el contrato mientras aún se puede

Todas las secciones anteriores llevan a un conjunto pequeño de puntos que conviene escribir en el contrato antes de empezar el trabajo, porque después de la entrega la posición negociadora es mucho más débil. El primero es la cesión por escrito de los derechos de explotación, nombrando qué derechos pasan, en qué territorio y por qué plazo, porque si falta el plazo el artículo 43.2 limita la transmisión a cinco años, y si falta el territorio, al país en el que se realice la cesión. El segundo es la declaración de que la agencia los ha adquirido de sus trabajadores y subcontratistas, porque sin ese eslabón la propia cesión puede estar vacía.

El tercero es la entrega regular del código fuente y de todo lo necesario para compilarlo, no una entrega única al final del proyecto, y el cuarto es que el repositorio esté en la cuenta de organización de usted desde el primer día. El quinto es una lista de los componentes de código abierto con sus licencias, porque sin esa lista nadie sabrá después qué hay en el sistema y con qué condiciones; el sexto es un contrato de encargo de tratamiento si el desarrollador va a ver datos reales, y el séptimo es un acuerdo sobre qué ocurre con los entornos, las claves y los accesos al terminar la colaboración.

Ninguno de estos puntos pide un texto largo, ninguno está en contradicción con una buena colaboración, y ningún desarrollador honesto se opone a ellos, porque dejan escrito exactamente lo que ambas partes ya piensan. Lo único que cambian es que el acuerdo ya no depende de si esas personas concretas siguen, dentro de tres años, en la misma empresa y de si alguien recuerda lo que entonces se dijo de palabra. Estos puntos conviene pedirlos a cualquier desarrollador, también a nosotros, y escribirlos en el contrato antes de empezar el trabajo. Nuestra página de desarrollo de software a medida promete hoy entregar el código fuente, la documentación y la configuración de la infraestructura al final del trabajo, y precisamente por eso el tercer punto de esta lista —la entrega regular a lo largo del trabajo— conviene hablarlo aparte, y no dar por sentado que es obvio. Si quiere que veamos un contrato que ya tiene, escríbanos.