cuestiones jurídicas en torno a los contratos de desarrollo y licencia de software

xxxx xxxxxx xxxxxx xxxxxxxxx*

1.1. concepto y naturaleza jurídica

El contrato de desarrollo de software es aquel por el cual una de las partes (el desarrollador) se compromete a crear y entregar un programa de computador y la otra (el cliente o encargante) se obliga a pagar un precio por el mismo, y produce, si el programa desarrollado es aceptado por el cliente o encargante, la adquisición del ejemplar del programa de computador por parte de este.

Como se trata de una obra protegida por el derecho de autor, los derechos patrimoniales sobre el programa creado podrán quedar en cabeza del desarrollador y/o cliente o encargante, según lo acuerden las partes.

El Código Civil utiliza el término de “contrato de arrendamiento de servicios inmateriales” para referirse a aquellos en que predomina la inteligencia sobre el trabajo físico (“obra de mano”), y regula esta materia en sus artículos 2063 a 2078. En ese sentido se diferencia del “contrato para la confección de una obra material” (arts. 2053 a 2062) en donde se trata de la elaboración de un objeto material o tangible.

La diferencia entre el contrato de arrendamiento de servicios inmateriales y el contrato para la confección de obra material es objeto de diversas interpretaciones y discusiones entre los estudiosos del derecho civil. El criterio diferenciador al parecer más aceptado por la doctrina es el de la contraposición entre actividades de medios y de resultado: mientras en el contrato de obra el artífice se obliga a producir un resultado, con independencia del trabajo necesario para realizarlo, en el contrato de arrendamiento de servicios el contratante se obliga a desarrollar

* Profesor de la Universidad Externado de Colombia, especializado en Propiedad Industrial, Derechos de Autor y Nuevas Tecnologias en la misma Universidad. Contacto: xxxxxxxxxxxxxxxx@xxxxx.xxx. Fecha de recepción: 5 xx xxxxx de 2012. Fecha de aceptación: 9 de julio de 2012.

una actividad, es decir, a poner de su parte su actividad y capacidades personales, pero sin comprometerse a garantizar la obtención de un resultado determinado.

En efecto, una característica fundamental del contrato para la confección de una obra que regula el Código Civil colombiano en sus artículos 2053 a 2062 es que el artífice adquiere una obligación de resultado, no simplemente una obliga- ción de medios. La principal obligación del artífice es alcanzar un resultado, ya sea material o inmaterial. No solamente se trata de realizar la obra sino de entregarla en el momento y lugar acordado, así como de responder por los vicios o defectos que la misma pueda presentar, entre otras obligaciones.

En el contrato de obra y en las obligaciones que se derivan de él aplica el régimen de prueba de los presupuestos de responsabilidad del deudor: la carga de la prueba del cumplimiento de una obligación le corresponde al deudor; si la obligación fundamental del contrato de confección de obra es la creación de la misma en las condiciones acordadas, es el artífice quien debe estar dispuesto a demostrar que cumplió adecuadamente con los requerimientos del contrato en condiciones de calidad y oportunidad.

Otras disposiciones propias del contrato para la confección de una obra material son las que siguen.

El artífice, es decir, quien se obliga a realizar la obra, ha de ejecutar su tarea respetando el modo de ejecución que corresponda, debiendo advertir al dueño de la obra la eventual mala calidad de los materiales, así como permitir el control de la obra por parte del dueño.

La obra ha de ser ejecutada conforme a las reglas del arte. En caso de haberse extendido instrucciones, deberán ser estrictamente observadas de acuerdo a los principios de autonomía de la voluntad y buena fe.

Si una vez entregada la obra el encargante alega no haberse ejecutado debida- mente el encargo, conforme al artículo 2059 C.C., dicho encargante asumirá la carga de probar que sus objeciones a la calidad son debidamente fundadas, y se requerirá la intervención de peritos designados por las dos partes.

Se ha considerado que el contrato de encargo para la elaboración de una obra intelectual se trata de un contrato de arrendamiento de servicios inmateriales por expresa mención del artículo 2063 C.C., pero al hacer dicho artículo una mención expresa de las normas del contrato de obra material el objeto de dicho contrato se convierte en una obligación de resultado, y son aplicables disposiciones como las mencionadas en el artículo 2059.

Por su parte, las actividades intelectuales de que trata el artículo 2064 C.C. corresponden a un contrato de arrendamiento de servicios inmateriales cuyo con- tenido es una obligación de medios.

En conclusión, el contrato de desarrollo de software corresponde por su natu- raleza a un contrato para la elaboración de obra inmaterial de que trata el artículo 2063 C.C., que es una especie de contrato de arrendamiento de servicios inmate- riales pero con la característica de establecer una obligación no de medios sino de

resultado, consistente en el desarrollo y entrega de un programa de computador bajo los requerimientos y condiciones pactadas en el contrato.

1.2. características

El contrato de desarrollo de programas de computador puede clasificarse como:

1. Bilateral: se celebra entre dos partes, el cliente o encargante y el desarrollador.

2. Oneroso: la labor de creación de la obra implica xx xxxxxxxxx una remune- ración económica, una suma pagada frecuentemente por instalamentos o cuotas a medida que avanzan las diferentes etapas del proyecto de desarrollo y que se reciben los mismos a satisfacción del cliente. En este tipo de contratos el Código Civil presume su carácter oneroso, al establecer el artículo 2054 que si en el contrato para la elaboración de obra no se ha fijado precio, se presumirá que las partes han convenido en el que ordinariamente se paga por la misma especie de obra, y a falta de este, por el que se estimare equitativo a juicio de peritos.

3. Conmutativo: a la obligación del desarrollador de crear la obra intelectual corresponde equitativamente la obligación del cliente o encargante de pagar el precio del contrato.

4. Consensual: la ley no especifica ningún requisito para el perfeccionamiento del contrato. Esto significa entonces que el contrato es consensual, y que se per- fecciona simplemente por el mutuo consentimiento de las partes, expresado ya sea por escrito, o verbalmente, o por actos inequívocos de aceptación o ejecución del mismo.

5. Atípico: el contenido del contrato no está específicamente desarrollado en la ley, si bien le son aplicables las disposiciones generales de los contratos de elaboración de obra y del contrato de arrendamiento de servicios inmateriales, consagrados en el Código Civil.

6. De ejecución sucesiva o diferida: el proyecto de desarrollo se cumple a través de varias etapas sucesivas, si bien la obligación fundamental del contrato se perfec- ciona con un acto único como lo es la entrega de la obra intelectual a satisfacción del cliente o encargante.

1.2.1. Formalidad escrita

Como se ha mencionado, el contrato de desarrollo de programas de computador es un contrato consensual en el que la ley no especifica ningún requisito para el perfeccionamiento mismo, pudiendo celebrarse ya sea por escrito o de manera verbal e, inclusive, por actos inequívocos idóneos para expresar la aceptación o el consentimiento.

No obstante lo anterior, resulta claramente conveniente que las partes se tomen el tiempo y el trabajo de redactar y acordar un contrato por escrito. Al principio, nadie espera que las obligaciones se incumplan y que la relación entre las partes

se rompa, pero cuando esto sucede, un contrato por escrito resulta muy valioso. Durante el trabajo de desarrollo el contrato determina el alcance de los derechos y obligaciones de las partes, y si surge alguna duda, las partes acuden al contrato y la aclaran. En el momento que una de las partes incumpla sus obligaciones, la parte afectada tiene en el contrato el sustento probatorio de cuáles fueron las obligaciones adquiridas y el alcance de las mismas, facilitando cualquier reclamación judicial. Finalmente, existe otro motivo para hacer conveniente la formalidad escrita:

el artículo 20 de la Ley 23 de 1982 establece una presunción en los contratos de prestación de servicios cuyo objeto sea el encargo para la elaboración de una obra protegida por el derecho de autor, como es el caso del contrato de desarrollo de programas de computador, entendiendo que los derechos patrimoniales de autor se presumen transferidos en favor del encargante. No obstante, acorde con la re- forma introducida por la Ley 1450 de 2011 al artículo 20 de la Ley 23 de 1982, una condición para que opere esta transferencia consiste en que el contrato conste por escrito; nada se presumirá en materia de transferencia de derechos si las partes optan por celebrar un contrato verbalmente.

1.2.2. Obligación “intuitu personae”

Se denomina “contratos intuitu personae” a los celebrados en razón de las condicio- nes personales particulares de quien se obliga, ya sea en función de su experiencia, talento, conocimiento, competencia profesional, relación de confianza, etc. que lo cualifican, al punto que, en ausencia de dicho contratante, el contrato pierde interés para la otra parte.

El artículo 2062 C.C. prescribe que “[t]odos los contratos para la construcción de una obra se resuelven por la muerte del artífice o del empresario…”. Esto deja entender que a estos contratos les es inherente la calidad o competencia de las personas que se han de involucrar en la tarea de crear la obra.

En el contrato de desarrollo de programas de computador es frecuente obser- var que los mismos se celebran única y exclusivamente en razón de las calidades y condiciones del desarrollador, y que este es el motivo por el cual se pacta la imposibilidad o prohibición del desarrollador para ceder el contrato a terceros.

Siendo inevitable en una empresa desarrolladora la rotación del personal a cargo de un proyecto, resulta apropiado para el interés de ambas partes determi- nar el perfil y competencias de cada una de las personas integrantes del equipo de trabajo, independientemente de su nombre, de manera que la ausencia de una de ellas pueda y deba suplirse por otra persona de capacidades equivalentes.

1.2.3. Titularidad de los derechos patrimoniales de autor

El contrato de desarrollo hace surgir una obra protegida por el derecho de autor, como lo es el programa de computador. Este derecho de autor comprende unos derechos xxxxxxx que quedan en cabeza de las personas naturales que hayan reali-

zado la creación intelectual del mismo, y unos derechos patrimoniales que nacen en dichos autores pero que pueden ser transferidos a terceros, pudiendo quedar en manos del cliente o encargante o bien de la empresa desarrolladora, según lo acuerden en el respectivo contrato.

La titularidad de los derechos patrimoniales de autor significa, para quien la detenta, la posibilidad de disponer de la explotación económica de la obra y de beneficiarse por la misma. Si es el desarrollador quien la asume podrá, por ejemplo, comercializar con otros clientes el software desarrollado, realizar adaptaciones o nuevas versiones del mismo, y reflejar esos derechos como un activo intangible en su patrimonio. Si las partes optan porque los derechos patrimoniales de autor sean transferidos en beneficio del cliente o encargante, la titularidad de estos derechos exclusivos le permitirá a este último, por ejemplo, realizar por sí mismo las posteriores modificaciones al software (si cuenta con el código fuente y con la capacidad de entenderlo y modificarlo), impedir que otras empresas competidoras accedan al uso del programa, consolidar ventajas competitivas, generar nuevas oportunidades de negocio así como generar valor para el activo de la empresa, entre otros beneficios.

Lo anterior deja ver la importancia de definir claramente en el contrato a cuál de las dos partes habrá de corresponder la titularidad de los derechos patrimo- niales de autor. Esta habrá de ser una de las materias objeto de negociación. Es posible que el cliente o encargante imponga su poder de negociación obligando a que los derechos se le transfieran, pero es claro para el desarrollador que el precio del contrato habrá de variarse sustancialmente si dentro del mismo se incuye la transferencia de los derechos patrimoniales de autor.

1.3. algunas cuestiones jurídicas

1.3.1. Revisión de las condiciones iniciales del contrato

El artículo 868 X.Xx. permite que cuando circunstancias extraordinarias, imprevis- tas o imprevisibles, posteriores a la celebración de un contrato de ejecución sucesiva, periódica o diferida, alteren o agraven la prestación de futuro cumplimiento a cargo de una de las partes, en grado tal que le resulte excesivamente onerosa, podrá esta demandar judicialmente su revisión.

Como claramente lo exige la norma mencionada, debe tratarse de circunstancias extraordinarias, imprevistas o imprevisibles que no podían ser conocidas por las partes al momento de la celebración del contrato y que alteran las bases del mismo. En este caso el juez procederá a examinar las circunstancias que hayan alterado las bases del contrato y ordenará, si ello es posible, los reajustes que la equidad indique; en caso contrario, el juez decretará la terminación del contrato.

No procederá la acción judicial para la revisión de las estipulaciones del con- trato si es por causas previsibles que su cumplimiento se hace más oneroso para

el deudor de la obligación. El artículo 2060 numeral 1 C.C. plantea, a propósito de los contratos para la construcción de obras inmobiliarias, que el empresario no podrá pedir aumento del precio a pretexto de haberse encarecido los jornales o los materiales, entendiéndose que se trata en ambos casos de eventos previsibles al momento de la celebración del contrato.

La revisión del precio inicialmente pactado procede en todo caso en que se realicen agregaciones o modificaciones al proyecto original. El citado artículo 2060 numeral 1 C.C. hace la salvedad de que cuando existan modificaciones o agregaciones en el plan primitivo, las partes deberán ajustar o acordar un precio particular por ellas.

1.3.2. Modificación en los requerimientos del cliente

Es posible, y de hecho sucede con frecuencia, que a lo largo del trabajo de desa- rrollo el cliente o encargante asuma interés en adicionar nuevos requerimientos, parámetros o funcionalidades a los que inicialmente quedaron recogidos en el contrato. Coloquialmente se les denomina “xxxxxx” a aquellas adiciones, aludien- do al cliente que una vez ve funcionando una versión preliminar del programa le dice al desarrollador: “Ya que el programa hace esto, quisiera que también sirviera para lo otro”.

La frecuencia con que suceden estas situaciones hace recomendable que el con- trato de desarrollo contemple sus propios mecanismos para ajustarse o modificarse a medida que avanza su ejecución, permitiendo a las partes incluir tales ajustes y consecuentemente modificar los presupuestos y cronogramas del proyecto.

Lo anterior no obsta para que las modificaciones a los requerimientos del clien- te, así como cualquier otra modificación de las condiciones iniciales del mismo, deban ser aceptadas plenamente por el desarrollador. El mismo consentimiento que se exige para la validez del contrato inicial se requiere para las modificacio- nes posteriores del contrato. Bien podrá el desarrollador negarse a asumir tareas diferentes a las inicialmente pactadas, y podrá tener fundados motivos cuando la prolongación del cronograma de trabajo y la modificación de los requerimientos le hacen incurrir en mayores costos, le quitan disponibilidad para otros proyectos, o le hacen incurrir en tareas para las cuales no cuenta con la suficiente capacidad. En síntesis, el desarrollador está en libertad de comprometerse o no a adicionar los requerimientos iniciales, si bien es aconsejable asumir desde el comienzo esa posibilidad y pactar en consecuencia el mecanismo para su modificación, ajuste de cronograma y ampliación del presupuesto.

1.3.3. Confidencialidad de la información del cliente

La tarea de sistematizar los procesos y flujos de información existentes al interior de una empresa pone al desarrollador en contacto con la información inherente a su negocio, ya sea que se trate de sus bases de datos de empleados, clientes o

proveedores, o de las listas de precios de sus productos o servicios, de las fórmulas de los productos que la empresa fabrica, o de los métodos o estrategias de comer- cialización, etc. El cliente o encargante abre las puertas de su empresa al equipo responsable del desarrollo informático, y a efecto del mismo pone a su disposición su documentación y demás recursos de información física y digital. Esto da base a considerar cuál ha de ser la responsabilidad del desarrollador respecto del manejo de dicha información de su cliente o encargante.

Al respecto, la Decisión Andina 486 de 2000, régimen común en materia de propiedad industrial para los países de la Comunidad Andina de Naciones, establece:

Artículo 265.- Toda persona que con motivo de su trabajo, empleo, cargo, puesto, desempeño de su profesión o relación de negocios, tenga acceso a un secreto empre- sarial sobre cuya confidencialidad se le haya prevenido, deberá abstenerse de usarlo o divulgarlo, o de revelarlo sin causa justificada y sin consentimiento de la persona que posea dicho secreto o de su usuario autorizado.

De este artículo se desprende que es una obligación o carga del empresario que posee un secreto empresarial el advertir sobre su confidencialidad a las personas que por uno u otro motivo hayan de tener acceso al mismo. Si el empresario interesado omite hacer esta advertencia entonces las personas que hayan tenido acceso a la información podrán libremente usarla o divulgarla.

En el caso de quien encarga el desarrollo de un programa de computador, es de su interés y necesidad el consagrar debidamente en el contrato una estipulación en virtud de la cual se obligue al desarrollador a mantener la confidencialidad sobre la información que constituye su secreto empresarial. Esta obligación debe extenderse no solamente al desarrollador sino a su personal, quien también debe estar sujeto a obligación de confidencialidad en el marco de los respectivos contratos de trabajo o de prestación de servicios.

1.3.4. Propiedad del código fuente

En los contratos para el desarrollo de programas de computador, la entrega del código fuente es uno de los puntos materia de negociación, de la mano de la dis- cusión sobre la titularidad de los derechos de autor respecto del software resultante. La posesión del código fuente determina la posibilidad de efectuar cualquier modificación o actualización del programa de computador. Si el cliente o encargante recibe el código fuente debidamente documentado, puede realizar por sí mismo, si así lo tiene a bien, el futuro mantenimiento de la aplicación. Por el contrario, si carece del código fuente deberá acudir necesariamente a su proveedor (el desarro-

llador) cada vez que necesite efectuar cualquier modificación a la misma.

En cuanto a la entrega del código fuente, se suelen contraponer los intereses del cliente o encargante y del desarrollador, así: el cliente o encargante suele

reclamar que no cuenta con garantía suficiente en caso de que en el futuro la em- presa desarrolladora desaparezca, y no se encuentre a nadie capacitado para seguir proveyendo mantenimiento y soporte a la aplicación que le fue vendida, motivo por el cual necesita tener una copia del código fuente (e inclusive solicita todo el código fuente, incluyendo las bases de datos y librerías que el desarrollador utiliza como base de todos su proyectos), para así poder asumir con sus propios medios las modificaciones o actualizaciones a que haya lugar.

Por su parte, el desarrollador (en especial cuando conserva los derechos patrimo- niales de autor sobre el software) prefiere mantener el código en secreto pues aspira válidamente a poder comercializar con otros clientes el software de su propiedad, y en ese sentido atenta seriamente contra el éxito de su propósito la divulgación del código fuente, pues las personas que tengan acceso al mismo y cuenten con la capacidad suficiente estarán en la posibilidad de basarse con dicho código para desarrollar otras aplicaciones más o menos diferentes y con igual funcionalidad.

Si en el contrato de desarrollo las partes guardan silencio en torno a la entrega del código fuente, o mejor, si no se pacta expresamente que el desarrollador habrá de entregar al cliente o encargante una copia del código fuente, esto significa en consecuencia que tal obligación no existe. En efecto, tal obligación solo puede tener como sustento el contrato: la ley no entra en manera alguna a suplir la voluntad de los contratantes para ordenar la entrega del código fuente, así como tampoco existe costumbre mercantil que pueda servir de sustento a la exigencia de su entrega. La Cámara de Comercio de Bogotá, en su función de emitir certificaciones sobre la costumbre mercantil que constituye fuente del derecho y por los tanto es exigible jurídicamente de conformidad con el Código de Comercio, adelantó en el año 2004 una investigación a efecto de verificar si los contratos de licencia de software conllevan habitualmente la entrega del código fuente como una costumbre mercantil. Al cabo de una investigación de tipo jurídico y estadístico llegó a la conclusión de que no existe una práctica generalizada y consuetudinaria en este sentido, y que por tanto dicha entrega no puede tener como sustento la

costumbre mercantil1.

1.3.5. ¿Propiedad sobre la idea?

Cabe formularse la siguiente pregunta: ¿la idea de desarrollar un software nove- doso o más o menos innovador en el mercado le pertenece únicamente a quien la concibe? Si alguien distinto termina desarrollando el software significa entonces que le “robó su idea” y por lo tanto debe asumir las consecuencias de haber violado los derechos de quien la concibió originalmente?

Por principio, las ideas no son protegibles por el derecho de autor. Nadie puede reclamar la propiedad exclusiva de una idea abstracta; no obstante, otra cosa sucede

1. cámara de comercio de bogotá. Costumbre mercantil Nº 17, diciembre de 2004, disponible en: [xxxx://xxxxxx.xxx.xxx.xx/xxxxxxxxxx/000_0000_00_00_00_00_00_00_xxxxxxxxx.xxx ].

si la idea está desarrollada en información susceptible de ser protegida desde el punto de vista de los secretos empresariales, en la medida que dicha información sea mantenida en secreto y se llenen los demás requisitos exigidos por la ley.

Lo que puede suceder en la práctica es que el creador de la idea logre asegurarse su control exclusivo mediante el manejo contractual de la información constitutiva xx xxxxxxx empresarial, y de esta manera pueda impedir que terceros sin autorización la accedan, la exploten o comercialicen.

Una vez la idea se plasma y se desarrolla en un programa de computador, en- tonces sí empieza a operar la protección del derecho de autor para impedir que ese programa sea copiado, reproducido o comercializado sin autorización del titular de los derechos patrimoniales. Si el empresario logra mantener su proyecto en secreto hasta el lanzamiento del producto al mercado, disfrutará seguramente los benefi- cios de haber sido innovador, mientras que otras empresas competidoras tardarán tiempo en desarrollar programas diferentes que cumplan la misma funcionalidad.

1.3.6. Controversias sobre la calidad del software desarrollado

El Código Civil establece:

Artículo 2059. Ejecución indebida de la obra. Si el que encargó la obra alegare no haberse ejecutado debidamente, se nombrarán por las dos partes peritos que decidan.

Siendo fundada la alegación del que encargó la obra, el artífice podrá ser obligado, a elección del que encargó la obra, a hacerla de nuevo o a la indemnización de perjuicios.

La restitución de los materiales podrá hacerse con otros de igual calidad o en dinero.

Las disposiciones relativas a la confección de obras materiales en lo que respecta al rechazo de la obra defectuosa (art. 2059 C.C.) se hacen extensivas a aquellos casos en que lo que se contrata es la elaboración de una obra o creación intelectual por virtud del artículo 2063 ibídem.

No se elimina la responsabilidad del artífice de modo absoluto por el mero hecho de la entrega y recepción de la obra. Por el contrario, tal cese de responsabilidad solo opera respecto de los vicios manifiestos o aparentes, es decir, los que no sean comprobables por su clara exteriorización, dado que no puede darse conformidad con lo que no se conoce, de manera que si los vicios o defectos estaban ocultos tendrá posibilidad de reclamo, al descubrirlos. Lo que libera la responsabilidad por los defectos o vicios es la “aceptación” de la obra, pues por recepción de ella debe entenderse no solo la toma y retiro de la cosa, como en la compraventa, sino además el reconocimiento de que se admite la obra en general como cumplimiento, aceptación que podrá ser expresa o tácita.

¿Qué sucede con los defectos de la obra que solo son advertidos después de que la obra ha sido recibida o aceptada? Si las partes se vincularon por un contrato

para la elaboración de una obra intelectual, cabe precisar que las posibles falencias o defectos de que pueda adolecer el mencionado proyecto no pueden ser adverti- dos en su totalidad por el encargante de manera palmaria al momento de recibir el ejemplar en que se plasma dicha obra. Por lo tanto, si se verifica el rechazo de la obra encargada luego de examinar su contenido, o sea, después de conocer y ponderar detenida y cuidadosamente el contenido y calidad de la obra, tal proceder no resulta arbitrario ni extemporáneo. Por el contrario, se trataría de un ejercicio racional de las facultades conferidas por el artículo 2059 C.C.

El caso De Beers UK Ltd vs. Atos Origin IT Services UK Ltd (Xxxxx Unido) (2010) ilustra las vicisitudes que pueden presentarse en torno al conflicto por la calidad del producto en el contrato de desarrollo de software.

La empresa Atos Origin IT Services UK Ltd contrató a la empresa De Beers UK Ltd. para desarrollar de manera conjunta y colaborativa un software cuyo propósito era sacarlo al mercado para ser vendido al público, habiendo acordado que los derechos de autor quedarían en cabeza del cliente o encargante. Se acordó realizar un pago inicial y otros pagos parciales a medida que avanzara el proyecto, el último de los cuales se haría a los 30 días de haberse lanzado al mercado el software, siempre y cuando no hubiera problemas de calidad por los cuales los consumidores hubieran hecho devolución del producto. En caso de que hubiera reclamos por la calidad, las pérdidas de las devoluciones serían descontadas del valor a pagarse al desarrollador. En el momento de efectuarse el último pago, el desarrollador firmaría los documentos de transferencia de los derechos de autor a favor del cliente o encargante, pero en el evento de que el cliente o encargante incurriera en xxxx del pago la transferencia no se firmaría y los derechos de autor quedarían para el desarrollador.

Una vez el desarrollador entregó al cliente el software objeto del contrato, dicho cliente o encargante lo sacó al mercado como era su propósito, dejando constancia de que el software no había sido aceptado aún de manera formal (y estando pendiente el último pago). Los consumidores empezaron a expresar su inconformidad y el desarrollador tuvo que proporcionar adicionalmente unos “parches” de programación y un documento de preguntas y respuestas para aclarar las dudas sobre la instalación.

No obstante, como las quejas de los consumidores continuaron, el cliente o encargante decidió negarse a hacer el pago argumentando que el software tenía problemas de calidad. Ante esto, el desarrollador interpuso una demanda judicial reclamando el pago del saldo del precio que estaba pendiente.

El Tribunal de primera instancia consideró que en el campo del desarrollo de software la revisión o evaluación del mismo por parte del cliente o encargante se realiza a medida que el trabajo avanza y aun después de su entrega. Consideró también que el cliente o encargante sacó el software al mercado inmediatamente lo recibió del desarrollador y sin que se hubiera formalizado todavía la aceptación. Por este hecho, consideró el Tribunal, el cliente o encargante tenía que asumir las

consecuencias de haber comercializado el producto en esas condiciones. El hecho de que el cliente o encargante hubiera aceptado las correcciones ofrecidas por el desarrollador (el parche de programación y el documento de preguntas frecuentes para la instalación) y las hubiera incluido dentro del paquete que había seguido vendiendo a los consumidores lo interpretó el Tribunal como una aceptación por parte de este de las condiciones de calidad del software desarrollado. Bajo estas condiciones, el hecho de que el cliente o encargante no hubiera pagado el saldo del precio que estaba pendiente resultaba ser un incumplimiento del contrato, y en consecuencia el Tribunal falló a favor del desarrollador y condenó al cliente o encargante a pagar la suma adecudada, con sus intereses y las costas del proceso.

El cliente o encargante apeló la sentencia de primera planteando que: 1) en- contró dos defectos del software durante las pruebas preliminares que se realizaron antes de que el software fuera comercializado. Aceptó que el software fue vendido antes de haberse formalizado la aceptación pues necesitaba evitar la ampliación de las pérdidas que se le estaban causando; 2) las pruebas finales no pudieron realizarse oportunamente debido a que el desarrollador terminó el diseño del programa en la noche anterior a la fecha de entrega; 3) en el proceso judicial, las pruebas que se practicaron en la primera instancia sobre la calidad del software no alcanzaron a comprender otros defectos que se le encontraron con posterioridad, y 4) fue en ejercicio del derecho de rechazo o repudio que el cliente o encargante no pagó el valor del saldo final del precio de conformidad con el contrato. Por lo tanto, el apelante pidió a la Corte revocar la sentencia de primera instancia, u ordenar un nuevo juicio conforme a la ley.

El desarrollador respondió a la apelación sosteniendo que los hechos fueron claramente comprobados y que las evidencias eran suficientes, siendo la ley aplicada correcta, de manera que pidió a la Corte confirmar la sentencia de primera instancia.

El Tribunal de segunda instancia consideró que los hechos básicos comprobados por el Tribunal de primera instancia fueron claros, que la ley se aplicó correctamente al caso y que el procedimiento fue legal.

De acuerdo a las condiciones propias del desarrollo de software, este debe ser continuamente revisado y optimizado a lo largo del trabajo de desarrollo y aun después. El hecho de que el software involucrado en el caso tuviera defectos no significa que existieran problemas de calidad. Si la ingeniería de desarrollo de soft- ware hubiera tenido problemas de calidad los mismos estarían sujetos a la norma técnica acordada en el contrato. El contrato de este caso se cumplió por parte del desarrollador en cuanto al tiempo estándar o cronograma, personal técnico invo- lucrado en el proyecto y método de desarrollo de software. Así las cosas, cualquier responsabilidad de las partes habría de corresponder al grado de cumplimiento que las mismas dieron al contrato.

En cuanto a las razones que el cliente o encargante invocó respecto a que era el desarrollador quien había incumplido el contrato primero, por haber entregado un software con problemas de calidad, el cliente o encargante tuvo en su oportu-

nidad el derecho de rechazar o repudiar el producto entregado, y ese hubiera sido fundamento válido para no pagar el pago del resto. En lugar de esto, el cliente o encargante lanzó el producto al mercado así como también comercializó las co- rrecciones o parches que el desarrollador ofreció, lo cual evidencia la aceptación por parte del cliente o encargante de la calidad del software desarrollado.

Con fundamento en lo anterior, el Tribunal de segunda instancia concluyó que no existían pruebas que demostraran el incumplimiento del desarrollador respecto de las cuestiones de calidad del software antes de su comercialización y que el contrato se cumplió por parte del desarrollador al haber realizado el cliente o encargante actos que evidenciaron su aceptación del producto recibido, de ma- nera que procedió a ordenar al cliente o encargante el pago del saldo del precio convenido en el contrato.

En esos términos, el Tribunal de segunda instancia desestimó la apelación y confirmó la sentencia inicial.

Así las cosas puede concluirse de este ejemplo lo siguiente:

1. La existencia de defectos de software no significa necesariamente que el cliente o encargante tenga justificación para rechazar o repudiar el producto entregado objetando su calidad.

Nuestra opinión sobre la relación entre los eventuales defectos de calidad del soft- ware y el rechazo o repudio del producto es que los problemas de calidad del software son una cuestión sustancial, por eso la calidad estándar que debe cumplir el software debe estar regulada en el contrato. Si el cliente o encargante cree tener fundamento para objetar la calidad debe entonces notificar claramente al desarrollador su rechazo o repudio del producto entregado, y debe poder estar en condiciones de demostrar o probar en el futuro que realizó y notificó oportunamente dicho rechazo o repudio.

Si el estándar de calidad no es claramente acordado en el contrato y el cliente o encargante no tiene pruebas para demostrar que ejerció clara y oportunamente su derecho a rechazar o repudiar la calidad del software desarrollado, no podrá entonces reclamar o argumentar que el desarrollador incumplió el contrato ni negarse a pagar el precio acordado.

Bajo estas condiciones, si el cliente o encargante no acepta el software entregado por el desarrollador con pruebas claras de que la calidad no corresponde a la que se pactó en el contrato, tendrá fundamento para manifestar su rechazo o repudio, el cual deberá notificar en su debida oportunidad.

2. Que el software presente defectos no significa que tenga problemas de calidad. Tanto el Tribunal de primera como el de segunda instancia sostuvieron que según las condiciones generales del desarrollo de software, este necesita continua- mente revisión después de terminado su desarrollo. Si la ingeniería de desarrollo de software tiene problemas de calidad los mismos estarán sujetos a la norma técnica

acordada en el contrato.

A falta de unos requisitos de calidad claramente definidos en el contrato, podría aplicarse alguna norma nacional, estándar industrial u otra norma general.

3. Que el software tenga defectos no significa necesariamente que el cliente o encargante pueda negarse a pagar la totalidad del precio acordado.

Puede suceder que un cliente o encargante invoque cualquier defecto que según su parecer presenta el software desarrollado, como argumento para negarse a hacer el pago del precio o del saldo final del mismo.

En nuestra opinión, si ambas partes acuerdan deducir las pérdidas sufridas por el cliente o encargante por los defectos del software del precio a pagarse al desarrollador, esta cláusula puede resultar aconsejable siempre y cuando la deter- minación de los defectos y la tasación de las pérdidas que son consecuencia de los mismos puedan ser determinadas por un tercero de confianza de ambas partes, debidamente calificado.

Si en el contrato no se incluye una cláusula de esta naturaleza, las partes asumen el riesgo legal de que el cliente o encargante se niegue a efectuar el pago del precio o del saldo final del mismo justificándose en los defectos del desarrollo del software, lo que daría lugar a que el desarrollador tuviera que reclamar judicialmente dicho pago, a lo que el cliente o encargante se negaría invocando los defectos de calidad, situación que requeriría la intervención de peritos y a un largo y costoso proceso judicial.

4. Si el software presenta defectos de calidad demostrados, el cliente o encargante deberá notificar al desarrollador que no lo acepta o recibe (rechazo o repudio), y solo entonces negarse a pagar el precio o el saldo final del mismo hasta tanto no se defina judicialmente la situación.

La responsabilidad fundamental del cliente o encargante es la de pagar el precio acordado, mientras que la responsabilidad del desarrollador es la de desarrollar y entregar el software bajo las condiciones de calidad pactadas o aplicables al caso. No obstante, ninguno de los dos contratantes está obligado a cumplir su parte mientras que el otro contratante no cumpla a su vez sus obligaciones derivadas del contrato, o no se allane a cumplirlas.

No obstante, si el cliente o encargante acepta el software entregado por el de- sarrollador de manera expresa o tácita, mediante actos inequívocos de aceptación, no podrá luego negarse a efectuar el pago del precio o del saldo final del mismo.

1.3.7. Parametrización de software e implementación

Actualmente en la industria informática el desarrollo de software a la medida ha venido cediendo terreno ante el auge de la oferta y demanda del servicio de pa- rametrización e implementación de aplicaciones informáticas preelaboradas, que evita a las partes la tarea a veces dispendiosa de tener que arrancar un proyecto “desde cero” y les permite concentrarse en el proceso de adaptación o personali- zación de la aplicación informática preelaborada a las particulares condiciones y necesidades del cliente.

Se suele diferenciar entre los términos “implantar” e “implementar” el software, en la siguiente forma: la palabra “implantar” se utiliza en relación con aquel soft-

ware que se puede instalar y parametrizar sin necesidad de hacer modificaciones en su código fuente. Por su parte, se utiliza la palabra “implementar” cuando hay necesidad de hacer modificaciones o nuevos desarrollos que implican programación y modificación de los códigos fuente.

En este sentido, respecto del servicio y el contrato consistente en la parametri- zación e implementación de software, en cuanto implica la modificación del código fuente, y comprende actividades de compilación, instalación, personalización, mi- gración de datos, capacitación y entrega de documentación, son de aplicación los comentarios y análisis mencionados respecto del contrato de desarrollo de software a la medida, salvo en relación con la transferencia de los derechos patrimoniales del autor, pues en este caso no suele existir tal transferencia de derechos sino que más bien lo que se otorga al cliente es una licencia de uso respecto del software así parametrizado.

2. contrato de licencia de software

2.1. concepto y características

En el contexto del derecho de autor, los contratos de licencia son aquellos cuyo objeto es autorizar uno o varios usos o actos de explotación de una obra protegida. A quien otorga dicha autorización se le denomina “licenciante”, y quien se beneficia de la misma se conoce como “licenciatario”. Una característica esencial de estos contratos consiste en que el titular del derecho de autor (generalmente el licen- ciante) no transfiere o cede la titularidad de tales derechos, sino que los mantiene en su poder, y se limita a autorizar, de manera exclusiva o no, los distintos usos o actos de explotación de que la obra puede ser objeto. Así mismo, la amplitud de sus derechos exclusivos de autor le brinda al licenciante la posibilidad jurídica de definir con detalle el alcance y las restricciones de las autorizaciones que otorga.

El contrato de licencia de software tiene por objeto autorizar al usuario ciertos usos o actos de utilización de un programa de computador, pudiendo comprender tanto la instalación en la memoria de un computador personal o servidor de red para el acceso de un determinado número de equipos cliente, como el acceso y uso de una aplicación en línea. Así mismo, el alcance de tales autorizaciones podrá variar según el tipo de licencia, pudiendo llegar a comprender inclusive la modificación y redistribución del programa de computador, así como el acceso al código fuente, como sería el caso por ejemplo del software libre de código abierto.

El alcance de la autorización viene determinado por las restricciones de uso que la propia licencia señala o determina, incluyendo generalmente la prohibi- ción de comercializar el software, instalarlo en un número de equipos superior al autorizado estrictamente, o hacerlo accesible a través de una red informática a un número de equipos cliente superior al determinado en la licencia, o permitir el uso del software a personal de empresas diferentes a la titular de la licencia, etc.

El fundamento jurídico del contrato de licencia de software parte del hecho de que los programas de computador constituyen obras protegidas por el derecho de autor que como tal está amparado por una serie de derechos exclusivos de natura- xxxx moral y patrimonial en virtud de los cuales el titular del derecho patrimonial de autor puede disponer de su obra libremente a título gratuito u oneroso bajo las condiciones lícitas que su propio criterio le dicte.

De este derecho de propiedad intelectual, y de su carácter exclusivo, surge el control jurídico que el titular de los derechos patrimoniales tiene para autorizar o prohibir las distintas formas de explotación de las que la obra puede ser objeto. Por ejemplo, la instalación del programa de computador en la memoria de un sistema informático constituye un acto de reproducción, y en virtud del derecho de reproducción es que el titular del derecho puede autorizar o prohibir la instalación del software en un de- terminado número de equipos. Así mismo, el acceso a través de redes informáticas a la obra es un acto de comunicación pública (en la modalidad de puesta a disposición) que requiere la autorización previa y expresa del titular del derecho patrimonial. De esta forma, es a través del contrato de licencia de software que el titular de derechos patrimoniales sobre un programa de computador dispone de sus derechos exclusivos para permitir al licenciatario acceder al uso y disfrute de la obra.

La autorización que se otorga a través de la licencia de uso es de carácter no exclusivo, de manera que el titular de derechos se reserva la posibilidad de autorizar el uso de la misma obra a todas las demás personas respecto de las cuales tenga a bien hacerlo.

Este contrato puede caracterizarse como:

– Bilateral

– Oneroso o gratuito

– Conmutativo

– Atípico

– Principal o accesorio

– Innominado

2.2. tipos de licencias

En cuanto al grado de libertad o de restricción de uso que se faculta al licenciatario, se suele diferenciar entre los siguientes tipos o modalidades de licenciamiento:

– Licencias de software comercial o propietario

– Licencias shareware

– Licencias freeware

– Licencias de software libre

En cuanto al grado de estandarización de los términos de la licencia, se diferencia así:

– Licencias de software genérico (empaquetado) que corresponden a contratos de adhesión (shrink wrap licences)

– Licencias de software personalizado

– En cuanto a la forma de celebración del contrato se puede diferenciar entre:

– Licencias celebradas por escrito

– Licencias celebradas por otros medios válidos de expresión del consentimiento

– Licencias celebradas por medios electrónicos (click wrap licences)

2.2.1. Licencias de software propietario, shareware, freeware y software libre

Las licencias de software comercial o propietario, en términos de la Software Publishers Association, se caracterizan como sigue:

… se cobra por el derecho de adquirir, instalar y/o acceder en línea una copia del pro- grama de computador, y por el derecho mismo de servirse del programa para los fines propios del usuario. Generalmente vienen establecidas una serie amplia de restricciones que impiden al usuario redistribuir las copias del programa, comercializarlo o permitir su uso por parte de personas distintas de las estrictamente autorizadas. Estas licencias y el software amparado en ellas se comercializan junto con la entrega del programa en su versión de código objeto, impidiendo el acceso al código fuente y restringiendo la posibilidad de que el usuario efectúe cualquier modificación al programa.

Las licencias shareware corresponden a un tipo de distribución de aplicaciones que consiste en liberar gratuitamente una versión con funcionamiento limitado. Esa limitación puede ser temporal (después de determinada cantidad de días deja de operar), por funciones (desde el comienzo, o a partir de determinado momento, hay funciones que el programa deja de realizar) o una combinación de las men- cionadas (el programa empieza con todas sus funciones y deja de realizar algunas al cabo de cierto tiempo). En cualquier caso, al finalizar el período de prueba el usuario debe pagar la licencia o desinstalar el programa.

Por su parte, las licencias freeware son licencias que permiten obtener, instalar y/o usar gratuitamente un programa de computador. No es necesario que el usuario se registre, se suscriba o compre una licencia. La gran diferencia entre el freeware y el código abierto (“open source”) es que el primero es cerrado, es decir, el usuario solo tiene acceso al código objeto del programa, no al código fuente.

Algunas licencias oscilan entre el freeware y el shareware, dependiendo de la manera como se exija o se haga opcional el pago por el programa. En algunos casos, el autor solo espera a cambio que le envíen un post o un mensaje de correo, en otros solicita una donación voluntaria, o un registro de los datos del usuario sin que implique ningún costo.

Por su parte, las licencias de software libre se explican a través del concepto de “copyleft”, que, por oposición al copyright, constituye un modelo alternativo de licenciamiento de obras en donde se privilegia el libre acceso y uso de las creaciones intelectuales, y con el cual sus promotores buscan brindar alternativas frente a los

inconvenientes y restricciones que –consideran ellos– se derivan del control de los titulares de derechos de autor sobre sus obras.

Las licencias de software constituyen un ejemplo de tales modelos alternativos de licenciamiento aplicado en materia de los programas de computador.

La Free Software Foundation creó la licencia más difundida de este tipo, que se denomina Licencia Pública General (gnu), la cual está basada en cuatro principios:

– Libertad de usar el programa con cualquier propósito (que conlleva la libertad de obtener sin costo una copia del programa e instalarla).

– Libertad de estudiar cómo funciona el programa y de adaptarlo a las necesi- dades del usuario (que implica el acceso al código fuente).

– Libertad de distribuir copias (valga aclarar que no se puede cobrar por ellas).

– Libertad de mejorar el programa y hacer públicas las mejoras a los demás, de modo que toda la comunidad se beneficie.

Existen otros dos tipos de licencias creadas por la Free Software Foundation: la Lesser gpl (Licencia Pública General Menor) y la fdl (Licencia de Documenta- ción Libre).

La licencia Lesser gpl permite al desarrollador de software libre utilizar librerías (conjuntos de rutinas que ejecutan distintas funcionalidades) que no son libres (como es el caso de la compresión de imágenes jpeg, p. ej.), haciendo la mención de que el programa desarrollado las utiliza.

La licencia fdl (Licencia de Documentación Libre) es una modalidad xx xx- cencia de copyleft para ser usada en un manual, libro de texto u otro documento relacionado con algún programa de computador o con cualquier texto en general.

La Free Software Foundation publicó una clasificación de licencias compatibles y no compatibles con la licencia gpl, entre las cuales se mencionan:

– La licencia xII que, atribuida frecuentemente al Instituto de Tecnología de Massachusetts (mit), es una licencia sin libre acceso, utilizada para las interfaces y los servidores de video como el xFree86.

– La licencia bsd, empleada en sistemas operativos diferentes a Linux, espe- cialmente NetBSD y FreeBSD. Fue diseñada en la Universidad xx Xxxxxxxx y se le considera una licencia de software libre simple y permisiva.

– La Open Software License, avalada por la Open Source Initiative (osi) creada por Xxxxx Xxxxxx y Xxxx X. Xxxxxxx, es una licencia de código abierto y de libre acceso similar a la gpl, pero contiene algunas menciones de patentes.

– Existen también muchas licencias que llevan el nombre de la aplicación o la organización que las instrumentó por primera vez, por ejemplo, las licencias Apache, Mozilla, Netscape, Jabber, Sun, Zope, etc. Estas licencias pueden o no ser derivadas de la gpl y pueden permitir o no el libre acceso, y han terminado siendo utilizadas para otros productos diferentes a aquellos para las que fueron creadas.

2.2.2. Licencias de software estándar (empaquetado) y personalizado

Hay dos tipos de licencias en función del grado de estandarización de sus términos y condiciones:

– Las licencias de software estándar o genérico (empaquetado)

– Las licencias de software personalizado

El software genérico corresponde a programas de computador que se venden al mercado abierto por canales masivos de distribución de manera que cualquier con- sumidor interesado puede adquirirlos. Algunas veces estos se denominan software empaquetado, simbolizando que se distribuyen al mercado en cajas o empaques sellados, listos para usar.

Como se trata de productos de distribución masiva, este tipo se software ha- bitualmente se ampara en contratos de adhesión de licencia de uso de software (shrink-wrap license), en donde las partes productor y cliente no tienen oportu- nidad de discutir libremente los términos y condiciones del contrato de licencia. Un contrato de adhesión es un tipo de contrato cuyas cláusulas son redacta- das por una sola de las partes, dejando a la otra parte en la única alternativa de aceptarlo o no en su integridad. Estos contratos son propios de la contratación masiva de productos o servicios tales como la suscripción de servicios públicos domiciliarios, contratos de servicios bancarios y de seguros, y venta de productos

de distribución masiva.

El tratamiento legal de los contratos de adhesión en Colombia implica:

1. Que las condiciones generales de los contratos de adhesión son ineficaces y se consideran no escritas si no cumplen con las obligaciones de:

– Haber informado suficiente, anticipada y expresamente en idioma castellano al adherente sobre la existencia, efectos y alcance de las condiciones generales (en los contratos se deberá utilizar el idioma castellano).

– Haber sido redactadas de manera concreta, xxxxx y completa.

– En los contratos escritos, los caracteres de los contratos deben ser legibles a simple vista y no incluir espacios en blanco.

2. Que en materia de la interpretación de los contratos, cuando existan cláusulas ambiguas (que se presten para varias interpretaciones posibles) se preferirá la in- terpretación que favorece a la parte que no redactó el contrato (el consumidor), lo que por tanto desfavorece a la parte que lo redactó (el proveedor del producto o servicio), siempre que la ambigüedad provenga de la falta de una explicación que haya debido darse por parte de ella (art. 1624 C.C.). En materia de protección al consumidor se establece que las condiciones generales de los contratos serán inter- pretadas de la manera más favorable al consumidor. En caso de duda, prevalecerán las cláusulas más favorables al consumidor sobre aquellas que no lo sean (art. 34 Estatuto del Consumidor).

3. Que se prohíbe incluir cláusulas que permitan al productor y/o proveedor modificar unilateralmente el contrato o sustraerse de sus obligaciones.

4. Que en los contratos de adhesión de tracto sucesivo solo podrá pactarse una cláusula de permanencia mínima cuando el consumidor obtenga una ventaja sustancial frente a las condiciones ordinarias del contrato.

5. Que son ineficaces de pleno derecho las cláusulas que el Estatuto del Con- sumidor considera como abusivas, esto es, aquellas que producen un desequilibrio injustificado en perjuicio del consumidor y las que, en las mismas condiciones, afecten el tiempo, modo o lugar en que el consumidor puede ejercer sus derechos. En cuanto a las licencias de software personalizado, a diferencia del software estándar, si bien pueden partir de la base de un contenido estándar, el productor respectivo realiza modificaciones o ajustes necesarios para adecuar el producto a las necesidades específicas de un determinado cliente o usuario. Como esta modalidad supone un contacto directo o personal entre el productor de software y el usuario, las respectivas licencias de uso suelen ser también personalizadas o ajustadas a los términos y condiciones acordadas entre las partes, sin que exista en este caso un

contrato de adhesión.

En el escenario en que las partes se encuentran en libertad de plasmar y dar forma a los términos del contrato (son “contratos de libre discusión”, por oposición a los contratos de adhesión) es necesario atender a los principios de contratación que dichas partes deben tener en cuenta.

Dentro de los principios de interpretación de los contratos en materia de derecho de autor, la autorización de uso se encuentra limitada a aquel o aquellos mencionados en el contrato, aclarando la diferencia e independencia entre la ce- sión de derecho de representación y la cesión del derecho de reproducción, que no supone lo mismo. La norma establece que en el contrato se expresen las posibles modalidades o limitaciones que convienen las partes para realizar el acto.

La cesión de derechos así como las autorizaciones o licencias de uso que hace el autor a terceros deben interpretarse en forma restrictiva, es decir solo aquellos límites previstos en el contrato podrán ser entendidos como cesibles sin considerar los derechos que constituye para el titular una reserva propia y particular para su uso.

2.2.3. Licencias celebradas por escrito, por otros medios válidos y por medios electrónicos

En cuanto a la forma de celebración del contrato se puede diferenciar así:

– Licencias celebradas por escrito

– Licencias celebradas por otros medios válidos de expresión del consentimiento (aceptación tácita)

– Licencias celebradas por medios electrónicos (click wrap licences)

En las licencias celebradas por escrito el productor del software y el usuario celebran a través de la licencia un contrato consensual, es decir que se perfecciona por el solo consentimiento de las partes, en donde uno y otro regulan sus intereses privados, pudiendo negociar y acordar diversas estipulaciones en ejercicio de su libertad y autonomía privada.

Acorde con el estatuto mercantil, los contratos se perfeccionan mediante la oferta y la aceptación. Dispone el artículo 864 X.Xx. que el contrato es un acuerdo de dos o más partes para constituir, regular o extinguir entre ellas una relación jurídica patrimonial, y que, salvo estipulación en contrario, se entenderá celebrado en el lugar de residencia del proponente y en el momento en que este reciba la aceptación de la propuesta.

En los términos del artículo 845 X.Xx., debe entenderse por “oferta o propues- ta” el proyecto de negocio jurídico que una persona formula o comunica a otra, siempre y cuando contenga los elementos esenciales del negocio y sea comunicada al destinatario. Se entenderá que la propuesta ha sido formulada o comunicada cuando se utilice cualquier medio adecuado para hacerla conocer del destinatario. Si bien el Código Civil no contiene disposiciones respecto a la formación del consentimiento, como tampoco define su concepto (simplemente se exige un consentimiento libre de vicios como requisito de validez del contrato), hoy en día parece no haber discusión acerca de que tanto los contratos consensuales civiles como los mercantiles se perfeccionan de la forma mencionada, esto es, mediante

la realización de una oferta y su consecuente aceptación.

La aceptación puede ser entendida como aquella declaración de voluntad realizada por el destinatario de la oferta por medio de la cual expresa su confor- midad en todos los aspectos con la oferta y, por tanto, manifiesta su voluntad de perfeccionar el negocio jurídico. En este mismo sentido coincide la generalidad de la doctrina en materia de contratos:

Albaladejo2 la define como “la declaración de voluntad por la que aquél a quien se ofreció la celebración del contrato, da a conocer su conformidad con ésta”.

Xxxx-Xxxxxx0 la entiende como “aquella declaración o acto del destinatario de una oferta que manifiesta el asentimiento o conformidad con ésta”.

Ferri4, a su turno, señala que la oferta “es la declaración de voluntad que el des- tinatario de la oferta dirige al oferente y mediante la cual se concluye el contrato”.

Flume5 la define así: “La declaración de aceptación es básicamente igual que la oferta, una declaración de voluntad recepticia, por consiguiente, se hace eficaz al llegar al oferente. No es ningún negocio jurídico unilateral independiente, sino una parte del negocio que es el contrato”.

2. xxxxxx xxxxxxxxxx. Derecho civil. Derecho de obligaciones. La obligación y el contrato en general, t. II, vol. 1.°, 10.ª ed., Xxxxxxxxx, Xxxxx, 0000, p. 394.

3. xxxx xxxx-xxxxxx. Fundamentos de derecho civil patrimonial. Introducción. Teoría del contrato, Madrid, vol. 1, 5.ª ed., 1996, p. 305.

4. xxxxx xxxxx. La autonomía privada, Granada, Comares, 2001, p. 145.

5. xxxxxx xxxxx. El negocio jurídico, Madrid, Fundación Cultural del Notariado, 1998, p. 744.

Scognamiglio6 refiere al respecto que “la aceptación constituye el caso con el cual concluye el ciclo formativo del contrato. En efecto, es el medio a través del cual el destinatario manifiesta su adhesión a la propuesta, tal como le ha sido formulada por la otra parte. Y en ese momento, el del encuentro y de la congruencia de los actos dispositivos de las partes interesadas, se celebra el acuerdo”.

Ahora bien, sobre los requisitos de validez de la aceptación la doctrina coincide más o menos en los mismos términos:

Xxxxxxxx xx Xxxxxxx0, siguiendo x Xxxx-Xxxxxx, señala como requisitos de la aceptación los siguientes: “1) debe coincidir con la oferta en todos sus términos; 2) debe suponer una voluntad de contratar que sea definitiva; 3) es una declaración de voluntad recepticia; 4) puede llevarse a cabo con arreglo a cualquier forma, salvo que el oferente haya dispuesto otra cosa, o el contrato sea formal; 5) debe ser tempestiva”.

En relación precisamente con la forma de la aceptación, surge una cuestión relevante para el tema de la celebración y perfeccionamiento de los contratos de licencia de programas de computador, cuando el mismo se celebra respecto de software que se comercializa como estándar o empaquetado en donde no existe un documento que el productor ni mucho menos el usuario firmen como demos- tración de su aceptación de las condiciones de la licencia.

En otras palabras, cuando el contrato de licencia se celebra por escrito y el productor y el usuario suscriben el documento en señal de su aceptación, no cabe duda de que existe una forma válida de expresar el conocimiento y consentimiento, de manera que ambas partes quedan obligadas recíprocamente según sus estipula- ciones y el contrato les es vinculante o exigible. Sin embargo, cuando la naturaleza del programa de computador y la forma en que se comercializa no dan lugar a que se pueda suscribir un documento por las partes o a que el usuario pueda aceptar expresamente el documento de licencia que el productor redactó, surge la cuestión de determinar de qué otra manera puede ser válidamente aceptado el contrato para que este se perfeccione y obligue a las partes.

2.2.4. Licencias celebradas por otros medios válidos de expresión del consentimiento (aceptación tácita)

Por lo general el programa de computador empaquetado o estándar es comer- cializado entregando un ejemplar del programa en su versión de código objeto (lenguaje de máquina) y los manuales de funcionamiento. Este software viene acompañado de un documento o formato de licencia de uso que determina los términos y condiciones de tal utilización. La validez jurídica de este documento

6. xxxxxx xxxxxxxxxxxx. Teoría general del contrato, trad. xxxxxxxx xxxxxxxxxx, Bogotá, Universidad Externado de Colombia, 1983, p. 130.

7. xxxxxx xxxxxxxx xx xxxxxxx, xxxxx de xxxxx xxxxxxxxx, xxxxxx xxxxx xxxxx xxxxxxx y xxxxx xxxxxxx xxxxx xxxxx. Curso de derecho civil, II, Derecho de obligaciones, Madrid, Colex, 2000, p. 366.

como contrato vinculante u obligatorio para las partes (nótese que el comprador no firma propiamente un documento en donde manifieste conocer y aceptar las condiciones de la licencia) será analizada a continuación.

La aceptación puede ser materializada en virtud de una declaración de voluntad expresa o tácita. Para que exista aceptación tácita se requiere que se constituya a través de actos inequívocos del aceptante que signifiquen conformidad con la oferta. El artículo 854 X.Xx. establece que la aceptación tácita, manifestada por un hecho inequívoco de ejecución del contrato propuesto, producirá los mismos efectos que la expresa, siempre que el proponente tenga conocimiento de tal hecho dentro

de los términos de aceptación de la oferta, los cuales son:

– Si la propuesta fue verbal de manera presencial o por teléfono, la aceptación debe hacerse inmediatamente.

– Si la propuesta se hizo por escrito, la aceptación debe hacerse dentro de los seis días siguientes. Si el destinatario de la oferta reside en otro lugar, a dicho término se sumará el término de la distancia, según el medio de comunicación empleado.

– Las partes podrán fijar otros plazos para la aceptación de la oferta, o podrán fijarse tales términos dentro de la propia oferta.

La Convención de Viena sobre Compraventa Internacional de Mercaderías reconoce expresamente la posibilidad de que exista una aceptación tácita, en vir- tud de su artículo 18.3, el cual dispone: “en virtud de la oferta, de prácticas o de usos, el destinatario puede indicar su asentimiento ejecutando un acto relativo, por ejemplo, a la expedición de las mercaderías o al pago del precio, sin comuni- cación al oferente”.

En los Principios del Derecho Europeo de Contratos, elaborados por la Co- misión sobre Derecho Contractual Europeo (Commission on European Contract Law) y publicados bajo el título de “Principios del Derecho Europeo en Materia de Contratos, Partes i, ii y iii”8, si bien no se menciona la aceptación tácita, el artículo 2:205 (2) prescribe: “En el caso de una aceptación derivada de una con- ducta, el contrato se entiende celebrado desde que el oferente tenga noticia de dicha conducta”.

La idea de una “aceptación derivada de una conducta” deja abierta la posibi- lidad de que distintos actos humanos distintos de la expresión escrita o verbal de la voluntad puedan significar aceptación.

El xxxxxxxx Xxxxxx Xxxxxxxxxxxx0 se refiere a la aceptación tácita en los si- guientes términos:

La naturaleza característica de la aceptación da lugar a interesantes reflexiones también sobre la forma de dicho acto. En especial, el art. 1326-4 [codice civile] prevé el caso de que el proponente exija una determinada formalidad para la aceptación, y estatuye

8. Principles of European Contract Law, Parts I and II, eds. Xxx Xxxxx y Xxxx Xxxxx, Kluwer Law International, 2000.

9. xxxxxxxxxxxx. Ob. cit., p. 134.

para esa hipótesis, evitando cualquiera duda, que la aceptación no se considera hecha sino cuando se realiza en la forma prescrita. A falta de una disposición de esa índole, la aceptación podrá producirse en cualquiera forma, inclusive bajo una distinta de aquella en que se hizo la propuesta. Esta consideración reviste un interés notable si se observa que la aceptación, dado que en últimas es un acto de adhesión (y, así, de contenido limitado), puede realizarse efectivamente con una mayor libertad de forma que la pro- puesta (salvo, óigase bien, que se trate de un contrato solemne). En este orden de ideas debemos consagrarle algunas líneas a la figura de la así llamada aceptación tácita, de frecuente ocurrencia en la práctica. Nos referimos a la hipótesis en que el destinatario de la propuesta adopta una conducta que, según los criterios de univocidad y con- cluyente, tenga que estimarse necesariamente compatible con su intención de aceptar la oferta. Entonces, es la opinión obvia, debe considerarse celebrado el contrato por medio de un comportamiento de esa índole, en el entendido de su cognoscibilidad por parte del proponente (distinto es el caso de la llamada aceptación por ejecución […]).

a) Validez de la aceptación tácita de la licencia mediante actos positivos del usuario, como desempacar el software o instalarlo

Como se ha mencionado, la licencia de software es un contrato consensual que se perfecciona por la aceptación de la oferta. En el software “empaquetado” el texto de la licencia es redactado unilateralmente por el productor, y el usuario interesado en adquirir dicho producto no tiene ocasión para discutir los términos y condiciones de la licencia. Es un contrato de adhesión.

Toda vez que en este caso el usuario no está manifestando expresamente su aceptación de los términos de la licencia, surge la cuestión de establecer de qué manera entonces puede surtirse la aceptación y el perfeccionamiento del contrato de licencia como una fuente de derechos y obligaciones entre las partes.

El artículo 854 X.Xx. establece que la aceptación tácita, manifestada por un hecho inequívoco de ejecución del contrato propuesto, producirá los mismos efectos que la expresa, siempre que el proponente tenga conocimiento de tal hecho dentro de los términos de aceptación de la oferta.

Acorde con lo anterior, ¿cuáles serían esos actos inequívocos de ejecución del contrato de licencia de software por parte del usuario?

Al respecto consideramos que para que una conducta del usuario pueda enten- derse como un acto “inequívoco” de aceptación del contrato de licencia ofrecido se necesita que dicho usuario:

1. Tenga previo y pleno conocimiento de la licencia, con todas las condiciones y restricciones de uso en su integridad.

2. Tenga conocimiento de las consecuencias jurídicas de su conducta (desem- pacar el software, instalarlo, usarlo, etc.) en cuanto a la conciencia de que por ese acto quedará vinculado jurídicamente tanto a los derechos como a las obligaciones contenidas en ese documento.

Contrario sensu, si el usuario primero desempaca el software y luego encuentra en la caja un documento (la licencia ofrecida) en cuyo texto se dice que por haber desempacado el producto se entiende haber aceptado los términos y condiciones de uso, salta a la vista que el usuario nunca tuvo oportunidad de conocer la licen- cia y decidir si la aceptaba o no antes de desempacar el producto, motivo por el cual en este caso el acto de sacar de su envoltura el ejemplar del programa no vale jurídicamente como un acto de aceptación.

b) Validez de la aceptación tácita de la licencia mediante el silencio o la inactividad del usuario (no devolver el software al fabricante)

Una primera posibilidad consiste en que el usuario que recibe o adquiere en una caja el producto de software encuentre dentro de ella un documento contentivo de la licencia (hasta ese momento lo que existe no es un contrato propiamente dicho sino apenas una oferta de contrato) y luego de conocerla manifieste su aceptación (y perfeccione entonces sí el contrato), pero no mediante actos o conductas sino, por el contrario, mediante su inactividad o silencio, como sería el caso de entender, por ejemplo, que por el hecho de no devolver al fabricante la caja con el producto que adquirió ha de entenderse que ha aceptado las condiciones de la licencia ofrecida.

Scognamiglio10 se refiere a la posibilidad de considerar al silencio o inactividad como una forma de aceptación tácita en los siguientes términos:

La cuestión se complica […] cuando se trata de decidir sobre el valor del silencio mantenido durante cierto tiempo frente a una propuesta ajena. No sería acertado sostener que entonces el destinatario de la propuesta implícitamente dio muestras de consentirla, dado que debiéndose limitar a responder con un sí o con un no, calló. Una valoración en este sentido de una conducta de suyo equívoca como es el silencio, podría dar lugar a un sacrificio grave e injustificado de la autonomía del destinatario de la propuesta, que podría resultar vinculado sin saber cómo ni cuándo (este princi- xxx merece ser particularmente sostenido frente a la intromisión de quien ofrece sus servicios, tan frecuente en la vida moderna). Tal solución se mantiene firme también en la hipótesis en que el proponente advierte (pero sin que tenga el poder de hacer- lo) que a falta de respuesta considerará celebrado el contrato. A la inversa, se debe adoptar la solución contraria, cuando existe un concreto deber de respuesta, frente al cual el silencio adquiriría el valor de aceptación. El incumplimiento de un deber tal, podría, en efecto, equipararse a la aceptación, solo en el caso excepcional de una valoración específica de la conducta en este sentido, por obra de una norma o según el acuerdo concreto de las partes. Así se explican algunas hipótesis en que el silencio parece adquirir una importancia particular en orden a la formación o a la renovación del contrato, bien porque se trata derechamente, por la citada intervención de la ley, de un modo particular y anómalo de formación del contrato (cfr. p. ej. el art. 1333

10. xxxxxxxxxxxx. Ob. cit., p. 135.

cpv.); bien porque las propias partes convinieron atribuirle al silencio un significado explícito (p. ej. la cláusula de prórroga tácita). Cosa distinta es que de conformidad con las circunstancias específicas, el deber de responder pueda coincidir con el deber genérico que tiene cada contratante de observar las reglas de corrección, etc., caso en el cual, el contratante que no se pronuncia pudiendo o debiendo hacerlo, incurre en responsabilidad por culpa in contrahendo.

Por su parte, la Convención de Viena sobre Compraventa Internacional de Merca- derías, artículo 18.1, prescribe: “Toda declaración u otro acto del destinatario que indique asentimiento a una oferta constituirá aceptación. El silencio o la inacción, por sí solos, no constituirán aceptación”.

En este mismo sentido los Principios del Derecho Europeo de Contratos seña- lan: “Artículo 2:204. Aceptación. (1) Toda declaración o conducta del destinatario de la oferta que indique conformidad con ella constituye una aceptación. (2) El silencio o la inactividad no constituyen aceptación por sí mismos”.

En este orden de ideas y volviendo al artículo 854 X.Xx. en virtud del cual la aceptación tácita supone la existencia de un hecho inequívoco de aceptación del contrato propuesto, creemos que el hecho de que el usuario adquirente de una copia del programa de computador no lo devuelva al vendedor o al productor constituirá o significará un acto de aceptación del contrato de licencia ofrecido cuando:

1. Se trate de una negociación en la que el usuario previamente expresó mediante un acto positivo e inequívoco su interés en recibir la oferta y celebrar el contrato;

2. El usuario tenga previo y pleno conocimiento de la licencia, con todas las condiciones y restricciones de uso en su integridad, y

3. Tenga conocimiento de las consecuencias jurídicas de su conducta (abstenerse de devolver la copia adquirida al vendedor o al productor) en cuanto a la conciencia de que por ese acto quedará vinculado jurídicamente tanto a los derechos como a las obligaciones contenidas en ese documento.

La primera condición mencionada es determinante y fundamental: si, por ejemplo, una persona recibiera un correo electrónico no deseado (spam) en donde se le advierte que si dentro del término de X días no realiza una conducta ha de entenderse que acepta los términos y condiciones de cualquier producto o servicio que le estén ofreciendo, de ninguna manera podría pensarse que esta sea una aceptación tácita o que constituye una forma válida de celebrar un contrato.

2.2.5. Licencias celebradas por medios electrónicos (click wrap licenses)

El “click wrap agreement” es el acuerdo de licencia presentado a los usuarios de un sitio web antes de iniciar la descarga de un programa informático. El acuerdo o contrato es similar a los de los programas informáticos convencionales. Por lo general estos acuerdos obligan al usuario a llevar a cabo algún tipo de acción como hacer clic sobre algún botón regularmente denominado “Aceptar”.

Las click-wrap licenses son las licencias de uso de software que se celebran por medios electrónicos, concretamente utilizando el click wrap, o lo que es lo mismo haciendo clic en un botón o hipervínculo. El click wrap supone un modo de acep- tación o consentimiento a las condiciones del contrato normalmente preestablecidas en la modalidad de un contrato de adhesión.

2.3. problemática jurídica

2.3.1. Violación del usuario a los términos de la licencia

Los contratos bilaterales de naturaleza civil o mercantil llevan implícita una con- dición resolutoria, en virtud de la cual una parte no está obligada a cumplir su parte del contrato si la otra parte a su vez no cumple o no se allana a cumplirlo. En otros términos, la parte que cumple sus obligaciones puede darlo por terminado y cesar el cumplimiento de sus obligaciones derivadas del mismo, si la otra parte incumple con las obligaciones propias de la naturaleza del contrato.

En efecto, el Código Civil establece: “Artículo 1546. “Condición resolutoria tácita. En los contratos bilaterales va envuelta la condición resolutoria en caso de no cumplirse por uno de los contratantes lo pactado…”.

Si, por ejemplo, el licenciatario incurre en una de las conductas que estaban ex- presamente restringidas o prohibidas dentro de la licencia de software, el productor está facultado jurídicamente para cesar la autorización de uso que otorgó a través del contrato así como cualquier otra obligación a su cargo derivada del mismo.

¿Qué acciones puede tomar la parte que sí cumplió el contrato contra la parte que lo incumplió?

– Puede pedir la resolución (terminación) del contrato, junto con la indemni- zación de los perjuicios que se le hayan causado.

– Puede pedir que se obligue al demandado a cumplir el contrato, también, con la correspondiente indemnización de perjuicios.

Lo anterior tiene sustento en el artículo 1546 C.C. que establece al respecto: “… Pero en tal caso podrá el otro contratante pedir a su arbitrio, o la resolución o el cumplimiento del contrato con indemnización de perjuicios”.

Así mismo el Código de Comercio lo establece: “Artículo 870. En los contratos bilaterales, en caso xx xxxx de una de las partes, podrá la otra pedir su resolución o terminación, con indemnización de perjuicios compensatorios, o hacer efectiva la obligación, con indemnización de los perjuicios moratorios”.

En el caso del contrato mercantil de compraventa, en aplicación de la condición resolutoria, el comprador puede exigir el pago de intereses sobre lo pagado al vende- dor, además de perseguir el pago de indemnizaciones; dispone en efecto el artículo 942 X.Xx.: “Resolución de contrato por incumplimiento del vendedor – derechos del comprador. En caso de resolución de una compraventa por incumplimiento del vendedor, el comprador tendrá derecho a que se le pague el interés legal comercial

sobre la parte pagada del precio o a retener los frutos de la cosa en proporción a dicha parte, sin menoscabo de la correspondiente indemnización de perjuicios”.

2.3.2. Validez de la licencia de software celebrada como contrato de adhesión

Existen diversas discusiones jurídicas en torno a los contratos de adhesión en las que se debate, por ejemplo, si tratándose de productos o servicios esenciales (tales como los servicios públicos domiciliarios) cuyos proveedores o prestadores se encuentran en posición dominante xxx xxxxxxx (monopolio) puede considerarse válido y libre el consentimiento de un usuario que no tiene otra opción distinta a aceptar el producto en las condiciones y términos en que el proveedor tenga a bien entregárselo.

Otro tipo de discusiones se ocupan de la validez de las cláusulas que se encuen- tran en letra menuda o ilegible, o redactadas de forma oscura, o que ni siquiera están a disposición del consumidor en el momento de la firma.

Acorde con la Ley 1480 de 2011, las condiciones generales de los contratos de adhesión requieren, para su validez, del cumplimiento de los siguientes requisitos:

– Haber informado suficiente, anticipada y expresamente al adherente sobre la existencia, efectos y alcance de las condiciones generales (en los contratos se utilizará el idioma castellano).

– Las condiciones generales del contrato deben ser concretas, claras y completas.

– En los contratos escritos, los caracteres deberán ser legibles a simple vista y no incluir espacios en blanco. En los contratos de seguros, el asegurador hará entrega anticipada del clausulado al tomador, explicándole el contenido de la cobertura, de las exclusiones y de las garantías.

– Serán ineficaces y se tendrán por no escritas las condiciones generales de los contratos de adhesión que no reúnan los requisitos señalados.

Por otra parte, son cláusulas abusivas aquellas que producen un desequilibrio injustificado en perjuicio del consumidor y las que, en las mismas condiciones, afecten el tiempo, modo o lugar en que el consumidor puede ejercer sus derechos. Para establecer la naturaleza y magnitud del desequilibrio serán relevantes todas las condiciones particulares de la transacción particular que se analiza.

Son ineficaces de pleno derecho las cláusulas que:

– Limiten la responsabilidad del productor o proveedor de las obligaciones legales.

– Impliquen renuncia de los derechos del consumidor que por ley le corres- ponden.

– Inviertan la carga de la prueba en perjuicio del consumidor.

– Trasladen al consumidor o a un tercero que no sea parte del contrato la responsabilidad del productor o proveedor.

– Establezcan que el productor o proveedor no deberá reintegrar lo pagado si no se ejecuta en todo o en parte el objeto contratado.

– Vinculen al consumidor al contrato, aun cuando el productor o proveedor no cumpla sus obligaciones.

– Concedan al productor o proveedor la facultad de determinar unilateralmente si el objeto y la ejecución del contrato se ajustan a lo estipulado en el mismo.

– Impidan al consumidor resolver el contrato en caso de que resulte procedente excepcionar el incumplimiento del productor o proveedor, salvo en el caso del arrendamiento financiero.

– Presuman cualquier manifestación de voluntad del consumidor, cuando de esta se deriven erogaciones u obligaciones a su cargo.

– Incluyan el pago de intereses no autorizados legalmente, sin perjuicio de la eventual responsabilidad penal.

– Impongan al consumidor, para la terminación del contrato, mayores requisitos que los solicitados al momento de la celebración del mismo, o impongan mayores cargas que las legalmente establecidas cuando estas existan.

– Obliguen al consumidor a acudir a la justicia arbitral.

– Restrinjan o eliminen la facultad del usuario del bien para hacer efectivas directamente ante el productor y/o proveedor las garantías a que hace referencia la presente ley, en los contratos de arrendamiento financiero y arrendamiento de bienes muebles.

– Siendo de renovación automática, impidan al consumidor dar por termina- do el contrato en cualquier momento, o impongan sanciones por la terminación anticipada.

La nulidad o ineficacia de una cláusula considerada como abusiva no afectará la totalidad del contrato, en la medida en que este pueda subsistir sin las cláusulas nulas o ineficaces. Cuando el contrato subsista, la autoridad competente aclarará cuáles serán los derechos y obligaciones que se deriven del contrato subsistente.

En Estados Unidos, el caso Affinity Internet, Inc., d/b/a SkyNetWeb vs. Conso- lidated Credit Counseling Services, Inc., Nº 4D05-1193 (Fla. Dist. Ct. App. 4th Dist., March 1, 2006), presenta un interesante ejemplo de la problemática en torno a la celebración del contrato de licencia de software como contrato de adhesión.

Consolidated Credit Counseling Services, Inc. (“Consolidated Credit”) celebró un acuerdo escrito con la empresa Affinity Internet Inc. para el suministro de equipo y servicios de hospedaje (hosting) de Internet. Insatisfecho con el servicio recibido de SkyNetWeb, la empresa Consolidated Credit decidió presentar una demanda. SkyNetWeb contestó la demanda planteando que el Tribunal no era compe- tente, porque existía entre las partes una cláusula que obligaba a que cualquier

controversia se tramitara a través de un arbitraje.

En efecto, SkyNetWeb argumentaba que en el contrato escrito firmado por el demandante este había aceptado someterse a los términos del acuerdo de usuario en línea que aparecen en la página web de SkyNetWeb. Como este segundo documento contiene una cláusula de arbitraje, dicho demandado consideraba que el demandante no debía intentar su reclamación por la vía judicial sino a través del arbitramento.

El Tribunal estimó que el acuerdo de usuario en línea no formaba parte del contrato entre las partes, de manera que el único contrato vinculante para ellas era el recogido en el documento suscrito, el cual no contenía ninguna cláusula que obligara al arbitraje.

En efecto, el Tribunal de primera instancia consideró que el demandante no está obligado por los términos de un acuerdo de usuario en línea, a pesar de que el contrato escrito entre las partes expresamente establezca que queda “sujeto a todos los términos, condiciones y políticas de usuario de SkyNetWeb” ubicados en un sitio web designado.

El Tribunal de segunda instancia confirmó la decisión del inferior. El Tribunal de Apelaciones del Distrito basó su decisión en que consideró que el lenguaje con que las partes escribieron el contrato, en el cual se dijo que el mismo “queda sujeto a” el acuerdo de usuario en línea, no deja suficientemente claro que la intención de las partes fuera incorporar dicho acuerdo como parte integral del contrato, lo que nunca se dijo expresamente. En consecuencia, el Tribunal de Apelaciones consideró que la estipulación en virtud de la cual se obligaba al arbitraje no era vinculante para el usuario, porque la misma solo estaba contenida en los términos del acuerdo de usuario en línea, el cual, estimó el Tribunal, no forma parte integral del contrato celebrado entre las partes.

Además de lo anterior, el Tribunal de Apelaciones tuvo en cuenta que el acuerdo de usuario en línea nunca fue anexado o entregado por SkyNetWeb al usuario, y además, en la página web este no se encontraba exactamente en la dirección url mencionada en el contrato escrito.

2.3.3. Validez de la formación del consentimiento en las licencias celebradas por medios electrónicos

La contratación en el comercio electrónico sufre las vicisitudes de los contratos entre personas ausentes, en donde la formación del consentimiento y la acepta- ción de la oferta se expresan a través de un acto inequívoco (hacer clic en el botón “Aceptar”) pero no obstante surge la posibilidad de que el consumidor no esté siendo informado adecuada y suficientemente sobre los términos y condiciones del contrato, antes de su aparente aceptación.

2.3.4. Responsabilidad por los daños ocasionados al licenciatario por un software defectuoso

Acorde con el Estatuto del Consumidor (Ley 1480 de 2011) en su artículo 20, el productor y el vendedor son solidariamente responsables de los daños causados por los defectos de sus productos. Los perjuicios ocasionados por los productos defectuosos que deben ser indemnizados comprenden tanto la muerte o lesiones corporales, causadas a las personas, como los daños producidos a “una cosa diferente al producto defectuoso, causados por el producto defectuoso”.

No siempre es posible determinar cuándo y hasta qué punto el fallo o mal fun- cionamiento es atribuible a la culpa del usuario. Sin embargo, hay errores muy bien documentados y que son exclusiva responsabilidad del programa en cuestión. Pues bien, sobre esta clase de errores de los programas, identificados y no solucionados en un tiempo prudencial, debería existir posibilidad de demanda cuando a su vez quepa probar que el asunto ha sido causa de daños y perjuicios.

Siempre se puede reclamar por un daño o perjuicio demostrable, pero no sobra- ría dejar sentado por ley cierta concurrencia de circunstancias que se configurarían como de suficiente riesgo como para reclamar responsabilidad con independencia de que exista perjuicio cierto.

La aplicación de este tipo de responsabilidades llevará a las empresas hacia un esquema de venta de servicio, en donde la adecuación del software a las necesida- des y requerimientos del cliente y la solución de problemas es parte del modelo de negocio.

Los desarrolladores de software que actúan de manera independiente pueden verse abrumados por la responsabilidad que se les puede venir encima. Estas em- presas están detrás de un porcentaje muy alto del software en circulación, han sido el germen de empresas de mayor tamaño y se perfilan como el paisaje dominante en la industria del software en los países en desarrollo. No obstante, acudir a la modalidad de entregar el producto con 30 e incluso 60 días de prueba antes de la compra puede ser una forma de que esas pequeñas empresas otorguen garantía suficiente de que el software funciona, no falla y, sobre todo, que no hay intención de “hacer daño”.

¿Son válidas las cláusulas de las licencias de software según las cuales el pro- ductor se exonera de responsabilidad por los daños que el usuario sufra sobre su información, sistemas o equipos?

Las cláusulas de exoneración y limitación de responsabilidad se entienden como aquellos pactos o negocios jurídicos por los cuales las partes de manera previa al incumplimiento o a la ocurrencia de un hecho ilícito pretenden restringir las consecuencias de la responsabilidad.

El artículo 1604 C.C. deja abierta la posibilidad de que las partes mediante acuerdo privado limiten la responsabilidad que puede derivarse por sus hechos culposos:

Artículo 1604. Responsabilidad del deudor. El deudor no es responsable sino de la culpa lata en los contratos que por su naturaleza solo son útiles al acreedor; es responsable de la leve en los contratos que se hacen para beneficio recíproco de las partes; y de la levísima en los contratos en que el deudor es el único que reporta beneficio.

El deudor no es responsable del caso fortuito, a menos que se haya constituido en xxxx (siendo el caso fortuito de aquellos que no hubieran dañado a la cosa debida, si hubiese sido entregado al acreedor), o que el caso fortuito haya sobrevenido por su culpa.

La prueba de la diligencia o cuidado incumbe al que ha debido emplearlo; la prueba del caso fortuito al que lo alega.

Todo lo cual, sin embargo, se entiende sin perjuicio de las disposiciones especiales de las leyes, y de las estipulaciones expresas de las partes. (Resaltado fuera del texto).

Otras normas semejantes están contenidas en el Código de Comercio, así como en la Ley 80 de 1993 (Estatuto de Contratación de la Administración Pública), en el artículo 16 de la Ley 446 de 1998, referido al principio de la reparación integral del daño, y en el artículo 133 de la Ley 142 de 1994, sobre servicios públicos.

Xxxx Xxxxxx considera que este panorama normativo muestra como preocupante la existencia de un régimen fragmentario y disperso que no resulta fácil de interpretar e integrar ante el interés del potencial deudor por tener un régimen de responsabi- lidad aligerado y las nuevas tendencias que marcan la interpretación del moderno derecho de contratos, que observan con detenimiento los principios de la buena fe y el equilibro contractual en los contratos de adhesión con condiciones generales predispuestas celebrados entre profesionales y consumidores a fin de evitar abusos11.

La jurisprudencia y la doctrina han reiterado algunas condiciones de validez de este tipo de cláusulas, tales como las siguientes:

– No son válidas las cláusulas de exoneración o limitación de la responsabilidad del deudor por los hechos que tengan su fuente en el dolo o la culpa grave.

– Tampoco son válidas las cláusulas de exoneración o limitación de responsabili- dad por daños causados a la vida, salud, el cuerpo u otro derecho de la personalidad.

– Igualmente, carecen de eficacia las cláusulas contrarias a normas de orden público, las buenas costumbres, normas imperativas o a los principios de buena fe y lealtad negocial.

– Para que se entienda que hubo aceptación válida de la estipulación exonera- tiva de la responsabilidad esta debió ser previamente informada por el deudor al acreedor y aceptada por este último.

En los contratos de adhesión, se consideran abusivas y por lo tanto ineficaces de pleno derecho las cláusulas que limiten la responsabilidad del productor o proveedor de las obligaciones que por ley le corresponden (art. 43 num. 1 Ley 1480 de 2011). Una cláusula que exonerase de responsabilidad al productor por los daños de- rivados de los defectos del producto estaría en clara contradicción con lo dispuesto

en el artículo 20 del Estatuto del Consumidor (Ley 1480 de 2011).

Otros varios aspectos del Estatuto del Consumidor son relevantes y de interés para la industria informática. Barrera Palacio12 menciona al respecto:

11. xxxx xxxxxx xxxx xxxxxx. “Cláusulas restrictivas de responsabilidad. Observaciones al régimen vigente y propuestas de reforma”, Bogotá, Universidad Xxxxxx Xxxxxxxxx, 2008, disponible en: [xxx.xxxxxxxxxxxxxxx.xxx.xx/xxxxxxxxx/xxxxxxx00/xxxxxxxxx %00xxxxxxxxxxxx.xxx ].

12. xxxxxx santiago xxxxxxx xxxxxxx. “El Estatuto del Consumidor en las empresas de tecnología”, disponible en: [xxx.xxxxxxxx.xxx/xxxxxxxxx/xx-xxxxxxxx-xxx-xxxxxxxxxx-xx-xxx- empresas-de-tecnologia].

En cuanto a la obligación de entregar información completa y veraz al consumidor, en el caso del software, el producto debe contener las instrucciones para el correcto uso e instalación, descripción, recomendaciones y explicar de forma clara el tipo de licencia adquirida. Así mismo, se debe especificar la fecha de caducidad, ya que el estatuto considera una responsabilidad objetiva en el caso que se pueda demostrar el uso indebido del bien por parte del consumidor.

Cuando se realizan compras por medios electrónicos, los proveedores deben especificar la información completa de la empresa con su nombre o razón social, nit y datos de contacto como dirección, teléfono y correo electrónico.

Se debe especificar el costo y los gastos en que debe incurrir el comprador para adqui- rirlo, así mismo, el procedimiento y tiempo de entrega. Previamente a la finalización de cualquier transacción de comercio electrónico, el expendedor deberá presentar un resumen del pedido de todos los bienes que pretende adquirir con su descripción com- pleta, con el que el consumidor pueda verificar que la operación refleje su intención de adquisición de los productos o servicios ofrecidos y las demás condiciones; en la página se pedirá su correo electrónico final, donde se debe enviar, una vez terminada la transacción, el resumen de la misma.

En cuanto a la garantía de los productos juega un papel importante el mantenimiento y soporte ofrecido por la empresa. A instancias de la garantía, el consumidor tiene derecho a realizar reclamaciones y devoluciones en los mismos términos.

Quedan abiertas, en cualquier caso, preguntas como las siguientes:

¿Qué sucede cuando el usuario ve paralizadas sus actividades por mal funciona- miento de su software debido a un virus informático? ¿Deben los desarrolladores asumir responsabilidad por el fallo de su programa? ¿Qué pasaría si lo que falla es una biblioteca que el desarrollador ha usado? ¿Quién es el responsable? ¿Y si es un fallo del sistema operativo?

bibliografía

Dirección Nacional de Derecho de Autor. Circular 01 de 2000, sobre “Orienta- ciones cumplimiento Ley 603 de 2000, vinculada con el derecho de autor”.

Dirección Nacional de Derecho de Autor. Circular 05 de 2000, sobre “Derechos de autor sobre los programas de computador, su licenciamiento y sanciones derivadas de su uso no autorizado”.

Dirección Nacional de Derecho de Autor. Circular 17 de 2000. Modificación Circular 12 del 2 de febrero de 2007, sobre “Recomendaciones, seguimiento y resultados sobre el cumplimiento de las normas en materia de derecho de autor sobre programas de computador (software)”.

xxxxxxx, xxxxxx x. Contratos de edición: Guía de licencias y cesión de derechos, derechos de autor, E-Books y el entorno digital, Montevideo y Buenos Aires, B de F Ediciones, 2010.

xxxxxxxxx xxxxx, xxxxxx. El encargo de obra intelectual, Madrid, Dykinson, 2006.

xxxxx vide, xxxxxx. Estudios completos de propiedad intelectual, vol. 1, Madrid, Reus/aisge, 2003.

xxxxx xxxxxxx, xxxx. El contrato para la elaboración de programas de ordenador, Xxxxxx, Xxxxxxxx, 0000.

xxxx xxxx, xxxx xxxxxxx. Contratos electrónicos y protección de los consumidores, Xxxxxx, Xxxx, 0000.

Document Metadata

Table of Contents

cuestiones jurídicas en torno a los contratos de desarrollo y licencia de software

Document Metadata