Journal Apple prépare-t'il un coup 'à la Oracle'?

Posté par .
Tags : aucun
8
19
août
2010
Quelqu'un connaîtrait-il la situation des brevets logiciels pris par Apple autour du projet LLVM?

En discutant sur LWN [ http://lwn.net/Articles/399099/ ], j'ai appris qu'Apple avait plusieurs brevets qui pourraient impacter directement LLVM..

J'espère qu'ils ont fait comme IBM et signé une promesse de non-utilisation pour tout les utilisateurs&développeurs de LLVM et dérivés, autrement cela rend le projet *beaucoup* moins intéressant..
  • # To FUD or not to FUD

    Posté par . Évalué à  10 .

    Un universitaire très impliqué dans le développement de GCC (je tairais son nom) m'a donné plusieurs informations un peu dérangeantes vis-à-vis de LLVM :

    1/ Les binaires de LLVM distribués par Apple avec ses outils de développement officiels vient d'un dépôt privé ayant plus de fonctionnalités.

    2/ LLVM fait du mal à la recherche académique et industrielle en génération de code en fragmentant la communauté, et Apple fait difficile rentrer les contributions extérieures tout en développant des fonctionnalités non-essentielles (de son point de vue de chercheur en compilation, évidemment). Grosso-modo, la BSD serait une licence peut adaptée à la formation de communautés saines ou diverses grosses boîtes peuvent contribuer sans craintes ou peur de se tirer dans les pattes, contrairement à la GPL.

    La personne en question est très crédible et à mon sens plutôt objective (elle reconnaît sans peine de nombreux avantages techniques à LLVM).
    • [^] # Re: To FUD or not to FUD

      Posté par (page perso) . Évalué à  1 .

      To FUD or not to FUD

      Surtout une tentative de troll BSD vs GPL que tu nous fais la...
      • [^] # Re: To FUD or not to FUD

        Posté par . Évalué à  10 .

        Libre à vous de me croire ou pas, mais je ne fais que répéter ce qu'on m'a dit, sans même indiquer ce que je pense de ce point précis. Après, je trouve l'argument cité plus intéressant et fertile que le dialogue habituel :

        GNU/Pimprenelle : Vive la GPL, vive la liberté.
        OpenNicolas : Même pas vrai, c'est la BSD qui est vraiment libre, y compris pour les programmeurs.
        GNU/Pimprenelle : Faux, la GPL c'est la liberté de l'utilisateur ! Et puis la liberté de réduire les autres en esclavages n'en est pas une. Et toc !
        OpenNicolas : Même pas vrai, c'est la BSD qui est vraiment libre, [...]

        etc.

        Quand je lis ça pour la 42ème fois, j'ai bien envie de leur savater la gueule, à ces couillons de libristes ! :-)
        • [^] # Re: To FUD or not to FUD

          Posté par . Évalué à  10 .

          Ya pas de troll

          on voit bien à la dernière ligne qu'OpenNicolas n'a plus d'arguments !
        • [^] # Re: To FUD or not to FUD

          Posté par . Évalué à  2 .

          Sauf que justement ici, la licence tombe comme un cheveux sur la soupe. Un projet sous GPL fermé à toute contribution extérieure, c’est possible. Un projet sous GPL avec un dépot privé ayant plus de possibilités, c’est possible aussi, surtout si on refuse les contributions extérieures (dans le cas contraire, il suffit d’imposer un accord de transfert de copyright aux contributeurs. Et qu’on ne me dise pas que c’est impossible, la FSF le fait bien)

          Donc je confirme : trop gros, passera pas.
          • [^] # Re: To FUD or not to FUD

            Posté par (page perso) . Évalué à  7 .

            "Un projet sous GPL avec un dépot privé ayant plus de possibilités"

            pourquoi pas, mais comme ils ont l'obligation de fournir les sources à la demande avec les binaires, ça sert à rien qu'il soit privé.

            j'ai juste là non ?
            • [^] # Re: To FUD or not to FUD

              Posté par . Évalué à  1 .

              Non, car en tant que propriétaires du code ils peuvent le distribuer sous une autre licence, comme le font MySQL et Qt. C’est pour ça que j’ai dit que c’était plus simple en refusant les contributions externes, ou sinon que ça pouvait se faire avec transfert de copyright.
              • [^] # Re: To FUD or not to FUD

                Posté par . Évalué à  6 .

                Heu, non. Si tu distribues des binaires sous GPL et qu'on te demande les sources, tu dois filer les sources sous GPL. Pas sous MonEULA 5.0.
                • [^] # Re: To FUD or not to FUD

                  Posté par (page perso) . Évalué à  3 .

                  Certes, mais justement, en tant que propriétaire du code ils ne sont pas obligés de fournir le binaire sous GPL(d'ailleurs, je ne suis pas certains que ça ait de sens de fournir un binaire sous GPL, cette licence ne s'applique-t-elle pas qu'aux codes sources ?).
                  • [^] # Re: To FUD or not to FUD

                    Posté par . Évalué à  3 .

                    d'ailleurs, je ne suis pas certains que ça ait de sens de fournir un binaire sous GPL, cette licence ne s'applique-t-elle pas qu'aux codes sources ?

                    Si je ne dis pas de bêtise si ton programme propriétaire est lié avec un programme GPL, le programme propriétaire doit être distribué sous GPL.

                    Pour cela, la LGPL à été créée pour permettre par exemple les liaisons dynamiques entre une bibliothèque LGPL et un programme propriétaire sans que ce dernier n'est à changer de licence. Une liaison statique implique un changement de la licence.

                    http://fr.wikipedia.org/wiki/Licence_publique_g%C3%A9n%C3%A9(...)

                    Donc je pense que l'on peut parler de binaire GPL.
                  • [^] # Re: To FUD or not to FUD

                    Posté par . Évalué à  4 .

                    La GPL est une licence pour logiciel, or un logiciel peut aussi bien être sous forme binaire ou sous forme de code source. La licence s'applique dans tous les cas.

                    Encore heureux, puisque la GPL impose :
                    * qu'on puisse exécuter librement le logiciel : elle s'applique donc aux binaires,
                    * qu'on puisse étudier le code : elle s'applique donc également au code.

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: To FUD or not to FUD

                    Posté par . Évalué à  2 .

                    S'ils ne fournissent ni le source ni le binaire sous GPL, il me semble que la discussion est close, non ?
                • [^] # Re: To FUD or not to FUD

                  Posté par . Évalué à  1 .

                  Tu es donc en train de nous dire que Qt et MySQL ont violé la licence GPL pendant des années (et continuent de le faire), au nez et à la barbe de la FSF qui n’ont pas levé le petit doigt ni même dit « c’est pas bien » ?
                  Non, c’est bien Vador Dark qui a raison : le propriétaire du code peut le distribuer sous plusieurs licences, à la tête du client. Chez Qt/MySQL, c’est GPL pour ceux qui font du compatible GPL, et proprio pour les autres. Et si ça les amuse, ils peuvent vendre une version ++ en proprio et une version -- en GPL.
                  • [^] # Re: To FUD or not to FUD

                    Posté par . Évalué à  1 .

                    Tu es donc en train de nous dire que Qt et MySQL ont violé la licence GPL pendant des années (et continuent de le faire),

                    Parce que le code source de MySQL n'est pas disponible sous licence GPL, peut-être ?
                    Et le fichier COPYING là, c'est une sucette géante ?
                    http://bazaar.launchpad.net/~mysql/mysql-server/mysql-trunk/(...)
                    • [^] # Re: To FUD or not to FUD

                      Posté par . Évalué à  3 .

                      Quel mot ne comprends-tu pas dans « double licence » ?
                      MySQL est distribué sous GPL pour ceux qui acceptent les règles de la GPL (toute application dérivée doit être sous une licence compatible GPL)
                      MySQL est distribué en proprio pour ceux qui ne veulent pas de la GPL (Source : MySQL)
                      MySQL AB^W^WSun^WOracle peut faire ça parce qu’ils possèdent le copyright sur le code.
                      Ergo : si tu possèdes les droits d’auteur sur le code, tu peux faire ce qui te chante, y compris une version proprio, et mettre des fonctionnalités en plus dans la version proprio. Le fait que tu distribues une version sous GPL ne t’interdit pas de distribuer une autre version en proprio avec plus de fonctionnalités. C’est pas bien compliqué, si ?
                      • [^] # Re: To FUD or not to FUD

                        Posté par . Évalué à  2 .

                        On va y aller doucement. Je répète ce que j'ai dit : « Heu, non. Si tu distribues des binaires sous GPL et qu'on te demande les sources, tu dois filer les sources sous GPL. »

                        Est-ce que tu es en désaccord avec quelque chose dans cette phrase ? Si oui, pourquoi ?
                        Si non, quel est le sens de ton opposition ?
                        • [^] # Re: To FUD or not to FUD

                          Posté par . Évalué à  2 .

                          Non, car en tant que propriétaires du code ils peuvent le distribuer sous une autre licence, comme le font MySQL et Qt.

                          Je pense que le sens de son opposition vient de là, il parle de code sous multiples licences, et toi de code sous GPL.

                          Depending on the time of day, the French go either way.

                          • [^] # Re: To FUD or not to FUD

                            Posté par . Évalué à  2 .

                            Une licence multiple n'est pas un truc magique qui autorise à faire n'importe quoi. Si l'auteur file un binaire à quelqu'un en disant : « tu as le droit d'utiliser ce binaire, au choix, selon les termes de la licence GPL ou de la licence X », alors l'utilisateur est en droit de choisir la GPL et demander des sources utilisables sous GPL.
                            • [^] # Re: To FUD or not to FUD

                              Posté par . Évalué à  1 .

                              Dans ce cas, le distributeur est generalement assez malin pour distribuer le binaire avec des features supplementaires sous licence proprio, plutot que sous double licence.

                              Genre firefox pour citer le plus connu. Ou chrome, pour citer un autre connu.

                              If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                        • [^] # Re: To FUD or not to FUD

                          Posté par . Évalué à  3 .

                          > On va y aller doucement
                          Pas de problèmes

                          > Est-ce que tu es en désaccord avec quelque chose dans cette phrase
                          Non

                          > Si non, quel est le sens de ton opposition ?
                          Parce que certains en déduisent bien trop rapidement qu’un binaire distribué sous GPL à une personne X (par exemple, mysqld) ne peut être distribué à côté sous une licence propriétaire à une personne Y, éventuellement sous une forme améliorée.

                          Je te rappelle que le débat original était : est-il possible de créer un logiciel, puis de le distribuer d’un côté sous GPL gratos, d’un autre côté en proprio payant avec plus de fonctionnalités privé, le tout sans violer la GPL ?
          • [^] # Re: To FUD or not to FUD

            Posté par (page perso) . Évalué à  4 .

            Donc je confirme : trop gros, passera pas.

            Je confirme aussi.

            Si le point 1) est avéré (dépôt privé), ça veut dire soit que Apple se coltine un gros boulot de fusion entre leur branche privée et la branche libre (qui bouge très vite - Cf. point 2), soit que leur branche privée a peut-être certaines fonctionnalité en plus, mais qu'elle va diverger très rapidement. Bref, pas grand intérêt.

            Le point 2 est facile à démonter : il suffit de regarder le nombre de contributions externes qui ont été incorporées, ce qui d'ailleurs permet au couple clang / LLVM de compiler de plus en plus de choses.

            Ex. [http://wiki.freebsd.org/BuildingFreeBSDWithClang]
    • [^] # Re: To FUD or not to FUD

      Posté par . Évalué à  0 .

      Euh on n'est pas Vendredi, mollo sur les troll..

      >> 1/ Les binaires de LLVM distribués par Apple avec ses outils de développement officiels vient d'un dépôt privé ayant plus de fonctionnalités <<

      Même si c'est vrai, je ne vois pas ou est le problème??
      Cela ne me gène pas du tout qu'Apple se garde des développements perso, ce qui me gène c'est si ils empèchent les autres d'utiliser un projet libre avec des brevets logiciels(*).

      Pour ton point 2:
      - l'alternative GPL GCC aussi rejeter des contributions pour des raisons politiques et non-technique
      - La FSF a aussi fragmenter la communauté du libre avec la GPLv3..
      - les trolls GPL vs BSD franchement --> poubelle: FreeBSD et OpenBSD se portent assez bien..

      *: je n'en suis pas sûr du tout: mon journal était une question!
    • [^] # Re: To FUD or not to FUD

      Posté par . Évalué à  8 .

      On pourrait aussi argumenter que gcc fait du mal a la communaute en evoluant trop lentement et que RMS avec ses avis politiques bornes comme l'architecture monolithique "pour faire chier le proprio" empeche d'avancer correctement.

      Quand aux raisons de LLVM, elles viennent justement d'un souhait de la communaute industrielle.
      GCC n'est pas forcement le projet plus simple auquel contribuer, il est en GPL donc ca va gener un certain nombre d'acteurs industriels (hors de question par exemple pour Apple d'integrer GCC au coeur d'Xcode vu qu'il est hors de question pour eux de le liberer).
      GCC est super lent et LLVM/clang offre certaines fonctionnalites tres interessante, comme l'analyse de code.

      Bref, c'est un peu comme Firefox vs IE, ca donne un coup de pied au cul de GCC, ca relance la competition, et ca c'est bien.
      En plus les 2 sont libres, donc on va pas vraiment se plaindre non plus.

      La question des brevets est autre probleme, certes delicat. Sur ce point, Apple est relativement coherent: quand ils font du libre, ils ouvrent leur code et le font parce que ca ne leur pose aucun probleme de le faire, voire parce que ca les arrange (pour LLVM, garder un fork interne est effectivement idiot).

      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

      • [^] # Re: To FUD or not to FUD

        Posté par . Évalué à  7 .

        RMS avec ses avis politiques bornes comme l'architecture monolithique "pour faire chier le proprio" empeche d'avancer correctement.

        Comme il le dit lui-même : « C’est facile, pour quelqu’un qui n’a pas de principes et qui est disposé à vendre n’importe quoi, de considérer les autres comme rigides ».

        Source : http://www.ecrans.fr/Richard-Stallman-Il-faut-exiger-la,8951(...)

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: To FUD or not to FUD

          Posté par . Évalué à  4 .

          Oui, cela dit, quand ca concerne RMS, c'est facile de penser qu'il est rigide et largue sur la question de GCC, meme quand on a des principes et qu'on est pas pret a tout vendre.

          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

        • [^] # Re: To FUD or not to FUD

          Posté par . Évalué à  10 .

          C’est facile aussi de dire de ceux qui n’ont pas les même principes qu’ils n’ont pas de principes.
    • [^] # Re: To FUD or not to FUD

      Posté par . Évalué à  3 .

      Je sais pas si un universitaire (appelons le M. C.) très impliqué dans GCC est le mieux placé pour faire ce genre de remarque.

      1/ je commenterais pas je sais pas si c'est vrai

      2/ il peut demander à tous les doctorants qui ont eu le choix, en général ils préferent LLVM, y'a surement une raison... on peut aussi argumenter et dire que la fragmentation elle vient de la FSF, c'est le passage en GPLv3 qui a fait abandonner GCC par Apple (à cause des brevets j'imagine). Pour les contributions exterieures je sais pas, en tout cas c'est surement plus facile de contribuer à LLVM, deja y'a pas d'assignation de copyright... Ensuite la communauté c'est rarement principalement lié a la licence, mais plus souvent au project leader (et perso entre Chris Lattner et le Stallman, je crois que je prefere Lattner ;)
      • [^] # Re: To FUD or not to FUD

        Posté par . Évalué à  2 .

        > Ensuite la communauté c'est rarement principalement lié a la licence

        ha ha !

        Adhérer à l'April, ça vous tente ?

      • [^] # Re: To FUD or not to FUD

        Posté par (page perso) . Évalué à  2 .

        >>> Ensuite la communauté c'est rarement principalement lié a la licence, mais plus souvent au project leader (et perso entre Chris Lattner et le Stallman, je crois que je prefere Lattner ;)

        Stallman n'est pas le project leader de GCC : http://gcc.gnu.org/steering.html
        Il y a un comité technique qui prend les décisions de façon collégiale.
        • [^] # Re: To FUD or not to FUD

          Posté par . Évalué à  9 .

          Allons, allons, on sait tous tres bien que c'est pas comme ca que ca fonctionne en realite.

          La meilleure preuve c'est que ce comite technique evite a tout prix de se reunir pour discuter technique et ne demande l'avis de RMS qu'en dernier recours.

          http://developers.slashdot.org/comments.pl?sid=117940&ci(...)

          You're not completely right, and not completely wrong. The politics are exceedingly complicated, and I regret it every time I learn more about them.

          RMS doesn't have dictatorial power over the SC, nor a formal veto vote.

          He does hold the copyright to GCC. (Well, the FSF holds the copyright, but he is the FSF.) That's a lot more important that many people realize.

          Choice of implementation language is, strictly speaking, a purely technical issue. But it has so many consequences that it gets special attention.

          The SC specifically avoids getting involved in technical issues whenever possible. Even when the SC is asked to decide something, they never go to RMS when they can help it, because he's so unaware of modern real-world technical issues and the bigger picture. It's far, far better to continue postponing a question than to ask it, when RMS is involved, because he will make a snap decision based on his own bizarre technical ideas, and then never change his mind in time for the new decision to be worth anything.

          He can be convinced. Eventually. It took the SC over a year to explain and demonstrate that Java bytecode could not easily be used to subvert the GPL, therefore permitting GCJ to be checked in to the official repository was okay. I'm sure that someday we'll be using C++ in core code. Just not anytime soon.

          As for forking again... well, yeah, I personally happen to be a proponent of that path. But I'm keenly aware of the damange that would to do GCC's reputation -- beyond the short-sighted typical /. viewpoint of "always disobey every authority" -- and I'm still probably underestimating the problems.


          C'etait en 2004. Ca a prix plus de 6 ans pour arriver a "convaincre" RMS d'avoir du C++ dans GCC.

          Et bizarrement, tous les projets dans lesquels il est dans le comite decisionnel mais n'ecrit pas de code (genre Gnome, GlibC - pas emacs donc) ont le meme genre de probleme et preferent eviter d'avoir affaire a lui.

          Il est tres bien comme representant du LL facon FSF, mais des qu'il s'agit de discuter technique, c'est plutot un frein aux projets sur lesquels il a de l'influence (et on parle pas de faire du proprio, juste d'eviter des decisions techniques debiles).
          • [^] # Re: To FUD or not to FUD

            Posté par (page perso) . Évalué à  -2 .

            Emacs est débile. Le Lisp est débile.

            Voilà, ça, c'est fait.

            Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

          • [^] # Re: To FUD or not to FUD

            Posté par . Évalué à  8 .

            J'adore, un poil plus haut dans le meme thread:


            GCC recently voted down using C++ in their core code.

            Again, a complete lie. We asked RMS whether we could make use of C++ in parts of the compiler. While a skilled and brilliant C and LISP hacker, RMS is a reactionary fuckhead when it comes to anything other than C or LISP. In his opinion, all GNU programs should be written in C, and only C, ever.

            There was no vote.

            Depending on the time of day, the French go either way.

          • [^] # Re: To FUD or not to FUD

            Posté par (page perso) . Évalué à  2 .

            C'est amusant, je me suis fais exactement la même remarque en constatant qu'une fonctionnalité attendue depuis longtemps en standard dans Emacs (existant déjà en application "tierce"), un système de gestion de programmes lisp (install, maj, sup etc.), fut annoncée pour Emacs 24 peu de temps après que RMS se soit définitivement retiré du développement de son bébé.

            Stallmann n'en voulait pas.
    • [^] # Re: To FUD or not to FUD

      Posté par . Évalué à  4 .

      D'un autre côté, ça ne m'étonne guère qu'un "universitaire très impliqué dans le développement de GCC" dénigre LLVM. Il a passé du temps pour apprendre les rouages de GCC et d'un coup, un petit nouveau arrive (LLVM) et tout le monde le trouve plus simple et mieux fait et plus hackable. Ça doit frustrer.

      Ensuite, pour répondre à tes remarques :

      1) Quelles fonctionnalités ? On a une liste ? Est-ce que ce sont des trucs hyper important ou juste des trucs mineurs d'intégration à MaxOSX ? "Ils nous cachent des trucs", c'est un argument un peu bidon... À ce compte là, Mozilla fait pareil (les méchants), ils ont longtemps distribué un binaire avec des fonctionnalités (le rapport de bug) qui n'étaient pas dans la version libre (je ne sais pas si c'est toujours le cas maintenant). LLVM a toujours été un projet libre, au départ c'est la thèse de Chris Lattner, ce n'est pas Apple qui a libéré un de leur logiciel. Donc il n'y a pas trop à s'inquiéter. Au pire, si Apple ferme le code d'un coup, je pense qu'un fork aura lieu.

      2) Oui, beaucoup de personnes dans la recherche travaille sur GCC, mais ce n'est pas le seul compilateur qui existe, même avant LLVM. Je ne parle même pas des dizaines de compilateur maison dans l'embarqué (qui travaillent beaucoup sur les optimisations très agressives), ou même d'[[Open64]] qui sert de support à pas mal de recherches. Faire croire qu'il n'y a que GCC dans la recherche et dans l'industrie est un mensonge.
      • [^] # Re: To FUD or not to FUD

        Posté par . Évalué à  2 .

        Réponses rapide :

        1/ Je ne sais pas précisément quelles sont les fonctionnalités en question, je demanderai quand il sera rentré de vacances. Je sais que typiquement, il ne considère pas clang et LLDB comme des apports intéressants de son point de vue (de chercheur en compilation, ce que je précise plus haut !).

        2/ Si mon message laissait paraître que la personne en question a prétendu que GCC était le seul compilateur utilisé dans le monde académique, c'est une erreur, surtout qu'il a lui-même pas mal utilisé Open64/Whirl à une époque. Ce qu'il dit, c'est que, après avoir énormément poussé avec d'autres la communauté académique vers GCC pour avoir des développements pérennes et fertiles, avec succès, LLVM fragmente de nouveau celle-ci.
        • [^] # Re: To FUD or not to FUD

          Posté par . Évalué à  1 .

          Même si GCC peut paraitre leader en France (mais surtout parce que le chercheur en question le pousse), un survey des confs international va montrer une plus grande diversité. Et cela ne m'étonnerait pas du tout si LLVM était leader si l'on prend les confs classiques (PLDI, CGO, CC).

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.