La respuesta corta
En la mayoría de los casos, cuando el desarrollo del sistema es el objeto mismo del contrato, la ley brasileña de software tiende a dejar los derechos con quien contrató. Esta regla vale salvo pacto en contrario, así que quien decide de verdad es el contrato, y debe decirlo por escrito.
Tener el derecho en el papel tampoco basta. En la práctica, el software solo es suyo cuando usted tiene el código en un repositorio bajo su control, la documentación para que otro equipo entienda el sistema y los accesos a la infraestructura donde funciona. Este texto es una guía práctica, no un dictamen jurídico: revise el contrato con un abogado de su confianza.
Qué dice la Ley 9.609/1998 sobre la propiedad del software
La Ley 9.609/1998, conocida como la ley de software de Brasil, trata el programa de computadora como una obra protegida por el régimen de derecho de autor. La protección existe con independencia del registro. El registro en el INPI, la oficina brasileña de propiedad industrial, es opcional y sirve como prueba de autoría y de fecha, no como condición para tener el derecho.
Para el caso que interesa aquí, la ley establece una regla de partida: salvo pacto en contrario, los derechos sobre el programa desarrollado durante un contrato de prestación de servicios cuya finalidad es justamente ese desarrollo pertenecen a quien contrató. La misma lógica vale para el empleador respecto del empleado contratado para desarrollar software.
El punto que más conflictos genera está en la expresión "salvo pacto en contrario". El contrato puede disponer otra cosa, y muchos lo hacen, a veces en una cláusula genérica que nadie leyó con atención. También hay zonas grises que la regla general no resuelve sola: herramientas y componentes que el proveedor ya tenía antes del proyecto, bibliotecas de terceros y productos propios del proveedor adaptados para usted.
Cesión o licencia: cuál es la diferencia en la práctica
Casi todo contrato de software cae en uno de dos modelos, o en una combinación de ellos. En la cesión, los derechos patrimoniales sobre el código pasan a usted. En la licencia, el proveedor sigue siendo el dueño y autoriza el uso, dentro de las condiciones que fije el contrato.
| Punto | Cesión de derechos | Licencia de uso |
|---|---|---|
| Quién se queda con el código | Usted, como titular de los derechos patrimoniales | El proveedor, que autoriza el uso |
| Acceso al código fuente | Se le entrega, con el historial de versiones | Depende del contrato; muchas veces no se entrega |
| Cambiar de proveedor | Otro equipo puede hacerse cargo del sistema | Exige negociar con el proveedor o empezar de nuevo |
| Cuándo suele tener sentido | Sistema hecho para su operación, que usted quiere evolucionar con libertad | Producto que el proveedor vende a muchos clientes |
| Qué revisar en el contrato | Alcance de la cesión y lo que queda fuera, como componentes previos | Plazo, usuarios, actualizaciones, soporte y qué pasa si el contrato termina |
Ninguno de los dos es incorrecto en sí. Licenciar un producto listo puede ser la mejor opción cuando el proceso es estándar, como explicamos en software listo o a medida. El problema aparece cuando usted paga por un sistema hecho para su operación y descubre, al final, que solo obtuvo el derecho de usarlo.
Un arreglo común y razonable es la combinación: usted recibe la cesión de lo que se construyó para su proyecto y una licencia permanente y gratuita para usar los componentes que el proveedor ya tenía y reutiliza con otros clientes. Lo importante es que esto esté por escrito, con la lista de lo que corresponde a cada categoría.
Qué debe decir el contrato de desarrollo
Antes de firmar, verifique que el contrato responda estas preguntas sin dejar margen de interpretación:
- Quién es el titular del código. La cláusula debe decir si hay cesión de los derechos patrimoniales, desde cuándo vale (en la entrega, con cada pago o al final) y si abarca también la documentación, el diseño y la base de datos.
- Qué queda fuera. Los componentes que el proveedor ya tenía, las bibliotecas de terceros y los productos propios deben estar listados, con la licencia que usted recibe para cada uno.
- Cuándo y cómo se entrega el código. Lo ideal es que el código esté en su repositorio desde el principio, y no que se entregue de una sola vez al final.
- Qué pasa al final del contrato. Plazo de transición, apoyo para pasar el sistema a otro equipo, devolución de accesos y exportación de los datos en formato abierto.
- Confidencialidad y datos. Quién puede acceder a los datos de la operación, con qué finalidad y cómo esto se relaciona con la ley brasileña de protección de datos (LGPD).
Estos puntos valen para cualquier proveedor. Si todavía está eligiendo quién va a desarrollar, entran en la lista de preguntas de la guía sobre cómo contratar una software house.
Qué pedir en la entrega del sistema
La propiedad que no se ejerce no protege a nadie. Si el proveedor desapareciera mañana, la pregunta es simple: ¿otro equipo podría poner el sistema en marcha, entender el código y continuar el trabajo? Para eso, la entrega debe incluir:
- Repositorio de código. En una cuenta de su empresa, con el historial completo de versiones, y no un archivo comprimido enviado por correo.
- Documentación técnica. Cómo está organizado el sistema, cómo instalarlo, cómo publicar una nueva versión y qué integraciones usa.
- Registro de decisiones. Por qué se tomó cada decisión importante, qué riesgos se aceptaron y qué quedó para después.
- Accesos administrativos. Hosting, base de datos, dominio, correo transaccional y servicios de terceros en cuentas suyas, o con usted como administrador.
- Infraestructura descrita. Qué entornos existen, cómo están configurados y dónde se guardan las copias de seguridad.
- Credenciales y claves. Guardadas en un gestor de contraseñas bajo su control, con la lista de para qué sirve cada una.
En nuestro método de trabajo, las decisiones, los criterios de aceptación, las versiones y los riesgos quedan documentados a lo largo del proyecto, y no solo al final. Eso es lo que hace que el conocimiento del sistema no dependa de la memoria de nadie, ni de la nuestra.
Bibliotecas de terceros y código abierto
Ningún sistema moderno se escribe desde cero. Frameworks, bibliotecas y componentes de código abierto forman parte de casi todo proyecto, y eso es bueno: son piezas probadas por mucha gente. Pero no pasan a ser suyas. Cada una tiene su propia licencia, y usted recibe el derecho de usarla en los términos de esa licencia.
La mayoría de las licencias más usadas, como MIT, BSD y Apache, son permisivas: permiten usar y modificar incluso en software cerrado, pidiendo básicamente que se mantenga el aviso de licencia. Otras, como la familia GPL, imponen condiciones sobre la distribución del software que las incorpora. Para un sistema que funciona solo dentro de su operación, esto suele tener poco impacto, pero conviene saber cuáles están en el proyecto.
Lo razonable es pedir al proveedor una lista de las dependencias principales con sus licencias, y el compromiso de no incluir componentes cuya licencia entre en conflicto con el uso que usted pretende dar al sistema.
Cómo evitar depender del proveedor
Quedar atado al proveedor rara vez ocurre por mala fe. Ocurre por acumulación: el código está en la cuenta del proveedor, el hosting está en su tarjeta, solo una persona sabe publicar una nueva versión y nada de eso está escrito. Cuando la relación termina, o cuando esa persona se va, el sistema se convierte en una caja negra.
Algunas prácticas simples lo evitan desde el primer día. Abra el repositorio y las cuentas de infraestructura a nombre de su empresa y dé acceso al proveedor, y no al revés. Pida ver la documentación en cada entrega, y no solo al cierre. Prefiera tecnologías de mercado, con comunidad y profesionales disponibles, a soluciones propietarias que solo el proveedor domina.
Si usted ya está en esa situación, con un sistema antiguo que nadie entiende, el camino suele ser una evaluación técnica antes de cualquier decisión. Hablamos de esto en la guía sobre cómo modernizar un sistema legado, y es el mismo cuidado que aplicamos cuando asumimos el mantenimiento de un sistema hecho por otro equipo en nuestro trabajo de desarrollo de software a medida.