Scroll to top
© 2017, Norebro theme by Colabr.io
en es

Desarrollo de software a medida: arrendamiento de servicios o contrato de obra


El encaje jurídico de los contratos de desarrollo de software en la figura del arrendamiento de servicios o en la de contrato de obra ha sido puesto en entredicho en el marco de varios procedimientos judiciales. Si bien puede parecer que se trata de una discusión meramente teórica, lo cierto es que adquiere una relevancia práctica mayúscula en el marco de la responsabilidad por incumplimiento. Por ello, además de analizar jurídicamente la naturaleza de dicho contrato, este post está destinado a ofrecer una serie de consejos para que las empresas que contraten el desarrollo a medida de un software puedan protegerse debidamente ante el incumplimiento de la contraparte.

Previamente a sumergirnos en la cuestión que da título a este artículo es necesario realizar una breve revisión teórica y jurisprudencial de los elementos que caracterizan –y por tanto diferencian- ambos contratos. El criterio consolidado y pacífico más relevante focaliza la distinción entre un contrato de obra y uno de servicio en el objeto inmediato de la obligación del arrendador: si este se obliga a la prestación de servicios, de trabajo o de una actividad en sí misma, estamos ante un contrato de servicios; si la obligación consiste en producir un resultado, sin consideración al trabajo que lo crea, el contrato es de obra (TS de 6 de mayo de 2004 y TS 9 de enero de 2006).

De lo anterior se deriva que en el contrato de obra se busca fundamentalmente la obtención de un resultado consecuencia de la actividad que el contratista desarrolla, por lo que el cumplimiento depende de la consecución o no del mismo. La parte llamada contratista está obligada, como resalta la Sentencia de 30 de enero de 1.997, a realizar y entregar la obra y que esta sea la prevista, correcta y adecuada, siendo ello determinante del derecho al pago o retribución. Sin embargo, en el contrato de servicios lo que se pretende es el desarrollo de una actividad en sí misma, por lo que el cumplimiento no depende de la consecución del resultado, sino solamente de que se haya hecho todo lo posible para lograr el resultado esperado por el acreedor.

El modo en el que se entienda que las obligaciones han sido cumplidas adquiere gran relevancia práctica en los contratos de desarrollo de software, donde una parte encarga a la otra desarrollar un programa de ordenador que se ajuste a sus necesidades y objetivos, concretando estos con mayor o menor definición según el caso. Dicha relevancia deriva de lo siguiente:

– Si estimamos que nos encontramos ante un contrato de servicios tenemos que interpretar que la empresa desarrolladora de software cumple con el contrato siempre y cuando actúe en su labor de modo diligente, aunque no llegue al resultado esperado por la empresa que la ha contratado. Por tanto, aunque finalizado el plazo fijado por las partes para la entrega del software la empresa desarrolladora no lo hubiese finalizado o el resultado no fuese el acordado, ésta podría eximirse de responsabilidad en tanto en cuanto hubiese hecho todo lo posible por alcanzar el resultado esperado. La carga de la prueba de que los servicios se efectuaron diligentemente recaería, eso sí, sobre la empresa prestadora de los mismos.

– Sin embargo, si entendemos que se trata de un contrato de obra, la empresa será incumplidora cuando no haga entrega del software o cuando este no haya sido ejecutado conforme lo pactado por las partes, por lo que no tendría derecho al pago. Lo importante en este supuesto no es el esfuerzo ni la actividad que el desarrollador haya empleado, no pudiendo eximirse de responsabilidad alegando que ha actuado diligentemente para dar cumplimiento a las expectativas del cliente.

– Los contratos de desarrollo a medida de software encuentran, salvo excepciones, cabida dentro de la figura de los contratos de obra. Para llegar a esta conclusión es determinante analizar cuáles son las necesidades de la empresa que contrata un desarrollo. En primer lugar, desea que el software se ajuste a sus necesidades y a lo convenido y que, en definitiva, se produzca el resultado acordado. En segundo lugar, desea que el software sea realizado y entregado dentro del plazo fijado por las partes, pudiendo programarse dicha entrega en diversas etapas. Como puede observarse, el objeto final del contrato no es otro que la entrega de una obra personalizada, sin que deba inducir a error el hecho de que para cumplir con dicha finalidad sea necesaria la prestación de servicios por parte de la empresa desarrolladora.

Cabría alegar que en caso de que no se den instrucciones claras y precisas de lo que se necesita y que, por tanto, no se defina la obra a realizar, quedaríamos inmersos en el ámbito de los contratos de servicios. Sin embargo, no se puede ignorar que la necesidad de determinación de la obra en el caso de los contratos de arrendamiento de obra es un criterio muy laxo en el marco de las obras de arte, siendo regulados los programas de ordenador de manera paralela a obras literarias en la Ley de Propiedad Intelectual.

Sin embargo, la frontera entre los contratos de obras y de servicios no siempre es nítida, y por ello resulta conveniente establecer unas pautas a la hora de redactar el contrato que regule el desarrollo de software para guiar la interpretación del juez en caso de que se acuda a los tribunales por incumplimiento de la contraparte. Es necesario recordar que la calificación jurídica de los contratos no depende de la denominación que le hayan dado los contratantes, sino de su contenido, por lo que puede no bastar con indicar en dicho documento que se trata de un contrato de obra, sino que es conveniente que empapar el documento de los elementos característicos de los mismos.

Para ello, nos hemos servido de los criterios sintomáticos adicionales utilizados por doctrina y jurisprudencia para distinguir ambos tipos de contratos, aplicando los mismos al contexto del desarrollo a medida de software. Incluir en el contrato las siguientes indicaciones, además de clarificar y ordenar las obligaciones, puede resultarle de mucha utilidad a la hora de reclamar ante un supuesto de incumplimiento o de ser reclamado para pagar el precio de un software que no le ha sido entregado o no le ha sido entregado correctamente:

1) Concreción del software a desarrollar: establecer en el contrato un documento de especificaciones técnicas del software tan detallado como sea posible es altamente aconsejable, si bien, como antes se explicaba, no es determinante para la calificación jurídica del mismo.

2) Fases del proyecto: es conveniente dividir el proyecto por fases y plasmarlo de este modo en el documento contractual. Las fases pueden dividirse en función de los entregables, fijando el modo de aceptación y entrega de cada uno de los mismos de modo claro y preciso.

3) Plazos de entrega: es aconsejable establecer una fecha de entrega del software final. En muchas ocasiones se necesitará dotar a esta fecha de flexibilidad por la naturaleza del software encargado, supuesto en el que deben plasmarse en el contrato los mecanismos que regulen los retrasos.

4) Modo de fijación de la contraprestación: es conveniente no fijar una remuneración individualizada de los servicios prestados por la empresa desarrolladora de software, sino conjunta y total en consideración al resultado proyectado y definitivamente alcanzado.

5) Entrega y aceptación: es fundamental establecer en el documento contractual el modo en el cual se realizará cada una de las entregas, así como el mecanismo o modo de aceptación de cada una de ellas por la contraparte.

Asimismo, y aunque pueda resultar evidente ya que se desprende de la lectura de este artículo, debe evitarse en el contrato en todo momento calificar como arrendamiento de servicios al encargo de desarrollo de software. La mayoría de la jurisprudencia que puede encontrarse al respecto responde a supuestos en los cuales, como consecuencia de haberse calificado como contrato de servicios, se hizo necesario recurrir para obtener un pronunciamiento judicial que llegase a la calificación correcta. Ejemplo de ello es lo establecido en la TS de 24 de noviembre de 2014, donde se establece que a pesar de la denominación dada al contrato y a la constante referencia a servicios como tipo de prestación debida, la correcta calificación es de obra, atendiendo a la voluntad de las partes que se manifiesta en las características del proyecto, en las fases del mismo, en los plazos de entrega y, por último, en la entrega y aceptación del resultado.

En Metricson contamos con un equipo de profesionales con dilatada experiencia en la elaboración de contratos de desarrollo de software y en la resolución de controversias relativas a los mismos. Para más información, no dude en contactarnos.

Por Carlota Corredoira, abogada en Metricson.


Related posts