Discussion :

[Idelways]

Android : la justice donne raison à Oracle
Sur les définitions des termes techniques, Google obtient le réexamen des brevets Java

Mise à jour du 02/05/2011 par Idelways


Dans l'affaire qui l'oppose à Google autour de l'utilisation de Java sur Android, Oracle vient de gagner un premier round, prématuré certes, mais stimulant d'une poursuite que les autorités de justice veuillent clore au plus vite.

Lors d'une audience d'interprétation vendredi, le juge William Alsup a donné raison à Oracle quant à la définition de quatre termes sur cinq relevés sur les textes des sept brevets mis en cause (pour plus de détails sur l'affaire, lire ci-devant)
Pour le cinquième terme, le juge ne s'est prononcé en faveur d'aucun des deux géants et a préféré opter pour sa propre définition.

En droit américain, l'interprétation des brevets (en anglais « claim construction ») est destinée à statuer sur les divergences des définitions que donnent les plaideurs aux termes techniques.

Le même jour, les avocats des deux entreprises ont déposé des propositions pour réduire leurs revendications respectives et rendre le nombre de ces revendications « jugeable » à la demande du magistrat qui espère clore cette affaire d'ici la fin du mois de novembre prochain.

Oracle a proposé de réduire progressivement le nombre de ses demandes de 132 à 75 d'ici la fin juin, à 35 au début septembre, puis à « un nombre jugeable » non encore fixé d'ici la conférence de préprocès prévue pour le 17 octobre.
Oracle exige en contrepartie que Google réduise à quatre le nombre des « affirmations d'antériorités et combinaisons de références » et à trois « motifs de nullité » par brevet.

Durant cette audience, l'avocat de Google a signifié au juge que le Bureau américain des brevets et des marques de commerce (USPTO) a accepté, la veille de cette audience, de réexaminer les brevets d'Oracle sur Java.
Toutefois, cette procédure est habituelle en cas de litige et ne garantit en rien que des brevets vont être invalidés.

Le procès est initialement programmé pour le 31 octobre et aucune des deux entreprises n'a demandé son report.
Le juge semble en tout cas intraitable sur cette question.


Source : Reuters

Et vous ?

Croyez-vous que cette affaire peut être clôturée d'ici fin novembre ?
Quelle fin prévoyez-vous pour cette poursuite ?

[s4mk1ng]

Encore une énième brevet sur des termes qui pourraient prêtés à confusion de toute façon même si le procès serait terminé d'ici fin novembre il y en aura d'autres dans la foulée,il faudrait peut être qu'ils revoient leur système de brevets...

[sidt]

Avec l'avidité d'Oracle, Java va très clairement passer du monde libre au monde commerciale à outrance. Donc avec un peu de chance, le monde industriel qui nous impose à dev avec ce langage (souvent mal implémenté donc lent et bourré de bugs) va peut-être réagir et s'orienter vers autres choses. Quant à google, je n'ai jamais compris leur choix ..Pourquoi Java ??
Le kernel ne tourne pas en Java! rien qui nécessite de vraies perfs peut utiliser Java... utiliser ce type de langage (trop évolué) pour un mobile, c'est à mon sens bizarre.

Donc perso, je dis 'bravo oracle', après la mort d'openoffice (VIVA LIBRE OFFICE) leur décision de vouloir s'en mettre pleins les fouilles va peut-être tuer Java.

[kpouer]

Moi j'ai toujours pas compris le problème réel. Tous les sites parlent de Google qui aurait selon Oracle décompilé des classes privées de la JVM pour les inclure dans Android. Or la classe citée en exemple a été distribuée en GPL par Sun donc je vois pas pourquoi Google l'aurait décompilée vu que les sources sont libres, et je vois pas ce que Oracle peut y redire du coup.

[transgohan]

Moi j'ai toujours pas compris le problème réel. Tous les sites parlent de Google qui aurait selon Oracle décompilé des classes privées de la JVM pour les inclure dans Android. Or la classe citée en exemple a été distribuée en GPL par Sun donc je vois pas pourquoi Google l'aurait décompilée vu que les sources sont libres, et je vois pas ce que Oracle peut y redire du coup.

Pour ce que j'ai pu en lire le soucis vient du fait que ces sources étaient sous licence GPL 2 et les headers avaient disparus (évidemment avec la décompilation...), cette licence n'autorise pas le fait de s'approprier un code (chose qui est faite puisque les crédits ont été enlevés. Ces sources étaient disponibles en lecture comme toutes les autres, mais n'étaient pas sous la même licence. Bon ça règle pas la question du "pourquoi ils ont décompilés les sources au lieu de les télécharger du dépôt ?".
C'est une différence entre la GPL 2 et la GPL 3 si j'ai bien lu les autres messages de ce topic, certaines sources sont sous licence GPL 3 et il n'y a aucun problème avec elles.

[kpouer]

Tu as peut-être raison, mais je trouve bizarre que Oracle fasse tout ce foin juste pour la licence GPL.
D'ailleurs les fichiers je crois ont eux-même changé de licence depuis l'arrivée d'Oracle, je crois me souvenir qu'en java 1.5 ils étaient GPL et en 1.6 le header GPL est remplacé par un header Oracle. Ils ont le droit puisque propriétaire mais ça montre un peu le changement d'orientation.

[Uther]

On va faire un petit rappel pour ceux qui arrivent alors que l'on en a discuté en long et en large dans les messages précédents. Il y a deux problèmes séparés, même s'ils ont été réunis dans le même procès : un problème de plagiat et un problème de brevet.

Pour l'accusation de plagiat : La base du Android SDK est réalisée depuis le projet Harmony d'Apache. Ce code ne pose aucun problème car la licence Apache est très libre et permet presque tout.
Cependant on a découvert que certaines parties du SDK présentées comme réalisés par Google sous leur propre licence ressemblent fortement à du code du SDK d'Oracle(ex Sun), ce qui poserait problème car même si l'OpenJDK est libre, sa licence (la GPL v2) est une licence de type copyleft fort: tout travail dérivé doit également être sous licence GPL.

Pour les brevets : Sun (et maintenant Oracle) a toujours possédé un certain nombre de brevets couvrant la technologie Java, pour lui permettre d'attaquer les implémentations non certifiées conforme de Java, ce qui est le cas d'Android.
De fait Java n'est pas totalement libre car même si la licence de l'OpenJDK est libre, tout fork se retrouve menacé d’attaque pour violation de brevet. Et comme Sun/Oracle se donne le droit de choisir à qui il fournit le TCK(outil de certification Java), il a virtuellement droit de mort sur toute implémentation Java, comme il l'a déjà fait pour le projet Apache Harmony.

D'ailleurs les fichiers je crois ont eux-même changé de licence depuis l'arrivée d'Oracle, je crois me souvenir qu'en java 1.5 ils étaient GPL et en 1.6 le header GPL est remplacé par un header Oracle. Ils ont le droit puisque propriétaire mais ça montre un peu le changement d'orientation.

Les version de Java distribuées par Sun (puis Oracle) sont toutes sous une licence propriétaire et ça restera le mode de fonctionnement pour les versions à l'avenir.
Sun a cependant publié la quasi totalité des sources de la version 1.6 sous GPLv2 dans un projet séparé : l'OpenJDK. Ce projet sert d'implémentation de référence.
Comme Oracle reste propriétaire des sources de l'OpenJDK, il pourra réutiliser tout le travail réalisé dans l'OpenJDK dans son JDK propriétaire alors que tout travail basé sur OpenJDK par quelqu'un d'autre sera forcément sous GPL.

Quant au changement de nom, ça n'a rien à voir avec un quelconque changement de politique. C'est juste que comme Sun n'existe plus légalement, ils ne peuvent tout simplement pas le conserver dans les entêtes. Maintenant Sun c'est Oracle, c'est tout.

Pour ce que j'ai pu en lire le soucis vient du fait que ces sources étaient sous licence GPL 2 et les headers avaient disparus (évidemment avec la décompilation...), cette licence n'autorise pas le fait de s'approprier un code (chose qui est faite puisque les crédits ont été enlevés. Ces sources étaient disponibles en lecture comme toutes les autres, mais n'étaient pas sous la même licence. Bon ça règle pas la question du "pourquoi ils ont décompilés les sources au lieu de les télécharger du dépôt ?".
C'est une différence entre la GPL 2 et la GPL 3 si j'ai bien lu les autres messages de ce topic, certaines sources sont sous licence GPL 3 et il n'y a aucun problème avec elles.

Le problème des entêtes disparues ne concerne pas cette affaire, c'est un tout autre problème lié cette fois a Linux et non Java.
Saches cependant que la GPLv3, n'autorise absolument pas l'appropriation de code, bien au contraire elle est même mieux protégée que la GPLv2 contre certaines pratiques comme le piège a brevet d'Oracle que j'explique ci dessus (c'est pour cela que Sun a choisi la GPL v2 et non v3 pour l'OpenJDK) ou la tivoisation

[transgohan]

Merci pour ces excellentes explication Uther.

[kpouer]

Uther, d'abord merci pour tes explications, Il y a cependant un point sur lequel j'ai un doute :

Tu dis que Oracle possède des brevets sur Java donnant droit de vie et de mort sur des implémentations non conformes. Mais en même temps les sources si elles sont en GPL, Google peut en faire ce qu'il veut, y compris un truc n'ayant rien à voir avec le java et Oracle n'a rien à dire sur le sujet non non ?
En admettant bien sur que Google ne s'en approprie pas la paternité et respecte la licence GPL.

[Matthieu Brucher]

Le code peut être couvert par un brevet et sujet à licence même sous une licence GPL, car on ne parle pas du même type de licence (la première est une licence intellectuelle, la seconde une licence sur le code).

[Uther]

Tu dis que Oracle possède des brevets sur Java donnant droit de vie et de mort sur des implémentations non conformes. Mais en même temps les sources si elles sont en GPL, Google peut en faire ce qu'il veut, y compris un truc n'ayant rien à voir avec le java et Oracle n'a rien à dire sur le sujet non non ?
En admettant bien sur que Google ne s'en approprie pas la paternité et respecte la licence GPL.

Si Google modifie suffisamment le code pour sortir du cadre des brevets d'Oracle, il peut en effet en faire ce qu'il veut. Reste que si on aboutit sur quelque-chose qui n'a plus rien a voir avec Java, était il utile de partir sur cette base?

Il faudrait étudier en détail ces brevets (ce que je ne ferais pas personnellement) pour savoir exactement ce qu'il couvrent et s'il est possible de faire quelque-chose d’intéressant du code d'OpenJDK sans les enfreindre.

J'avoue que j'ai été un peu dur en parlant de droit de mort. Un projet peut continuer sans être certifié Java mais il s'expose a payer des royalties à Oracle, ce qui en refroidira plus d'un, et mettra directement hors concours un projet qui se veut vraiment libre (dans les pays qui reconnaissent les brevets) car le droit de pouvoir modifier et redistribuer gratuitement ne peut pas être garanti, malgré la licence GPL.

[levolutionniste]

Salut, je me demande comment Oracle fait pour portez plainte à Google sur du code source d'Androïd, même si Google à utiliser de manière illicite du code de Java, Oracle n'est pas censé le savoir puisque dans cette guerre technologique, chacun devrait cacher ces succès. Alors comment les gars de chez Oracle ont fait pour accéder au code d'androïd et démontrer que Google utilise bel et bien du code de java. j'aimerai comprendre. Merci.

[transgohan]

Salut, je me demande comment Oracle fait pour portez plainte à Google sur du code source d'Androïd, même si Google à utiliser de manière illicite du code de Java, Oracle n'est pas censé le savoir puisque dans cette guerre technologique, chacun devrait cacher ces succès. Alors comment les gars de chez Oracle ont fait pour accéder au code d'androïd et démontrer que Google utilise bel et bien du code de java. j'aimerai comprendre. Merci.

Android est open source... Ce qui signifie... Beh que tout le monde peut voir le code en se rendant sur leur dépôt.

[Idelways]

Java : Oracle implique la Fondation Apache dans sa plainte contre Google
Et la cite à comparaitre

Mise à jour du 05/05/2011 par Idelways


Dans le cadre de sa procédure judiciaire contre Google autour de Java sur Android, Oracle vient de citer à comparaitre la fondation Apache Software.

Dans son blog, la fondation explique qu'Oracle cherche à « produire de documents relatifs à l'utilisation du code d'Apache Harmony dans la plateforme logicielle Android et les tentatives infructueuses de la fondation Apache à obtenir une licence acceptable du Kit de Compatibilité technologique pour Java SE ».

Pour ce faire, Oracle exige dans sa requête (dont le scan est consultable sur le blog de la fondation) tous les documents des communications entre Google et Apache, relatifs à l'utilisation du code du projet Harmony ou concernant tous accord ou licence entre les deux entités à ce sujet.

Oracle requière aussi toutes les communications entre Google et Apache sur le « besoin ou prudence d'obtenir toute licence » de sa part ou de la part de Sun, ou les communications relatifs à cette poursuite engagée par Oracle contre Google et toute discussion sur une éventuelle indemnisation.

Oracle exige enfin tous documents sur les violations potentielles ou avérées des brevets et droits d'auteurs sur Java par Google, Android ou l'Open Handset Alliance, un consortium créé à l'initiative de Google pour développer des normes ouvertes pour les appareils de téléphonie mobile.

Cette requête, reçue de la part des avocats d'Oracle le 2 mai, accorde à la fondation jusqu'au 13 mai prochain pour récolter et présenter ces documents.
La fondation signifie qu'elle se pliera à toutes les exigences du tribunal et rappelle qu'en tant que groupe de développement ouvert, la majorité de ses documents sont déjà publiquement disponibles.

Il n'est pas clair pour le moment si le rôle de la fondation dans cette affaire peut aider Oracle à inculper Google.
La relation désormais très tendue entre Oracle et la fondation Apache a conduit cette dernière à quitter le Java Community Process, lasse de tenter, une décennie durant, d'obtenir une licence convenable du Kit de compatibilité de Java (TCK) lui permettant de valider Harmony en tant que machine virtuelle Java entièrement open-source.

Le juge chargé de cette affaire a par ailleur ordonné aux deux géants de réduire le nombre de revendications en vue de clore rapidement cette affaire (lire ci-devant).


Source : Texte de la requête d'Oracle (PDF, 260 KO) Réponse de la fondation Apache

Et vous ?

L'implication de la fondation dans cette affaire jouera-t-elle un rôle prépondérant ?
En faveur de qui ?

[Traroth2]

Je serais étonné vues les circonstances que l'ASF intervienne en faveur d'Oracle...

[Traroth2]

Le code peut être couvert par un brevet et sujet à licence même sous une licence GPL, car on ne parle pas du même type de licence (la première est une licence intellectuelle, la seconde une licence sur le code).

Pas avec la GPL v3. La licence précise bien que quand on place du code en GPL v3, on donne à tout utilisateur de ce code un licence sur tout brevet qu'on détiendrait concernant ce code, licence permettant d'exercer tout les droits prévus par la GPL v3.

[Uther]

Je serais étonné vues les circonstances que l'ASF intervienne en faveur d'Oracle...

En effet, mais en même temps, je serais surpris qu'Oracle demande à l'ASF d'intervenir en tant que témoin de moralité
On peut supposer que le but est de voir si des communications entre l'ASF et Google portent sur les brevets de Sun, pour prouver que Google a bien enfreint ces brevets en connaissance de cause.

Pas avec la GPL v3. La licence précise bien que quand on place du code en GPL v3, on donne à tout utilisateur de ce code un licence sur tout brevet qu'on détiendrait concernant ce code, licence permettant d'exercer tout les droits prévus par la GPL v3.

Oui, mais en l’occurrence, Sun a délibérément choisi pour l'OpenJDK la GPL v2 car elle ne garantit pas ce genre de protection .

[sionnel]

Code automatique ne signifie pas décompilé.
Il suffit de faire de la réflexion et d'appliquer des aspects,
le tout avec un peu d'interaction pour combler les trous.
Et on peut automatiser avec des tests pour sélectionner les aspects.


Java est somme toute du domaine public.
Il n'y a pas 36 moyens d'appeler Maman ou Mum,
ni 36 moyens de la chatouiller ou la pousser...

Le brevet sur le langage ou même l'API est un non sens.


En terme d'implémentation, on en revient un peu au même...
Imaginez qu'on brevet la fabrication du beurre, le feu, le moteur à explosion...
Java n'apporte plus aujourd'hui aucune innovation technique;
L'esprit même du brevet n'est que la protection de l'activité économique.
Hors java n'est plus qu'un consensus sur la définition de contrats interface.
(Et encore, il y a peu consensus, et peu spec, peu d'impl...)


Au sujet des restrictions d'utilisation, absurde.
On revient sur le même problème que télé et ADSL.
Quelle différence y a-t-il fondamentalement entre smart-phone et PC ?
D'ailleurs si la restriction portait sur du matériel de l'époque,
peut-elle encore s'appliquer sur du matériel moderne n'ayant plus rien à voir ?



Qu'il faille respecter la compatibilité pour imposer la marque java est normal.
Que cette marque interdise toute évolution est absurde;
cela signifierai l'illégalité de toute bibliothèque.
Ici Google ne souhaite pas imposer l'estampille java, donc non lieu.


L'ouverture de java est ici clairement remise en cause.
La liberté d'innovation est clairement limitée.
De plus le langage commence à traîner quelques lacunes...
(calcul lambda et query langage, réflexivité, prototypage)


Autant dire que java est par ce coup d'Oracle sur la fin.
Et java sera bien plus facilement remplacé que Cobol...


L'avenir semble un choix entre:
- piratage massif (utiliser java sans tenir compte des licences)
- fork / migration (vers autre langage/jvm/libs, cette fois open source)

Il serait assez facile, en fait, d'avoir un outil de meta-polymorphisme,
entendez par là convertir une appli entre java, dotnet, autre.
Et à cette occasion de faire un langage plus haut niveau, voir déclaratif.

Les gros projets opensource ne sont plus une utopie.
Citons à titre d'exemple hibernate, spider monkey, apache xalan, linux.
Et les initiatives de nouvelle plate-forme sont déjà du réel (scala).

Libre à nous de définir la nouvelle plateforme opensource.
Et apache aurait probablement les épaules assez solide pour servir de guide.
Il ne manque qu'un outil de migration de code.




Pour revenir sur le sujet :
- Oracle se goinfrera comme il pourra, mais après la poule sera morte.
- Google switchera sans soucis, sa communauté sera faite et suivra.
- L'open source doit se décider, l'entreprise suivra l'opensource.

D'ailleurs aujourd'hui on n'utilise plus vraiment java, mais apache.

[Uther]

Je sais qu'il faut pas répondre aux trolls mais c'était trop tentant.

Code automatique ne signifie pas décompilé.
Il suffit de faire de la réflexion et d'appliquer des aspects,
le tout avec un peu d'interaction pour combler les trous.
Et on peut automatiser avec des tests pour sélectionner les aspects.

, "il dit qu'il voit pas le rapport"

Java est somme toute du domaine public.

Absolument pas, la marque est propriété d'Oracle et le standard est défini par le JCP.

Il n'y a pas 36 moyens d'appeler Maman ou Mum,
ni 36 moyens de la chatouiller ou la pousser...

Certes, il possible que les ressemblances ne soient que coïncidences, mais il faut voir que les exemples présentés semblent plutôt convainquant d'autant plus que Google n'a pas vraiment nié que certains codes pouvaient avoir été plagiés(rejetant la faute sur des sous-traitants)

Le brevet sur le langage ou même l'API est un non sens.

Les brevets ne portent pas sur le langage ou l'API eux même(ce qui n'est pas brevetable) mais sur les algorithmes qui permettent de les implémenter en interne de manière performante.

Qu'il faille respecter la compatibilité pour imposer la marque java est normal.
Que cette marque interdise toute évolution est absurde;
cela signifierai l'illégalité de toute bibliothèque.
Ici Google ne souhaite pas imposer l'estampille java, donc non lieu.

Heureusement que les bibliothèques tierces ne sont pas interdites et ne le seront jamais.
Elle sont dans un cadre complètement séparé des spécification.

L'ouverture de java est ici clairement remise en cause.
La liberté d'innovation est clairement limitée.
De plus le langage commence à traîner quelques lacunes...
(calcul lambda et query langage, réflexivité, prototypage)

Qu'est ce que tu entends par ouverture? Si tu veux dire, la possibilité de faire tout et n'importe quoi avec les spécification, alors tu te trompes, il n'a jamais été ouvert. Bien au contraire leur coté strict est ce qui fait son intérêt et il est indispensable pour essayer de coller au mieux a son modèle "Write once run anywhere".

Autant dire que java est par ce coup d'Oracle sur la fin.
Et java sera bien plus facilement remplacé que Cobol...

L'avenir semble un choix entre:
- piratage massif (utiliser java sans tenir compte des licences)
- fork / migration (vers autre langage/jvm/libs, cette fois open source)

Que ce coup face du mal à Java, c'est possible mais loin d'être certain.
Une chose est sure c'est qu'il n'est pas prêt d'être remplacé en masse pour ci peu et que 99% des entreprises qui utilisent Java se contrefichent de ce procès qui n'aura pas le moindre impact sur eux..

Libre à nous de définir la nouvelle plateforme opensource.
Et apache aurait probablement les épaules assez solide pour servir de guide.
Il ne manque qu'un outil de migration de code.

Ça serait fort sympathique. Je demande à voir, mais il faut pas se leurrer, c'est pas pour demain. En partant sur des bases vierges, il y en a pour des années pour arriver a quelque chose d'utilisable.
Quant a faire accepter une énième plateforme, c'est loin d'être gagné.

Pour revenir sur le sujet :
- Oracle se goinfrera comme il pourra, mais après la poule sera morte.
- Google switchera sans soucis, sa communauté sera faite et suivra.
- L'open source doit se décider, l'entreprise suivra l'opensource.

Oracle tire sur la corde mais contrairement à OpenOffice ou Hudson ou la rupture était imminente, Java est dans une situation bien différente.
Les entreprises sont pragmatiques, elles ne soutiennent pas l'open-source pour l'open-source. Bien au contraire, elles sont très frileuses s'il n'y a pas une grosse société derrière.

Par contre le switch de Google semble clairement se préparer en douceur, Android 3.0 permet déjà de faire du full C++ et au vu de l'intégration du Go à gcc, il me parait fort probable qu'il remplacera le Java à terme.

D'ailleurs aujourd'hui on n'utilise plus vraiment java, mais apache.

Heu!!! Si tu parle de Tomcat, vu qu'il repose sur Java, ça me parait une affirmation bien drôle.

[Philippe Bastiani]

D'ailleurs aujourd'hui on n'utilise plus vraiment java, mais apache.

Amusant ! langage, techno, plateforme: beaucoup de confusion et d'approximation dans ton post...

Regardes aussi la définition de domaine public... Je n'ai pas souvenance que SUN et/ou Oracle ait renoncé à leurs droits !
Et au passage les brevets détenus par Oracle ne touchent pas le langage mais la technologie...

Piratage massif de la JVM ???? Ce n'est pas comme celà que tu vas recevoir ta lettre d'Hadopi ;-)