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 auve . Évalué à 10.
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 Zenitram (site web personnel) . Évalué à 1.
Surtout une tentative de troll BSD vs GPL que tu nous fais la...
[^] # Re: To FUD or not to FUD
Posté par auve . Évalué à 10.
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 Alex . Évalué à 10.
on voit bien à la dernière ligne qu'OpenNicolas n'a plus d'arguments !
[^] # Re: To FUD or not to FUD
Posté par Moonz . Évalué à 2.
Donc je confirme : trop gros, passera pas.
[^] # Re: To FUD or not to FUD
Posté par Mathieu CLAUDEL (site web personnel) . Évalué à 7.
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 Moonz . Évalué à 1.
[^] # Re: To FUD or not to FUD
Posté par Antoine . Évalué à 6.
[^] # Re: To FUD or not to FUD
Posté par Vador Dark (site web personnel) . Évalué à 3.
[^] # Re: To FUD or not to FUD
Posté par Spack . Évalué à 3.
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 zebra3 . Évalué à 4.
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 Antoine . Évalué à 2.
[^] # Re: To FUD or not to FUD
Posté par Moonz . Évalué à 1.
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 Antoine . Évalué à 1.
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 Moonz . Évalué à 3.
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 Antoine . Évalué à 2.
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 Frank-N-Furter . Évalué à 2.
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 Antoine . Évalué à 2.
[^] # Re: To FUD or not to FUD
Posté par pasScott pasForstall . Évalué à 1.
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 Moonz . Évalué à 3.
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 Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
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 reno . Évalué à 0.
>> 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 pasScott pasForstall . Évalué à 8.
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 zebra3 . Évalué à 7.
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 pasScott pasForstall . Évalué à 4.
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 Moonz . Évalué à 10.
[^] # Re: To FUD or not to FUD
Posté par ribwund . Évalué à 3.
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 Pol' uX (site web personnel) . Évalué à 2.
ha ha !
Adhérer à l'April, ça vous tente ?
[^] # Re: To FUD or not to FUD
Posté par patrick_g (site web personnel) . Évalué à 2.
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 Littleboy . Évalué à 9.
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 Zarmakuizz (site web personnel) . Évalué à -2.
Voilà, ça, c'est fait.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: To FUD or not to FUD
Posté par Frank-N-Furter . Évalué à 8.
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 jbbourgoin (site web personnel) . Évalué à 2.
Stallmann n'en voulait pas.
[^] # Re: To FUD or not to FUD
Posté par rewind (Mastodon) . Évalué à 4.
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 auve . Évalué à 2.
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 ribwund . Évalué à 1.
[^] # Re: To FUD or not to FUD
Posté par lasher . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.