Java, Microsoft, Mercados digitales, Plataformas de Software, Sherman Act, Sección dos, Section 2, Monopolization, Monopoly Maintenance.

¿Fue el “Java Contaminado” de Microsoft una mejora en el diseño del producto presumiblemente legal? (J. Gray)

27.09.2023

CeCo Chile

15 minutos

*Esta nota corresponde a una traducción al español de esta publicación original de Promarket.org, de fecha 9 de junio de 2023. Esto se realiza en el marco de un convenio de re-publicación suscrito entre CeCo y ProMarket (Stigler Center, University of Chicago Booth School of Business).

En 1998, el Departamento de Justicia y 20 Estados demandaron a Microsoft por blindar ilegalmente a su monopolio, el Sistema Operativo Windows (OS), frente a la nueva competencia de la innovadora tecnología de middleware de sus rivales. El caso se centró en un tipo específico de middleware en particular: un lenguaje de programación multiplataforma Java desarrollado inicialmente por Sun Microsystems. En aquel tiempo, Herbert Hovenkamp explicó la teoría del daño en el corazón del caso de Microsoft de la siguiente manera: el Java de Sun era “el ‘interruptor’ que conectaría múltiples sistemas operativos, destruyendo así la significativa ventaja de red que Microsoft tenía sobre los sistemas rivales y permitiendo que las personas basen sus decisiones de compra en factores como el precio o la calidad”. Microsoft reaccionó a Java con un curso de acción “para evitar que este interruptor se despliegue, y así preservar la incapacidad de los diferentes sistemas para interconectarse”.

La Corte del Distrito falló a favor del gobierno el 3 de abril del año 2000, considerando que Microsoft era responsable por el rediseño, licenciamiento y distribución de Java. Sin embargo, en junio de 2001, la Corte de Apelaciones del Circuito del Distrito de Columbia de EE.UU. (o “Corte del Circuito de D.C.”) en una serie de resoluciones elusivas e impactantes, se negó a afirmar la responsabilidad de Microsoft por la “creación y promoción” de su versión personalizada —o, tomando prestada una palabra de una comunicación interna, “contaminada”— de Java. Sin embargo, la Corte del Circuito de D.C. igualmente condenó ampliamente las acciones de Microsoft respecto de Java. Estas consideraciones jugaron un papel central en el caso de Microsoft y siguen siendo centrales para la construcción moderna de la Sección Dos de la Ley Sherman hoy, a varias décadas del inicio de la era digital. La cuestión aún no resuelta sobre qué hacer con estas sentencias adquiere una nueva urgencia a la luz de la moción pendiente para fallar de forma sumaria el caso sobre mantenimiento del monopolio de búsqueda de Google de la División Antitrust del Departamento de Justicia.

La Corte del Circuito de D.C. señaló que existía un aumento no especificado en la velocidad del OS y concluyó que la versión de Java de Microsoft “sí permite que las aplicaciones se ejecuten más fluidamente y no tiene en sí misma ningún efecto anticompetitivo”. Así, las personas demandadas por infringir la Sección Dos en casos posteriores, interpretaron este pronunciamiento específico sobre Java, para establecer una regla categórica de exención de responsabilidad por el desarrollo de cualquier cosa que pueda describirse objetivamente como una mejora tecnológica. Según esta interpretación, cualquier mejora ordinal en velocidad —o cualquier otra cosa medible— detiene el análisis. En consecuencia, no habría espacio para considerar alternativas al diseño del producto y la prueba de intencionalidad anticompetitiva no sería relevante. Lo anterior, a su vez, en opinión de quienes defienden esta postura, permitiría establecer que las mejoras del producto son conductas privilegiadas no sujetas a los principios ordinarios del análisis de la Sección Dos.

Por ejemplo, en el resumen del informe de moción de juicio sumario de Google en el caso de mantenimiento del monopolio de búsqueda, se afirma esta visión sobre las decisiones relacionadas con Java, argumentando que “[n]o tenía importancia que la [versión de Java] de Microsoft hubiera mejorado aún más si hubiera permitido la creación de aplicaciones tanto con el [Java] de Microsoft como con el de Sun, o que Microsoft podría haber logrado ese resultado con poco o ningún costo. En lugar de eso, la pregunta era simple: ¿era la [versión de Java] de Microsoft una mejora genuina del producto?”.

Sin embargo, es incorrecto afirmar que el análisis de la Corte del Circuito de D.C. habría ignorado las decisiones de diseño plausiblemente anticompetitivas debido al aumento de la velocidad. Una mejor interpretación de las decisiones sobre Java es que la Corte del Circuito de D.C. concluyó solamente que los cambios de Microsoft en Java no eran una farsa. Visto objetivamente, los cambios de diseño de Microsoft también tenían la capacidad de ser utilizados para causar daños anticompetitivos, por lo que se necesitaba un análisis más detallado. Se sigue necesariamente que las mejoras plausibles del producto no son presuntamente legales, y mucho menos están exentas de un análisis “normal” desde la Sección Dos.

La Corte del Circuito de D.C. dirigió su atención al contexto del mercado en el rediseño de Java por parte de Microsoft y la distribución de su nuevo producto. Discutió sobre las evidencias de que Microsoft coaccionó a sus socios comerciales para forzarlos a adoptar su nuevo producto. Debido a que Microsoft participó en actos que impidieron que el mercado llegara a una determinación sobre los méritos técnicos y comerciales de un nuevo producto con la capacidad de mantener o extender el poder monopólico, se le podía considerar debidamente como responsable por el mantenimiento del monopolio.

Su análisis sobre el rediseño y distribución de Java por parte de Microsoft se entiende mejor como un método de equilibrio, entre daños y beneficios, que se basa en pruebas de mercado. La Corte del Circuito de D.C. podría haber escrito que “no tenemos que decidir si el Java contaminado fue una mejora porque Microsoft no permitió que el mercado emitiera ese juicio sobre los méritos”. No lo hizo. Aunque, desde la perspectiva del precedente vinculante, importa menos lo que esta corte escribió, porque eso es lo que realmente hizo, convirtiéndolo en la ratio decidendi del caso.

Según lo descrito por la Corte del distrito, el expediente ofrece poca o ninguna evidencia de que el rediseño de Java por parte de Microsoft haya tenido probabilidades de ganar la carrera competitiva en base a sus méritos, especialmente a largo plazo. Según los hallazgos de hecho del tribunal inferior, durante el crucial período de 1995-1997, Java era un audaz experimento con un futuro incierto. Para madurar, Java necesitaba bibliotecas más extensas (i.e. recursos utilizados para la programación, como código pre-escrito o plantillas de mensajes) que pudieran replicar las funciones de un sistema operativo completo sin realizar llamadas a API nativas (i.e. interfaces de software que permiten que los programas de computadora se comuniquen) y, posiblemente, mayor velocidad. La construcción de las bibliotecas fue una tarea monumental realizada por tres protagonistas: Sun, Intel y Microsoft. Puede ser que el innovador inicial, Sun, haya tenido recursos insuficientes para terminar el proyecto solo. Intel era el único socio con la capacidad de ayudar a Sun a realizar sus aspiraciones multiplataforma para Java, y tenía la capacidad de escribir código para completar las bibliotecas de Java. Además, de manera única, Intel podía adaptar sus CPU para que Java igualara la velocidad y eficiencia de las llamadas nativas de Windows. Finalmente, Microsoft controlaba el entorno nativo para Windows y tenía una capacidad incomparable para codificar.

Cuando Netscape adquirió una licencia de Java en mayo de 1995 para su popular navegador de internet Navigator, se convirtió en el vehículo más probable para distribuir Java ampliamente a la mayoría de los usuarios de Windows. Antes de abril de 1996, Intel había desarrollado una versión de alto rendimiento de Java diseñada para funcionar bien en sistemas Intel y que cumplía con los estándares multiplataforma de Sun. Microsoft reaccionó con un curso de acción que impidió que los agentes del mercado tomasen una decisión basada en los méritos de la nueva tecnología de Sun e Intel.

En primer lugar, utilizando incentivos y presiones, Microsoft convenció a Intel para que no permitiera a Sun distribuir la nueva versión de alto rendimiento de Java de Intel y, eventualmente, detuviera el trabajo de ampliación de las bibliotecas de Java.

En segundo lugar, en marzo de 1996, Microsoft firmó una licencia con Sun para el uso de Java, y comenzó su propio desarrollo de un “Java Contaminado” sin capacidad multiplataforma. Similar al Java de Intel, la versión de Microsoft tenía un alto rendimiento porque priorizaba la facilidad de uso para los desarrolladores y la velocidad.

Un ejemplo representativo de los cambios que Microsoft implementó es la inclusión de “extensiones” para superar la construcción inherentemente multiplataforma de Java. Específicamente, Microsoft “desarrolló métodos para habilitar ‘llamadas’ a código ‘nativo’ de Windows que dificultaban la portabilidad en mayor medida que el método que Sun estaba esforzándose por estandarizar”. Aunque “Microsoft fácilmente podría haber implementado el método nativo de Sun junto con el suyo en sus herramientas de desarrollo y su [versión de Java]… en su lugar optó por implementar solo los métodos de Microsoft”. Microsoft implementó este diseño porque negaba a los desarrolladores una opción “entre velocidad y portabilidad”. Asimismo “Microsoft alentó a los desarrolladores a utilizar estas extensiones al enviar sus herramientas de desarrollo con las extensiones habilitadas de forma predeterminada y al no advertir a los desarrolladores” que las herramientas en su modo predeterminado producirían aplicaciones que solo funcionan en Windows y en la versión de Java de Microsoft.

En tercer lugar, a partir de 1997, Microsoft firmó “Acuerdos de Primera Ola” con grandes desarrolladores, otorgándoles acceso anticipado a las versiones beta de Windows a cambio de su promesa de “utilizar la versión de [Java] de Microsoft como la ‘predeterminada’”. Según la Corte del Distrito, “Microsoft y todos los [desarrolladores] interpretaron este requisito como una obligación de que los [desarrolladores] aseguren que sus aplicaciones de Java fueran compatibles con la versión de [Java] de Microsoft. La única forma efectiva de garantizar la compatibilidad con el [Java] de Microsoft era utilizar las herramientas de desarrollo de Java de este último que, a su vez” se configuraban por defecto en las extensiones de Java “incompatibles”.

Al declarar su responsabilidad, la Corte del Circuito de D.C. caracterizó las acciones de Microsoft como “engañosas” y los Acuerdos de Primera Ola como “exclusivos”. Los tribunales que interpreten las decisiones sobre Java no deben permitir que las caracterizaciones de la Corte del Circuito de D.C. oscurezcan la mecánica de lo que Microsoft realmente hizo, ni pierdan de vista cuántos hechos subyacentes implicaron las elecciones de diseño de Microsoft. Para esto puede que sea necesario leer la opinión de la Corte del Circuito de D.C. junto a los hallazgos de hecho de la Corte del Distrito.

Las decisiones judiciales sobre Java no se referían a una simple tergiversación. El caso de Microsoft no fue el típico caso de engaño contra un monopolista que realizó una campaña publicitaria tergiversando fraudulentamente un producto de un rival no monopolista. Fue mucho más fuerte. Las tergiversaciones de Microsoft concernían a la naturaleza de su propio producto. Lo que Microsoft no divulgó, o afirmativamente ocultó al responder preguntas de la prensa, fueron sus elecciones de diseño del producto. Más específicamente, ocultó la naturaleza anticompetitiva de los cambios que hizo a Java para evitar que otros, especialmente los desarrolladores, hicieran elecciones informadas sobre los méritos de la competencia.

De manera similar, las decisiones judiciales sobre Java no involucraron condenas formales por acuerdos exclusivos. Con una única excepción, los Acuerdos de Primera Ola eran exclusivos en el sentido técnico de que los desarrolladores prometieron crear y distribuir aplicaciones que se inclinaban “por defecto” hacia el Java Contaminado, utilizando herramientas que Microsoft había diseñado para hacer esto con sus extensiones de Java. El único acuerdo que era “exclusivo”, en el sentido formal de incluir un término expreso que prohibía el uso o distribución de cualquier versión de Java que no fuera la de Microsoft, era la licencia de Microsoft a RealNetworks, la aplicación más popular para el contenido multimedia en transmisión a fines de la década de 1990.

Es notable que la Corte del Circuito de D.C. nunca mencionara la licencia con RealNetworks. Por el contrario, se refirió a un grupo de Acuerdos de Primera Ola en los que importantes desarrolladores prometieron usar el Java de Microsoft como predeterminado, pero no prohibieron ni el uso ni la distribución de otras versiones de Java que cumplieran con las normativas. Además, según la Corte del Distrito, una razón principal por la que el grupo de acuerdos era similar a uno de tipo exclusivo en su efecto práctico, era que los desarrolladores creían que se les exigía usar las herramientas de Microsoft que se inclinaban por defecto hacia las extensiones de este último. Sería un error leer estas decisiones sobre Java como preocupadas por la exclusividad contractual en un sentido formal en lugar de la exclusividad como un atributo del diseño del producto que incluye dos configuraciones predeterminadas diferentes.

El análisis de la Corte del Circuito de D.C. también consideró un amplio rango de evidencia del mercado para llegar a conclusiones sobre el efecto competitivo neto. Si los desarrolladores de software, los usuarios de PC y todos los demás negocios que usaban Windows valoraban la velocidad adicional incremental, entonces Microsoft no habría tenido que engañar a los desarrolladores ni restringir su elección de herramientas para ganar aceptación en el mercado. Sin embargo, eso es exactamente lo que hizo Microsoft. En la medida en que la menor velocidad fue un obstáculo para la expansión de Java en 1996, según la Corte del Distrito, Intel estaba trabajando para superarlo. Si Intel tenía éxito, podría haber anulado cualquier valor comercial de la “mejora” de Microsoft a Java.

A menudo los demandados respaldan su interpretación de “regla de inmunidad” para las mejoras de diseño con la creencia de que los méritos de los cambios de diseño no son un tema justiciable. Lo anterior porque los tribunales carecerían de las habilidades para medir o sopesar los méritos técnicos de los cambios de diseño, o para llegar a conclusiones fiables en cuanto a los efectos competitivos netos. Al mismo tiempo, no tienen problemas para avanzar en una visión robusta, según la cual la Corte del Circuito de D.C. habría sostenido que el Java Contaminado era una “mejora” de importancia concluyente para el análisis del derecho antitrust. Si esto último fuese cierto, habría una contradicción no resuelta entre esas dos visiones de las capacidades de nuestras cortes.

Al cambiar el enfoque hacia el contexto del mercado, el método de análisis de la Corte del Circuito de D.C. evita cargar a los tribunales con la necesidad de tomar una decisión definitiva sobre el tema, en cualquiera de las direcciones, basándose únicamente en el nuevo producto en sí mismo. Esta interpretación de las decisiones sobre Java, por lo tanto, ofrece una construcción más fiel de la crucial, pero esquiva, frase de la opinión de la Corte del Circuito D.C., que fue parcialmente citada anteriormente. Aquí está esa frase de nuevo, pero en su versión íntegra: “[La versión de Microsoft de Java] sí permite que las aplicaciones se ejecuten más rápidamente y no tiene en sí misma ningún efecto anticompetitivo” (énfasis del autor). Esta frase describe el Java Contaminado como un nuevo producto con al menos una ventaja plausible y concluye de manera limitada que su existencia no resulta en un efecto perjudicial. Para expresar el punto claramente, esta es una conclusión estrecha sobre un tema tan circunscrito que su importancia práctica es casi nula.

Así interpretadas, las decisiones del Circuito de D.C. sobre Java se alinean con la ley en el Segundo Circuito. Un caso temprano e influyente de mantenimiento de monopolio de alta tecnología, Berkey Photo, Inc. vs Eastman Kodak Co., consideró lícita la introducción por parte de Kodak de “una película nueva y notable” porque su “éxito no se basó en ninguna forma de coerción”. Y en Schneiderman vs. Actavis PLC (en adelante “Namenda”) se siguió ese principio al sostener que “la jurisprudencia bien establecida deja en claro que el rediseño del producto es anticompetitivo cuando coacciona a los consumidores e impide la competencia”. En una nota al pie especialmente pertinente, el panel de Namenda explicó que la cuestión de si el nuevo producto en cuestión “es superior (…) no es significativa en este caso. Cuando hay coerción, la conveniencia técnica del cambio del producto (…) incide en la cuestión de la intención monopolística, más que en la permisibilidad de la conducta del acusado” (limpiado).

Dada la importancia duradera de las decisiones judiciales sobre Java, es lamentable que parte del lenguaje de la Corte del Circuito de D.C. pueda malinterpretarse para privilegiar los cambios de diseño del producto en mayor medida que una interpretación basada en lo que el tribunal en pleno realmente decidió en su opinión histórica. Leyendo el caso de Microsoft junto con los casos Berkey y Namenda, el estándar es aproximadamente similar en los Circuitos Segundo y D.C., y la cuestión legal relevante es si el monopolista actuó para coaccionar a sus socios comerciales de modo que los obligara a usar o distribuir su nuevo producto plausiblemente anticompetitivo, dañando así la competencia. Si ha participado en actos que interrumpieron materialmente los procesos competitivos normales de aceptación e implementación de nuevos productos, entonces el monopolista puede ser declarado responsable por el mantenimiento del monopolio. En casos que involucran tecnologías digitales, estos serán típicamente problemas vinculados a hechos que no se pueden resolver en un juicio sumario. Especialmente para productos que están relacionados con estándares en industrias de redes, esta prueba exige una aplicación cuidadosa, como la propia Corte del Circuito de D.C. demostró.

Disclaimer: Joshua Gray ha asesorado a algunas compañías sobre posibles reclamaciones de derecho antimonopolios contra varias empresas tecnológicas globales. También ha asesorado a clientes sobre las prácticas comerciales de Google, pero este trabajo no se refleja en ningún litigio pasado o actual.

*Los artículos representan las opiniones de sus escritores, no necesariamente las de la Universidad de Chicago, la Escuela de Negocios Booth o su facultad.

** Nota del traductor: Esta traducción al español fue realizada con el apoyo de la herramienta Chat GPT, de Open AI.