El contrato decide de quién es el código. Quién pagó, quién tuvo la idea o en qué repositorio vive son datos de contexto. Si el MSA o el SOW tienen una cesión firmada a favor del cliente, el código cedido es del cliente.
Si el contrato no dice nada, aplica la regla por defecto de la ley, y en EE. UU. esa regla deja el copyright con quien escribió el código: tu agencia. El cliente se queda con una licencia implícita para usar lo que pagó. Casi todos los clientes y muchos dueños de agencia se sorprenden con esto.
Qué pasa si no hay contrato o el contrato no dice nada
En EE. UU. la regla por defecto tiene tres partes:
- El autor de una obra es su titular desde que la escribe (17 U.S.C. § 201(a)).
- Para el código que escriben tus empleados dentro de su trabajo, el autor es tu empresa (17 U.S.C. § 201(b)).
- Frente al cliente, tu agencia es un contratista independiente.
Así que sin un acuerdo escrito, el copyright del código que escribiste para el cliente es de tu agencia.
El pago no transfiere el copyright. Según 17 U.S.C. § 204(a), una transferencia tiene que ir por escrito y firmada por el titular de los derechos. Una factura pagada prueba que se vendió un servicio y no dice nada sobre la titularidad.
Por qué el “work made for hire” hace menos de lo que el cliente cree
Los contratos de clientes gringos usan mucho la frase work made for hire. Para un empleado funciona: lo que hace dentro de su trabajo es del empleador.
Para un contratista independiente, como tu agencia, la ley (17 U.S.C. § 101) solo lo admite en nueve categorías (contribución a obra colectiva, parte de obra audiovisual, traducción, obra suplementaria, compilación, texto didáctico, examen, respuestas de examen y atlas), y además exige un documento escrito firmado por ambas partes. El software a medida no encaja limpiamente en ninguna de esas categorías.
| Situación | Quién tiene el copyright | Qué tiene la otra parte |
|---|---|---|
| No hay contrato, la agencia escribió el código | La agencia | El cliente, una licencia implícita |
| El contrato dice solo “work made for hire” | Probablemente la agencia | El cliente, una licencia implícita y un argumento |
| El contrato tiene una cesión firmada | El cliente, desde el momento que fije la cláusula | La agencia, lo que el contrato le licencie de regreso |
| Lo escribió un contractor de la agencia sin cesión a la agencia | El contractor | Agencia y cliente, licencias implícitas como mucho |
Revisa tu propia cadena de titularidad
La última fila es la que duele. Tus contractors están frente a ti en la misma posición en que tú estás frente al cliente. No puedes ceder al cliente algo que nunca fue tuyo.
La ley de tu país importa aquí, porque ese contrato se firma en tu país:
- México. El artículo 103 de la Ley Federal del Derecho de Autor dice que, para software hecho por empleados en sus funciones, salvo pacto en contrario, los derechos patrimoniales sobre el programa y su documentación corresponden al empleador. Para obras por encargo, el artículo 83 dice que salvo pacto en contrario, quien comisiona la obra o la produce con colaboración remunerada tiene los derechos patrimoniales. Y los contratos que transmiten derechos patrimoniales y las licencias se tienen que hacer por escrito; si no, son nulos de pleno derecho (artículo 30).
- Colombia. Para obras hechas por contrato de trabajo o de prestación de servicios, el artículo 20 de la Ley 23 de 1982 dice que se presume, salvo pacto en contrario, que los derechos patrimoniales pasan al contratante o al empleador en la medida necesaria para sus actividades habituales, siempre que el contrato conste por escrito. Ojo con “en la medida necesaria para sus actividades habituales”: esa presunción puede no cubrir que tu agencia relicencie el código a un tercero.
- Argentina. Según la Ley 11.723, artículo 4, inciso d, el titular es la empresa cuyos dependientes, contratados para elaborar un programa, lo produjeron en el desempeño de sus funciones, salvo estipulación en contrario. Para contractors que no son empleados, necesitas una cesión.
Los tres modelos de titularidad que vas a ver
| Modelo | El cliente recibe | La agencia conserva | Dónde aparece |
|---|---|---|---|
| 1. Todo para el cliente | Titularidad de todo, a veces incluso de tus herramientas | Nada, salvo que negocies una licencia de regreso | Contratos enterprise, startups con inversión |
| 2. Entregables para el cliente, background IP para la agencia | Titularidad de lo hecho a medida y licencia perpetua de tus componentes | Librerías, frameworks, herramientas, know-how | La mayoría de los proyectos a medida |
| 3. Todo para la agencia, licencia al cliente | Una licencia de uso | Todo | Plataformas propias, proyectos con descuento |
El modelo 1 está bien si se cobra. Si el cliente quiere también tu librería de componentes, o la reescribes desde cero a su costo o le cobras por renunciar a reutilizarla.
El modelo 2 es el razonable para casi todo. Necesita dos cosas por escrito: una definición de background IP y un anexo con la lista de componentes de fondo que entraron en el proyecto.
El modelo 3 se usa poco y debería usarse más. Si despliegas tu propia plataforma con configuración encima, la estructura honesta es una licencia. Lo explicamos en licenciamiento de software.
Tres detalles de la cláusula de cesión
| Detalle | Redacción | Qué significa |
|---|---|---|
| Tiempo verbal | “Agency hereby assigns” | Cede en el acto cuando ocurre el disparador |
| “Agency agrees to assign” | Es una promesa de firmar algo después | |
| Disparador | Cesión “upon creation” | Cada commit es del cliente al subirse, haya pagado o no |
| Cesión “upon full payment” | La titularidad queda contigo hasta que pague | |
| Alcance | “All work product” | Barre con todo lo que tocaste |
| “The Deliverables listed in the SOW” | Cubre lo que vendiste |
“Upon full payment” es la cláusula más útil cuando un cliente deja de pagar. Más sobre esto en contrato con cliente de EE. UU..
En el alcance, la definición pesa más que la frase de cesión.
Lo que conservas cuando el cliente se lleva el entregable
Con el modelo 2, o con un contrato que dejó la titularidad contigo, cada proyecto termina con cosas que siguen siendo tuyas:
- el background IP;
- las mejoras a ese background IP, si el contrato lo dice;
- el código genérico que el cliente te licencia de regreso;
- los proyectos completos sin cesión;
- los productos internos que hiciste con tu tiempo y tu dinero.
Lo que no es tuyo es igual de claro: el código cedido, los datos del cliente, sus credenciales y su información confidencial. Si un contrato es ambiguo, trata el código como del cliente hasta que un abogado diga otra cosa.
Para ponerle número, ve a cuánto vale el código.