Contrato de desarrollo a medida de programas de ordenador

Aquí debemos tener claro si estamos regulando una prestación de servicios o un arrendamiento de obra, ya que se puede pedir un resultado concreto.

Se pueden dar dos situaciones:

1.- Cliente que quiere que una empresa tecnológica desarrolle un software desde cero y  específico para él.

2.- Cliente que quiere que una empresa tecnológica desarrolle un software ya creado.

En ambos casos, se adapta al cliente y se produce un resultado que crea un software, o modifica o añade algo al software existente.

Por tanto la empresa tecnológica ha de producir un resultado, y en este sentido debemos partir de unas bases:

1.- ¿Qué queremos que haga el software?

2.- ¿Es un arrendamiento de obra o de servicios, o la mezcla de ambos?

3.- Si es un software a medida, tener en cuenta que el análisis funcional y el analista son básicos.

En cuanto al objeto del contrato, es importante definirlo con el máximo de detalles, sobre todo a nivel técnico. Esto beneficia a ambas partes:

A la empresa tecnológica porque así tiene claro su objetivo y hasta dónde debe realizar su trabajo sin que se le pueda exigir más allá por un precio cerrado.

Al cliente porque así sabe qué es exactamente lo que se le va a desarrollar y lo que puede exigir conforme al precio pactado.

Si se solicita más de lo acordado, lo más adecuado es crear un anexo o incluso un nuevo contrato que regule todas las nuevas circunstancias.

La empresas de consultoría nos podrán ayudar a realizar este análisis funcional, sobre todo si el software se crea desde cero.

También conviene regular un calendario de Fases de realización del objeto / proyecto en cuestión. Se trata de hitos y pautas para controlar el trabajo y los plazos.

Hay 2 sistemas básicamente:

1.- Las fases se van aceptando una a una mediante actas. Si defiendes al cliente, esta es la mejor opción.

2.- Se aceptan tácitamente si en el plazo de X días ninguna de las partes se manifiesta. Si defiendes a la empresa tecnológica, esta es la mejor opción.

Muy importante: Según el Código civil, lo entregado y pagado, se entiende por aceptado.

Es común igualmente establecer Penalizaciones si los hitos o plazos de entrega no se cumplen a tiempo. Se puede realizar mediante tablas orientativas sobre hito/plazo/penalización, que irá en aumento cuanto mayor sea el retraso, pudiendo incluir un plazo máximo de retraso que da lugar a la extinción del contrato por incumplimiento.

Aquí es importante regular los casos en los que las partes no se ponen de acuerdo, regular el escalado de la cuestión de los jefes de proyecto a los responsables superiores, etc, para evitar la terminación del contrato con lo que todo ello conlleva (gastos, indemnizaciones, pleitos…).

Siempre se debe regular la Confidencilidad y la protección de datos de carácter personal, tanto para una parte como para la otra.

Garantía y RC: Se suele otorgar un periodo de garantía o de prueba de un año o dos, en el que la empresa tecnológica debe velar por el buen funcionamiento del software, solucionando posibles incidencias.

Desplazamiento del personal: Es muy común en estos contratos que el personal de la empresa tecnológica se tenga que desplazar habitualmente a la sede del cliente, por lo que es muy conveniente dejar bien claro que la relación es exclusivamente mercantil, y nunca laboral, por las implicaciones que esto podría tener para el cliente, sobre todo. Igualmente conviene cuidar a tu analista si eres la empresa tecnológica, y evitar la “fuga” de talentos al cliente.

Se debe evitar la cesión ilegal de trabajadores, por tanto, en el contrato siempre hablaremos de “perfiles”, no de personal, o de trabajadores, e indicando que las instrucciones de trabajo las recibe su empresa tecnológica, no del cliente.

Responsabilidad: En el sector está muy aceptada la limitación de responsabilidad a una cuantía determinada. Los pactos pueden variar mucho. Por ejemplo: precio del contrato.

Propiedad intelectual e industrial

Si no se regula o no se pacta nada, se entiende que la propiedad intelectual es para la parte que realiza el esfuerzo creativo (en este caso la empresa tecnológica). Por tanto, si quieres adquirir esta propiedad como cliente, deberás pactarlo expresamente.

En este punto pueden producirse 3 casos básicamente:

1.- Si se trata de un software ya creado y standard, la empresa tecnológica conserva la propiedad intelectual.

2.- Si es un software ya creado pero con modificaciones, la empresa tecnológica podría conservar la propiedad intelectual, pero ceder o no las modificaciones realizadas para que el cliente continúe desarrollando su programa.

2.- Si hay desarrollo integral o adicionales, puede que el cliente desse adquirir la propiedad intelectual, o incluso ser compartida por las partes, y que luego ambas desarrollen el software por caminos diferentes.

Aquí, la empresa tecnológica tratará de proteger su “know-how”, obviamente.

Aunque el trabajo lo realiza la empresa tecnológica, conviene también regular ciertas obligaciones del cliente, que no se reducen al pago. En este caso hablamos de efectiva colaboración, que permita el acceso a información , instalaciones, documentación, etc…

Consejo: Intentar que el jefe de proyecto o analista del mismo no abandonen durante la ejecución del contrato, puesto que son los “directores de orquesta” del proyecto. Se puede establece que en caso de abandono, el contrato se extinga, sin perjuicio de la indemnización que por daños y perjuicios al cliente le pudiera corresponder.

Contrato de mantenimiento de hardware y software

Es un contrato de prestación de servicios.

El objeto por tanto es el mantenimiento tanto del hardware como del software.

Es básico indicar lo siguiente:

1.- ¿Qué servicios incluye? Mantenimiento, actulización anual o semestral, corrección de errores, averías…

2.- Tipos de mantenimiento:

1.- Correctivo: corregir errores del hardware y el software.

2.- Adaptativo: entrega de nuevas versiones del software.

3.- Evolutivo: Desarrollo de nuevas funciones del software. Cuando el mantenimiento es evolutivo, por su complejidad, suele ser un contrato aparte.

3.- Plazos de respuesta y resolución de problemas

Aquí se suele hablar de «Niveles de servicio» ó SLA (service level agreement). Estos niveles definen la calidad de la prestación del servicio, horarios, tiempo de respuesta, prioridades, plazo de resolución. Aquí lo importante es regular dos plazos:

1.- ¿Cuanto tarda el prestador en decirme que ya es consciente del problema que le he comunicado?

2.- ¿Cuánto tarda el prestador el solucionármelo?

Obviamente también conviene regular cómo comunicar estas incidencias.

Ejemplos:

Error crítico: prioridad máxima, respuesta inmediata.

Error medio / sensible: prioridad media, respuesta en 5 horas

Casos residuales: Prioridad baja, respuesta en 24 horas.

Es básico definir qué se considerará error crítico.

4.- Obligaciones del Usuario

Incluir el éste debe utilizar el programa conforme el manual de instrucciones del hardware y software, no modificarlo, no utilizar para otros fines que los indicados, obligación de hacer copias de seguridad.

5.- Garantía y responsabilidad civil

Hardware: 2 años conforme Ley.

Software: es un intangible, por lo que las partes deben regularlo. Normalemnte se da un año o dos de garantía para reparaciones del día a día.

Contrato de distribución de software

Este contrato regula lo mismo que el anteriormente comentado, pero sólo se cede el derecho a distribuirlo.

Exclusiva: A veces se cede la distribución en exclusiva, o se reparte por sectores. Las grandes empresas tecnológicas que quieren distribuir su software a nivel mundial, suelen “repartir” el mundo en tres partes:

1.- LATAM (Latinoamérica)

2.- EMEA (Europa, Oriente Medio y África)

3.- APAC (Asia y Pacífico)

En estos casos, para cada zona se elige un distribuidor diferente, de manera que geográficamente se limita la distribución.

Obligaciones para el distribuidor: En este tipo de contratos, lo básico es exigir al distribuidor unos resultados mínimos, que, de no llevarse a cabo, producirán la resolución del contrato.

Derechos del distribuidor: Aunque no suele aparecer en los contratos, y menos en los de las grandes empresas tecnológicas cuyos contratos son de adhesión, la jurisprudencia y doctrina admite abiertamente la indemnización por clientela a favor del distribuidor, una vez se termina el contrato.

El “know how” que se transmite al distribuidor. La empresa tecnológica debe proteger esta información, no sólo en relación con el software, sino a los procedimientos internos, formas de operar, etc, propias de la empresa tecnológica. Por ello, se firman cláusulas de confidencialidad.

Muchas veces la distribución de software lleva aparejada una serie de prestación de servicios. Es decir, el distribuidor puede ser a su vez es prestador de servicios. Por tanto, es muy importante definir bien qué servicios se prestarán, cómo se prestarán, si será necesario el acceso al código fuente del software por parte del distribuidor/prestador de servicios.

Ejemplo: Lo habitual es que una empresa tecnológica (por ejemplo Oracle) firme un contrato de distribución con un “Implantador”, y éste a su vez firma con el cliente final (por ejemplo una empresa que quiere un software ERP que le haga la contabilidad) un contrato de Licencia de Uso asociado a una prestación de servicios de software a medida.

¿De qué servicios estamos hablando?

Suelen ser: instalación del software, servicios de mantenimiento, resolución de errores, incidencias o problemas, actualizaciones, etc.

Habitualmente se habla de dos niveles de mantenimiento:

–         Mantenimiento de primer nivel: Son los servicios que pueden ser llevados a cabo por el Implantador, y normalmente aquí se engloban problemas menores del día a día, casos simples.

–         Mantenimiento de segundo nivel: Sólo puede ser solucionado por el propietario del software (la empresa tecnológica). Esto es porque es necesario acceder al código fuente y a otra información tan privada y confidencial que no se da acceso al implantador. Suelen ser casos complejos.

La propiedad intelectual debe también regularse en el propio contrato: Lo lógico es que la conserve en su totalidad la empresa tecnológica propietaria del software. El derecho de Transformación es un punto clave del contrato. Si el Implantador, a la hora de prestar servicios debe acceder al código fuente, además de regular la confidencialidad, se deberá indicar que toda modificación o transformación del software será propiedad de la empresa tecnológica propietaria del software, ya que si no pactamos nada, la propiedad intelectual de lo transformado podría ser para el Implantador, y esto es un gran riesgo.

Auditoría: De cara a comprobar los resultados mínimos exigidos al distribuidor/implantador, se suele pactar un derecho a auditar a éste, que generalmente paga la empresa tecnológica, salvo que los resultados evidencien que el implantador no está revelando resultados correctos.

Contrato de cesión de derechos de explotación de un software

Cuando un programador/empresa tecnológica crea un software para un cliente, puede transmitir los derechos de explotación del mismo.

Para ello, es muy importante ser muy específico en los derechos que se transmiten, y que según la LPI son cuatro:

1.- Distribución

2.- Transformación

3.- Reproducción

4.- Comunicación pública

Si no se dice nada, entramos en un terreno muy pantanoso, ya que la Ley indica que se interpretará la cesión conforme acordaron las partes en el momento de la transmisión, lo cual es muy indeterminado y difícil de probar.

El art. 8 de la LPI es el único caso que contempla que una persona jurídica pueda ostentar derechos morales de autor (obra colectiva), y los derechos de explotación corresponder al coordinador y el que «edita y divulga» el software.

«Se considerá obra colectiva la creada por la iniciativa y bajo la coordinación de una persona natural o jurídica que la edita y divulga bajo su nombre y está constituida por la reunión de aportaciones de diferentes autores cuya contribución personal se funde en una creación única y autónoma, para la cual haya sido concebida sin que sea posible atribuir separadamente a cualquiera de ellos un derecho sobre el conjunto de la obra realizada.

Salvo pacto en contrario, los derechos sobre la obra colectiva corresponderán a la persona que la edite y divulgue bajo su nombre.»

Es importante indicar la duración de la cesión. Si no se dice nada, serán 5 años de duración. Si queremos que sea lo más indeterminada posible, que es lo común, debemos indicar que la duración será la máxima permitida por Ley (vida del autor más 70 años tras su muerte).

También es importante indicar el ámbito geográfico. Si no se pacta nada, será sólo España. Lo ideal: ámbito mundial.

Igualmente conviene indicar con todo detalle en qué términos se cede un software:

1.- Software concreto, con todas sus versiones o no, actualizaciones….

2.- Si está inscrito en el Registro de la Propiedad Intelectual, conviene hacer referencia a esto para que quede claro y conciso qué se está cediendo, o si está en acta notarial también.

La exclusividad también debe regularse: Si no se pacta expresamente, no existe exclusividad y la cesión se desvirtúa. Es decir, que nuestra inversión puede ser un desastre puesto que el Software podrá ser explotado por otros. La cesión en exclusiva pactada expresamente incluye al cedente salvo excepciones pactadas.

El alcance de la cesión también debe ser regulado, indicando que se entrega el código fuente completo, documentado y listo para poder seguir desarrollándolo. Aquí un técnico informática (analista, porgramador, ingeniero) podrá ayudarnos a concretar bien el texto para que la cesión sea útil.

Igualmente se puede regular la competencia.

¿Qué es Internet? Los protocolos de Internet y la IETF.

Internet se suele definir como la «red de redes». Esto es porque realmente NO es una sola red, sino millones de redes de comunicación interconectadas entre sí, sin una estructura centralizada. Por tanto no hay jerarquía y es difícil imponer normas sobre la misma.

Su origen primitivo es Arpanet, una red interna del Ministerio de Defensa de USA para poder mantener la comunicación aunque se cortara la red telefónica, y que tras un periodo de desarrollo, comenzó a utilizarse a finales de los años 60, principios de los 70.

Internet tiene un lenguaje común que es lo que hace que todos los «Paquetes» que «viajan» por ella sean inteligibles para nosotros. Es el TCP/IP. Se trata de un protocolo estandarizado que permite que todas las redes entiendan, como digo, el contenido de los paquetes (imágenes, texto, video, música, voz, etc…).

Es importante tener claro que Internet NO es sólo la Web (World Wide Web).

Los protocolos en Internet

Un protocolo de Internet es básicamente una estandarización para el uso a nivel global de la tecnología de Internet, favoreciendo la compatibilidad entre los usuarios en todo el mundo civilizado. Los más conocidos son TCP (protocolo de control de transmisión) e IP (Protocolo de Internet).

Otro protocolos:

HTTP es un protocolo para la WEB.

POP3 para recibir e-mail

SMTP ó IMAP para enviar e-mail

FTP para la transferencia de archivos, etc…

Por tanto, un protocolo es una serie de especificaciones que, si así se quiere (por tanto es voluntario su uso), se puede usar y que generalmente es un standard.  Por supuesto se puede utilizar otros protocolos no estandarizados con un software específico, pudiendo o no ser explotados económicamente.

EjemploSkype utiliza un protocolo privado basado en un protocolo abierto anterior llamado SIP. La diferencia aquí es que el protocolo privado se ha adelantado y mejorado el protocolo SIP, y la gran mayoría usa Skype en lugar de SIP.

«Skype utiliza un protocolo propietario de telefonía VoIP. Parte de la tecnología usada por Skype pertenecen a Joltid Ltd. corporation. La gran diferencia entre este software y otros estándar de análoga funcionalidad, es que Skype opera en base al modelo P2P (originalmente usado en el software Kazaa en 2001) en vez del usual modelo Cliente-Servidor. Nótese que el modelo más popular, SIP, de VoIP también es P2P, pero su implementación generalmente requiere su registro en un servidor». Fuente: Wikipedia.

El paquete

Se llama «paquete» al archivo que recorre la red de un destino a otro por orden de un usuario. La estructura de un paquete se compone de:

1.- Remitente: IP1.

2.- Destinatario IP2

3.- Versión de protocolo

4.- Contenido «Hola».

Los paquetes por tanto NO se «abren», sólo se trasladan de un sitio a otro, y generalmente no en línea recta precisamente. El paquete busca su camino por donde se le permite, de manera que un paquete puede llegar a dar cinco vueltas al mundo en un segundo antes de llegar a su destinatario que, por otro lado, puede estar en la misma ciudad que el remitente. Este es un ejemplo claro de la red de redes y su extensa interconexión.

Sin embargo, no todo está descentralizado en Internet. Existe  control consentido en ciertos aspectos y ámbitos que pasamos a analizar:

1.- Las direcciones IP (Internet Protocol). Es como el carnet de «identidad» de cada ordenador.

2.- Los nombres de dominio.

3.- Los Protocolos.

¿Quién configura los protocolos?

Existe un grupo no determinado de personas y no organizado que jurídicamente no existe por no ostentar personalidad jurídica compuesto por ingenieros, científicos, informáticos, investigadores y algún abogado que otro, llamado IETF (Internet Engineering Task Force).

Sin embargo, hemos de tener en cuenta que estos protocolo durante más de 30 años fueron realizados por JON POSTEL aka GOD.

Además de los 3 puntos de control comentados, existe un cuarto «punto de control», que podríamos definir como el «efecto Mubarak«: si se cortan las conexiones, no hay nada que hacer. Sin embargo esto sería difícil de llevar a cabo en países desarrollados.

La IETF

Tras definir brevemente la IETF, podemos decir que su principal función es desarrollar los protocolos de Internet.

Como decía, la IETF NO es una organización, sino un grupo de personas sin ánimo de lucro, no es un organismo gubernamental ni tiene miembros concretos identificados, por lo que es un grupo abierto, y permite colaboración o propuestas de cualquiera (otra cosa es que te hagan caso o sean aprobadas). La base o motivo principal de su “no existencia” es que así evitan ser demandados, ya que sin personalidad jurídica no hay demanda.

Su principal objetivo, además de crear protocolos de Internet, es el desarrollo de la Red y avanzar tecnológicamente sobre el funcionamiento de la misma y su mejor usabilidad.

En la IETF encontramos miembros representantes de grandes empresas interesadas como IBM, Cisco, Oracle y particulares. También representantes de Telefónica han acudido según se dice, pero tienen prohibido intervenir.

¿Cómo aprueba la IETF un protocolo?

Este proceso realmente es muy complicado, y está de alguna manera regulado por una serie de órganos que van filtrando y gestionando técnicamente las propuestas de protocolo. IESG es uno de estos órganos que realizan la gestión técnica, a través de las propuestas de los Grupos de Trabajo (working groups), que son abiertos. El desarrollo para la aprobación de un protocolo puede llevar años, apelaciones, actualizaciones, etc.

¿Quién puede ser miembro de un Workin Group? Cualquiera puede serlo, pero deberá tener un proyecto interesante. Con suscribirte a una lista de correo, te conviertes en miembro. El carácter de “abierto” de la IETF se entiende en su máxima expresión.

Otro órgano de la IETF es el IAB (Internet Arquitecture Board), el cual nos da una visión global de cómo se va a desarrollar Internet en el futuro, y en esto trabajan a diario. Además, ejerce de “tribunal supremo” cuando se han de presentar apelaciones a proyectos de futuros protocolos.

La Estandarización (“the standard process”)

Un standard no es más que un lenguaje globalizado que suponga que todos lo entendamos para facilitar la comunicación, el mejor desarrollo de Internet y mejorar tecnológicamente.

IETF. Sin personalidad jurídica pero con excepción

La IETF, de cara a poder operar en el mercado (aunque sea para almacenar  fondos, alquilar salas de reuniones, pagar facturas, etc…) creo una fundación o “trust” para poder funcionar. Aunque no es el espíritu de la IETF, este órgano es necesario para funcionar.

En todo caso, hemos de tener claro que la IETF no es una organización, no tienen miembros definidos, no está jerarquizado, no tiene organismos sino órganos, no hay votaciones, todo se realiza por consenso (oohmmmm) y, aunque esto ralentiza la aprobación de protocolos, parece la forma más justa y democrática de aprobar protocolos.

Ver: W3C

Lecturas recomendadas:

The TAO of IETF.

The Internet standards process.

Rights Contributors Provide to the IETF Trust.
Intellectual Property Rights in IETF Technology.

Derechos de propiedad intelectual sobre el software

1.- Contratación tecnológica en el ámbito laboral: un analista o programador que es contratado mediante un contrato laboral, salvo pacto en contrario, cede todos los derechos de propiedad intelectual (explotación) a la empresa contratante. Art. 97.4 de la LPI. “Cuando un trabajador asalariado cree un programa de ordenador, en el ejercicio de las funciones que le han sido confiadas o siguiendo las instrucciones de su empresario, la titularidad de los derechos de explotación correspondientes al programa de ordenador así creado, tanto el programa fuente como el programa objeto, corresponderán, exclusivamente, al empresario, salvo pacto en contrario.”

2.- Obra colectiva: Es la obra compuesta por las aportaciones de más de una persona y es imposible diferencia cuánto aporta cada una. En este caso los derechos de autor pertenecen al que coordina todo esto y divulga el software. Art. 97.2 LPI “Cuando se trate de una obra colectiva tendrá la consideración de autor, salvo pacto en contrario, la persona natural o jurídica que la edite y divulgue bajo su nombre.”

Aquí es importante abordar las cláusulas que se imponen a los desarrolladores para evitar la “fuga” a la competencia. Es común que en los contratos se regule que durante 1 ó 2 años el trabajador asalariado no pueda trabajar para la competencia. En este caso, además de determinar qué empresas se consideran competencia, es importante saber que el límite máximo son 2 años para esta prohibición, y que en todo caso debe ser remunerada . Es decir, si no me dejas irme a la competencia, me tienes que pagar por ello aunque no trabaje para ti.

También es común que si la empresa ha invertido dinero en formación de un desarrollador/programador/analista y esto supone un incremente en su categoría laboral, se establezcan cláusulas de permanencia en la empresa para el empleado en cuestión, puesto que se ha beneficiado de una formación que en teoría, debe desarrollar en la empresa que le ha proporcionado dicha formación, y no en la competencia.

Confidencialidad

Los acuerdos de confidencialidad en la contratación tecnológica para que sean medianamente eficaces deben seguir los siguientes patrones:

1.- Definir qué es Información confidencial.
2.- Definir en qué supuestos no se considera Información confidencial (por ejemplo cuando la información ya sea ha hecho pública, o cuando se ha tenido acceso a esta información de forma lícita a través de un tercero, etc…).
3.- Cuantificar la indemnización por la vulneración de la confidencialidad.

Contratación de un autónomo (“freelance”)

Si se contrata un programador externo, se debe acordar y dejar claro que no hay vinculación laboral, que la relación es mercantil y, lo más importante, se debe pactar expresamente y por escrito la cesión de los derechos de explotación del software, ya que si no pertenecerán a éste. Igualmente es importante regular la confidencialidad y la no competencia.

El contrato de depósito de código fuente (“escrow”)


El contrato de depóstio de código fuente (“escrow”)

En los contratos de licencia de uso de software, cuando el propietario/autor del código fuente no quiera entregarlo directamente al que va a hacer uso de él por causas de confidencialidad, secreto, etc, pero sí que es necesario que el que va a hacer uso del mismo tenga la seguridad de que, aunque la empresa propietaria del código fuente desaparezca (concuros, quiebra…), ésta pueda seguir con su actividad.

Para ello, la solución más frecuente es el contrato de scrow, de manera que dicho código fuente se deposita en una tercera entidad en el mundo jurídico anglosajón, y en España generalmente se hace a través de un Notario que, si carece de medios suficientes para tener el código fuente protegido, puede pasarlo a una tercera empresa pero siempre bajo Acta notarial. En España una empresa bastante potente en este sentido es ESABE.

Esto implica dos cuestiones mas:

1.- El código fuente debe ser auditado para comprobar que es el correcto.
2.- Lo ideal es que el mismo se vaya actualizando en sus versiones.

Problema real: Todo este proceso es carísimo, por lo que hay poco contratos de “escrow”.

Sociedad de la Información y Comercio electrónico (e-commerce)

El concepto de Sociedad de la información se puede reducir a aquellas técnicas que sirven para recibir, archivar, adquirir, procesar, etc, información utilizando los medios que la tecnología actualmente nos permite. Resumiendo: sobre todo Internet.

Tres características:

1.- Digitalización de la información (lenguaje universal de ceros y unos).

2.- Redes de ordenadores (intranet, móviles…)

3.- Redes globales (Internet).

La digitalización nos permite copia, modificar y distribuir la información con gran facilidad y rapidez, de ahí que una característica tan técnica tenga tanto impacto a nivel social y, en este caso, jurídico.

Consecuencias legales:

– La información es el centro del sistema. Cuantos más participantes hay en estos sistemas, más valorar cobran. Incluido el valor económico.

– Información fácil de copiar, procesar y distribuir (ya veremos si legal o ilegalmente).

– Facilidad de obtención y procesamiento.

Nuevos canales, nuevos mercados.

Blog recomendado: Foss Patents

Nuevos bienes digitales: ventas de IP´s, ventas de bases de datos, y en definitiva, venta de información útil extraída, ya veremos, de forma más o menos legítima.

Redes sociales: ¿Te has leído las condiciones legales de lo que firmas electrónicamente al hacerte miembro de una web social, de los derechos que cedes, licencias que otorgas y libertades a las que renuncias?

¿Nos compensa esto? Dependerá de cada uno, pero desde luego a Google o Facebook sí. La información es poder, y ellos disponen de tantísima información sobre los usuarios que son capaces de saber hasta qué querremos comprar de aquí a unos meses sólo basándose en estudios estadísticos de las búsquedas que realizamos en Google, por ejemplo. Para ellos nuestros datos es su mayor activo.

¿Cómo deben reaccionar los órdenes jurídicos?

Lo iremos viendo a lo largo de este blog.

Lecturas recomendadas:

The Tao of IETF: A Novice’s Guide to the Internet Engineering Task Force

Contratación tecnológica

Según la LPI, se entiendo por “programa de ordenador” o “software” toda secuencia de instrucciones o indicaciones destinadas a ser utilizadas, directa o indirectamente, en un sistema informático para realizar una función o una tarea o para obtener un resultado determinado, cualquiera que fuere su forma de expresión y fijación.

Antes de entrar en materia, vamos a ver unas nociones básicas de qué entendemos por “programación”.

La programación clásica se divide en 3 fases:

1.- ¿Qué quiero que haga mi programa?

2.- ¿Cómo lo hago para que mi programa haga lo que quiero? Esta es la fase de diseño funcional o análisis funcional, donde se describe detalladamente las funciones que realizará mi programa.

3.- Desarrollo del programa mediante un lenguaje de programación (HTML ,XML, etc…).

A partir de aquí, el programador crea un código que genera las funciones llamado código fuente.

Además, el programador con el tiempo realizará actualizaciones o nuevas versiones del programa.

Este tipo de programación es vertical.

La programación orientada a objetos es la vertiente más avanzada de programación no lineal, simplificando el proceso de programación.

Para que un programa funcione, por ejemplo SAP, no sólo es necesario el código fuente, sino 3 pilares básicos:

1.- Una base de datos (Oracle, SQL de Microsoft…).

2.- Un sistema operativo que traduzca a al ordenador las funciones (Mac OS Windows, Linux, Unix…)

3.- Un ordenador (el “hardware”), que básicamente emite impulsos eléctricos.

¿Cómo se protege un programa de ordenador?

La protección comienza desde que se comienza a crear el código fuente, aunque también puede ser protegida las fases preparatorias previas, documentación y manuales de uso.

Si nos vamos a la práctica, es común encontrarnos con los siguientes tipos de contratos:

1.- Contrato de licencia de uso de software

Aquí lo que básicamente se regula es la autorización por parte del propietario de un software a un tercero para su uso, por un precio determinado.

En este tipo de contratos hay varios puntos relevantes que se han de considerar antes de su firma:

1.- Ámbito geográfico: Según el tipo de programa, se suele regular este ámbito de una manera u otra. Si el programa es de Ofimática (Office) o Business software (PhotoShop, Autocad, etc..), se suele definir por número de ordenadores o número de usuarios. Si el programa es un ERP (por ejemplo SAP), se regula o por número de usuarios, por país, por servidores…..digamos que varía más y por tanto hay más opciones.

Si no se contempla nada respecto al ámbito geográfico en el contrato, se entiende que es para todo el país del domicilio de la empresa licenciataria.

2.- Ámbito temporal: Si no se contempla, se entiende que la cesión de uso es por 5 años (LPI). En la práctica suele ser común un contrato indefinido con posibilidad de resolución con un preaviso determinado. EL plazo máximo es la vida del autor más 70 años (LPI), a partir de aquí los derechos pasan a ser de dominio público.

Contrato perpetuo = Contrato NULO.

Hay otras licencias que se conceden por un tiempo cierto, por ejemplo un año, y a partir de éste si no hay renovación dejan de funcionar (técnicamente hablando). Es un control por tanto tecnológico.

3.- Propiedad intelectual: Lo lógico es que se la reserve el licenciante (SAP en nuestro caso) siempre, cediendo sólo el derecho de uso por precio cierto.

4.- Garantía sobre el software / responsabilidad: Debemos tener en cuenta que un software es un intangible, por lo que no le aplica la Ley de garantías entre dos personas jurídicas, de manera que se debe regular este punto, ya sea por años o mediante limitación económica de la responsabilidad (muy típico de contratos anglosajones). Si el software es estándar y no ha implicado muchas modificaciones para hacerlo a medida del cliente, la limitación económica suele ser menor puesto que las posibilidades de que haya fallo son menores. Si el software hay que adaptarlo a la empresa, es más posible que falle puesto que no está tan probado, y por tanto el importe de la limitación económica aumenta.

¿Cuándo consideramos un software defectuoso?

Pues dependerá del caso, ya que como comenté antes, un software depende de una base de datos, de un sistema operativo y el hardware. En todo caso, podemos acudir a la definición de “producto defectuoso” y relacionarlo con el propio software. Es decir, si el software no es capaz de realizar las funciones descritas en sus instrucciones, es defectuoso.

Según el artículo 3 de la Ley 22/1994, de 6 de julio, de Responsabilidad civil por daños causados por productos defectuosos, “se entenderá por producto defectuoso aquél que no ofrezca la seguridad que cabría legítimamente esperar, teniendo en cuenta todas las circunstancias y, especialmente, su presentación, el uso razonablemente previsible del mismo y el momento de su puesta en circulación.

2. En todo caso, un producto es defectuoso si no ofrece la seguridad normalmente ofrecida por los demás ejemplares de la misma serie.

3. Un producto no podrá ser considerado defectuoso por el solo hecho de que tal producto se ponga posteriormente en circulación de forma más perfeccionada.”

El software libre

Las licencias de uso sobre software libre implican básicamente que no hay gasto económico por su uso, pero igualmente están sometidas a una serie de obligaciones para el programador o desarrollador que modifica el código fuente, ya sea para adaptarlo, actualizarlo, mejorarlo, etc…

Por tanto, con el software libre (“open source”), el mismo se comparte sin precio pactado, pero hay que tener en cuenta lo siguiente:

1.- Se comparte el código fuente y nadie se apropia del resultado.

2.- Sí se puede cobrar por los servicios prestados en la preparación/adaptación de un software libre. De hecho, de la Junta de Andalucía por ejemplo, que es defensora del software libre, se comenta que se ha gastado tanto dinero en la prestación de servicios de desarrollos del software como si hubiera adquirido una licencia de uso de un software “privado”.* Info no contrastada.

Por tanto, las empresas se pueden lucrar adaptando software libre. Empresas como IBM u Oracle dedican parte de su rama de negocio a esto.

3.- Cualquiera puede variar, utilizar, modificar, adaptar, evolucionar etc el código fuente de software libre, pero siempre debe compartirlo. Por tanto, siempre se transmiten los derechos.

Límites al Software libre:

1.- No hay garantía (porque todos podemos modificarlo).

2.- No puedes reservarte los derechos sobre tu aportación. Debes compartirla.

3.- La aportación va al “común creativo”.

Obligaciones del que participa en un Software libre:

1.- Indicar que es un código abierto.

2.- Incluir las llamadas “repudias de garantía”.

3.- Transmitir los derechos que se han recibido.

4.- Indicar las partes modificadas y cuándo se realizaron.

5.- Debe transmitirse sin carga ni cobro de beneficios.

6.- La distribución siempre ha de ser en código abierto.

El contrato de Scrow o de depósito de código fuente.