Google le gana la partida a Oracle : la Corte Suprema de EE.UU. sentencia que el uso de Java en Android es legítimo

Es según algunos el juicio del siglo: Oracle lleva más de una década inmersa en una batalla legal con Google, y la razón no es otra que el uso que esta última empresa hizo de Java para el desarrollo de Android. El caso es un absoluto referente a la hora de dilucidar cómo afectan las reglas del copyright al desarrollo software, y la Corte Suprema de Estados Unidos ha decidido por mayoría (6-2) que Google tiene razón y por tanto el uso de Java en Android es legítimo.

[#4 Veelicus]

#3 He trabajado con bases de datos Oracle... no me dan ninguna pena.

[#26 Fartis]

#4 A mi menos aún, trabajo con el combo Weblogic + Oracle.

[#29 Desactivado]

#26 Que Dios te lleve pronto

[#43 noises]

#26 Si también usas Eclipse pregunta en tu trabajo que con esa combinación creo que te dan una prima de penosidad.

[#58 Fartis]

#43 Efectivamente, utilizo Eclipse, combo triple.

[#49 Poignard]

#26 Weblogic es lo peor de lo peor.... no se como se lo han colado a algunas empresas

[#59 Fartis]

#49 Y no solo a las empresas, sino tambien a los organismos oficiales del estado, trabajo para una empresa que a su vez le ofrece los servicios a dos gobiernos autonomicos, actualmente estoy en sanidad.

[#62 Poignard]

#59 Oracle tiene mucho poderío (if you know what I mean)

[#51 ed25519]

#26 pues una estatua te mereces por que weblogic........

[#60 Fartis]

#51 Si fuera por mi utilizaba cualquier cosa, quien ha padecido ya cualquier cosa es buena jaja, pero es por contrato con el cliente.

[#56 CrudaVerdad]

#26 No te preocupes si tu alma se va al infierno de Dante cuando mueras.... será muchísimo mejor lugar comparado a lo que estás padeciendo ahora mismo.

[#61 Fartis]

#56 ¿Cuál de los círculos le tocan a los programadores? Por ir mirando las reseñas en Google y buscar sitios donde se coma bien, que al ritmo que voy de estrés y ansiedad será pronto la visita.

[#1 Veelicus]

Excelente noticia para los desarrollos independientes, una sentencia contraria hubiese puesto patas arriba el mundo del software

[#3 ioxoi]

#1 no te da pena la pobre Oracle que se gastó un pastizal comprando Sun para amortizar la inversión de esta forma tan ... Poco limpia.

[#12 Desactivado]

#1 Lo dudo mucho, la verdad.

Si Oracle denuncia es porque creen que pueden sacar diez mil millones.

Primero, que la culpa de usar la API fe Google es de Google. Y por los derechos de autor estarían pagando y sería su responsabilidad.

Segundo, aunque pudieran denunciarte (porque eso querría decir que todas esas api las estás usando en tu desarrollo, que habría que verlo), Oracle no se va a poner a denunciar a los desarrolladores que hace diez años las usaron.

Y tercero. Aunque lo hicieran, en un mes ya tendrías librerías Google o Open source haciendo lo mismo.

[#15 Desactivado]

#12 Sienta un precedente para futuros casos de plagio

[#63 rafael90]

#15 Por ejemplo, que Microsoft demande a los desarrolladores de Wine, DXVK, etc, por usar sus APIs propietarias para traducirlas a las de Linux o Vulkan. Si ganase, Microsoft asestaría un duro golpe a la competencia y fortalecería su monopolio.

[#64 Desactivado]

#63 Exactamente, y el problema ya no es solo de replicar API's ya conocidas para poder integrarlo facilmente con soluciones existentes. Imaginemos que alguien decide que se metodo "list_all" es propietario y que cualquier llamada a una base de datos que devuelva todos los objetos es infirngir propiedad intelectual. Al final, puede crear un precedente del que primero que crea una funcionalidad basica se puede adueñar de ella.

[#65 meneandro]

#15 O no plagio. Imagina que un producto de software muere, pero aún necesitas algo que ocupe ese hueco porque es un componente vital en tu trabajo. Si diseñas algo que se comunique del mismo modo (unas apis iguales, aunque haga cosas completamente distintas por dentro) para que sea un reemplazo que no te obligue a modificar todo lo que tienes hecho (sino simplemente sustituír tal cual lo que tenías), también tendrías problemas (si alguien te pilla y denuncia, al menos). Esto te obligaría a cambiar todo.

#14 No se usa nada de código. Míralo de este modo, con un ejemplo supertonto y muy simplificado: oracle tiene una receta patentada para hacer magdalenas. Google dice: yo quiero vender magdalentas, busco mi propia receta y voy a vender magdalenas. Oracle dice: estás usando el nombre magdalentas que tengo patentado. Google dice: no hombre, tú has patentado una receta, no puedes patentar el nombre magdalenas también porque hay muchas formas de hacer magdalenas... y si las llamo muffins, los que hablen español no sabrán qué son, aunque realmente sean lo mismo, sólo funcionará en mercados anglosajones.

Pues aquí pasa igual: google hizo una implementación independiente y sin usar nada de lo de oracle, pero para poder ser compatible, necesita que las cosas se llamen igual, si no, no pueden sustituír lo que ha hecho oracle por su propia implementación y que funcionen las cosas.

Para poder ejecutar aplicaciones java, oracle tiene una máquina virtual (que es lo que tenía patentado). Esa máquina virtual se diseñó con una serie de requisitos muy genéricos en mente para que fuera fácil portarla a todo tipo de dispositivos, requisitos que no encajaban bien con la ejecución en dispositivos móviles que es un caso muy concreto, había muchas cosas que a google le sobraban, otras que le faltaban y muchas que no encajaban bien con lo que google necesitaba. ¿Qué pasó? google se creó su propia máquina virtual específicamente para móviles, de manera que pudiera interpretar código java de forma eficiente para la ejecución en dichos dispositivos. A todos los efectos es una máquina virtual java y tiene que responder y funcionar como es definida en el estándar del lenguaje para que funcione el código java, tiene que tener algunas cosas comunes, es como hablar el mismo idioma, pero siendo dos personas completamente distintas.

Oracle viendo que google ingresaba un montón de dinero por trabajo en cierto modo derivado sus propiedades intelectuales, demandó. Pero a oracle le importa una mierda las implicaciones de lo que pide o de si realmente tiene o no razón, lo que le importa es la pasta. Algo parecido fue el caso SCO contra linux, también muy famoso (y que parece que aún colea).

[#21 Fayer]

#12 El tema es que Sun si permitía el uso de esas APIs a Google, y la movida empezó cuando Oracle compró Sun

[#14 DenisseJoel]

#1 Puede que sea una buena noticia, pero también es injusta. Si Java no había liberado ese código, Google no tenía derecho a usarlo.

Si no se respetan las licencias del código, eso también va a perjudicar al software libre, ya que las licencias que intentan evitar que un determinado software, una vez modificado, sea convertido en privativo, no tendrán efecto.

[#18 Desactivado]

#14 Google no se aprovecho del codigo, se limito a replicar la funcionalidad para que otros programadorescon experiencia en el uso de Java pudiera desarrollar para Android, no hubo un robo de propiedad intelectual, simplemente se reutilizo una interfaz.

Las licencias de codigo estan hechas para proteger el trabajo de los programadores, en este caso Google no se aprovecho de nada puesto hicieron su propio desarrollo y se limitaron a replicar la API de Java, en ningun momento copiaron el sistema al completo.

[#20 DenisseJoel]

#18 ¿Solo copiaron las APIs pero no la implementación?

[#24 Desactivado]

#20 Es lo que dice Google, que replicaron las API's pero que muchas lineas de codigo resultaron similares o iguales porque la funcionalidad no permitia otro codigo distinto.

De todas formas si se hubieran limitado a copiar el sistema de Java, serian muchas mas lineas.

[#38 Desactivado]

#20 Exacto. Pero Oracle afirmaba que los ficheros de cabeceras también estaban cubiertos por el copyright. Una salvajada se mire por donde se mire.

[#31 fugaz]

#14 No. Google no usó el Java de Oracle. Google implementó de cero su versión usando la API (nombres de métodos y clases) de Java.
Oracle al demandar que la API era propietaria impediría implementaciones libres (o cualquier otra implementación) de Java.
De darse la razón a Oracle todas las implementaciones de Java libre dejarían de poder usarse.
El sinsentido de extender el copyright a las API es como el de extender el copyright al ancho de las vías de tren.
Y además ataria a todos los programas sobre Java a las tinieblas, porque dependerían de Oracle, que ante un fallo de seguridad podría solucionarlo y poner que cuesta 1.000€, y apoquinas o no tienes parche de seguridad.

[#53 alvdavi]

#31 Esto que comentas no es totalmente cierto. La mayor parte de las implementaciones libres de la maquina virtual de java estan basadas en OpenJDK. OpenJDK es la maquina virtual que Sun libero poco antes de ser comprada por Oracle. Aunque al principio no incluia todos los componentes, en las ultimas versiones el JDK que ofrece Oracle es una build de OpenJDK. OpenJDK es GPLv2, por lo que incluso si el juicio hubiera ido a favor de Oracle, esto no habria afectado a OpenJDK (aunque quiza a otras implementaciones como OpenJ9). Igualmente, aunque Oracle no suministrase parches de seguridad, otra gente podria hacerlo (de la misma manera que a dia de hoy, Oracle distribuye parches de seguridad para OracleJDK8, pero para OpenJDK8 los parches de seguridad no necesariamente vienen de Oracle

[#17 Fayer]

#1 Ya pueden parar Fuchsia

[#45 aironman]

#17 y kotlin

[#46 sxentinel]

#1 Ojo, no tanta....

"Al revisar esa decisión, asumimos, en aras de la argumentación, que el material era susceptible de ser protegido por los derechos de autor. Sin embargo sostenemos que la copia en cuestión constituyó un uso justo. Por lo tanto, la copia de Google no violó la ley de derechos de autor".

Consideran que el material es susceptible de ser protegido por copyright.

[#55 superplinio]

#46 No, suponen que está protegido por copyright (porque es más sencillo y así no entran en el tema peliagudo) para luego ver que lo que hace Google es un uso justo de dicho material y por tanto no procede la demanda de Oracle.

Es una forma de resolver el caso sin complicarse. Dicen "asumamos que tienen copyright" y tiran para adelante, pero no quiere decir que "fallan" que las API tienen copyright

[#50 Desactivado]

#1 puesto pata arriba lo qué, Google paga y listo.

[#7 Veelicus]

#6 El problema seria para cualquiera que quisiera desarrollar algun usando una API de un tercero, mucho mas grave de lo que puede parecer a simple vista

[#13 Desactivado]

Oracle: Como se atreve Google a utilizar la misma API!

También Oracle: Vamos a copiar la API de AWS para que los clientes lo tengan más fácil para migrar a nuestra plataforma.

Que se jodan.

[#23 Fayer]

#13 Pues no has visto los HMS (Los servicios de Huawei equivalentes a los de Google). La API es la misma solo cambiando los imports (y que la mitad de las cosas no funcionan, pero bueno )

[#37 Desactivado]

#23 La API es la misma solo cambiando los imports

Es que si no no serían equivalentes

la mitad de las cosas no funcionan

Pues si funciona la otra mitad ya es la hostia. Implementar una API de ese tamaño no es algo que se haga de un día para otro.

[#40 Desactivado]

#23 Pero Huawei no va demandando a otras empresas por copiar una API.

Ese es el problema, no copiar APIs.

[#11 Ovidio]

¿Pero no habíamos quedado en que las API no estaban sujetas a derechos de autor? O sea, un archivo de cabecera de C (*.h), donde se declaran funciones, ¿cómo va a tener derechos de autor? La comparación con el teclado QWERTY que hace el juez es muy adecuada al caso

[#34 Razhan]

#11 creo que el argumento de Oracle no era basándose en derechos de autor, sino en que muchas de las APIs contienen la palabra Java que es marca registrada de Oracle

[#36 Desactivado]

#16 Muchísimo, sobre todo en lo que se conoce como enterprise software (que a menudo se traduce incorrectamente como "software empresarial", cuando esto corresponde a business software).

La arquitectura de microservicios, dentro de este nicho, tiene un uso cada vez mayor en servicios accesorios (los que no forman parte del core) y ahí es donde entran las NoSQL. Aunque "NoSQL" ya está dejando de significar algo porque muchas implementan un lenguaje de consulta SQL-like y porque el término es tan amplio que no describe la necesidad que cubre.

Actualmente tienen mucha demanda las columnares (para cantidades ingentes de datos estructurados), las graph (para ontologías y, en general, para cualquier estructura difícilmente expresable en un árbol), las key/value (para cachés), las documentales...

Dentro de este sector, MySQL/MariaDB (sobre todo la primera) tienen un uso restringido como query database, es decir, como una base de datos desnormalizada adaptada a consultas comunes, que es para lo que está optimizada, pero en la práctica son incapaces de sostener un modelo relacional como el que suelen requerir este tipo de aplicaciones. Y ahí es donde entran Oracle, IBM Db2, Postgres...

[#41 llorencs]

#36 Gracias por la respuesta. Me imaginaba que sí, pero como todo tendía a microservicios, pues suponía que empezaba a usarse menos, porque para ese modelo es un monstruo.

[#42 Desactivado]

#41 Y para el otro también¹ Pero migrar una estructura de enterprise a microservicios no es trivial y, en algunos casos, puede que incluso no sea posible (o totalmente desaconsejable).

Una situación parecida es la de los cores bancarios, muchos aún siguen anclados a Cobol porque han sido incapaces de migrar hacia otras infraestructuras. Y me consta que no ha sido por falta de esfuerzo.

¹ Una honrosa excepción la consituye Postgres: una de las joyas del open source y que lo mismo sirve para un roto que para un descosido. Una de sus historias de éxito es la migración de The Guardian a MongoDB... y de ahí a Postgres, cuando se dieron cuenta de bajo muchas condiciones servía documentos de manera mucho más eficiente que una base de datos documental como MongoDB.

Hoy en día cualquier diseño de infraestructura de persistencia debería explicar, si es el caso, por qué no se puede hacer con Postgres

[#47 llorencs]

#42 Yo pasé de MySQL a Postgres cuando hice alguna cosilla con BBDD. Y ahora he hecho cosas con Sqllite por el tipo de apps y lo logro a microservicios y Docker. Tengo que aprender a integrar mi Python-Flask con Docker y luego integrarlo con BD que creo que lo integraré con Postgres.

Software libre siempre.

[#48 Desactivado]

#47 Sqlite es una pequeña maravilla para persistencia local y desarrollo. Para la integración con una DB relacional no puedo más que recomendar SQLAlchemy, de esa manera puedes desacoplar la DB de la aplicación y a partir de ahí, cambiar entre Postgres, MariaDB y SQLite es tan trivial como cambiar un parámetro, ya que soporta las tres nativamente.

Para la integración con Docker yo le echaría un ojo a esta plantilla: https://github.com/tiangolo/uwsgi-nginx-flask-docker Es un despliegue single-container con nginx como servidor http y uwsgi+Flask como servidor de aplicaciones.

Y por supuesto también a FastAPI (esa imagen permite migrar fácilmente Flask a FastAPI) que apostaría un sueldo que acabará sustituyendo a Flask en poco tiempo como microframework por defecto de Python Ronacher es un puto crack, pero ahora está centrado en Rust y Flask ha entrado en fase de mantenimiento, no va a haber un Flask con soporte async.

[#52 llorencs]

#48 Para la integración con DB relacional usé Ponyorm. Me gustó su sistema de integración. El problema de ponyorm es que si migro a FastAPI tendré que migrar a SQLAlchemy porque de momento no tiene soporte para async. Pero me sentía más cómodo con la API de ponyorm, cuando decidí aprender una ORM.

Sí, la de tiangolo es la que he mirado.

PS: Tiangolo tiene varias cosas interesantes, como también una biblioteca para línea de comandos como Typer.

[#54 Desactivado]

#52 Ponyorm está muy bien y yo también prefiero antes su sintaxis que la de SQLAlchemy, pero no me convence su soporte para un proyecto en producción. Si no fuese así seguramente la usaría antes que SQLAlchemy.

Con typer me pasó algo parecido, lo acabé retirando como dependencia de un proyecto antes de la release candidate y quedándome con click a pelo porque el soporte no es nada convincente y los PRs se acumulan sin revisión desde hace meses. Es lo que tienen los proyectos de los 10x developers, si no son abrazados al instante por una comunidad que les preste soporte corren el riesgo que quedarse fosilizados en algo con muy buena pinta pero poco futuro.

A este respecto Tiangolo tiene un proyecto muy interesante, aún en alpha y al que aún no le he podido echar la mano, que es un mapper entre SQLAlchemy y Pydantic. Viendo la integración de Pydantic que ha implentado en FastAPI sólo espero cosas buenas de este proyecto.

[#30 Desactivado]

Es que de otro modo Wine sería ilegal, HMS sería ilegal, el uso de POSIX sería ilegal... y así tantas cosas.

En octubre de 2020 se realizaron las defensas orales de esos argumentos, y el juez Stephen Breyer comparó la demanda de Oracle referente a esas APIs con tratar de asignar derechos de autor a los teclados QWERTY. "Si dejases que alguien tuviera el copyright sobre eso, controlarían todas las máquinas de escribir, y ese no es el objetivo del copyright", indicó entonces.

Código abierto != software libre.

[#10 Desactivado]

Gracias, Google, por evitar la tiranía opensource.

[#28 uno_ke_va]

#16 https://db-engines.com/en/ranking

[#33 Razhan]

Buena noticia. Eso si, he de decir que la postura de Oracle (al menos al principio) no era tan descabellada como he visto en algunas noticias, que parece cosa solo de pasta. Lo que Oracle pedía inicialmente a Google es que si iba a implementar APIs de Java, tenía que comprometerse a implementar el 100%, no solo una parte, y que si no lo hacían, entonces no es Java y en vez de algo como java.lang.String tendrían que usar google.lang.String, ya que Java es una marca registrada. Aunque para el usuario fuera una operación sencillla de buscar y reemplazar, aún así esto tendría implicaciones masivas, por ejemplo mogollón de librerías que son utilizables en Android y otra máquina Java no podrían serlo, por no hablar del riesgo a otros proyectos como wine

[#57 abuelillo]

#33 Pues que quieres que te diga, lo que acabas de aclarar me parece igual de descabellado, o incluso más porque prohibirá completamente la interacción entre sistemas distintos.
Por ejemplo un sistema operativo ya no podría leer particiones o sistemas de red de otros sistemas operativos, bastaría con que los protocolos incluyesen palabras registradas simples.
Adiós a poder leer un disco compartido en Windows desde un Linux o un Mac por ejemplo.

[#27 Escheriano]

Oracle ha ido a cobrar y le ha saltado un NullPointerException

[#19 Fayer]

#16 Aquí se refiere a la empresa...

[#22 llorencs]

#19 El comentario que respondía decía que se jodan porque había usado su software. Así, que sí, ese monstruo aún se usa?

[#25 Fayer]

#22 "el software tal y como lo conocemos" se entiende que refiere al software en general, no a "ese" software concreto al que te refieres. pero vamos, que nos diga #5

[#2 Desactivado]

La noticia es un poco incompleta, no dice cuanto han cobrado los jueces.

Ni si quiera si han cobrado, aunque eso de da por supuesto.
Es mucha pasta la que habría recibido Oracle por parte de Google por el uso de Java en Android.

[#5 Veelicus]

#2 Si le hubiesen dado la razon a Oracle el software tal y como lo conocemos tendria un problema gravisimo porque saldrian demandas por todos lados.

[#6 Desactivado]

#5

El problema sería de los accionistas que lo usan.
Cierto que tendría un sobrecoste para el usuario final..
O quizá se desarrollarían alternativas

[#9 pawer13]

#5 ¿Por todos lados en USA o por todos lados en el mundo? Los americanos y sus patentes de software se meten en unos líos que aquí son impensables.

[#32 frankiegth]

#9. No te creas, España_TM compra y acata muchas de las políticas al otro lado del charco.

#5. Efectivamente, dudo mucho de que existan infinitas formas sustancialmente diferentes de construir una API para algo concreto. Extracto de la noticia :

"...En octubre de 2020 se realizaron las defensas orales de esos argumentos, y el juez Stephen Breyer comparó la demanda de Oracle referente a esas APIs con tratar de asignar derechos de autor a los teclados QWERTY. "Si dejases que alguien tuviera el copyright sobre eso, controlarían todas las máquinas de escribir, y ese no es el objetivo del copyright", indicó entonces...'

[#35 frankiegth]

#9. No... aquí son más de intentar meter a gente normal en la carcel o arruinarla de por vida sin haber hecho nada ilegal en el momento de sus respectivas denuncias :

Absueltos los responsables del sitio de enlaces PCTorrent tras seis años de litigio

Absueltos los responsables del sitio de enlaces PC...

Ingeniero en Telecomunicaciones absuelto tras informar de un fallo de seguridad y ser denunciado

Ingeniero en Telecomunicaciones absuelto tras info...

Sentencia absolutoria definitiva en uno de los casos más antiguos de P2P: EMWReloaded absuelto tras 11 años

Sentencia absolutoria definitiva en uno de los cas...

Caso Zonaemule: sentencia absolutoria para web de enlaces P2P tras 9 años de proceso

Caso Zonaemule: sentencia absolutoria para web de ...

Y una bola extra :
Se triplica el número de webs bloqueadas por la autorización que permite a Telefónica incluir nuevas URL cada semana

Se triplica el número de webs bloqueadas por la au...

_{(CC #5)}

[#16 llorencs]

#5 Aún se usan esos monstruos?

La tendencia es a nosql y mariaDB y eso, no?

[#8 bargusi]

#2 Que no ha sido la justicia española!

[#44 Desactivado]

#8
Lo de untar a jueces es universal, aunque no habitual.En todo el mundo.

[#39 Desactivado]

El uso de POSIX "sin pagar". Ojo.