Firma el módulo quien lo publica, y el código es de quien lo escribe salvo pacto escrito en contra: así lo dicen las directrices de publicación de Odoo. Ahí empieza el problema de subcontratar un proyecto Odoo ya vendido. Proveedores hay de sobra; lo difícil es hacerlo sin quedarte sin cliente, sin código y sin argumentos dentro de dos años. Eso no lo decide el precio por hora, sino cuatro cosas que casi nunca se escriben: quién consta como autor del módulo, dónde vive el código, con qué licencia se entrega y quién lo porta a la siguiente versión.
Idea clave: el acuerdo de partner de Odoo no dice nada sobre que tú subcontrates a otra empresa. Regula el código de Enterprise, la marca y quién es el interlocutor del cliente. Autoría, propiedad, licencia y mantenimiento van en tu contrato con el subcontratista, o no van en ninguna parte.
Has vendido, el cliente espera y no tienes equipo
Las tres salidas que aparecen primero fallan por motivos distintos:
- Contratar a prisa. Un perfil con Odoo real no aparece en semanas, y acabas con una nómina fija para un proyecto que tiene final.
- Decir que no. Devuelves el proyecto y con él la cuenta: quien lo entregue la tendrá el año que viene.
- Subcontratar a ciegas. Buscar quien lo haga barato y reenviarle el correo del cliente. Es la única opción que puede costarte el cliente entero.
Subcontratar es la respuesta correcta. Lo que la separa de la tercera opción es papeleo, no confianza. Si aún estás eligiendo con quién, los criterios están en cómo elegir un partner o desarrollador de Odoo.
Las tres formas de subcontratar
No son grados de lo mismo: cambian quién da la cara, quién consta como autor y por dónde se rompe.
| Modalidad | Quién da la cara | Dónde se rompe |
|---|---|---|
| White-label puro | Solo tú; el proveedor no existe para el cliente. | El conocimiento del sistema vive fuera de tu empresa y tú respondes de él. |
| Equipo ampliado | Tú; sus perfiles trabajan bajo tu gestión. | Gestionas tú, así que la calidad la asumes tú. Sin criterio de aceptación técnico se va sin que nadie mienta. |
| Proveedor visible, co-marcado | Tú como implantadora; él consta como autor de los módulos. | El miedo a que te quiten el cliente. Se ataja con no captación y plazo, no con confianza. |
Detalle que casi nadie mira: el acuerdo de partner de Odoo sí tiene cláusula de no captación de personal, pero entre Odoo y el partner (sección 8.2), no entre dos empresas del ecosistema. Frente a un subcontratista que se acerca a tu cliente, tu única protección es tu propio contrato.
¿Quién consta como autor del módulo?
Un módulo se publica conectando un repositorio Git a una cuenta del App Store, y la ficha resultante lleva un autor visible. Tres hechos comprobables en la documentación de Odoo:
- El código es de quien lo escribe. Las directrices de publicación del App Store lo dicen literalmente: el código de una aplicación se considera propiedad intelectual de su desarrollador. No de quien paga.
- Quien publica, cobra y soporta. Odoo se queda el 30 % de cada venta y el 70 % va a quien publica; en las apps de pago, sus directrices hacen al autor responsable de resolver en un plazo razonable las incidencias del cliente que la compró.
- Con licencia propietaria, tu cliente compra al autor. La Odoo Proprietary License v1.0 dice que el software solo puede usarse si se ha comprado licencia válida a los autores. Si publica el subcontratista, «los autores» no eres tú.
Si el módulo es a medida y no va al App Store no hay ficha pública, pero la autoría sigue ahí: en la cabecera de copyright de cada fichero y en el LICENSE del repositorio. Ábrelos antes de aceptar la entrega.
Qué dice —y qué no— el acuerdo de partner de Odoo
El acuerdo es público: Odoo lo publica en PDF dentro de su documentación. La versión vigente al escribir esto es la 11, de 19 de mayo de 2023. Cuatro secciones te afectan.
| Sección | Qué significa para tu subcontratación |
|---|---|
| 3.2 · Restricciones | El partner mantiene el código de Enterprise confidencial dentro de su plantilla y no lo redistribuye a terceros sin permiso escrito de Odoo. Tu subcontratista es un tercero: que tenga acuerdo y acceso propios. |
| 4.5 · Comisiones | Dentro de esa sección, el bloque «Maintenance of Covered Extra Modules»: cuando el cliente decide trabajar con el partner, Odoo le delega el mantenimiento de esos módulos y el partner pasa a ser su interlocutor principal. Ante Odoo, el interlocutor sigues siendo tú, subcontrates o no. |
| 8 · Imagen de marca | Odoo autoriza el uso de su marca mientras no haya confusión posible sobre que el servicio lo presta el partner y no Odoo. Regula la confusión con Odoo, no entre dos empresas: el white-label entre partners no está prohibido, pero tampoco cubierto. |
| 8.3 · Contratistas independientes | Las partes son contratistas independientes y ninguna responde por los actos de la otra. La cadena de responsabilidad se construye con contratos, no con sellos. |
El mismo acuerdo describe cuatro niveles: «Learning Partner» figura con visibilidad en odoo.com marcada como «No», mientras que Ready, Silver y Gold sí salen en el directorio público y exigen usuarios de Enterprise vendidos y personas certificadas. No estar no es un defecto, pero conviene que te lo cuenten tal cual es.
Propiedad del código: repositorio, licencia y entrega
El código tiene que vivir desde el primer commit en un repositorio tuyo o de tu cliente, con administración por tu parte. La diferencia con un ZIP en un correo es el historial: quién tocó qué, cuándo y por qué. Sin historial, el siguiente proveedor empieza a ciegas y te lo cobra.
La licencia es la otra mitad. En Odoo conviven tres y no son un detalle del manifiesto: deciden lo que podréis hacer después.
| Licencia | Qué implica |
|---|---|
| LGPL-3 | Licencia del núcleo de Odoo Community y la recomendada para módulos abiertos. Permite módulos propietarios encima. |
| AGPL-3 | Estándar de la comunidad OCA. Su artículo 13 obliga a ofrecer el código a quien interactúe por red con una versión modificada. |
| OPL-1 | Propietaria de Odoo, la de los módulos de pago. Prohíbe publicar, distribuir, sublicenciar o vender copias, también modificadas. |
No hay que elegir una para todo el catálogo. En el repositorio con el que servimos nuestra demo pública hay 83 módulos, y la clave license de sus manifiestos toma exactamente dos valores: 52 OPL-1 y 31 LGPL-3. Lo que no puede pasar es llegar a la entrega sin haberlo decidido: entonces lo decide el manifiesto del subcontratista. El detalle de cada licencia está en nuestra página de licencias.
Y la entrega no es el código a secas: es el código, el manifiesto, los tests, las instrucciones de despliegue y, si quieres la propiedad, una cesión escrita. Se pacta al firmar, no al terminar; así lo planteamos en desarrollo a medida.
El riesgo que casi nadie mira: la siguiente versión
Odoo da soporte estándar a cada versión mayor durante tres años; más allá hay soporte extendido con tarifa adicional obligatoria. La tabla oficial de las tres versiones vivas:
| Versión | Publicada | Fin del soporte estándar |
|---|---|---|
| Odoo 17.0 | Noviembre de 2023 | Septiembre de 2026 (previsto) |
| Odoo 18.0 | Octubre de 2024 | Septiembre de 2027 (previsto) |
| Odoo 19.0 | Septiembre de 2025 | Septiembre de 2028 (previsto) |
Un módulo entregado en Odoo 17 en 2024 tenía fecha de caducidad desde el primer día, y esa fecha es este mes. La documentación oficial es explícita en dos puntos. Uno: una base de datos con módulos a medida no se puede actualizar hasta que exista una versión de esos módulos para la versión de destino; el módulo bloquea la subida entera. Dos: si un cambio de la nueva versión rompe una personalización, es responsabilidad de quien mantiene ese módulo hacerlo compatible. Y el servicio de actualización de Odoo excluye expresamente los módulos creados por terceros, partners incluidos, sin contrato de mantenimiento.
Traducido a tu contrato: dos años después, alguien tiene que portar ese módulo. Si no está escrito quién y a cambio de qué, serás tú, gratis y con un desarrollador que ya no está. Hay dos salidas válidas: mantenimiento con alcance y precio desde el día uno, o entrega de código con licencia que permita migrarlo a cualquiera.
Cómo se verifica lo entregado: build verde, no captura
«Funciona en mi local» no es una entrega, es una opinión. Odoo.sh define los estados sin margen: verde si no se producen errores ni avisos durante la creación del build, amarillo si hay avisos sin errores, rojo si hay errores. En ramas de desarrollo el listón sube: crean base de datos nueva, cargan los datos de demostración y ejecutan los tests unitarios, y el build se considera fallido si los tests fallan durante la instalación. Un verde ahí no es un adjetivo: es base de datos creada desde cero, módulo instalado y tests pasados en la misma plataforma en la que vivirá tu cliente.
Con números nuestros: nuestro conector de Amazon vive en tres ramas —17.0, 18.0 y 19.0— con manifiestos 17.0.6.59.0, 18.0.6.59.0 y 19.0.6.60.0, y 685, 685 y 786 métodos de test respectivamente. Mantener el mismo módulo en tres versiones no es publicarlo tres veces: son tres builds que devolver a verde cada vez que se toca una línea, y tres bases de código que divergen porque la API de Odoo cambia entre versiones mayores. Ese es el coste que un presupuesto barato no incluye. Pide el enlace al build, no la captura, y que la instalación se repita en un entorno tuyo.
Seis preguntas antes de firmar
- ¿Quién consta como autor? En la cabecera de copyright, en el
LICENSEy, si se publica, en la ficha del App Store. - ¿En qué repositorio vive el código desde el primer commit y quién tiene administración? Si te lo entregan al final, no hay historial.
- ¿Con qué licencia se entrega y quién la decide? OPL-1, LGPL-3 y AGPL-3 no son equivalentes: determinan si otro proveedor podrá tocar el módulo mañana.
- ¿Quién lo porta a la siguiente versión mayor, en qué plazo y a qué precio? Con la fecha de fin de soporte escrita en el contrato.
- ¿Cuál es el criterio de aceptación? Escríbelo tal cual: «build verde en Odoo.sh en las versiones X, Y y Z, con tests pasando».
- ¿Puede el proveedor vender directamente a tu cliente? El acuerdo de partner de Odoo no se lo impide: su cláusula de no captación (8.2) es entre Odoo y el partner. Tu contrato sí, con no captación y plazo.
Si alguna se contesta con «eso ya lo vemos sobre la marcha», esa es la respuesta.
Enlaces útiles dentro de FlexigoTech
Preguntas frecuentes
¿Puedo darle el código de Odoo Enterprise a un subcontratista?
El acuerdo de partner de Odoo (versión 11, de 19 de mayo de 2023) dice en su sección 3.2 que el partner mantiene la confidencialidad del código de Enterprise dentro de su plantilla y que no lo redistribuirá a terceros sin permiso escrito de Odoo. Un subcontratista es un tercero: la salida limpia es que tenga su propio acuerdo y su propio acceso.
¿De quién es el módulo que me desarrolla un subcontratista?
Salvo pacto escrito en contra, de quien lo escribe. Las directrices de publicación del App Store de Odoo lo dicen sin rodeos: el código de una aplicación se considera propiedad intelectual de su desarrollador. Si quieres la propiedad, se pacta como cesión por escrito antes de empezar, no al entregar.
¿Qué pasa con el módulo cuando el cliente suba de versión?
Que alguien tiene que portarlo, y la documentación de Odoo dice quién: si un cambio de la nueva versión rompe una personalización, es responsabilidad de quien mantiene ese módulo hacerlo compatible. Además, una base de datos con módulos a medida no se puede actualizar hasta que exista una versión de esos módulos para la versión de destino.
¿Has cerrado un proyecto Odoo y te falta el equipo técnico?
Si has cerrado un proyecto Odoo y te falta la parte técnica, cuéntanoslo: te decimos qué se entrega, con qué licencia y con qué criterio de aceptación, facturado a tu nombre y no al de tu cliente. Escribe a comercial@flexigobe.com o llama al +34 616 809 504.