A. Responsabilidad civil por productos y servicios informáticos defectuosos.
2.1.1. Métodos de análisis y de diseño.
2.1.2. Proyecto de modificación del código civil.
2.1.3. Propuesta de directiva sobre services liability.
2.1.4. Aspectos procesales: la prueba pericial.
B) Responsabilidad civil por infracción de los derechos de autor relativos al software
INTRODUCCIÓN
En las relaciones contractuales que surgen día a día en el mercado informático aparecen conflictos que tienen su origen en problemas de comunicación entre las partes, exceso de confianza o a veces incluso de desconfianza y desequilibrio en el nivel de conocimientos técnicos, entre otras causas.
Vamos a efectuar un rápido análisis de los dos "entornos" en los que más habitualmente plantean reclamaciones judiciales el suministrador o el usuario de productos o servicios informáticos.
Intentaremos localizar las causas de estos conflictos al mismo tiempo que hacemos un repaso de los proyectos legislativos existentes en la actualidad y de las sentencias que hemos podido recopilar.
A. RESPONSABILIDAD CIVIL POR PRODUCTOS Y SERVICIOS INFORMATICOS DEFECTUOSOS.
La compraventa de ordenadores y periféricos no entraña ninguna dificultad a la hora de diseñar el esquema de responsabilidades aplicable a un defecto oculto o a un daño causado por un mal funcionamiento.
El ordenador es equiparable a cualquier otro producto, y le son aplicables por lo tanto las normas relativas a los demás bienes muebles que son objeto de transmisión en el mercado.
Es de destacar, en este sentido el cambio que se va a producir próximamente al entrar en vigor la ley de transposición de la Directiva 85/374/CEE sobre responsabilidad civil por daños causados por productos defectuosos.
Los aspectos más importantes del Proyecto de Ley, que entró el pasado 12 de mayo de 1994 en el Senado, son los siguientes:
1) Se entiende por producto defectuoso aquél que no ofrece la seguridad que cabría legítimamente que esperar, teniendo en cuenta de forma especial su presentación, el uso razonablemente previsible del mismo y el momento de su puesta en circulación.
En el caso del hardware, son realmente trascendentes los dos últimos aspectos.
Un usuario con poca formación en materia informática se muestra a menudo excesivamente optimista frente a las prestaciones que puede ofrecerle un ordenador. El que se inicia como usuario informático sabe que no coincide exactamente con la realidad aquella frase que decía: "tocas una tecla y ya está", pero ello no impide que a veces se contagie por la ilusión de acceder a una nueva tecnología con el convencimiento interno de que todas sus expectativas se verán satisfechas. Por ello, entendemos que el desarrollo del concepto "uso razonablemente previsible" permitirá diferenciar las aptitudes de un equipo informático para satisfacer las necesidades de usuario de acuerdo con unas especificaciones técnicas establecidas y no con unas expectativas subjetivas apartadas de la funcionalidad media.
Por otro lado, el momento de la puesta en circulación es decisivo para analizar a quién debe corresponder el riesgo de la obsolescencia. Aunque un producto no podrá ser considerado defectuoso por el solo hecho de el mismo producto se ponga posteriormente en circulación de forma más perfeccionada, de acuerdo con el artículo 3.2 del proyecto.
2) Entre las causas de exoneración de la responsabilidad del fabricante o del importador de un equipo informático cabe destacar la de que el estado de los conocimientos científicos y técnicos existentes en el momento de la puesta en circulación no permitía apreciar la existencia del defecto.
3) Son ineficaces frente al perjudicado las cláusulas de exoneración o de limitación de la responsabilidad civil por productos defectuosos.
4) La responsabilidad del fabricante o importador podrá deducirse o suprimirse en función de las circunstancias del caso, si el daño causado fuera debido conjuntamente a un defecto del producto y a culpa del dañado o de una persona de la que éste deba responder civilmente.Es de destacar la labor efectuada por los tribunales arbitrales de consumo en la resolución de divergencias causadas por la adquisición de productos informáticos. En muchos casos, el mal funcionamiento del equipo se debe a defectos de escasa entidad cuya reclamación por la vía judicial sería mucho más onerosa.
Deben diferenciarse aquí las reclamaciones que tienen su origen en un defecto del producto, de aquéllas en las que el equipo funciona correctamente, pero no se ajusta a las necesidades del usuario, es decir, se ha entregado un "aliud pro alio"
En este caso debemos distinguir entre el usuario que simplemente adquiere un ordenador y el que contrata una solución. En el primer caso estaremos ante una simple compraventa pero en el segundo concurrirá además un contrato de consultoría, caracterizado por el encargo que hace el usuario para que el suministrador le asesore sobre el producto que se ajuste más a sus necesidades. Aunque este caso corresponde más a un supuesto de servicios informáticos, es habitual ver reclamaciones en las que se solicita la resolución de un contrato de compraventa alegando que el suministrador había incumplido su obligación de entregar un equipo que cumpliese las expectativas del usuario, entendiendo que al existir un desequilibrio entre los conocimientos de ambas partes, debía corresponder al suministrador la elección del equipo más idóneo.
Al usuario le corresponde la carga de la prueba para demostrar la existencia de un contrato previo de consultoría y en la valoración de los medios que aporte deberá tenerse en cuenta la finalidad profesional o doméstica de la adquisición del equipo, el nivel de conocimientos informáticos, el contenido de la oferta del suministrador, la información facilitada por el usuario, etc.
Atendiendo a las reclamaciones estudiadas para la realización de este artículo, podríamos clasificar las causas de la divergencia en las siguientes:
A. Existencia de defectos:
A.1 Defectos de diseño:
– Elección de componentes inadecuados
– Problemas de compatibilidad
– Insuficiencia en la capacidad de memoria RAM, velocidad del microprocesador, capacidad de disco duro, entorno gráfico, etc.
A.2 Defectos de fabricación:
– Componentes defectuosos
– Soldaduras o contactos defectuosos
– Información insuficiente sobre el uso del producto.
A.3 Defectos de instalación:
– Imputables al fabricante.
– Imputables al distribuidor o instalador
– Imputables al usuario
B. Solución global inadecuada
C. Insuficiencia de la información facilitada por el usuario
D. Mal uso por parte del usuario
1.2. SOFTWARE
Cuando hablamos del software como producto nos referimos a los paquetes standard, y su tratamiento no difiere mucho, en cuanto a la responsabilidad del fabricante, de los productos de hardware a los que hemos hecho referencia en el apartado anterior.
En este caso cobra mayor importancia el problema de las expectativas del usuario, ya que, mientras la concepción de cuáles son las funciones de un ordenador está clara para la mayoría de usuarios, las dudas sobre la idoneidad de un programa de ordenador pueden ser importantes si no media el asesoram iento de un profesional informático.
Dentro de los niveles de adaptación de un programa a las necesidades de un usuario determinado cabe distinguir:
– El paquete estándar, cuyo grado de adaptación es mínimo, por ir dirigido a una pluralidad de usuarios. En este caso, la responsabilidad del fabricante del producto por la idoneidad de sus funciones, es decir, por el grado de satisfacción de las necesidades del usuario, acostumbra a estar excluida, por la heterogeneidad de las prestaciones que necesita cada usuario. El suministrador sólo será responsable de la idoneidad del programa cuando haya efectuado un análisis previo de las necesidades del usuario y haya aconsejado la adquisición de ese paquete de forma errónea. Estaríamos ante el caso, antes comentado, del servicio de consultoría previo que puede acompañar a la adquisición de un producto informático.
– El paquete standard personalizado, o adaptado a un cliente concreto. En este caso el nivel de satisfacción del usuario es superior, pero cabe también la posibilidad de error en la elección de esta solución y no la de un desarrollo a medida. Generalmente estamos ante un contrato híbrido, formado por una licencia de uso y un arrendamiento de obra consistente en la adaptación del programa. El origen de algunas reclamaciones en las que se solicitaba la resolución de un contrato de esta naturaleza ha estado en la excesiva confianza del suministrador en la flexibilidad del programa, en una afán comercial por vender un producto determinado o en una indefinición del usuario respecto a sus necesidades informáticas.
– El programa desarrollado para un cliente específico, en el que el usuario tiende a esperar que todas sus necesidades se vean satisfechas. Este tipo de contratación será objeto de un estudio específico en el apartado de servicios informáticos.
Para concluir, una sentencia que resalta los riesgos de la contratación verbal en materia de informática. Se trata de un caso en el que el usuario de una aplicación vertical destinada al sector de Administradores de Fincas solicita a su suministrador el código fuente del programa que hasta esa fecha venía utilizando en código objeto. El Administrador de Fincas dispone de un informático en plantilla que precisa el código fuente para efectuar ciertas adaptaciones del programa. Tras pactar verbalmente las condiciones de la entrega y el aplazamiento del pago, el usuario recibe el código fuente, pero transcurrido un tiempo, el informático que debía efectuar la modificación, se ve incapaz de hacerlo, por exigir tal operación unos conocimientos técnicos superiores a los que realmente tenía. Ante la imposibilidad de sacar provecho al referido código fuente sin un desembolso mayor y estando pendientes las cantidades aplazadas, el usuario decide devolverlo al suministrador, solicitando la resolución del contrato.
Tras las correspondientes negociaciones y requerimientos notariales el suministrador interponde una demanda contra el usuario exigiendo el pago de las cantidades aplazadas. El usuario contesta y reconviene solicitando la resolución del contrato por considerar que el suministrador tenía la obligación de instalar el código fuente a satisfacción del cliente y que dicha obligación se ha incumplido al haberse entregado el código fuente en sus soportes y no haberse efectuado la puesta en marcha. El Juzgado de 1ª Instancia, acudiendo a las obligaciones del suministrador en el contrato relativo al código objeto, e interpretando ampliamente la palabra instalación como puesta en marcha a satisfacción del cliente, entiende que el suministrador ha incumplido el contrato y que procede la resolución del mismo. Apelada la sentencia, ésta es ratificada por la Audiencia Provincial.
Entendemos que todo ello se habría evitado si el suministrador hubiese establecido contractualmente que su obligación se limitaba a la entrega del código fuente, corriendo a cargo del usuario la adaptación e instalación del mismo. No obstante, es evidente que falta una unificación de la terminología informática desde el punto de vista de su significación jurídica, por lo que se hace aconsejable el típico apartado de definiciones en los contratos.
2.1.1 Métodos de análisis y de diseño
Los problemas que más habitualmente originan desacuerdos en los proyectos informáticos son los siguientes:
– Inicio de la programación sin análisis funcional: A pesar de que parece increíble que ello pueda ocurrir, el exceso de confianza entre las partes, o la aparente ausencia de dificultad de un proyecto, hacen que, en ocasiones se inicie la fase de programación sin que ambas partes hayan planteado los objetivos a alcanzar ni se hayan descrito las funciones que el programa deberá llevar a cabo para satisfacer las necesidades del cliente.
– En otras ocasiones se ha realizado un análisis funcional, pero la metodología empleada ha sido incorrecta, por lo que el análisis es defectuoso o insuficiente.
– En muchos casos, la propia inexperiencia del usuario no le permite conocer cuales son exactamente sus necesidades, por lo que la información recibida por la empresa de desarrollo es incompleta y obliga a constantes replanteamientos del proyecto.
– También se da la circunstancia de que el usuario dispone de experiencia e incluso de personal informático propio, pero los cambios de criterio sobre la estrategia de la empresa a largo plazo o los cambios de interlocutor son los que originan los cambios en el proyecto.
Teniendo en cuenta que un cambio funcional a mitad de un proyecto obliga a replantear aspectos básicos del mismo, y por lo tanto, a empezar de nuevo módulos enteros del mismo, será fácil comprender que, cuando concurre una de las circunstancias antes descritas, o el usuario acabe pagando un precio superior al inicialmente presupuestado, o la empresa informática acabe el proyecto con una pérdida importante de dinero. Todo ello suponiendo que una de las partes no haya solicitado la resolución del contrato con anterioridad a la finalización.
Por ello, en la difícil tarea de atribuir la responsabilidad del fracaso del proyecto, habrá que tener en cuenta los siguientes elementos:
– Nivel de formación y experiencia informática de ambas partes.
– Existencia o no en la plantilla del usuario de técnicos informáticos que participen activamente en la fase de análisis funcional.
– Empleo de una metodología de análisis y diseño correcta.
– Nivel de rotación del personal de ambas partes asignado al proyecto.
– Existencia de circunstancias internas o externas que incidan en el proyecto: fusión de empresas, cambios organizativos, cambios legislativos, etc.
Hay que añadir que una parte importante de la carga probatoria relativa a este tipo de demandas se ha centrado en demostrar si la relación contractual pivotaba sobre la base de un arrendamiento de servicios o de un arrendamiento de obra, es decir, si la empresa informática estaba obligada a una prestación o a un resultado.
Es evidente que toda prestación de actividad tiende a un resultado, pero de lo que se trata es de determinar si el resultado ha sido incorporado en el contrato y, en caso afirmativo cuál de los posibles resultados, hasta el punto de que el obligado se comprometa a conseguirlo.
La regulación del Código Civil y la jurisprudencia aplicable no podían escapar a la "vis atractiva" de la obra inmobiliaria, por lo que tal régimen ha resultado en ocasiones poco esclarecedor.
Merece, por ello un estudio aparte el proyecto legislativo que pretende subsanar esta insuficiencia.
2.1.2 Proyecto de modificación del Código Civil
De acuerdo con el Proyecto de Ley publicado el pasado 12 de abril de 1994 en el Boletin Oficial de las Cortes, por el que se modifica la regulación del Código Civil sobre los contratos de servicios y de obra, los puntos más destacados de la reforma son:
El artículo 1.583 del Proyecto define el contrato de servicios como aquél en el que una de las partes se obliga, a cambio de una retribución, a realizar determinada actividad considerada en si misma y no por su resultado.
Por otro lado, el artículo 1.588 del Proyecto define el contrato de obra como aquél mediante el cual el contratista se obliga a ejecutar determinada obra a cambio de la prestación convenida, entendiéndose por obra la construcción, reparación o transformación de una cosa, así como la obtención de cualquier otro resultado convenido por las partes.
Cabe resaltar la novedad introducida por el Proyecto al ampliar el concepto de obra no sólo a la construcción de una cosa, sino también a su reparación o transformación.
Piénsese que parte de los esfuerzos probatorios en las demandas de este tipo consisten en demostrar que la adaptación de un programa standard a las características específicas de un determinado usuario constituye un arrendamiento de obra.
Recordemos el supuesto antes comentado del contrato híbrido formado por la cesión del derecho de uso de un programa de ordenador standard y el arrendamiento de obra consistente en su personalización.
Es importante el régimen establecido para la entrega, la recepción y la presunción de aprobación. Así, el artículo 1.592 establece que la obra deberá ser realizada y puesta a disposición del comitente en el plazo convenido.
A tal fin, deberá el contratista comunicar al comitente la conclusión de la obra, para que proceda a su recepción, que se realizará en el momento que ambos convengan o, en otro caso, al concluir los diez días siguientes. En la recepción podrá el comitente, con los asesoramientos que estimare pertinentes, formular reservas, señalando los vicios manifiestos que apreciare, o rechazarla.
Si no hubiese existido recepción expresa, se entenderá que la recibe y aprueba si transcurren sin protesta otros diez días.
Sigue el sistema anterior respecto a la obra hecha a satisfacción del usuario, en el sentido de que se entiende reservada la aprobación, a falta de conformidad a la decisión de peritos que nombren las partes.
La aprobación explícita o implícita excluye la responsabilidad del contratista por los vicios o defectos que al tiempo de la recepción de la obra fueren manifiestos, y también por los que no lo fueren si quién aprobó la obra hubiera podido conocerlos fácilmente por razón de su oficio o profesión.
Tampoco responderá el contratista de los vicios o defectos imputables al comitente ni de los que se deban a la mala calidad de los materiales elegidos o aportados por éste, si el contratista hubiera advertido esta circunstancia antes de utilizarlos o de incorporarlos a la obra.
De existir vicios o defectos de los que deba responder el contratista el comitente podrá optar entre rebajar una cantidad proporcional del precio o exigir que aquéllos sean corregidos por el contratista; en este caso y si no los corrige en plazo prudencial, después de haber sido requerido, o si la reparación no permite demora, podrá hacerlo el comitente con cargo al contratista.
Debe tenerse en cuenta que en muchos casos los defectos son de imposible corrección debido a que:
-o bien la especial forma de trabajar de la empresa informática impide la continuación del proyecto por un tercero.
-o bien la pérdida de confianza entre las partes impide el acuerdo y la transmisión de información necesarios para la corrección.
Por ello el Proyecto prevé que cuando los vicios o defectos hagan la cosa inadecuada para su uso normal o convenido o resulten de imposible corrección, podrá, además el comitente optar por la resolución del contrato.
En este caso, si la obra queda incorporada a cosa propia del comitente, el contratista tendrá derecho a reclamar la utilidad que la obra reporte al comitente sin que exceda de su coste. Todo ello sin perjuicio de la obligación del contratista de indemnizar daños y perjuicios si procediere.
Se tendrán por no puestas las cláusulas que excluyan o limiten la responsabilidad del contratista por vicios o defectos de la obra.
El plazo de prescripción de estas acciones es de tres años a partir de la recepción de la obra.
Otra importante novedad es que en el caso de que el comitente desista, por su sola voluntad de la obra ya empezada, deberá indemnizar al contratista todos sus gastos y trabajo, así como el beneficio que habría obtenido de haberla terminado.
Respecto a los cambios funcionales y aumentos de carga comentados con anterioridad, el Proyecto establece que las variaciones en el encargo requerirán la conformidad de ambas partes. No obstante, el contratista deberá atenerse a las ordenadas por el comitente que, sin alterar sustancialmente la obra, supongan aumento o disminución que no exceda de la décima parte del presupuesto. En tal caso, quedará modificado proporcionalmente el precio y, si el contratista lo pidiera, se modificará adecuadamente el plazo de ejecución de la obra.
Esta última regla se aplicará cuando las variaciones vengan impuestas por exigencias legales técnicas o para respetar derechos de terceros. Si suponen aumento o disminución que exceda de la cuarta parte del presupuesto, cualquiera de las partes podrá desistir del contrato. Si es el contratista el que desiste tendrá derecho al coste de la obra realizada. Si es el comitente, deberá el precio de la misma.
A continuación se introduce la novedad a nuestro juicio más importante aplicable al desarrollo de software, la penalización de una de las partes por su falta de previsión. Hemos dicho anteriormente que la empresa informática no debe ser responsable de la falta de previsión del usuario en el momento de describir sus necesidades. Al mismo tiempo la empresa informática debe tener en cuenta la posible obsolescencia del programa y el natural crecimiento o evolución del usuario.
El Proyecto de modificación del Código Civil resuelve el asunto estableciendo que si las variaciones se deben a falta de previsión de alguna de las partes, ésta indemnizará los daños y perjuicios y quedará privada de la facultad de desistir.
2.1.3. Propuesta de Directiva sobre Services Liability
Al igual que existe una Directiva Comunitaria sobre responsabilidad por productos defectuosos, existe una Propuesta de Directiva relativa a la responsabilidad de los prestadores de servicios, de contenido similar.
El concepto de servicio queda definido como cualquier transacción realizada con finalidad comercial o mediante un servicio público y de forma independiente, onerosa o gratuita, que no tenga como objeto directo y exclusivo la fabricación de bienes muebles o la transferencia de derechos reales o de propiedad intelectual.
El perjudicado deberá demostrar el daño y la relación causal entre la prestación del servicio y el daño.
El prestador de un servicio no puede limitar o excluir su responsabilidad.
Los derechos de los perjudicados se extinguirán en el plazo de cinco años desde la fecha de prestación del servicio.
2.1.4. Aspectos procesales: la prueba pericial
Los procedimientos relativos a la resolución de contratos de desarrollo de software tienen especiales dificultades en el periodo de práctica de la prueba. No todas las reclamaciones que se producen afectan a proyectos previstos para el entorno PC.
Cuando se trata de grandes configuraciones, de programas extremadamente complejos, de lenguajes de programación poco conocidos o de sistemas operativos en los que hay pocos especialistas, a la tarea de buscar un perito imparcial y conocedor de la materia se une la incertidumbre sobre si va a aceptar el cargo o no.
Hay que tener en cuenta que en muchos casos, la emisión del informe pericial implica muchas horas de dedicación, y el perito es generalmente un profesor de informática o un profesional que tiene su propio trabajo que atender. Además, si la parte condenada en costas es insolvente, es difícil que el perito llegue a cobrar sus honorarios.
Todo ello hace que, en los casos de prueba pericial compleja, exista una cierta desmotivación del perito para aceptar el cargo. No obstante, debemos resaltar el trabajo efectuado hasta la fecha por la Asociación de Técnicos de Informática ATI, en la localización de peritos informáticos para la Administración de Justicia y en la unificación de metodologías periciales. En el número 103 de la revista NOVATICA se hace un magnífico estudio monográfico sobre la llamada auditoría pericial.
Pero a la dificultad de encontrar un perito idóneo se une la de la escasez de tiempo para la práctica de la prueba pericial. Los plazos de los juicios declarativos son totalmente insuficientes para oficiar a la correspondiente universidad o asociación profesional, preparar la terna, insacular, aceptar el cargo, analizar el programa objeto del litigio y emitir un informe. Por ello, en este tipo de procedimientos siempre se acaba acudiendo a las medidas para mejor proveer.
Fijémonos por ejemplo en esta propuesta de pericial: Pericial informática: Consistente en que por un perito técnico en informática, designado por la Asociación de Técnicos de Informática, ATI, con domicilio en c/ Padilla 66, 3-D, Madrid 28006, y experto en lenguaje YYYY, emita dictamen acerca de los siguientes extremos:
1) Grado de veracidad de las siguientes afirmaciones:
- En el método de diseño informático XXXX el cliente participa activamente en la fase de análisis funcional.
- En el dicho método XXXX, los dirigentes de la compañía cliente fijan los objetivos a perseguir por el estudio del proyecto y toman las decisiones entre las posibles soluciones que se presentan como alternativas para obtener y satisfacer sus objetivos.
- Los usuarios del sistema informático del cliente indican las necesidades detectadas en la ejecución de tareas y comunican la forma en que se efectúan dichas tareas.
- Si el cliente incumple su obligación de comunicar sus necesidades reales en la fase de análisis, el proyecto deberá ser revisado en la fase de desarrollo.
- Si el cliente introduce cambios funcionales durante la fase de desarrollo se producirán inevitables replanteamientos y retrasos en el proyecto.
- La fase final del método XXXX está destinada a la depuración y subsanación de errores.
- El Business Process Engineering (BPR) consiste en un rediseño de procesos que comporta cambios organizativos importantes en una empresa y afecta a los proyectos informáticos que en ese momento se estén desarrollando.
2) Estudio de la auditoría o control de calidad efectuada por el usuario, y aportada como DOCUMENTO NUEVE de la contestación a la demanda, con el fin de comprobar:
- si son correctas las conclusiones a las que llega el informe.
- en caso de ser ciertas:
- si los problemas detectados son o no, subsanables.
- si los problemas detectados impiden totalmente el funcionamiento de la aplicación.
- número de horas aproximado, que sería necesario para la subsanación de los problemas apreciados.
- si se hace referencia a nuevas funciones no previstas en el Análisis Funcional de la aplicación AAAA.
3) Análisis de la aplicación actualmente explotada por el usuario, con el fin de comprobar:
- Si se cumplen las especificaciones técnicas contenidas en el Análisis Funcional de la aplicación AAAA.
- Si aparecen nuevas funciones no previstas en el Análisis Funcional de la aplicación AAAA.
- Si están subsanados los errores descritos en la auditoría realizada por el usuairo, aportada como DOCUMENTO NUEVE de la contestación a la demanda.
4) Examen del sistema informático del usuario, con el fin de comprobar:
- si en las historizaciones de la aplicación AAAA efectuadas por el usuario con posterioridad al mes de marzo de 1992 aparecen movimientos que tambien sean posteriores a esa fecha en los que se hayan utilizado los códigos de usuario 123456 asignados a los técnicos de la demandante y por lo tanto determinar si ésta estuvo trabajando en la aplicación AAAA con posterioridad al mes de marzo de 1992.
- Si existe algún fichero o tarea informática efectuada con alguno de los anteriores códigos en el mismo periodo de tiempo.
- Si los movimientos o ficheros informáticos realizados en el periodo antedicho y utilizando alguno de los códigos referidos contienen subsanaciones de incidencias de la aplicación AAAA.
- Si la historización de la aplicación AAAA más cercana al mes de octubre de 1992 cumple las especificaciones funcionales contenidas en el Análisis Funcional de la aplicación AAAA
En esta propuesta de prueba pericial se encuentran casi todos los elementos que son objeto de análisis en un procedimiento de este tipo, por lo que consideramos interesante haberla reproducido en su totalidad, a pesar de su extensión.
El contrato de depósito o escrow, tiene como finalidad garantizar al usuario el acceso al código fuente del programa cedido en el caso de desaparición de la empresa titular de los derechos de propiedad intelectual.
En algunos casos, también se garantiza la disponibilidad del código fuente para la prestación del servicio de mantenimiento en los supuestos de imposibilidad de prestación por el titular debido a una serie de causas enumeradas en el contrato.
Este contrato está basado en la protección de elementos integrantes del código fuente que no pueden ser protegidos por la propiedad intelectual sino por el mantenimiento de un estricto secreto sobre los mismos: métodos, sistemas de trabajo, soluciones específicas, uso combinado de utilidades, etcétera…
El régimen del escrow consiste en la entrega del programa fuente a un feadtario público o asociación profesional que se convertirá en depositario del programa, asumiendo la función de custodia.
El depositario asume la obligación de entregar al usuario designado en el contrato, o legitimado por una licencia de uso, el código fuente depositado, cuando concurran las circunstancias especificadas en el contrato de escrow.
El titular de los derechos de propiedad intelectual que efectúe el depósito deberá comunicar y depositar las actualizaciones o transformaciones que realice sobre el programa fuente depositado.
Asimismo, deberá comunicar al depositario cualquier cambio de domicilio o transmisión de los derechos de propiedad intelectual sobre el programa depositado, que se produzcan a partir de la fecha de depósito.
A continuación efectuamos una reseña de las cuestiones relacionadas con la responsabilidad civil que afectan a un contrato de mantenimiento:
- contenido del servicio de mantenimiento: la finalidad de esta cláusula es establecer una delimitación clara de las prestaciones que se contratan y de las que quedan excluidas del servicio de mantenimiento. Es interesante configurar estas prestaciones en el contrato como módulos independientes, de esta forma el contrato puede ajustarse al tipo de programa o equipo informático objeto del mantenimiento. Los módulos más habituales son los siguientes:
- -Hot line.
- -Adaptación a cambios legales.
- -Corrección de errrores.
- -Adaptación a cambios sectoriales.
- -Nuevas versiones o actualizaciones.
- -Recuperación de información.
- -Servicio de back up.
- -Detección y prevención de virus.
- -Servicio de escrow.
- -Responsabilidades de la empresa informática: además de las obligaciones correspondientes a cada módulo, la empresa que presta el servicio de mantenimiento acostumbrará a responsabilizarse de dar un plazo de respuesta en un determinado tiempo, de tener disponibilidad de personal especializado, de respetar la confidencialidad de los datos a los que tenga acceso, de no destruir información, de indemnizar al usuario en cao de destrucción de información, etc.
- -Responsabilidades del usuario: el usuario acostumbra a estar obligado a facilitar la prestación del servicio de mantenimiento, a conservar la documentación y los discos originales del programa , a realizar copias de seguridad de forma periódica, a facilitar la información que le sea requerida, a nombrar un interlocutor y a notificar el traslado de los equipos.
Respecto a la responsabilidad de ambas partes por la cesión temporal de trabajadores en el caso de que ésta sea una práctica habitual de la compañía informática, nos remitimos a la recientemente aprobada Ley 14/1994 de 1 de junio, por la que se regulan las empresas de trabajo temporal, y que fue publicada en el B.O.E. de 2 de junio de 1994.
A continuación efectuamos una reseña de las cuestiones relacionadas con la responsabilidad civil que afectan a un contrato de outsourcing:
Plan de acción: El plan de acción proporciona una oportunidad para que ambas partes reflejen el acuerdo alcanzado respecto a los objetivos que van a establecerse. A partir de su aceptación, constituirá la mejor referencia escrita a la que podrá acudirse para comprobar si los resultados de la colaboración son positivos.
Por ello es importante que el plan de acción reúna los siguientes requisitos:
- Debe ser exhaustivo y detallado: Es indispensable que incluya todas las actividades que van a desarrollarse, los plazos previstos para cada fase y una previsión de las necesidades que puedan surgir a medio y largo plazo.
- Debe estar integrado por el plan general de la empresa, y por lo tanto, ser fiel a la estrategia global de la misma.
- Contendrá los objetivos a alcanzar y un orden de prioridades.
- Irá firmado por las dos partes como prueba de la aceptación de su contenido.
- Formará parte del contrato como anexo.
La división del contrato en módulos que representen las diferentes prestaciones a contratar facilitará la diferenciación entre ellas y definirá la existencia de un outsourcing total o parcial.
Dentro de las actividades relacionadas con el outsourcing destacan:
– consultoría.
– desarrollo de aplicaciones.
– implantación de aplicaciones.
– formación.
– mantenimiento: preventivo, correctivo y actualizaciones.
– operación.
– servicios de redes.
– servicios de back up.
Es importante definir las áreas o departamentos de la empresa que se verán involucrados en el outsourcing.
Es normal que el ámbito de aplicación esté constituido por la totalidad de la empresa aunque en ocasiones, la decisión de externalizar la gestión de los sistemas informáticos afecta sólo a determinados departamentos.
Resulta imprescindible establecer en el contrato la existencia de un interlocutor individual o colectivo al que se asignarán las siguientes misiones:
– interface entre la gerencia de la empresa y el socio tecnológico.
– comprobación del cumplimiento del plan de acción.
– coordinación global a través de reuniones periódicas.
– elaboración de informes sobre disponibilidad, tiempo de respuesta, calidad, etc.
– Garantías que acostumbran a incluirse:
– garantía de funcionamiento.
– garantía de idoneidad de la solución.
– garantía de economía de costes.
– control de calidad.
– disponibilidad/tiempo de respuesta.
– seguridad de datos/back up.
– garantía de acceso al código fuente/escrow.
-Plazos de entrega:
Es conveniente definir en los anexos correspondientes los plazos de finalización y entrega de cada prestación, siendo recomendable en ciertas ocasiones el establecimiento de cláusulas de penalización que aseguren la cobertura de los daños que pueda provocar el retraso.
Debe quedar estipulado quién asume los riesgos y responsabilidades derivados de la relación contractual.
Entre ellos destacan especialmente:
Riesgo de obsolescencia: es una característica propia del contrato de outsourcing la transmisión del riesgo de obsolescencia del sistema al suministrador del servicio.
Solución inadecuada: en los casos de outsourcing total, el socio tecnológico participa de las decisiones estratégicas relativas a la configuración del sistema, y define cuál es la solución más idónea para las necesidades presentes y futuras del usuario. En caso de elegir una opción incorrecta es lógico que la responsabilidad recaiga sobre el suministrador del servicio.
Mal funcionamiento: se definirán las responsabilidades y el tipo de daños de los que cada parte deberá responder.
Pérdida de datos: también se establecerá el régimen de responsabilidades respecto a la destrucción o a la pérdida de información.
Finalmente, es aconsejable incluir en el contrato la obligación de ambas partes de contratar un seguro de responsabilidad civil que cubra las responsabilidades que a cada una puedan corresponder.
B) RESPONSABILIDAD CIVIL POR INFRACCION DE LOS DERECHOS DE AUTOR RELATIVOS AL SOFTWARE.
Consiste en la reproducción no autorizada de un programa con el fin de utilizarlo en diversos ordenadores de la empresa.
El usuario puede realizar una copia de seguridad del programa, pero si la utiliza se convierte en una copia no autorizada.
1.2. Venta por correo
Este tipo de infracción la realizan normalmente aficionados a la informática que actúan de forma individual, aunque a veces pueden constituir una compañía mercantil o un club de usuarios.
En la mayoría de los casos se anuncian en revistas de anuncios de inserción gratuita o en prensa especializada en informática, ofreciendo la venta de programas de todo tipo y de videojuegos.
El origen de estas copias suele estar en la reproducción no autorizada de un original o de otras copias obtenidas mediante el mismo sistema.
En este caso la infracción puede consistir en la entrega de copias no autorizadas en disco flexible o ya instalados en el disco duro, como estímulo para la venta de ordenadores.
La infracción puede consistir tanto en la entrega de copias no autorizadas a los alumnos como en la reproducción no autorizada de programas con el fin de instalarlas en los ordenadores de las aulas de formación.
La actividad infractora del empleado de una empresa de software consiste habitualmente en la comercialización no autorizada de un programa propiedad de la propia compañía en la que prestaba sus servicios. Este supuesto se diferencia del caso del distribuidor no autorizado en dos factores:
– El ex-empleado ha tenido acceso al código fuente y es probable que tenga una copia del mismo.
– El ex-empleado ha participado en el desarrollo del programa, por lo que es posible que reivindique algún derecho sobre el mismo.
La posesión del código fuente permitirá al ex-empleado modificar o enmascarar el programa con el fin de cambiar su apariencia externa y evitar la identidad con el original. En caso de reclamación, esta circunstancia obligará al actor a proponer un examen pericial del programa para determinar el grado de similitud y la existencia o no de una reproducción total o parcial.
Otra actividad del ex-empleado desleal que se ha convertido en habitual consiste en entrar en contacto con los clientes de la empresa titular del programa, con el fin de sustituir a ésta en el servicio de mantenimiento, para lo cual el infractor acostumbrará a realizar las siguientes acciones:
– Copia no autorizada del programa fuente.
– Modificación no autorizada del programa fuente.
– Compilación, reproducción y cesión no autorizadas del programa modificado.
2.1 Sentencia firme del Juzgado de lo Penal Nº 20 de Barcelona de fecha 18 de octubre de 1993: "Reproducción, conforme al artículo 18 LPI la constituye la fijación del programa de ordenador en un disquette o en una cinta magnética, dado que los mismos son medios que permiten almacenar cualquier información codificada.
Es indiferente para la protección de los derechos de Propiedad Intelectual que la obra esté inscrita Registro de la Propiedad Intelectual, ya que la inscripción tiene carácter declarativo del derecho y no constitutivo.
Los actos externos y obetivos que determinan el elemento subjetivo del dolo son: la dedicación del acusado a la informática, es un profesional del medio que conoce las reglas que rigen el uso de los programas y la prohibición de copiar.
El acusado actuaba movido por el ánimo de lucro. Es evidente que la enseñanza privada constituye una actividad comercial que produce beneficios. Con la copia se reducían los costes del curso y aumentaba el margen de beneficio.
El artículo 37 LPI no tiene aplicación en relación a los programas de ordenador en virtud de los dispuesto en el artículo 99.2 LPI, en el que se indica que la reproducción, incluso para uso personal, exi-girá la autorización del titular.
El centro, como responsable civil subsidiario, deberá indemnizar a los perjudicados en la remuneración que habrían percibido de haber autorizado la explotación, de acuerdo con el artículo 125 LPI.
No consta acreditado que los titulares de los derechos de explotación sufrieran daños morales por el proceder del acusado. Distinto hubiera sido que se hubiera alterado la configuración inicial del programa, con menoscabo de imagen."
2.2 Sentencia del Juzgado de lo Penal nº 13 de Madrid, de fecha 21 de julio de 1993, ratificada por la Audiencia Provincial, Sección Sexta, el 22 de febrero de 1994: "De la relación de clientes, encriptada en el disco duro, y de los movimientos de sus cuentas corriente resulta que el acusado recibía abonos por giro postal por cantidades no elevadas, síntoma típico de pago a distancia y, por consiguiente, de ánimo de lucro.
No consta valoración económica de las copias ilícitas que permita comprobar la concurrencia de la agravante de "especial trascendencia económica". Pero la existencia de copias y ventas anteriores configuran un delito continuado.
El acusado deberá indemnizar a los perjudicados que han ejercitado la acción civil en el precio que tenían los programas copiados en la época de los hechos y en que fueron intervenidos al acusado."
2.3 Sentencia firme del Juzgado de lo Penal Nº 1 de León de fecha 2 de julio de 1993: "Es notoria la relevancia alcanzada por la difusión pública de la problemática relativa al fraude y la piratería informática, lo que no puede ser desconocido por el público en general y menos aún por quien es un experto en informática.
Y máxime cuando en la primera pantalla de los programas propiedad de la acusación aparece la mención Copyright. Deberá valorarse incluso el posible daño moral o desprestigio que para la firma titular de los derechos sobre los programas pudiera derivarse de la divulgación por el acusado de los programas no actualizados, dada la constante evolución y actualización a que se someten los programas técnicos."
2.4 Sentencia de la Audiencia Provincial de Valencia, Sección Cuarta, de fecha 29 de noviembre de 1993: "El delito provocado viene constituido por una inducción engañosa de un agente que incita a perpetrar un delito a quien previamente no tenía tal propósito, siendo la actividad del provocador determinante en la acción delictiva.
No existe quebranto del principio de legalidad cuando se trata de descubrir delitos ya cometidos, generalmente de tracto sucesivo, porque en tales casos el provocador no busca la comisión del delito, sino acreditar el ya cometido.
En orden a la responsabilidad civil, el artículo 534 Ter. del Código Penal contiene una remisión a lo establecido en la LPI, creando un patrón de medida al que el Juez de lo Penal, al estudiar la acción civil, ha de acudir."
Xavier Ribas, Contract-Soft onnet
http://www.onnet.es