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