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