Ámbito de aplicación de la Convención de Viena sobre la

Ámbito de aplicación de la Convención de Viena sobre la

Ámbito de aplicación de la Convención de Viena sobre la Compraventa
Internacional de Mercaderías en relación con los contratos de compraventa
internacional de software.
Por: Pablo Andrés Velasco Ordóñez.
I.
Introducción.
Desde siempre, la compraventa de mercaderías, como actividad arquetípica
mercantil, ha supuesto la necesidad del mantenimiento de la seguridad jurídica de
quienes se emplean en dicha labor. De acuerdo con esto, en diferentes ocasiones durante
la evolución de la denominada “Lex Mercatoria”, se diseñaron mecanismos de
resolución de conflictos tendientes a la superación exitosa de la “rebus sic stantibus”,
implícita en toda operación de compraventa de mercancías, sin que ello significara
necesariamente la terminación abrupta de un negocio o el desmedro para alguna de las
partes.1
Como consecuencia de esta búsqueda y ante la necesidad de hacer compatibles
los diferentes sistemas jurídicos bajo cuya égida se solventaron las dificultades que se
presentaban, esto es, los sistemas jurídicos de estirpe anglosajona y los de estirpe
continental, se negoció un nuevo instrumento internacional destinado a uniformar y
concatenar las distintas soluciones jurídicas existentes. En efecto, de este proceso nace
en 1980 la Convención de Viena sobre la Compraventa Internacional de Mercaderías
(CCIM), la cual, desde su concepción y desde su entrada en vigor en 1988, ha
propendido por la unificación del derecho internacional de los contratos de compraventa
internacional de mercaderías, otrora sujetos a ordenamientos internacionalmente
disímiles y a conflictos de interpretación normativa de difícil solución.
Ha sido un largo camino el que se ha recorrido desde entonces pero, no obstante
su vocación universal y autónoma, además del avance que representa de cara a la
1
MARTÍNEZ CAÑELLAS, Anselmo. La interpretación y la integración de la Convención de Viena sobre la
compraventa internacional de mercaderías, de 11 de abril de 1980. Ed. Comares. Granada, 2004. Páginas
1 a 7.
realidad que le antecedía, parece ser que la CCIM deja fuera cuestiones que hoy resultan
de gran importancia para el actual tráfico jurídico y, en especial, para la compraventa de
mercancías, máxime cuando éstas tienen una naturaleza particular (aunque cada vez más
común), como sucede en el caso del Software.
Ciertamente, como se verá, las principales dificultades en torno al software se
vislumbran por razón de la inmaterialidad del software y sobre su naturaleza sui-generis
que dificulta su subsunción en el concepto de “mercaderías”.
II.
Ámbito de aplicación de la Convención.
El art. 3 de la Convención precisa cuál es el campo de aplicación de la
Convención desde una perspectiva material. En efecto, el art. 3(1) de la Convención
señala que se considerará compraventa, los contratos de suministro de mercaderías que
hayan de ser manufacturadas o producidas, a menos que la parte que las encargue asuma
la obligación de proporcionar una parte sustancial de los materiales necesarios para esa
manufactura o producción. Por su parte, el art. 3(2) de la Convención excluye la
aplicación de la convención a los contratos en los que la parte principal2 de las
obligaciones del vendedor de las mercaderías, consista en suministrar mano de obra o
prestar otros servicios.
A este respecto, viene a discutirse entonces si un contrato que verse sobre
software debe ser considerado o no como un contrato susceptible de la aplicación de la
Convención. Justamente, la dificultad de interpretación se observa en tanto no se logra
hacer una identificación unívoca sobre los elementos que conformarían dicho software,
sobre su naturaleza inmaterial y sobre la determinación o incidencia que tiene el término
2
Se ha suscitado un debate en relación sobre cómo debe interpretarse el concepto que encierra la frase
“parte principal”. A este respecto, el Consejo Asesor de la Convención de la Convención de Naciones
Unidas sobre los Contratos de Compraventa Internacional de Mercaderías (CISG-AC), en su opinión No.
4, ha señalado cuáles son los criterios que jurisprudencialmente se han utilizado para entender,
cuantitativamente, cuándo un contrato consiste principalmente en una obligación de suministrar mano
de obra o prestar servicios. Para más información, ver aparte 3.2. y siguientes de la opinión 4, disponible
en http://www.cisgac.com/UserFiles/File/w%20Spanish_Opinion4x%281%29.pdf (última visita el 28 de
noviembre de 2009).
“entrega”3 en estos casos. También es preciso tener en cuenta que reiteradamente se ha
sostenido que la Convención hace referencia, en cuanto a su aplicación, únicamente a
las mercaderías4 que son entendidas como bienes corporales, de acuerdo con los
términos definidos en los Art. 1(1) y 3(1) de la Convención.
II.1.Naturaleza del software y régimen de propiedad intelectual.
El Software es un bien inmaterial, cuya protección cae dentro de la órbita de los
bienes protegidos por el régimen de la Propiedad Intelectual.5 Ciertamente, la Ley de
Propiedad Intelectual, que en España regula las materias vinculadas a la protección bajo
el régimen de derecho de autor, en su Art. 10 señala que son objeto de propiedad
intelectual todas las creaciones originales literarias, artísticas o científicas expresadas
por cualquier medio o soporte, tangible o intangible, actualmente conocido o que se
invente en el futuro, dentro de las cuales están comprendidos, en forma expresa, los
programas de ordenador6.
El hecho de que la ley destaque que las creaciones a proteger se encuentren
“expresadas por cualquier medio o soporte, tangible o intangible”, denota desde un
comienzo que el objeto de protección del derecho de autor no se identifica con el medio
o soporte en el que se expresa la obra sino, por el contrario, crea la idea de que la obra
3
Se ha sostenido que el momento de la determinación de la corporeidad, es el de la entrega, tal y como
lo afirma Martínez Cañellas, citando a Calvo Cravaca, en Op. Cit. Página 313.
4
Tradicionalmente se ha estimado que la Convención hace necesaria referencia a los bienes corpóreos,
para que éstos sean reputados como mercancías. Así se ha interpretado en la Sentencia del
Oberlandesgericht Köln, de 26 agosto 1994, en la que se sostuvo que la CCIM no era aplicable en la
medida en que el contrato no versaba sobre bienes cuya naturaleza cupiese en la definición del art. 1(1)
CCIM, ni se erigía como un contrato para la distribución de bienes que debieran ser manufacturados o
producidos.
5
Entiéndase el concepto de “Propiedad Intelectual” como aquel que abarca indistintamente los
conceptos de Propiedad Intelectual, propiamente dicha (derechos de autor) y Propiedad Industrial
(marcas, patentes, etc.). No obstante, huelga mencionar que, de conformidad con el Art. 4 de la Ley
11/1986, de Patentes, el Software se encuentra expresamente excluido de protección por vía de
patentes.
6
A efectos del presente art., haremos referencia indistintamente a “software” y a “programas de
ordenador”, para hacer alusión al mismo concepto.
es un bien intangible que se abstrae de cómo ha sido puesto a disposición de otras
personas. Ciertamente, para citar un ejemplo, una obra literaria no se confunde con el
libro en el cual se encuentra impresa. De la misma manera, la existencia de una
composición musical no dependerá, en cuanto a su existencia como bien, del acetato,
partitura, casete, CD, etc., en el que se encuentre grabada (si es que en efecto ha sido
grabada7).
Lo mismo sucede con el software, el cual es protegido como una secuencia de
instrucciones o indicaciones a ser utilizadas en un sistema informático (Art. 96.1. Ley
de Propiedad Intelectual), lo cual reitera una vez más la independencia de que goza este
tipo de obra respecto del soporte en el que se encuentre expresado o almacenado, que
bien puede ser físico o electrónico.
De acuerdo con lo anterior, la propiedad sobre una obra protegida por el derecho
de autor se predica de quien cuente con la titularidad de los derechos de propiedad
intelectual respectivos. En tanto se trata de bienes incorpóreos, los tradicionales modos
de adquisición de los bienes se tornan irrelevantes en cuanto al análisis de la adquisición
de los derechos sobre una obra. Ciertamente, existe un modo originario de adquirir la
propiedad (intelectual) sobre una obra y es el que consiste en el acto mismo de la
creación de la obra. De otro lado, existe la transferencia de dicha propiedad (intelectual)
y ésta no puede hacerse mediante la entrega de la obra8 sino, mediante el
perfeccionamiento de un acuerdo expreso, a menudo solemne, en el cual el titular de los
derechos, los transfiere (total o parcialmente) a favor de otro9.
7
Las obras musicales pueden existir con independencia de que hayan sido o no interpretadas por algún
artista, lo mismo que si han sido fijadas o no en un fonograma, reproducidas o comunicadas
públicamente pues, la condición de su existencia no se limita a su forma material de existencia ni al
medio en que dicha existencia se encuentra expresada. Lo mismo sucede con los demás tipos de obra
que, como podrá notarse por razón de la redacción del Art. 10 de la Ley de Propiedad Intelectual, no se
encuentran taxativamente enunciados.
8
En cuyo caso básicamente se estaría haciendo transferencia de la propiedad sobre el objeto material
que sirve de soporte a la obra, más no sobre la obra en sí misma considerada.
9
Debe señalarse que el derecho de autor es uno solo. Sin embargo, dada la existencia de múltiples
formas de explotación de ese derecho de autor, tradicionalmente se habla de “derechos”, en plural, con
el fin de facilitar la comprensión de aquellos acuerdos en los que un titular transfiere o licencia una obra
bajo condición de que dicha transferencia o licencia sólo sea válida en relación con una o múltiples
formas de explotación de la obra debidamente especificadas.
En la otra mano, se evidencia como una obra, en nuestro caso el software, carece
de materiales para ser manufacturado. Justamente, al tratarse de un conjunto de
instrucciones, el software no está llamado a ser manufacturado y por tanto, tampoco a
se encuentra llamado a estar compuesto de materiales en los términos del Art. 3 de la
Convención, para ser producido10.
II.2. El software como producto y como servicio.
El software tradicionalmente ha sido visto como un producto pues,
ordinariamente ha sido desarrollado y obtenido como tal. Esta forma de entendimiento
del software implica que deba ser tratado como el objeto sobre el cual directamente
confluirían diversas operaciones del tráfico jurídico: compro software, vendo software,
desarrollo software, en el mismo sentido en que compro un coche, vendo un coche y
construyo un coche.11
De otra parte, el software también puede ser visto como un servicio. En este
caso, el software es entendido como aquella infraestructura respecto de la que se da
acceso a un tercero para que por su través se pueda obtener un resultado específico. En
este caso, la puesta del software a disposición de un tercero no representa ninguna
transacción respecto de la propiedad de dicho software sino, meramente la prestación de
un servicio en donde la funcionalidad del software es el servicio mismo a prestar.
En Estados Unidos, la Asociación de los Industriales del Software y la
Información, ha definido el concepto de software como servicio de la siguiente forma:
“En el modelo del software como servicio, la aplicación, o servicio, es puesta en
funcionamiento desde un centro de datos centralizado a través de una red – Internet,
Intranet, LAN, o VPN – proporcionando así acceso y posibilidad de uso sobre la base
10
La característica de incorpóreo del Software no obsta para que sea considerado un producto. Sin
embargo, la forma de utilización del software puede implicar que a través de este se preste un servicio,
en lo que comúnmente se ha denominado como “Software como Servicio” o “SaaS”, por sus siglas en
inglés.
11
Para más información, sugiero consultar GUNTHER, Richard C. Management methodology for
software product engineering. Wiley Interscience. Nueva York, 1978. 2da Ed. Pág. 13. En esta obra, el
autor hace una descripción del concepto de software como producto desde la perspectiva de la
administración de su desarrollo.
de una tarifa periódica. Los usuarios „rentan‟, „se suscriben a‟, “les es asignado‟ o „les
es permitido acceso‟ a los programas desde un proveedor central. Los modelos de
negocio varían de acuerdo al nivel con el que el software haya sido ajustado para
disminuir el precio y aumentar la eficiencia o, bien, con base en el mayor valor que se
la haya añadido a través de su personalización para el mejoramiento de los procesos
de negocio digitales”12.
De acuerdo con lo anterior, es importante tener en cuenta que existen múltiples
escenarios de negocio en el ámbito internacional que comprenden la adquisición de
software, sin que dicha adquisición implique necesariamente que el software objeto de
dicha transacción resulte siendo transferido a quien lo adquiere. Por el contrario, existen
múltiples formas de vender y adquirir software, cobijadas por la visión del “Software
como Servicio” (“SaaS”, por sus siglas en inglés) que al resultar en muchos casos más
eficientes (por ejemplo, en términos de costos totales de operación, facilidad de puesta
en marcha y manutención), terminan siendo preferidas aún bajo idénticos supuestos de
adquisición a los que se encontraría sujeta una tradicional “compraventa” internacional.
Valga destacar, pues, que la puesta en funcionamiento del software, al igual que
su distribución, es hecha a través de redes telemáticas, luego el problema a resolver
estaría dado en cuanto a la semántica del término “mercadería”, pues casi que resulta
evidente que en este caso la adquisición versa sobre un servicio y no sobre el software
propiamente dicho, ergo no habrá realmente ninguna mercadería, lo mismo que no
existirá compraventa. Es más, aun cuando profundizar en este punto excede los límites
propuestos de este art., consideramos que ni siquiera existe una licencia por cuanto en
strictu sensu no se está disponiendo de ningún derecho de propiedad intelectual por
parte de su titular. En efecto, a lo sumo el titular estaría explotando su derecho a
comunicar públicamente el software en tanto obra, claro está, sólo en aquellos casos en
los que el acceso a ésta haya sido puesto a disposición del público en los términos
previstos en el art. 3.1 de la Directiva Europea 2001/29, pero ello no implica que haya
una disposición de derechos a favor de quién adquiere el servicio (representado en el
acceso a la funcionalidad del software ejecutado remotamente a través de una red
telemática), lo cual, a mi juicio, necesariamente significa que se excluye de plano la
posibilidad de considerar que al menos existe una licencia entre las partes contratantes.
12
Tomado del original en inglés en Software as a Service: Strategic Brackgrounder. Software &
Information Industry Association - SIIA. Washington. 2001. Página 4.
A este respecto y ante la atipicidad de este tipo de negocio jurídico, la doctrina y
la industria han considerado que este modelo de puesta a disposición del software, crea
una nueva especie contractual denominada contrato de servicios de provisión de
aplicaciones (ASP, por sus siglas en inglés)13. No obstante lo anterior, se ha especulado
sobre la posibilidad de asimilar el contrato ASP al contrato de arrendamiento de
software, pero al final ello tampoco es posible puesto que el contrato de arrendamiento
de software, de acuerdo con lo previsto en el Art. 99 LPI, exige el reparto de soportes
tangibles (contrario sensu de lo que ocurre en el contrato ASP)14.
Todo lo antedicho, al igual que las demás características reunidas bajo la
sombrilla del concepto “ASP”, hacen que el software como servicio sea tenido como el
objeto de un contrato sui generis que, en lo que a mi opinión respecta, no puede caber
dentro del espectro regulatorio de la Convención pues éste no se hace, como se ha
anotado, a título de compraventa, como tampoco versa en torno a mercaderías15. En este
mismo sentido, puede citarse la celebérrima sentencia de la Corte Provincial de
Apelaciones de Colonia (Alemania), de fecha 26 de Agosto de 199416, en la cual la
corte estimó que la Convención no era aplicable en la medida en que el contrato
estudiado no podía reputarse como de compraventa, lo mismo que no versaba sobre un
objeto que pudiera subsumirse en el concepto de “mercaderías” de conformidad con lo
exigido por el Art. 1(1) de la Convención.
III.
La compraventa de software.
Haciendo de lado la adquisición de SaaS por las razones que ya han sido
expuestas, huelga la oportunidad para explorar los diferentes tipos de negocio jurídico
que caben dentro del concepto de “Compraventa de Software”.
13
LÓPEZ TARRUELLA-MARTINEZ, Aurelio. CONTRATOS INTERNACIONALES DE SOFTWARE EN DERECHO
INTERNACIONAL PRIVADO COMUNITARIO. Universidad de Alicante. 2004. Pág. 87.
14
Ibídem. Pág. 88.
15
Ver notas Nos. 3 y 4.
16
OLG Köln, 26 de Agosto de 1994, 19 U 282/93.
Justamente, es importante deslindar el concepto de “compraventa” de otro tipo
de conceptos que, dentro del mundillo del software, son confundidos y utilizados
indiscriminadamente para hacer referencia a todos aquellos actos por cuya virtud se
adquiere software.
Así, pues, resulta relevante hablar de la compraventa propiamente dicha y,
dentro de ésta, del desarrollo de software por encargo; de las licencias de software,
dentro de las que están los End User License Agreements (EULA‟s) y; finalmente, de la
adecuación que de estos tipos de negocio jurídico pueda hacerse dentro del marco del
Art. 3 de la Convención.
III.1. Compraventa.
La expresión “compraventa de software”, para hacer referencia a la adquisición
propiamente dicha de un programa de ordenador, esto es, de la adquisición de la
propiedad de los derechos de autor sobre una pieza de software, se encuentra mal
utilizada pues, en realidad este concepto hace referencia a lo que comúnmente se
denomina “contrato de cesión de derechos patrimoniales” (en los países de tradición
civil) o “assignment of copyright” (en los países de tradición anglosajona).17
Ciertamente, para hacer claridad respecto de aquel tipo de negocio jurídico que
eventualmente cabría dentro de la definición de „compraventa‟ especificada en el Art. 1
de la Convención, cuando se habla de “comprar” software en el sentido más estricto del
término, se debe estar haciendo referencia a la idea de adquirir la titularidad de los
derechos que se derivan del objeto del contrato correspondiente, esto es, adquirir la
titularidad del derecho de autor sobre el software específico que se desea adquirir. Valga
anotar que se ha utilizado la palabra “derechos”, en plural, pues si bien el derecho de
autor es uno solo, como ya se notó previamente, éste se desmiembra en diferentes
formas (no taxativas) de explotación de la obra que son tenidas, cada una, como
derechos individuales que pueden ser cedidos de manera conjunta o separada.
17
Esto, inclusive, sin hacer disquisiciones en relación con el mantenimiento, en los países de tradición
civilista, de los inalienables e imprescriptibles derechos morales del autor.
Así las cosas, cuando se haga referencia al concepto de “compraventa de
software”, deberá precisarse si con ello también quiere hacerse referencia a la idea de
adquirir la titularidad sobre dicho software o si por el contrario sólo se desea tener
autorización para usar o explotar dicho software de una u otra manera que no implique
la transferencia de la titularidad de uno o más derechos sobre aquél, en cuyo caso
estaríamos frente a una licencia.
Nótese que con la cesión, sea ésta total o parcial, se está teniendo acceso al
control sobre una o varias formas de explotación del software en tanto obra protegible
por el derecho de autor. Sin embargo, ello no necesariamente conlleva la utilización de
soportes físicos para la obra, como por ejemplo de discos ópticos, para que se pueda
entender que se ha perfeccionado la mencionada transferencia de derechos, ya que el
objeto de la cesión no es material sino, inmaterial. Esto, por supuesto, nos pone
nuevamente en la problemática de encuadrar el concepto de „software‟ dentro del
concepto de „mercaderías‟, tal y como tradicionalmente ha sido entendido en relación
con la aplicación de los arts. 1 y 3 de la Convención.
III.2. Software por encargo:
Uno de los supuestos que eventualmente podría encuadrarse en las previsiones
del Art. 3(1) de la Convención, haciendo caso omiso de la inmaterialidad del software
en tanto propiedad intelectual, es el de la fabricación o desarrollo de software por
encargo o fabricación de software a medida.
Se trata de aquel contrato en el que una empresa informática se obliga, a cambio
de una remuneración dineraria, a elaborar un programa de ordenador, de acuerdo a las
indicaciones de la empresa cliente, para que cumpla unas funciones específicas18. En
estos casos, también se ha sostenido que los contratos de fabricación o de desarrollo de
software a medida deben equipararse a las denominadas “licencias de software de valor
18
LÓPEZ TARRUELLA-MARTINEZ, Aurelio. Op. Cit. Pág. 72
añadido”, por cuya virtud una empresa fabricante modifica un software estándar para
adaptarlo o ajustarlo según las necesidades del cliente19.
Sobre el respecto es importante señalar que, sin importar si el escenario es el de
desarrollo de software desde cero o es el de la modificación y ajuste puntual de un
software preexistente de acuerdo con las necesidades del cliente, puede escogerse entre
la posibilidad de ceder la titularidad sobre dicho software (el cual sería el escenario por
omisión en el caso en que una obra se desarrolle desde cero de acuerdo con las
especificaciones del cliente); o bien, la posibilidad de que el fabricante del software se
reserve íntegramente la propiedad intelectual sobre el software para sí y, en su lugar,
otorgue una licencia al comprador (caso éste que representa el escenario por omisión
cuando el software es modificado a pedido de un cliente en particular).
No obstante lo anterior, se ha discutido si este tipo de contrato puede tener la
misma naturaleza de un contrato de obra o la naturaleza de un contrato de servicio. Sea
cual sea la respuesta, ésta encierra la dificultad de que el objeto sobre el que versa la
transacción, no es un objeto tangible, esto es, un objeto que pueda comprenderse dentro
del concepto de “mercadería” como tradicionalmente se ha entendido en torno a la
aplicación de la Convención20.
Dependiendo de la legislación que resulte aplicable en materia de asignación de
la titularidad, en muchos casos la titularidad originaria corresponderá al encargante de la
fabricación del software, cuando en otros corresponderá a quien lo fabricó. De cualquier
manera, es importante tener en cuenta que ficciones jurídicas como la de la asignación
originaria de la titularidad al encargante, por completo desvirtúan la posibilidad de que
se hable de una compraventa y casi fuerzan a considerar que existe un contrato de obra
o, algunas veces, un contrato de servicios, todo en función de las particularidades de
cada caso pues, si la titularidad de los derechos nace originalmente en cabeza de quien
ostentaría la posición de comprador, en strictu sensu no existiría una transferencia de
19
20
Ibídem.
MANZ y PADMANN-REICH han sostenido que por virtud del art. 3 de la Convención, ésta no será
aplicable en donde la obligación principal de la parte que suministra los bienes, consiste en la ejecución
de un servicio u obra; así mismo sostienen, de manera general, que la Convención no es aplicable a los
bienes inmateriales o intangibles. MANZ, Gerhard y PADMANN-REICH, Susan. Introduction of the U.N.
Convention on International Sale of Goods in Germany. International Business Lawyer. Vol. 300. 1991.
Pág. 302.
derechos sino, el nacimiento de derechos en cabeza de una persona, natural o jurídica,
por razón de la creación de un software (obra protegible por el derecho de autor), lo cual
muestra un escenario donde el fabricante del software nunca tendría más derecho que el
de percibir el pago del precio convenido.21
III.3. Licencias de software.
En el caso de las licencias de software es importante mencionar que no existe
transferencia de la titularidad de derechos a favor de otro, luego no existe transferencia
de la propiedad sobre el software y, como consecuencia, no existe compraventa. En
suma, lo que existe es una autorización para que un tercero pueda explotar, de una u otra
manera, un programa de ordenador a su conveniencia, pero dentro de ciertos parámetros
específicos.
Contrario a esta opinión, LÓPEZ-TARRUELLA MARTÍNEZ considera que
existen ciertos contratos de licencia de explotación de software que constituyen
genuinos contratos de transmisión de derechos de propiedad intelectual22, pues entiende
que dentro de este tipo de licencias opera la cesión, limitada temporalmente en el
tiempo, de uno o varios derechos del titular, ergo implicando que exista un escenario
similar al de la cesión de derechos.
Nos apartamos de esta posición por cuanto creemos que el significado de la
palabra “licencia” necesariamente implica que sea comprendida como “autorización de
uso”23 pues, de quererse transmitir algún derecho a un tercero, debería más bien
suscribirse un contrato de cesión, aún estando éste limitado temporalmente. En este
mismo sentido, consideramos que un contrato de cesión no puede equipararse a una
“autorización” vistos sus efectos y su naturaleza.
21
OLIVA BLÁSQUEZ ha señalado que el vendedor-productor se limitará en tal caso a ejecutar un atarea
de manufactura de un programa, siguiendo para ello las indicaciones suministradas por el compradorcomitente. OLIVA BLÁSQUEZ, Francisco. Compraventa Internacional de Mercaderías (Ámbito de
aplicación del Convenio de Viena de 1980). Editorial Tirant lo Blanch. Valencia, 2002. Pág. 488.
22
23
LÓPEZ TARRUELLA-MARTINEZ, Aurelio. Op. Cit. Pág. 51
De acuerdo con la vigésimo segunda edición del Diccionario de la Lengua de la Real Academia
Española, el significado de la palabra “licencia” significa: “Permiso para hacer algo”.
Así, pues, estimamos que la utilización de las licencias y la adquisición de éstas,
no comporta una compraventa sino, como se ha indicado, la mera entrega de un permiso
o autorización para utilizar un software específico bajo ciertos parámetros
preestablecidos. Desde este punto de vista, estaríamos en ausencia de uno de los
elementos indispensables, exigidos por la Convención, para entender que nos
encontramos dentro del espectro de su ámbito de aplicación, esto es, el que exista un
contrato de compraventa.
Otra sería la discusión si lo que se compra y vende son licencias (autorizaciones)
en sí mismas consideradas. Sin embargo, dicho supuesto también comporta dificultades
pues no existe ninguna mercadería que realmente esté siendo comprada y vendida; sólo
se está adquiriendo una autorización para usar un software que, por demás, puede ser
entregado separadamente y mediante la utilización de soportes inmateriales24.
De otra parte, están los EULA o End User License Agreement (Contrato de
licencia del usuario final). Este tipo de licencias, como las demás licencias, sólo
comportan una autorización para la utilización de la obra, bajo ciertas condiciones
preestablecidas. No obstante, bajo ciertas legislaciones, desde la perspectiva del
Derecho del Consumidor, los EULA son tenidos como verdaderos contratos de
compraventa de mercancías pues, los mismos están sujetos al cumplimiento de ciertos
estándares mínimos y a encontrarse de conformidad con las características ofrecidas a
los consumidores, esto es, el software en estos casos es tratado como una verdadera
mercadería. En todo caso, no obstante la equiparación ficticia mencionada, estimamos
que los EULA también se encontrarían por fuera del ámbito de aplicación de la
Convención en virtud del art. 2, el cual expresamente excluye todas aquellas
operaciones de consumo personal, familiar o doméstico que, a la postre, son el típico
destino de los acuerdos de licencia del usuario final o EULA. Además, este tipo de
ficciones corresponden a ordenamientos jurídicos nacionales que, por su naturaleza
local, no informan la interpretación de las normas de la Convención, lo cual dispersa
aún más la posibilidad de que estos criterios se usen a nivel internacional de manera
homogénea.
24
Como sucede con la adquisición de descargas pre-pagadas, mecanismo muy popular hoy en día en el
mercado del software y de los contenidos (música, video, texto) en Internet.
IV.
Adecuaciones jurisprudenciales y doctrinarias; aplicación en concreto de
la Convención al software.
Vistas las particularidades de la naturaleza del software y de los típicos negocios
jurídicos de los que es objeto, cabe preguntarse si finalmente, al menos en teoría, resulta
o no aplicable la Convención y, aún no siéndolo, si en algún momento los tribunales han
considerado aplicarla en algún caso concreto.
Pues bien, nos hemos topado con casos en los que los tribunales han equiparado
al software con las mercaderías y, por consiguiente, en casos puntuales, han llegado a
estimar pretensiones bajo el amparo de la Convención de Viena de 1980.
Ciertamente, si bien ha habido jurisprudencia que defiende que la Convención
no es aplicable al software25, en ciertas oportunidades ésta misma jurisprudencia ha sido
contradictoria y ha otorgado al software todos los efectos de una mercadería para hacer
aplicable la Convención a los contratos internacionales de compraventa que lo tienen
por objeto. Tal es el caso de la sentencia de la Corte del Distrito de Múnich del 8 de
febrero de 1995, en la que la corte estimó que la venta final de software estándar a
cambio de un único precio, debería ser visto como una compraventa de mercaderías en
conformidad con el art. 1(1)26.
Mucho se ha especulado sobre la calidad de estándar o no estándar del software,
en forma tal que con base en ello se pueda determinar que existe equiparación a una
mercadería. Aparentemente la divergencia se debe a que el denominado “software
estándar”, se encuentra confeccionado para un público indeterminado, adquiriendo
connotaciones de un producto en abstracto, mientras que el “software no estándar”,
responde a unos parámetros que a su vez satisfacen las necesidades particulares de un
encargante, semejándose más a lo que podría denominarse como “contrato de obra” o
“contrato de servicios”.
25
Ver nota No. 16.
26
Landgericht München, 08 de febrero de 1995, 8 HKO 24667/93.
Sobre el respecto, la doctrina ha señalado que la naturaleza del software estándar
lo hace apto y equiparable a una mercadería en la medida en que se encuentre fijado a
un soporte físico27, pues de ese modo el software se convierte en una cosa material.
Para el efecto, se ha optado por hacer una disgregación entre lo que se considera
el elemento inmaterial o corpus mysticum y el elemento material o corpus mechanicum.
Por virtud del elemento material, el elemento inmaterial, que es el software en sí mismo
considerado, adquiere entidad física suficiente como para ser considerado una
mercadería, luego podrían hacerse aplicables las disposiciones pertinentes de la
Convención en cuanto a ámbito de aplicación, conformidad de mercancías, remedios,
etc.28 El problema que deja sin resolver esta teoría es que no resiste un análisis profundo
sobre cuál es el elemento que predomina en la transacción y que debería ser reputado
como el objeto del contrato. En nuestra opinión, el elemento principal que debe ser
reputado como el objeto del contrato es el corpus mysticum, esto es, el software pues,
como ya se ha visto, el mismo existe con independencia de su soporte, incluso si éste
último es así mismo inmaterial (p. ej., un soporte digital). Esto, por supuesto, significa
que no existirá una respuesta unívoca en torno a dos contratos que versen sobre un
mismo software, pues si en un contrato la venta se efectúa mediante un soporte físico,
pero en otro contrato el software es “vendido” en soporte digital, las normas aplicables
serían diferentes y, por tanto, distintas las soluciones a proveer en cada caso, implicando
que uno de los objetivos principales de la Convención, que es el de uniformar la
normatividad aplicable en materia de contratos de compraventa de mercaderías, no se
cumpla.
IV. 1. El software como componente de otras mercaderías.
Otro asunto que ha llamado la atención, es el software que hace parte (no
principal) de otras mercaderías, como el hardware. En estos casos, resulta plausible que
lo accesorio siga la suerte de lo principal y si bien sobre el software individualmente
considerado no está operando una cesión, como tampoco lo hace en relación con ningún
27
OLIVA BLÁSQUEZ, Francisco. Op. Cit. Página 467.
28
Ibídem.
otro tipo de propiedad intelectual que pese sobre las mercaderías29, es el conjunto de los
bienes tangibles vendidos lo que impregna al contrato de su naturaleza de compraventa
de mercaderías.
Sobre el respecto, la jurisprudencia alemana30 ha señalado que el conjunto
formado por el software y el hardware producen una sola unidad. En efecto, en un
contrato consistente en la venta de un sistema computarizado de impresión, se añadió
una garantía en la que se especificaba: “La garantía cubre el software y el hardware
como una unidad. El periodo de garantía es de 6 meses y empieza con el
funcionamiento no defectuoso del sistema. La iniciación del periodo es calculada desde
la instalación y la puesta en funcionamiento. (…)”. Esta cláusula fue tenida por la Corte
como parte integrante del contrato de compraventa y a partir de ella consideró que el
software hacía parte de una venta “como paquete”, además de que la venta versaba
sobre un sistema de impresión computarizado y no sólo respecto de una impresora.
En cuanto a este tipo de interpretación, valga decir que consideramos que la
solución es acertada, pero también es importante señalar que el software, desde la
perspectiva de la propiedad intelectual como tal, no ha sido cedido y que la ficción a la
que recurre la Corte sólo es útil a efectos de considerar la aplicación de la Convención
según corresponda. Ciertamente, se ha criticado la posibilidad de que se dé aplicación a
ordenamientos jurídicos distintos: uno para el software y otro para el hardware. La
problemática reside, pues, en que ello desnaturalizaría la unidad contractual y se
prestaría para dificultades interpretativas de las normas pertinentes.
V.
Conclusiones.
De acuerdo con todo lo expuesto, es posible concluir que la naturaleza del
software no resulta, por definición, compatible con la Convención, particularmente por
su condición de inmaterial, por cuanto su desarrollo puede asimilarse más a un servicio
que a una compraventa y porque su forma principal de comercialización es la licencia.
29
Ver arts. 41 y 42 de la Convención.
30
Corte Federal de Justicia , 4 de Diciembre de 1996, VIII ZR 306/95
No obstante lo anterior, hemos visto como la jurisprudencia y la doctrina han
intentado hacer una interpretación extensiva de los conceptos que rigen el ámbito de
aplicación de la Convención, especialmente el de “mercaderías”, de modo que ese
cuerpo normativo resulte aplicable a las transacciones asimilables a las compraventas y
cuyo objeto sea o se relacione con una pieza de software. En todo caso, estas
interpretaciones no se encuentran exentas de ofrecer dificultades, especialmente en lo
que a la uniformidad de la aplicación de las normas se refiere, pues en ciertos casos las
soluciones podrían ser divergentes aún cuando el objeto de los contratos bajo análisis
sea el mismo.
Finalmente, es importante concluir que la ausencia de un cuerpo normativo que
incluya unívocamente al software como una categoría de mercaderías en forma expresa,
genera un nivel de incertidumbre que pugna con las finalidades y objetivos que persigue
la Convención. Como consecuencia, otro tipo de cuerpos normativos han sido sugeridos
para resolver la cuestión, como la propuesta estadounidense de la “Uniform Computer
Information Transactions Act”, pero que no obstante adolecen de no poseer un carácter
de instrumento internacional como el que ostenta la Convención, lo cual es
determinante para lograr los objetivos que han sido trazados con ella en mente.
VI.
Bibliografía.
GUNTHER, Richard C. Management methodology for software product engineering.
Wiley Interscience. Nueva York, 1978. 2da Ed.
LÓPEZ TARRUELLA-MARTINEZ, Aurelio. CONTRATOS INTERNACIONALES
DE SOFTWARE EN DERECHO INTERNACIONAL PRIVADO COMUNITARIO.
Universidad de Alicante. Alicante, 2004.
MANZ, Gerhard y PADMANN-REICH, Susan. Introduction of the U.N. Convention
on International Sale of Goods in Germany. En “International Business Lawyer”. Vol.
300. 1991. Pág. 302.
MARTÍNEZ CAÑELLAS, Anselmo. La interpretación y la integración de la
Convención de Viena sobre la compraventa internacional de mercaderías, de 11 de
abril de 1980. Ed. Comares. Granada, 2004.
OLIVA BLÁSQUEZ, Francisco. Compraventa Internacional de Mercaderías (Ámbito
de aplicación del Convenio de Viena de 1980). Editorial Tirant lo Blanch. Valencia,
2002.
SIIA. Software as a Service: Strategic Brackgrounder. Software & Information
Industry Association - SIIA. Washington. 2001.