Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #421
    Rédacteur/Modérateur

    Citation Envoyé par walfrat Voir le message
    "par principe" : tu as une référence de loi Américaine ou française qui va dans ce sens ? parce que un "principe" ça tient pas devant un juge s'il n'est pas dans la loi...
    Comme l'a signalé Steinvikel, le droit coutumier des pays anglo-saxons permet de faire bien des choses qui ne sont pas écrites dans la loi.
    Merci de penser au tag quand une réponse a été apportée à votre question. Aucune réponse ne sera donnée à des messages privés portant sur des questions d'ordre technique. Les forums sont là pour que vous y postiez publiquement vos problèmes.

    suivez mon blog sur Développez.

    Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. ~ Rich Cook

  2. #422
    Expert éminent sénior
    Citation Envoyé par LeBressaud Voir le message
    Et pourquoi sur le principe ça ne se vendrait pas ? Créer une API cohérente de cette taille et utilisé par autant de développeur ça demande un énorme travail. Sur le principe on peut comprendre qu'ils soient un peu frustré que google ai tous pompé et se fasse du blé avec...
    La cohérence peut en effet demander du travail, par contre le nombre d'utilisateur ne change rien a la complexité de la tache.

    Par contre , la quantité d'utilisateur rend d'autant plus importante la possibilité de faire une implémentation compatible d'une bibliothèque. Cela permet d’éviter de se retrouver piégé par une société qui bloque les possibilités d'évolution en abusant de sa position dominante.

    Citation Envoyé par walfrat Voir le message
    "par principe" : tu as une référence de loi Américaine ou française qui va dans ce sens ? parce que un "principe" ça tient pas devant un juge s'il n'est pas dans la loi...
    En Amérique il y a la notion juridique de Fair-Use qui reste cependant assez vague. Toute la question du procès est justement de savoir si la reprise de l'interface d'une bibliothèque rentre dans ce cadre. Jusqu’à présent l'ensemble du milieu informatique considérait que c'était le cas.

    Citation Envoyé par walfrat Voir le message
    Et oui si une entreprise pond un système, je ne vois pas pourquoi on devrait pouvoir y brancher un autre système qui prétend fonctionner comme celui de l’entreprise. Cela dit rien ne t'empêche de faire un nouveau système, avec tes propres APIs, qui répond au même besoin que celle d'une autre entreprise. Lorsqu'un entreprise vend et supporte un système, elle le fait en toute logique de bout en bout.
    Sauf que Google avait besoin de pouvoir s'appuyer sur une base de code existant. L'énorme majorité des bibliothèques qui constituent l'écosystème Java n'appartiennent pas a Oracle. Google n'a pas de raison de ne pas vouloir en profiter. C'est bon que Oracle ne puisse pas avoir la main mise l'écosystème Java entier.

    Le succès d'un écosystème c'est pas que sa qualité, c'est surtout arriver au bon moment. Pouvoir faire des implémentations compatible permet d'éviter qu'une entreprise profite indûment d'une position de rente.
    S'il suffisait de faire une bonne API pour qu'elle soit massivement utilisée, Google ne se serait pas gêné, ça fait longtemps que l'on sait ce qui ne va pas dans l'API Java et qui mériterait d'être revu. D'ailleurs dans l'API Java elle même, Oracle en est à sa seconde itération des API des gestion du JavaScript, du Client HTTP, du réseau, sa troisième en ce qui concerne la gestion des dates, ... Chaque fois en conservant l'API précédente car même Oracle ne peut pas se permettre de se couper de l'écosystème existant.

  3. #423
    Membre éprouvé
    Je ne suis effectivement pas très au point des lois anglo-saxonnes, cependant j'ai effectivement entendu parler du Fair-Use, notamment de la part des youtubeur français qui maintenant te passe un extrait en 5s de musique en midi avec marquer dessus "ceci est un extrait libre de droit"


    La cohérence peut en effet demander du travail, par contre le nombre d'utilisateur ne change rien a la complexité de la tache.
    Au contraire la possibilité de faire une implémentation compatible d'une bibliothèque permet d’éviter de se retrouver piégé par une société qui bloque les possibilités d'évolution en abusant de sa position dominante.
    [ ... ]
    Sauf que Google avait besoin de pouvoir s'appuyer sur une base de code existant. L'énorme majorité des bibliothèques qui constituent l'écosystème Java n'appartiennent pas a Oracle. Google n'a pas de raison de ne pas vouloir en profiter. C'est bon que Oracle ne puisse pas avoir la main mise l'écosystème Java entier.

    Le succès d'un écosystème c'est pas que sa qualité, c'est surtout arriver au bon moment. Pouvoir faire des implémentation alternative permet d'éviter qu'une entreprise profite indûment d'une position de rente.
    S'il suffisait de faire une bonne API pour qu'elle soit massivement utilisée, Google ne se serait pas gêné, ça fait longtemps que l'on sait ce qui ne va pas dans l'API Java et qui mériterait d'être revu. D'ailleurs l'API Java d'Oracle lui même en est à sa seconde itération des API des gestion du JavaScript, du Client HTTP, du réseau, sa troisième en ce qui concerne la gestion des dates, ... Chaque fois en conservant l'API précédente car même Oracle ne peut pas se permettre de se couper de l'écosystème existant.
    Je suis effectivement d'accord sur ce que tu dis, cependant de l'autre côté, on peux aussi regarder ce qu'a fait google avec Androïd.

    Un juge peut avoir une vue différente, et ce avec de bonnes raisons.

  4. #424
    Membre extrêmement actif
    Citation Envoyé par forthx Voir le message
    c'est un peut comme si je développais un navigateur qui respecte la norme et qui exécute du angular nativement: google pourrait me dire que je n'ai pas le droit car l'api angular est sa propriété ...

    ou a plus bas niveau, si je fait un processeur compatible X86 car c'est intel qui a défini le jeux d'instruction. (ils on pas vendu des droits d'exploitation de l' "API" x86 d’ailleurs ?)
    Pour le libre, on a déjà pas mal d'API dispos, ca voudrait dire qu'un logiciel propriétaire n'a pas de droit de se substituer a un logiciel libre si il présente la même API
    Angular est distribué sous licence MIT qui permet la copie, la modification, la distribution, la revente, donc rien ne t'en empêche.
    De même les licences des produits open-source autorisent la copie, la modification, la revente d'où les forks sans fin. L'inverse n'est pas vrai.

    AMD dispose d'une licence pour l'utilisation du jeu d'instruction X86, et tout ce qui date du 486 et antérieur est libre. Par contre cloner un jeu d'instruction plus récent réclame de prendre une licence auprès d'Intel et d'AMD.

    Citation Envoyé par walfrat Voir le message
    a seule différence à mes yeux, c'est que à la base Java était gratuit et pas la propriété d'Oracle, de plus même après Oracle n'a pas écrit seul les spécifications de Java (cf reprise de Jodatime par exemple), et donc les APIs qui en découlent.
    Gratuit ne veut pas dire libre.

    Citation Envoyé par Uther Voir le message
    Tout a fait car les situations sont foncièrement différentes.
    Je ne parlais pas des situations mais du principe de procès. Et du fait que Sun défende sa marque.

    Citation Envoyé par Uther Voir le message
    Dans un cas on a une implémentation incompatible qui revendiquait le nom Java. Le procès concernait l'utilisation de la marque déposée Java, pas le fait de refaire une implémentation, chose que Sun encourageait a l'époque.
    Dans l'autre cas, on a une implémentation à laquelle on veut interdire d'être compatible. Le procès ne concerne pas la marque Java (que Google n'utilise pas) mais le droit de faire une implémentation compatible.
    Le conflit ne porte pas sur l'interdiction de la compatibilité de l'implémentation mais sur le fait qu'Android prenne une licence, comme l'on fait Blackberry, Nokia, et sans doute IBM a l'époque.
    En outre l'implémentation n'est pas compatible, je ne peux pas prendre une classe java et la déposer sur un système Android.

    Par contre, je peux prendre un code source Java et le recompiler pour Android, parce que Google a copié l'API Java justement.

    Citation Envoyé par Uther Voir le message
    Justement la culture d'entreprise de Microsoft a complètement changé depuis l'époque.
    Certainement. Pourquoi ne publient-ils pas Windows et Sql Server en open-source alors ?

    Citation Envoyé par Uther Voir le message
    Désolé mais je ne peux pas prendre en compte l'avis de toutes les personne qui se sont expimées sur le sujet, dont certaine sont en plus complètement parti pris. Je dis juste que le fait de pouvoir faire une implémentation compatible d'une bibliothèque est quelque chose qui a toujours été admis en informatique jusqu'a présent, et que interdire ça aurait des implications énormes.
    Les lésés n'ont pas droit d'exprimer leur avis. Par contre, un petit juge programmant en python sous Ubuntu est plus qualifié qu'un architecte système gérant des dizaines de programmeur, quand bien même son jugement a été cassé.

    Citation Envoyé par Uther Voir le message
    Les royalties de ARM reposent sur des brevets qui couvrent l'architecture complète du processeur.
    Comme il ne s'agit pas de copyright les lois ne s'appliquent pas. Cela dit si on refaisait un processeur avec un jeu d'instruction compatible mais une architecture générale différente, ça ne me choquerait pas.
    Alors cela ne me choquerait pas non plus qu'un concurrent copie votre code source sans autorisation expresse et livre une solution 100% interopérable et 10 fois moins chère.
    La joie de l'âme est dans la planification -- Louis Hubert Liautey

  5. #425
    Expert éminent sénior
    Citation Envoyé par ddoumeche Voir le message
    Je ne parlais pas des situations mais du principe de procès. Et du fait que Sun défende sa marque.
    Bien sur qu'une société va défendre tout ce qui peut lui rapporter, mais il y a le cadre de la loi pour dire jusqu’où elle peut aller. Justement dans le procès Microsoft l'objet du litige était la marque Java, là ou dans le procès actuel, l'objet du litige n'est la marque mais l'interface de la bibliothèque standard.

    Citation Envoyé par ddoumeche Voir le message
    Le conflit ne porte pas sur l'interdiction de la compatibilité de l'implémentation mais sur le fait qu'Android prenne une licence, comme l'on fait Blackberry, Nokia, et sans doute IBM a l'époque.
    Pour le moment, dans le domaine du logiciel, on ne prend pas une licence pour produire une bibliothèque avec une API compatible. Si Nokia, Blackberry, ... ont acheté une licence, c'est pour pouvoir utiliser l'intégralité du code source (pas uniquement l'API) de l'implémentation de Sun de la JVM.

    Citation Envoyé par ddoumeche Voir le message
    En outre l'implémentation n'est pas compatible, je ne peux pas prendre une classe java et la déposer sur un système Android.
    Par contre, je peux prendre un code source Java et le recompiler pour Android, parce que Google a copié l'API Java justement.
    Il y a deux niveau de compatibilité pour les bibliothèques : ABI et API. Android n'offre pas en effet une compatibilité binaire (ABI compatibility) mais une compatibilité des sources (API compatibility).

    Citation Envoyé par ddoumeche Voir le message
    Certainement. Pourquoi ne publient-ils pas Windows et Sql Server en open-source alors ?
    J'ai pas dit que Microsoft étaient devenu des philanthropes. Juste que la culture générale surtout vis à vis des technologies concurrente à bien changé.

    Citation Envoyé par ddoumeche Voir le message
    Les lésés n'ont pas droit d'exprimer leur avis.
    Les personnes qui s'estiment lésés ont le droit de donner leur avis mais il ne faut pas oublier qu'il sont parti pris, et c'est le rôle des juges de déterminer dans quelle mesure il est recevable vis a vis de la loi.

    Citation Envoyé par ddoumeche Voir le message
    Par contre, un petit juge programmant en python sous Ubuntu est plus qualifié qu'un architecte système gérant des dizaines de programmeur, quand bien même son jugement a été cassé.
    Il y a aussi énormément de gens qualifiés techniquement qui ont pris la défense de Google.

    Citation Envoyé par ddoumeche Voir le message
    Alors cela ne me choquerait pas non plus qu'un concurrent copie votre code source sans autorisation expresse et livre une solution 100% interopérable et 10 fois moins chère.
    Sauf que ce n'est pas ce qui ce joue dans ce procès. Il ne s'agit pas de l'intégralité du code source mais juste l'interface de la bibliothèque.

  6. #426
    Chroniqueur Actualités

    API Java : Google et Oracle seront entendus à la Cour suprême ce mercredi 7 octobre 2020
    API Java : Google et Oracle seront entendus à la Cour suprême ce mercredi 7 octobre 2020,
    dans l'épisode final d'une affaire qui pourrait avoir de lourdes conséquences sur l'industrie du développement logiciel

    Mercredi le 7 octobre 2020, la Cour suprême entendra des plaidoiries dans l'une des décisions les plus importantes de la décennie en matière de droits d'auteur sur les logiciels : trancher sur les conclusions de 2018 d'une cour d'appel selon lesquelles Google a violé les droits d'auteur d'Oracle lorsque Google a créé une implémentation indépendante du langage de programmation Java. Plus largement, l'affaire pourrait décider du statut de copyright des interfaces de programmation d'application, avec d'énormes implications pour l'industrie du logiciel.

    Une interface de programmation d'application est le ciment qui unit les systèmes logiciels complexes. Jusqu'en 2014, il était largement admis que personne ne pouvait utiliser la loi sur le droit d'auteur pour restreindre l'utilisation des API : une perspective qui a favorisé l'interopérabilité des logiciels.

    Puis, en 2014, le Federal Circuit Appeals Court a rendu une décision explosive en décidant le contraire. Pour le contexte, Oracle avait poursuivi Google, arguant que Google avait violé les droits d'auteur d'Oracle en ré-implémentant des API à partir du langage de programmation Java. Depuis, l'affaire fait son chemin devant les tribunaux, le Federal Circuit Appeals Court étant parvenu à une deuxième décision controversée en 2018.

    « L'approche du Federal Circuit va bouleverser l'attente de longue date des développeurs de logiciels selon laquelle ils sont libres d'utiliser les interfaces logicielles existantes pour créer de nouveaux programmes informatiques », a écrit Google dans sa pétition de 2019 demandant à la Cour suprême d'entendre l'affaire.

    James Grimmelmann, spécialiste du droit d'auteur à l'Université Cornell et ancien développeur de logiciels, est d'accord avec cela. « La décision du Circuit fédéral menace la vitalité continue de l'innovation logicielle », a-t-il déclaré en 2019.

    Si les API peuvent être restreintes par le droit d'auteur, alors chaque programme informatique important pourrait être un véritable champ de mines prêtes à exploser devant les tribunaux. Grimmelmann prévient que les droits d'auteur d'API pourraient facilement donner lieu à des trolls d'API : les entreprises qui acquièrent les droits d'auteur d'anciens logiciels, puis poursuivent les entreprises qui ont construit leur logiciel en utilisant ce qu'elles supposaient être des normes ouvertes. Les droits d'auteur des API pourraient également entraver l'interopérabilité entre les plateformes logicielles, car les entreprises seront obligées de créer leurs logiciels en utilisant des normes délibérément incompatibles pour éviter des tracasseries juridiques.

    Les éditeurs de logiciels et les groupes de droits numériques ont présenté ces arguments au Federal Circuit à deux reprises (une fois en 2014 et de nouveau en 2018) sans succès. Aujourd’hui, les avocats de Google auront l'occasion de persuader la Cour suprême que le Federal Circuit s'est trompé. Les enjeux sont importants, à la fois pour Google et Oracle en particulier, mais également pour l'industrie du logiciel au sens large.


    Google évoque un cas des années 1990 concernant les menus de feuilles de calcul

    Le Federal Circuit a rendu deux décisions majeures dans la bataille juridique de Google avec Oracle, et il s'est rangé du côté d'Oracle à deux reprises. Dans la première décision, le Federal Circuit a annulé une décision de jugement selon laquelle les API ne pouvaient pas être protégées par le droit d'auteur. L'affaire a ensuite été renvoyée au tribunal de première instance pour décider si l'utilisation de l'API par Google était autorisée par un usage loyal.

    Le tribunal de première instance (sous la direction du même juge averti en technologie qui avait précédemment statué que les API ne devraient pas du tout être protégées par des droits d'auteur) a décidé que l'utilisation de Google était équitable. Oracle a fait appel et, en 2018, le Federal Circuit s'est de nouveau rangé du côté d'Oracle, décidant que l'utilisation de Google n'était pas juste.

    Un principe fondamental de la législation sur le droit d’auteur est que la protection des œuvres de création ne s’étend à aucune « idée, procédure, processus, système, méthode de fonctionnement » contenu dans l’œuvre. C'est la raison, par exemple, pour laquelle les agences de presse sont libres de se rapporter mutuellement. Pour être plus précis, le texte d'un article de presse est protégé par le droit d'auteur, mais n'importe qui est libre de décrire l'information contenue dans un article de presse dans ses propres mots.

    Cette ligne entre une idée et son expression est particulièrement cruciale pour les logiciels. L'un des cas les plus importants en l'espèce était Lotus c. Borland. Au début des années 1990, Lotus a poursuivi Borland, accusant la société d'avoir déchiré la structure des menus du logiciel de feuille de calcul Lotus 1-2-3 dans le propre tableur Quattro de Borland.


    Transition vers Quattro

    Pour aider les utilisateurs expérimentés de Lotus 1-2-3 à faire la transition vers Quattro, Borland avait inclus une interface d'émulation Lotus (une version du logiciel qui dupliquait précisément la structure de menu de Lotus 1-2-3). Lotus a soutenu que cette copie servile violait ses droits d'auteur, et le tribunal de première instance a rendu un verdict en sa faveur.

    Mais la Cour d'appel du premier circuit n'était pas d'accord. Dans une décision historique de 1995, la cour d'appel s'est rangée du côté de Borland, jugeant que la structure des menus Lotus était une « méthode de fonctionnement » (et donc en dehors de la protection du droit d'auteur).

    « Nous pensons que le "mode de fonctionnement" fait référence aux moyens par lesquels une personne fait fonctionner quelque chose, que ce soit une voiture, un robot culinaire ou un ordinateur », a estimé le tribunal. « La hiérarchie des commandes de menu Lotus fournit les moyens par lesquels les utilisateurs contrôlent et utilisent Lotus 1-2-3 ».

    Notamment, la hiérarchie des menus n'était pas seulement l'interface utilisateur de Lotus 1-2-3; c'était une API primitive à part entière. Lotus 1-2-3 permettait aux fonctions de menu d'être appelées à l'aide des raccourcis clavier de ses menus. Une séquence de touches peut être enregistrée sous forme de macro, essentiellement un simple programme informatique. La duplication de la hiérarchie des menus Lotus 1-2-3 permettait aux utilisateurs d'utiliser leurs anciennes macros Lotus 1-2-3 sur Quattro sans modification.

    Google fait valoir que la logique de la décision Lotus de la Cour d'appel du premier circuit peut être appliquée directement à son différend avec Oracle. Selon Google, les appels d'API Java sont des « méthodes de fonctionnement » pour la plateforme Java exactement de la même manière que les éléments de menu de Lotus 1-2-3 étaient des méthodes de fonctionnement pour le logiciel de tableur.

    Le problème pour Google est que toutes les cours d'appel n'ont pas suivi l'approche du premier circuit dans l’affaire Lotus. La Cour suprême a en fait accepté d'entendre un appel de la décision Lotus dans les années 1990, mais, avec un juge absent de l'affaire, l’affaire a été bloquée en Haute Cour (quatre juges penchaient en faveur de Lotus et quatre juges penchaient en la faveur de Quatro). Un résultat qui a permis de faire prévaloir la décision de la cour inférieure, mais qui n’était pas suffisant pour rendre la décision contraignante pour les autres cours d'appel. Depuis lors, d'autres cours d'appel ont développé des approches différentes qui ne sont pas forcément bien alignées avec le précédent Lotus.


    Les API protégées par des droits d'auteur pourraient provoquer le chaos dans l'industrie du logiciel

    Bien que les tribunaux n'aient pas été unanimes sur la meilleure façon d'appliquer la loi sur le droit d'auteur aux API (et ne l’étaient d’ailleurs pas avant les premières décisions dans l’affaire opposant Oracle à Google), les pratiques de l'industrie du logiciel étaient assez bien établies avant que le Federal Circuit ne soit impliqué. Cela signifie que les enjeux de cette affaire sont assez élevés. Si le raisonnement du Federal Circuit est maintenu, il pourrait forcer des changements dramatiques dans la façon dont l'industrie du logiciel est organisée.

    Il est courant que les développeurs de logiciels clonent les fonctionnalités des plateformes et des normes logicielles établies afin de s'assurer que leurs nouveaux produits sont compatibles avec ce qui existe déjà. Parfois, ce logiciel compatible est ensuite emballé dans des bibliothèques open source qui deviennent libres d'utilisation par d'autres, et il peut être combiné avec d'autres programmes pour produire des progiciels plus volumineux. Parce qu'il a été largement admis que les API ne peuvent pas être protégées par des droits d'auteur (ou du moins que les droits d'auteur ne sont pas susceptibles d'être appliqués) les entreprises ne se soucient pas d'utiliser des bibliothèques qui tirent parti d'API tierces qui pourraient appartenir à quelqu'un d'autre .

    Les décisions Oracle du Federal Circuit signifient qu'il peut y avoir beaucoup de logiciels qui sont soudainement vulnérables aux réclamations pour violation de droits d'auteur parce qu'ils implémentent des API produites par des tiers.

    Grimmelmann note que cela pourrait être un problème particulièrement grave dans le monde du cloud computing. « Si vous avez construit un service cloud, que dles gens ont écrit des clients et qu’un individu déclare 'nous détenons un droit d'auteur sur le rassemblement des arguments de cette fonction de cette façon', vous êtes foutu », a-t-il déclaré en 2019. « Vous ne pouvez pas changer cette API sans perdre de clients. Les possibilités de hold-up sont immenses ».

    À long terme, soumettre les API à des restrictions de droits d'auteur pourrait également conduire à une balkanisation des normes logicielles. Méfiant à adopter des API appartenant à des rivaux, les entreprises seront plus susceptibles de développer leurs propres versions incompatibles de normes clés. Un amicus curiae déposé devant la Cour en 2018 par trois groupes de l'industrie du logiciel (Engine, App Alliance et GitHub) souligne que cela pourrait être particulièrement préjudiciable aux petits éditeurs de logiciels qui n'ont pas les ressources pour réimplémenter leurs produits en utilisant plusieurs normes incompatibles.

    Et l'amicus curiae de 2018 de la Computer and Communications Industry Association souligne que cela pourrait également devenir un fardeau important pour la profession du développement de logiciels. Maîtriser un langage tel que Java nécessite beaucoup de temps et d'efforts. CCIA souligne qu'en essayant d'empêcher les implémentations indépendantes de Java, Oracle limite essentiellement les opportunités pour les développeurs Java. « Il est difficile de voir pourquoi les développeurs qui ont appris les API Java devraient rester captifs d'Oracle en raison d'un investissement dans l'apprentissage effectué par les développeurs et non par Oracle », a écrit CCIA.


    Supreme court of the United States : Google v. Oracle America


    Source : Cour suprême, Google
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  7. #427
    Membre du Club
    Droits d'auteur sur les API: du pur délire
    Citation Envoyé par Stéphane le calme Voir le message
    API Java : Google et Oracle seront entendus à la Cour suprême ce mercredi 7 octobre 2020,

    Si les API peuvent être restreintes par le droit d'auteur, alors chaque programme informatique important pourrait être un véritable champ de mines prêtes à exploser devant les tribunaux. Grimmelmann prévient que les droits d'auteur d'API pourraient facilement donner lieu à des trolls d'API : les entreprises qui acquièrent les droits d'auteur d'anciens logiciels, puis poursuivent les entreprises qui ont construit leur logiciel en utilisant ce qu'elles supposaient être des normes ouvertes. Les droits d'auteur des API pourraient également entraver l'interopérabilité entre les plateformes logicielles, car les entreprises seront obligées de créer leurs logiciels en utilisant des normes délibérément incompatibles pour éviter des tracasseries juridiques.
    Je crois urgent de breveter l'utilisation de l'eau comme solvant.

    Selon ORACLE et le Federal Circuit, je comprends que les droits sur des API appartiendraient aux premiers qui ont dégainé.
    Par suite, Java fourmille de plagiats.
    Un seul exemple:
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    public class Nom_du_programme {
       public static void main (String args[]){
       	System.out.println("Hello World");
     
       }
    }


    • utilisation de parenthèses pour passer des arguments
    • de virgules pour séparer les arguments
    • de guillemets pour définir une string
    • utilisation de points pour décliner une hiérarchie
    • de crochets, de points virgules ...



    tout ça odieusement volé à des langages prédécesseurs .

    Le grand malheur avec les juridictions US est le critère n°1 est le $, pas le bon sens.

  8. #428
    Membre éprouvé
    Balkanisation, eh ben l'ancien maire de lavallois-perret a encore de beaux jours devant lui. J'espère qu'il ne va pas encore s'en tirer

  9. #429
    Chroniqueur Actualités

    API Java : la Cour suprême des États-Unis a semblé divisée sur la demande de Google
    API Java : la Cour suprême des États-Unis a semblé divisée sur la demande de Google
    de mettre fin à l'action en justice d'Oracle en vertu de la violation des droits d'auteur

    Mercredi, la Cour suprême des États-Unis a semblé divisée alors qu'elle examinait la question de savoir s'il fallait protéger Google d'Alphabet Inc. face à un procès de longue durée intenté par Oracle Corp, l'accusant d'avoir enfreint les droits d'auteur d'Oracle lorsque Google a créé une implémentation indépendante du langage de programmation Java.

    Durant une session téléphonique dans l'un des plus grands combats de l'industrie du logiciel dans l'histoire américaine, les juges ont remis en question mercredi l'affirmation de Google selon laquelle il n'avait aucun moyen de reproduire le code sans forcer des millions de développeurs de logiciels à apprendre un nouveau langage de programmation. Le juge Neil Gorsuch a déclaré à l'avocat de Google qu'Apple Inc. et d'autres entreprises avaient « mis au point des téléphones qui fonctionnent très bien sans se livrer à ce type de copie ». Mais Gorsuch a également évoqué la possibilité de renvoyer l'affaire devant une cour d'appel fédérale pour un nouvel examen de l'affirmation de Google selon laquelle il se livrait à une « utilisation équitable » légitime du langage de programmation Java d'Oracle.

    Certains des huit juges se sont dits préoccupés par le fait que Google copiait simplement le code logiciel d'Oracle au lieu d'innover et de créer le sien pour les appareils mobiles. D'autres ont souligné que se ranger du côté d'Oracle pourrait donner aux développeurs de logiciels trop de pouvoir avec des effets potentiellement néfastes sur l'industrie de la technologie.

    Un jury a blanchi Google en 2016, mais la Cour d'appel des États-Unis pour le circuit fédéral a annulé cette décision en 2018, estimant que l'inclusion par Google du code logiciel d'Oracle dans Android n'était pas autorisée en vertu de la loi américaine sur les droits d'auteur. Oracle a accusé Google de copier des milliers de lignes de code informatique à partir de son populaire langage de programmation Java sans licence afin de développer Android, une plateforme concurrente qui a nui aux activités d'Oracle.

    De nombreuses analogies

    L'avocat de Google, Thomas Goldstein, a déclaré aux juges que le code Java contesté ne devrait pas bénéficier de la protection des droits d'auteur, car c'était « le seul moyen » de créer de nouveaux programmes en utilisant le langage de programmation. « Le langage nous permet seulement de les utiliser », a déclaré Goldstein.

    Le juge en chef John Roberts a suggéré que Google aurait encore dû payer Oracle pour une licence Java, comparant la situation à celle d'un cambrioleur : « Casser un coffre-fort pourrait être votre seul moyen d'obtenir l'argent que vous voulez, mais cela ne signifie pas que vous êtes autorisés à le faire », a déclaré Roberts. « Si vous avez estimé qu'il s'agissait du seul moyen, alors vous deviez obtenir une licence.»

    Le juge Neil Gorsuch a demandé à Goldstein si Google s'était simplement appuyé sur l'innovation d'Oracle : « Que faisons-nous du fait que les autres concurrents, Apple, Microsoft et autres ont, en fait, été en mesure de proposer des téléphones qui fonctionnent très bien sans s'engager dans ce type de copie ? »

    Google a déclaré que les commandes de raccourci copiées dans Android ne garantissaient pas la protection des droits d'auteur, car elles aidaient les développeurs à écrire des programmes fonctionnant sur plusieurs plateformes, une clé de l'innovation logicielle.

    Les échanges devaient durer une heure, mais ont duré plus de 90 minutes pendant lesquelles les juges ont fait des analogies avec des menus de restaurants, des équipes de football et des machines à écrire.


    La juge Sonia Sotomayor a suggéré qu'elle était plus sympathique à Google. Elle a demandé à l’avocat d’Oracle, Joshua Rosenkranz, pourquoi le tribunal « devrait maintenant bouleverser ce que l’industrie considère comme les éléments protégés par le droit d’auteur » du code informatique.

    Des entreprises technologiques telles que Mozilla Corp., Microsoft Corp.et International Business Machines Corp. ont soutenu Google dans cette affaire, affirmant que les développeurs de logiciels ont besoin de la liberté de créer de nouvelles plateformes et des programmes capables de communiquer avec la technologie et les appareils existants sans craindre de faire face à la responsabilité du droit d'auteur.

    Les entreprises de médias et de divertissement ont soutenu Oracle parce que leurs industries reposent sur des normes de droits d'auteur strictes. La Motion Picture Association, qui représente les studios Walt Disney, Sony Pictures Entertainment et Netflix Inc., et la News Media Alliance, qui représente des organes de presse tels que le New York Times et News Corp., figuraient parmi les organisations commerciales qui ont déposé des amicus curia dans l'affaire.

    L'administration Trump soutient également Oracle.


    Le cas est centré sur des instructions pré-écrites appelées interfaces de programme d'application, ou API, qui fournissent des instructions pour des fonctions telles que la connexion à Internet ou l'accès à certains types de fichiers. En utilisant ces raccourcis, les développeurs n'ont pas à écrire du code à partir de zéro pour chaque fonction de leur logiciel ni à le modifier pour chaque type d'appareil.

    Oracle affirme que les API Java sont disponibles gratuitement pour ceux qui souhaitent créer des applications qui s'exécutent sur des ordinateurs et des appareils mobiles. Mais la société affirme qu'elle a besoin d'une licence pour utiliser les raccourcis d'une plateforme concurrente ou pour les intégrer dans un appareil électronique.

    Menace existentielle

    Oracle estime que Google faisait face à une menace existentielle parce que son moteur de recherche, la source de ses revenus publicitaires, n'était pas utilisé sur les smartphones. Google a acheté le système d'exploitation mobile Android en 2005 et a copié le code Java pour attirer les développeurs, mais a refusé de prendre une licence, soutient Oracle.

    Google soutient que la décision de la cour d'appel rendrait plus difficile l'utilisation des interfaces pour développer de nouvelles applications.

    Selon Google, les interfaces logicielles sont catégoriquement inéligibles à la protection des droits d'auteur. La société indique également que la cour d'appel a limité la défense « d'usage équitable » au point de rendre impossible pour un développeur la réutilisation d'une interface dans une nouvelle application.

    Android a généré 42 milliards de dollars pour Google entre 2007 et 2016, selon les archives judiciaires d'Oracle.

    La Cour suprême avait prévu d'entendre les arguments en mars 2020, mais a annulé cette session à cause de la pandémie de COVID-19.

    Cour suprême

    Source : plaidoyers des deux entreprises (vidéo dans le texte)
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  10. #430
    Membre éprouvé
    C'est délicat comme situation. C'est comme un fabricant de robinet, on est bien obligé de le copier si on veut que les tuyaux prévus s'y adaptent.

    Doit on payer le créateur du robinet ? pour pouvoir faire l'embout du tuyau qui pourra s'adapter dessus.
    Et ensuite ? celui qui fait le robinet ne vendra peut être plus d'embout car les miens sont moins chers...Et au final celui qui a créé le produit se retrouve avec des copies qui seront moins chères.

    Moi je dis que ce n'est pas évident. Dans le cas d'Oracle je me sentirais spolié.

  11. #431
    Membre actif
    Le problème de Oracle, ce n'est pas Google, c'est leur politique qui consiste à presser le citron client au détriment de l'innovation.

    Leur cœur de métier, c'est la BDD, c'est même Oracle qui a inventé la BDD.

    Seulement, la BDD oracle est la plus chère. Pire, quand on prend une licence Oracle, il faut prévoir les futurs frais d'avocats, car ils ont une tendance à être malhonnête sur les options.
    Et ça peut vite finir en procès.

    Et pendant qu'ils sont occupés à presser le citron client, les concurrents sont moins chers et meilleurs sur le cœur de métier.
    https://blog.developpez.com/sqlpro/p...-la-difference

    La différence entre Larry Ellison et Dieu, c'est que Dieu ne se prend pas pour Larry Ellinson.

  12. #432
    Membre éclairé
    Et puis Java commence à lassé , surtout avec des technologies équivalentes comme Python et javascript qui font peu ou prou les mèmes chose en open source , mème C++ a bougé !

  13. #433
    Membre du Club
    j'ai l'impression qu'Oracle n'a pas retenue la lecon/fessé d'openJDK...

    du coup... on continue a dev en java ou pas ?

  14. #434
    Expert éminent sénior
    Citation Envoyé par darklinux Voir le message
    Et puis Java commence à lassé , surtout avec des technologies équivalentes comme Python et javascript qui font peu ou prou les mèmes chose en open source , mème C++ a bougé !
    Java est open-source et n'est pas vraiment équivalent a JavaScript ou Python notamment à cause de son typage bien plus strict.

    Citation Envoyé par foxzoolm Voir le message
    j'ai l'impression qu'Oracle n'a pas retenue la lecon/fessé d'openJDK...
    Quelle fessée ? L'OpenJDK marché plutôt bien et reste un produit contrôlé par Oracle.

  15. #435
    Membre éprouvé
    Citation Envoyé par darklinux Voir le message
    Et puis Java commence à lassé , surtout avec des technologies équivalentes comme Python et javascript qui font peu ou prou les mèmes chose en open source , mème C++ a bougé !
    Heu, Java et tout l'écosystème autour est l'exemple même de la réussite de l'open source.

    Et quand on veut faire des trucs qui marchent, on prend pas des trucs "fun et pas lassant", on prend même l'opposé, des trucs qui sont là depuis assez longtemps pour avoir été éprouvé et avoir suffisamment d'expérience dessus.

    @archiqt : +1 sur la remarque, j'ajouterais cependant que les tailles de tuyauteries sont standardisés ils me semblent, du fait ces tailles n'appartiennent à personnes.

  16. #436
    Chroniqueur Actualités

    La confrontation de Google et d'Oracle devant la Cour suprême ne s'est pas très bien passée pour Google
    La confrontation de Google et d'Oracle devant la Cour suprême ne s'est pas très bien passée pour l'éditeur d'Android,
    les juges de la Cour suprême semblent prêts à autoriser les droits d'auteur sur les API

    Rappelons que la Cour suprême est constituée de neuf juges, mais que la juge Ruth Bader Ginsburg est décédée le 18 septembre 2020, à six semaines de l'élection présidentielle. Son siège n'a pas encore été remplacé.

    Mercredi, certains des huit juges de la Cour suprême semblaient sceptiques quant à l'argument de Google selon lequel les interfaces de programmation d'application (API) ne sont pas protégées par la loi sur le droit d'auteur. La haute cour entendait des plaidoiries dans le cadre de la bataille juridique de Google avec Oracle, qui a déjà duré dix ans. Oracle fait valoir que Google a enfreint ses droits d'auteur sur le langage de programmation Java lors de la réimplémentation des API Java à l'usage des développeurs d'applications Android.

    Les enjeux de cette affaire sont importants pour Google, qui pourrait devoir à Oracle des milliards de dollars de dommages et intérêts. Plus important encore, une victoire d'Oracle pourrait remodeler la façon dont la loi sur le droit d'auteur traite les API, donnant aux titulaires le pouvoir de verrouiller les concurrents qui souhaitent créer des logiciels compatibles.

    Pendant des décennies avant le procès d'Oracle, la plupart des gens de l'industrie du logiciel supposaient que les API ne pouvaient pas être protégées par le droit d'auteur. Cela signifiait qu'un éditeur de logiciels pouvait réimplémenter les API du produit d'un concurrent afin de permettre à un logiciel, conçu pour fonctionner avec le produit du concurrent, de fonctionner avec le sien.

    Une victoire pour Oracle remettrait cela en question. Cela ne générerait pas seulement du travail supplémentaire pour les juristes du droit d'auteur, cela pourrait conduire à un monde où les problèmes de compatibilité des logiciels surgissent plus souvent dans la vie quotidienne. Cela pourrait également affecter directement les moyens de subsistance des développeurs, qui pourraient se trouver être plus fréquemment obligés d'apprendre de nouveaux langages de programmation ou d’apprendre à utiliser d'autres outils logiciels lorsqu'ils changent d'emploi.

    Il est toujours risqué d'extrapoler à partir des plaidoiries de la Cour suprême. Parfois, les juges posent des questions plus difficiles à un parti, mais se prononcent de toute façon en faveur de ce parti. Mais au vu du déroulement des échanges, il est difficile d’imaginer une majorité de cinq juges acceptant l'argument de Google selon lequel les API ne peuvent pas être protégées par le droit d'auteur. Si Google gagne, il semble que ce soit pour des raisons plus restreintes (des raisons qui ouvriraient la porte à davantage de poursuites en matière de droits d'auteur sur les API à l'avenir). Quoi qu’il en soit, il semble y avoir de bonnes chances qu'Oracle l'emporte.


    Des juges qui se montrent sceptiques

    Au milieu des années 2000, Google savait qu'il aurait besoin de beaucoup de développeurs pour créer des applications pour sa prochaine plateforme Android. Pour accélérer le processus, Google a réimplémenté le langage de programmation Java plutôt que de développer un nouveau langage de programmation à partir de zéro. Google a écrit un nouveau code pour exécuter des programmes Java selon les spécifications exactes du logiciel Java officiel de Sun (Oracle a par la suite acquis Sun). Cela a permis à des milliers de développeurs Java existants de devenir des développeurs Android sans avoir à apprendre un nouveau langage.

    Pour réimplémenter Java, Google avait besoin de copier les noms et les types d'arguments de fonctions telles que java.lang.Math.max. Sinon, un programme Java utilisant ces fonctions ne fonctionnerait pas sur le système d'exploitation de Google. L'article 102 (b) de la Loi sur le droit d'auteur stipule que personne ne peut protéger « une idée, une procédure, un processus, un système, une méthode de fonctionnement, un concept, un principe ou une découverte ». Google a conclu que des fonctions comme Math.max sont des « méthodes de fonctionnement », car les développeurs « exploitent » la plateforme Java en les invoquant. Par conséquent, Google n'a pas payé de licence à Sun, ce qui a conduit à un procès quelques années plus tard.

    C'est une pratique répandue dans l'industrie du logiciel. Oracle, par exemple, a réimplémenté l'API S3 d'Amazon afin que les clients qui ont créé des logiciels pour la plateforme cloud d'Amazon puissent facilement passer à la plateforme cloud rivale d'Oracle.

    La stratégie d'Oracle tout au long de la bataille juridique, déjà vieille d’une décennie, a été essentiellement de nier qu'il y a quelque chose de spécial dans les API. Selon Oracle, une spécification d'API (essentiellement juste une liste de noms de fonctions et de types d'arguments) est un code informatique qui peut être protégé par copyright comme n'importe quel autre code. Oracle affirme que si les tribunaux suppriment les spécifications API de la protection des droits d'auteur, les avocats pourraient utiliser les mêmes arguments pour affaiblir la protection des droits d'auteur de tout programme informatique.


    Samuel Alito, juge à la Cour suprême

    Le juge Samuel Alito a soulevé cette préoccupation dans sa première question à l'avocat de Google, Thomas Goldstein :

    « Je suis préoccupé par le fait que selon votre argument, tout code informatique risque de perdre sa protection en vertu de 102 (b) », a déclaré Alito. « Comment conciliez-vous votre position avec l'intention expresse du Congrès de protéger les codes informatiques ? »

    La tâche la plus importante de Goldstein ici (et tout au long de l'argumentation de mercredi) était de convaincre les juges qu'il y avait une différence importante entre les API et d'autres codes et que cette différence avait des implications juridiques.

    « Il a fait un travail épouvantable », a commenté après les échanges James Grimmelmann, un juriste de l'Université Cornell. « Au niveau de la nuance dans laquelle il était prêt à entrer, son cas les donnait pour perdants. La seule façon de faire tenir cette argumentation est d'être nuancé sur ce que signifie déclarer du code. »


    Des difficultés pour Google

    La distinction entre un programme et une API a un sens intuitif pour les développeurs qui utilisent régulièrement des API (et écrivent des programmes) dans leur travail quotidien. Mais c'est loin d'être évident pour les juges de la Cour suprême, qui sont tous des avocats de plus de 50 ans.

    Cela aurait peut-être aidé Goldstein d’utiliser des analogies ou des exemples concrets de l'industrie du logiciel pour aider les juges à comprendre la distinction, mais il en a très peu fait. Au lieu de cela, il a répété encore et encore une poignée d'arguments juridiques abstraits. Goldstein n'a jamais semblé trouver une explication du caractère unique des API que les juges ont trouvé convaincante.

    Lorsque le tour du juge Brett Kavanaugh est venu de poser des questions à Goldstein, il était clair que sa pensée n'avait pas été changée par les réponses précédentes de Goldstein. Les avocats d'Oracle, a noté Kavanaugh, « disent que la déclaration de code n'est une méthode de fonctionnement que dans le même sens que les programmes informatiques dans leur ensemble sont des méthodes de fonctionnement, et que par conséquent, votre argument de méthode de fonctionnement engloutirait la protection des programmes informatiques ».

    « Vous n'êtes pas autorisé à copier une chanson simplement parce que c'est la seule façon de copier une chanson », a déclaré Kavanaugh, en prélude de sa question suivante à Goldstein. « Pourquoi ce principe ne s’applique pas ici? »

    En somme, Kavanaugh ne semblait absolument pas convaincu qu'il y avait quelque chose de distinctif dans les API qui justifierait un traitement différent en vertu de la loi sur le droit d'auteur.


    Brett Kavanaugh, juge à la Cour suprême

    Le juge Clarence Thomas semblait tout aussi impassible. À un moment donné, il a comparé les actions de Google à une équipe de football prenant le livre de jeu d'un rival. Le juge Neil Gorsuch a noté que « d'autres concurrents ont été en mesure de proposer des téléphones qui fonctionnent très bien sans se livrer à ce type de copie ».

    Il y avait donc au moins quatre juges (Kavanaugh, Alito, Thomas et Gorsuch) qui semblaient sceptiques quant à la position de Google selon laquelle les API ne peuvent pas être protégées par le droit d'auteur. Si les quatre votaient pour Oracle, le meilleur que Google puisse espérer est une égalité. Une égalité serait toujours une perte pour Google, car elle laisserait en place la victoire d'Oracle au niveau de l'appel, mais ne créerait pas de précédent à l'échelle nationale. Si Google perd une décision de justice supplémentaire, cela créerait un précédent national en faveur des droits d'auteur des API.

    Une entreprise qui n'était pas entièrement antipathique à la Cour ?

    Google n'était pas entièrement sans défenseurs sur le terrain. En fait, quelques juges ont fait un meilleur travail en exprimant la position de Google que son propre avocat.

    « C'est comme le clavier QWERTY », a déclaré Breyer dans une question à l'avocat d'Oracle. « Vous n'aviez pas besoin d'un clavier QWERTY sur les machines à écrire au début. Mais mon Dieu, si vous laissez quelqu'un avoir un droit d'auteur là-dessus maintenant, il contrôlerait toutes les machines à écrire, ce qui n'a vraiment rien à voir avec le droit d'auteur. »

    Tout comme un droit d'auteur QWERTY bloquerait les dactylographes sur l’utilisation des machines à écrire d'une entreprise particulière, a suggéré Breyer, un droit d'auteur sur les API Java bloquerait les développeurs qui ont appris Java sur des implémentations Java sous licence Oracle.


    Sonia Sotomayor, juge à la Cour suprême

    Dans une autre question adressée à l'avocat d'Oracle, la juge Sonia Sotomayor a offert l'explication la plus claire sur les enjeux de l'affaire. Voici l'un de ses commentaires :

    « Dans votre déclaration de départ, vous aviez dit que le ciel vous tomberait sur la tête si nous nous prononcions en faveur de Google. Le problème avec cet argument pour moi, c'est qu'il semble que depuis 1992, [les tribunaux ont dit que] l'interface de programmation d'application, dont le code de déclaration fait partie, n'est pas protégée par le droit d'auteur. Par contre, les codes de mise en œuvre le sont.

    « Sur cette base, les industries se sont construites sur des applications en sachant qu'elles ne peuvent copier que ce qui est nécessaire pour s'exécuter sur l'application, mais qu’elles doivent changer tout le reste. C'est ce que Google a fait ici. C'est pourquoi ils ont pris moins de 1 % du code Java...

    « Tout le monde sait que les API, déclarant des codes, ne sont pas protégées par le droit d'auteur. Les codes de mise en œuvre le sont. Alors s'il vous plaît, expliquez-moi pourquoi nous devrions maintenant revoir ce que l'industrie a considéré comme les éléments protégés par le droit d'auteur, déclarant que certaines sont des méthodes de fonctionnement et d'autres sont des expressions ? »

    L'avocat d'Oracle Joshua Rosenkranz a contesté la prémisse de la question de Sotomayor. « Dans aucun cas, vous ne verrez dire que vous pouvez copier cette grande quantité de code sur une plateforme concurrente pour l'utiliser dans le même but », a-t-il déclaré à Sotomayor. « Personne n'a fait cette distinction entre l'implémentation du code et la déclaration du code. Vous ne trouverez pas un seul cas qui fasse cela ».

    C'était l'une des choses les plus frappantes dans les arguments de mercredi: Oracle et Google ont chacun affirmé que la position de l'autre partie bouleverserait les attentes établies dans l'industrie du logiciel. Selon Grimmelmann, à ce niveau Google avait le meilleur argument ici. Il existe peu de précédents qui se concentrent spécifiquement sur le statut de copyright de la déclaration de code. Mais un certain nombre de cours d'appel ont statué que les interfaces logicielles ne peuvent pas être protégées par le droit d'auteur. Et un grand nombre de projets logiciels ont été construits sur la base de cette compréhension.

    En plus de Breyer et Sotomayor, la juge Elena Kagan a posé quelques questions indiquant qu'elle pourrait être sensible à la position de Google. Mais même si ces trois juges se rangeaient du côté de Google, la société aurait encore besoin de deux votes supplémentaires pour annuler la décision du tribunal inférieur en faveur des droits d'auteur des API.

    Source : plaidoyers des deux entreprises (vidéo dans le texte)
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  17. #437
    Membre du Club
    Un accord de Si bemol n'est pas un blues
    Citation Envoyé par archqt Voir le message
    C'est délicat comme situation. C'est comme un fabricant de robinet, on est bien obligé de le copier si on veut que les tuyaux prévus s'y adaptent.
    Je suis d'accord pour l'adjectif "délicat". Si c'était trivial, les juges n'auraient aucune raison d'intervenir.
    En l'espèce, je trouve que l'exemple "hardware" proposé s'applique mal à la situation, d'autant que le tuyau a certainement précédé le robinet dans la création: le robinet permet d'interrompre ou pas le passage du fluide dans le tuyau.
    • Si le raccordement entre tuyau et le robinet se fait avec un dispositif plus ou moins innovant (filetage, baïonnette, raccord rapide...) il peut s'agir d'une invention, et la protection des droits de précédence se fait par un dépôt de brevet (contestable ou pas).
    • Si le raccordement se fait par un dispositif classique il s'agit de l'état de l'art, et personne en peut se prévaloir du fait que le diamètre du robinet soit x ou y; si un concurrent utilise le même diamètre, c'est le bon sens. Et s'il est plus efficace dans son industrialisation ou son marketing, tant mieux pour lui.
    • Le cas qui pourrait peut être relever du droit d'auteur (selon ma perception du moins) serait que ledit concepteur du robinet ait défini tout ce qui peut se raccorder au robinet (tuyaux, buses, dispositif de sécurité, détendeur...) pour que l'agencement de ces éléments se fasse harmonieusement. De ce point de vue il aura fait preuve de créativité (au même titre qu'un auteur aura écrit un roman, pas donné une liste de personnages, ou qu'un compositeur aura créé une œuvre, pas listé des accords d'accompagnement ).


    Citation Envoyé par archqt Voir le message

    Moi je dis que ce n'est pas évident. Dans le cas d'Oracle je me sentirais spolié.
    Ce n'est donc pas évident. Si effectivement Oracle prouve qu'il a effectivement défini de façon particulièrement pertinente les API et les fonctions assurées, on peut envisager une certaine créativité.
    Mais a défaut, les API ne sont que comme les personnages du roman, ou un accord de guitare. Les accords sont réutilisables à l'envi.
    Ce qui me navre c'est que le débat semble porter sur le fait que les API, par ailleurs publics comme un accord de E#, puissent être envisagés soumis à droit d'auteur. Je n'ai vu nulle part mention d'une quelconque revendication de propriété sur l'articulation des API java. Cette confusion peut conduire aux aberrations juridiques évoquées par plusieurs intervenants.

  18. #438
    Membre chevronné
    Oracle n'est pas l'inventeur de java, il n'a fait que racheter l'entreprise SUN Microsystems et changer la nature de la licence Java.

    Cela pourrait, par ailleurs, aussi valoir des problèmes aux systèmes Linux FreeBSD, OsX et iOs qui ont largement pompé leur base de code sur UNIX.

  19. #439
    Membre extrêmement actif
    Pour l'analogie, breveter une API reviendrait dans le monde réelle à breveter un langage, puisque c'est la façon dont nous pouvons communiquer.
    Est-ce que la façon de communiquer peut être breveter ? Drôle de question à mon avis.
    Alors, oui, la communication est une invention géniale, maintenant si seul 1 ou 2 personnes peuvent l'utiliser, ça me parait perdre pas mal de son intérêt premier .

    Globalement, si les idées de la cour suprême ce démocratise sur ce sujet, on aura plus de possibilités d'interconnexion de systèmes hétérogène, puisque tous les environnement devront devenir propriétaire pour exister.
    Et je ne crois pas que ce soit une bonne nouvelle pour qui que ce soit, Oracle compris.

  20. #440
    Membre chevronné
    Citation Envoyé par defZero Voir le message
    Pour l'analogie, breveter une API reviendrait dans le monde réelle à breveter un langage, puisque c'est la façon dont nous pouvons communiquer.
    Le language de programmation définit une manière de communiquer et des mots clés mais ne formule pas pour toi une ligne réutilisable et copiable. Est-ce que tu peux copier le français ou l'anglais ? Non. Mais tu peux copier n'importe quelle phrase écrite en français.

    Une deuxième chose pour réfuter l'argument selon lequel la méthode Math.max est une méthode de fonctionnement, c'est comme passer son temps à comparer un objet Java avec un objet du monde réel qui partagent seulement le nom. D'autre part l y a une différence entre l'idée du fonctionnement de la méthode max qui prend pour argument deux entier pour retourner un des deux entiers et la classe java.lang.Math.
    Code Java :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    java.lang.Math;
     
    public final class Math extends Object {
    //....... 
    public static int max(int a, int b) {
    } 
    //.... 
    }

    Ceci est du code qui sera compilé, une signature intégrale qui ne pourra jamais se formuler différemment sur le Java d'adroid, et une partie intégrante qui ne se séparera jamais du programme final. Alors en quoi ce programme ne pourra pas être protégé ? Est ce juste une méthode de fonctionnement ou une idée.
    Il ne faut pas mélanger les idées de bon sens sur l'utilisation et l'intérêt de l'industrie du logiciel avec le fait que le code intergral est original.

###raw>template_hook.ano_emploi###