Contrato freelance: propiedad del código fuente

1. Defina con precisión el resultado de propiedad del código

Antes de escribir una sola cláusula, decida qué está comprando realmente el cliente. Una cesión total, una licencia o la propiedad solo después del pago final no son lo mismo, y el contrato debe reflejar el acuerdo comercial que de verdad desea. Si el cliente espera ser dueño del código fuente desde el primer día, dígalo. Si el freelancer conserva los derechos hasta que se pague la última factura, diga eso también. Una sola frase ambigua genera meses de fricción.

Aquí es donde “cómo redactar un contrato freelance para la propiedad del código fuente” empieza a volverse práctico, y donde la expresión contrato freelance propiedad del código fuente ayuda a fijar la idea central del acuerdo. Un fundador de una startup quizá quiera que se le transfiera todo el repositorio, mientras que una pequeña agencia puede necesitar solo una licencia amplia para ejecutar la aplicación. Son acuerdos distintos. Un contrato que los mezcle puede dejar a ambas partes molestas y sin protección completa.

Use el contrato para responder tres preguntas directas: quién es el propietario del código, cuándo cambia la titularidad y si el cliente puede modificar o revender el trabajo. Si la respuesta es “después del pago final”, deje claro que no se producirá ninguna transferencia hasta que el pago se haya acreditado. Si la respuesta es “cesión total desde la creación”, escríbalo con claridad y sin rodeos. Las frases cortas ayudan aquí.

Para una buena comparación sobre el uso cuidadoso de plataformas, vea cómo contratar a un freelancer de forma segura. Ese artículo trata sobre elegir bien a las personas; este trata sobre dejar por escrito el acuerdo una vez que ya las ha elegido.

2. Identifique los activos de código específicos incluidos en el alcance

No deje que “código fuente” quede flotando como una frase bonita. Nombre los activos. Si el proyecto incluye código de la aplicación, scripts, repositorios, archivos de compilación, configuraciones de despliegue, documentación y cualquier código refactorizado o derivado creado durante el proyecto, enumérelos. Un contrato que solo diga “el código” deja la puerta abierta a disputas posteriores. Dos palabras no bastan.

Piense en carpetas y archivos, no en abstracciones. Por ejemplo, el alcance puede cubrir el repositorio principal de la aplicación, un repositorio separado para el panel de administración, scripts de CI, archivos de migración de base de datos, envoltorios de API y un README que explique la configuración local. Si el freelancer crea una versión parcheada de un módulo existente durante el proyecto, decida si ese parche forma parte del entregable. Ese detalle importa.

Una forma sencilla de plantear el alcance es: “Todo el código fuente y los archivos relacionados del proyecto creados para el Proyecto X, incluido el código escrito en el Repositorio A y cualquier código derivado o refactorizado producido durante la vigencia de este acuerdo”. Esa frase no es elegante. Funciona porque nombra el lugar, el tipo de trabajo y el periodo temporal.

Si el proyecto tiene varios repositorios, añada una lista numerada. Un repositorio, una línea. Dos repositorios, dos líneas. El contrato no debería obligar a nadie a adivinar si el paquete de la app móvil cuenta como código fuente o solo como un artefacto exportado.

3. Añada una cláusula clara de cesión de propiedad intelectual

La cláusula de cesión de propiedad intelectual código fuente freelancer es el corazón del contrato. Debe decir que el freelancer cede al cliente todos los derechos, títulos e intereses sobre el código creado. Si la transferencia ocurre al crearlo, dígalo. Si ocurre al pagarlo, diga eso en su lugar. La cláusula no debe depender de una suposición oculta.

Una cláusula práctica podría decir algo como esto: “Tras el pago íntegro de todas las cantidades adeudadas conforme a este acuerdo, el Freelancer cede al Cliente todos los derechos de propiedad intelectual sobre los entregables creados específicamente para el Cliente en este proyecto, excluyendo cualquier material preexistente incluido en el Anexo A”. Esa redacción ofrece un punto de transferencia, una condición de pago y una exclusión. Tres elementos móviles, una sola frase.

Algunos contratos también indican que la cesión tiene efecto en todo el mundo y durante todo el plazo de protección, incluidas renovaciones y prórrogas cuando la ley lo permita. Ese tipo de lenguaje es común porque el software puede durar años, y nadie quiere renegociar la titularidad cuando la aplicación ya está en producción. Una cesión de una sola línea puede quedarse corta si la ley de la jurisdicción aplicable exige más detalle.

Para una visión relacionada sobre términos y reglas de plataformas, la página de reglas del sitio 24freelance.pro. freelance es un buen contexto. No redactará la cláusula por usted, pero le recuerda que las normas formales y el lenguaje contractual no deben entrar en conflicto.

4. Separe las herramientas preexistentes, plantillas y componentes reutilizables

Los freelancers suelen llevar sus propias herramientas al trabajo. Una plantilla, una biblioteca de utilidades personalizada, un envoltorio privado de API o un script de compilación pueden existir antes de que empiece el proyecto. El contrato debe proteger ese trabajo preexistente y, al mismo tiempo, dar al cliente derechos sobre el entregable final. Sin esa separación, el cliente podría creer que compró toda la caja de herramientas.

El método más claro es nombrar los materiales excluidos en un anexo o apéndice. Llámelo Anexo A, Anexo B o Apéndice 1. Liste todas las herramientas, plantillas o componentes reutilizables preexistentes que el freelancer no cede. Si el cliente puede usar uno de esos elementos dentro del entregable, indique si ese uso se hace mediante una licencia y si esa licencia es exclusiva o no exclusiva. Las pequeñas etiquetas evitan grandes conflictos.

Ejemplo: un freelancer crea un flujo de pagos usando una biblioteca privada de validación creada dos años antes. El contrato puede decir que la biblioteca sigue siendo propiedad del freelancer, mientras que el cliente recibe una licencia perpetua para usarla solo integrada en la aplicación entregada. Eso protege el trabajo anterior del freelancer y aun así deja al cliente con un producto utilizable. La línea entre “propiedad” y “licencia” debe verse con claridad.

Este es uno de esos casos en los que el lenguaje de un anexo supera a las promesas vagas. Si el freelancer dice: “Tengo algo de código reutilizable”, eso no basta. Ponga los nombres en un anexo. Ponga las excepciones por escrito. Ponga el número del anexo en el cuerpo principal para que nadie olvide abrirlo después.

5. Establezca requisitos de entrega, acceso al repositorio y traspaso

Las cláusulas de propiedad no bastan si el cliente no puede obtener realmente los archivos. El contrato debería cubrir el acceso a Git, el historial de commits, el traspaso de ramas, la transferencia de credenciales, la documentación y una declaración de que todos los archivos fuente finales se entregan al aceptar. Una cláusula legal bien redactada está muy bien; una contraseña de repositorio que falta, no.

Especifique qué significa entrega. ¿El freelancer sube el código final al repositorio propiedad del cliente? ¿Entrega un archivo zip con el proyecto completo? ¿El traspaso incluye notas de esquema de base de datos, variables de entorno y pasos de despliegue? Si el proyecto depende de una cuenta privada de servicio, el contrato debería indicar cuándo esas credenciales pasan al cliente o se rotan. Un solo token olvidado puede retrasar el lanzamiento.

Mantenga concretos los términos del repositorio. Por ejemplo: “El Freelancer concederá al Cliente acceso de administrador al repositorio del proyecto en la fecha de entrega, conservará el historial de commits salvo que el Cliente solicite un traspaso limpio y transferirá el control de todas las ramas utilizadas para trabajo de producción”. Ese lenguaje cubre acceso, historial y propiedad de ramas en un solo lugar. Si el cliente quiere una rama separada de pruebas, nombrela también.

Unos buenos términos de traspaso también reducen las disputas de “ya lo envié todo”. Si la aceptación depende de la entrega de los archivos fuente finales, diga cuáles son. Si la documentación final incluye notas de configuración, enumérelas. Si el proyecto incluye despliegue en la nube, incluso las credenciales de ese entorno pueden requerir un paso de traspaso separado, y ahí es donde la tecnología de computación en la nube puede influir en la parte práctica de la entrega.

6. Incluya confidencialidad y reglas sobre código abierto y de terceros

La propiedad del código fuente puede complicarse rápidamente cuando entra código externo en el proyecto. El contrato debería restringir bibliotecas no divulgadas, exigir aprobación para el uso de código abierto y obligar a revelar componentes o dependencias de terceros que puedan afectar a la propiedad. Si el freelancer incorpora un paquete bajo una licencia que limita el uso comercial, el cliente debe saberlo antes del lanzamiento, no después de recibir un ticket de soporte.

Establezca una norma para el material de código abierto. Por ejemplo, el freelancer solo puede usar código abierto si el cliente lo aprueba por escrito y solo si los términos de la licencia no entran en conflicto con las expectativas de propiedad del cliente. Eso significa que el freelancer debe identificar cualquier componente GPL, LGPL, MIT, Apache o similar usado en el proyecto y explicar su efecto práctico. Los nombres importan.

El código de terceros merece la misma honestidad. Un SDK de pago, un script de un empleador anterior o un fragmento copiado de un repositorio público pueden complicar la titularidad. El contrato debería exigir la divulgación de cualquier componente así antes de incluirlo. Si hace falta aprobación, convierta la aprobación en un paso formal, no en un mensaje de chat. Una nota en Slack se pierde fácilmente.

La confidencialidad también debería cubrir el contenido de los repositorios, las credenciales, las notas de arquitectura y la lógica de negocio. Eso no es solo un trámite legal. Un competidor que vea el proceso de compilación o el flujo de despliegue puede obtener más de lo que el cliente pretendía compartir. Si el proyecto incluye casos de estudio públicos o uso en portafolio, el contrato debería decir si el freelancer puede mostrar capturas de pantalla después del lanzamiento.

7. Defina la aceptación, el pago y el momento de transferencia de la propiedad

La transferencia de propiedad suele depender del pago. Eso es normal. El contrato debe indicar si la aprobación de un hito o el pago final activan la transferencia de la titularidad, y también debe decir qué ocurre si el proyecto termina antes de tiempo. Si la transferencia se produce en la aceptación, defina la aceptación con claridad. Si ocurre cuando se paga la última factura, escriba esa condición en lenguaje sencillo.

No deje el momento a la memoria. Una cláusula puede decir que los entregables se consideran aceptados tras una aprobación por escrito o tras un periodo de revisión determinado si no llega ningún aviso de rechazo. Luego vincule la transferencia de titularidad a ese evento de aceptación, o a la recepción del pago después de la aceptación. Un evento, una consecuencia. Esa estructura evita que todos discutan sobre el orden de los pasos.

La terminación anticipada necesita su propia regla. Supongamos que el cliente cancela después del hito 2. ¿El cliente posee el código ya pagado? ¿El freelancer conserva los derechos sobre los módulos inacabados? ¿El cliente recibe una licencia para usar el trabajo parcial o solo una copia para revisión interna? El contrato debería responder a esas tres preguntas antes de que nadie empiece a programar.

Para proyectos de mayor riesgo, algunos equipos separan el pago de la propiedad. El freelancer puede recibir pagos parciales en cada hito, mientras que la propiedad del código final solo se transfiere cuando se cierra el último hito. Eso puede funcionar, pero solo si el contrato explica si el código parcialmente pagado puede usarse internamente durante el proyecto bajo licencia. Si la respuesta es no, diga que no.

8. Añada una lista de verificación lista para firmar antes de enviar el contrato

Antes de enviar el contrato, haga una revisión con lista de verificación. Use nombres, rutas y fechas. El nombre del proyecto, la ubicación del repositorio, la cláusula de propiedad, los materiales excluidos, las obligaciones de entrega y cualquier revisión legal necesaria para lenguaje específico de la jurisdicción deben estar presentes. Si falta alguno de esos elementos, corríjalo primero. Una firma apresurada sigue siendo un riesgo.

Esta es una lista práctica previa al envío:

• El nombre del proyecto coincide con la declaración de trabajo.
• La ubicación del repositorio se identifica por URL o ruta exacta.
• La cláusula de propiedad indica cuándo ocurre la transferencia.
• Los materiales excluidos figuran en un anexo.
• Las obligaciones de entrega mencionan archivos fuente, documentación y acceso.
• Las reglas sobre código abierto y de terceros están redactadas.
• La aceptación y el momento del pago están vinculados.
• El lenguaje específico de la jurisdicción ha sido revisado legalmente.

Si el contrato es para un equipo que también valora la reputación pública, conviene revisar las reseñas de freelancers antes de asignar más trabajo. Un contrato puede proteger la propiedad del código, pero no corrige malos hábitos de entrega ni retrasos repetidos. Dos medidas de seguridad son mejor que una.

Un último apunte práctico: si el proyecto está ligado a un flujo de trabajo de una plataforma concreta, el contrato no debería chocar con las normas operativas del sitio, la secuencia de pago o la ruta de aprobación. Por eso muchos clientes mantienen una breve lista de control interna junto al borrador del contrato. Suena simple. Y lo simple es bueno.