Propiedad intelectual del código: ¿de quién es lo que escribe tu squad?

Por defecto, el código le pertenece a quien lo escribe —no a quien paga por él—. En la mayoría de las jurisdicciones, incluido Estados Unidos, el software encargado a un contratista independiente no entra en las categorías que la ley reconoce como “trabajo por encargo” (work made for hire), así que un squad, una agencia o un freelancer retienen los derechos de autor del código salvo que exista un contrato que se los ceda explícitamente a la empresa que pagó por el proyecto.

Pagar la factura no alcanza: sin esa cesión por escrito, la empresa puede terminar sin la propiedad legal del producto que financió. Es un problema que casi nunca se nota hasta que hace falta —una ronda de inversión que pide due diligence técnica, un cambio de proveedor, una disputa por exclusividad— y ahí es cuando alguien revisa el contrato y descubre que nunca hubo una cláusula de cesión de propiedad intelectual, o que la que había estaba mal redactada.

¿Por qué pagar por el código no te hace dueño de él?

La ley de derechos de autor define un listado cerrado de categorías elegibles para “trabajo por encargo” en obras producidas por terceros —traducciones, contribuciones a una obra colectiva, partes de una película, entre pocas más— y el software encargado a un contratista independiente no es una de ellas (17 U.S. Code § 101). Por eso la etiqueta “work for hire” sola, sin una cesión de derechos explícita, casi nunca alcanza para transferir la titularidad real del código: el punto de partida legal es que el autor original conserva los derechos, y el contrato tiene que revertir esa regla por escrito, no asumirla.

¿Qué tiene que tener un contrato para ceder la propiedad del código?

Una cesión de propiedad intelectual sólida no es una frase suelta en la última página. Tiene que cubrir, como mínimo:

• Una cláusula de cesión (assignment) redactada en tiempo presente —“cede y transfiere”, no “cederá en el futuro”— para que la transferencia sea efectiva desde el momento en que el código se crea, no condicionada a un trámite posterior.
• Alcance completo del trabajo: no solo el entregable final, sino documentación, scripts internos, configuración de infraestructura y cualquier otro artefacto producido durante el proyecto.
• Tratamiento explícito de las librerías y componentes preexistentes que el squad ya tenía antes del proyecto —esos se licencian para el uso del cliente, no se ceden, y el contrato tiene que decir cuáles son.
• Renuncia a derechos morales donde la jurisdicción lo permita, para evitar reclamos posteriores sobre atribución o modificación del código.

¿Qué pasa si nunca se firmó una cesión explícita?

Sin cesión, la empresa que pagó el proyecto queda en una posición legal más débil de la que asume: no tiene un derecho de propiedad que pueda hacer valer frente a un tercero, no puede iniciar una demanda por infracción de copyright sobre ese código sin ser la titular, y cualquier intento de vender el producto, levantar una ronda o cambiar de proveedor técnico puede tropezar con la misma pregunta sin respuesta clara. La tendencia regulatoria va en esta dirección: en California, la Freelance Worker Protection Act —vigente desde enero de 2025— exige directamente que todo contrato con un trabajador freelance esté por escrito, reconociendo que dejarlo verbal o implícito es la causa más común de este tipo de disputas.

¿Cómo lo resuelve Zenit?

En Zenit, la cesión de propiedad intelectual no es algo que cada empresa tiene que negociar desde cero con cada squad: es parte del acuerdo bajo el que un squad opera dentro de la plataforma, no un punto suelto que depende de que alguien se acuerde de pedirlo. Esa claridad contractual se complementa con evidencia verificable: SafePay libera cada pago contra un milestone específico, con criterios de aceptación acordados y trabajo entregado en el repositorio —así que, además del contrato, queda un registro concreto de qué se construyó, cuándo y bajo qué condición.

Esa combinación —contrato claro más evidencia verificable— es la misma lógica que protege a la empresa si un squad no puede terminar un proyecto: lo que ya se construyó y aceptó no depende de la memoria de nadie.