GeneralZod a écrit 2316 commentaires

Avant de taper sa gueulante "RedHat abandonne le desktop gnagnagna", lisez un peu l'article.
Premièrement, RedHat constate que si eux font des efforts pour partager leur travail en upstream, ce n'est pas le cas de tout le monde au niveau du desktop.
Effectivement, les distributions perdent beaucoup de temps dans des développements particuliers qui pourraient être avantageusement mutualisés. RedHat et FedoraProject ne sont pas exempte de ce défaut, mais il y a une volonté de contribuer directement en upstream (récemment gvfs, le nouveau gdm par exemple), et de développer des composants réutilisables par tous (ex: NetworkManager qui depuis le départ de Robert Love de Novell, reçoit très peu de contributions hors de RH/FP.o, Codeina)

Le résultat est que ça ralentit la progression du desktop permettant d'offrir un produit fini et léché.

Ensuite RedHat explique que deux objectifs à remplir pour finaliser le produit desktop sont: la possibilité de générer des bénéfices et que ce produit s'insère dans son offre existante. Jusque là rien de bien choquant.


Ensuite, RedHat dans le processus a rencontré pas mal d'embûches:
* les changements de hardware et du marché, retardant l'avancement.
* des fournisseurs peu coopératifs.
* problèmes de licences notamment avec les codecs.
RedHat n'a pas l'ambition de vendre une simple boiboite et après on prie que ça marche sur sa machine mais de vendre un produit fini avec une compatibilité matérielle parfaite.
Rendons-nous à l'évidence, le marché du desktop est peu générateur de revenu contrairement à celui de l'entreprise (+embarqué), d'un côté, on trouve des distributions communautaires disponibles à peu de frais et de qualité, de l'autre, il est difficile d'expliquer à un non-initié pourquoi son matériel n'est pas correctement supporté, pourquoi il ne peut pas lire ses mp3, pourquoi le Wi-Fi marche pas.
à l'heure actuelle, le produit desktop n'est pas viable pour RedHat et ils recommandent Fedora, l'upstream de RHEL dirigé par la communauté et sponsorisé par RedHat.

RedHat n'abandonne pas le desktop (ils font un récapitulatif de leur engagement dans ce domaine) et continueront dans cette voie. RedHat note un succès parmi ces résultats mitigés: OLPC.

* premier contributeur au noyau.
* gros contributeur à GNOME (très utile pour un serveur)
* NetworkManager (les serveurs ont besoin de gérer les connexions Wi-Fi et GSM c'est bien connu)
* AIGLX (faut bien amuser les admins avec des fenêtres molles et des effets kikoolol).
* PackageKit.
* gvfs
* HAL
* D-Bus
* ConsoleKit et PolicyKit (trop lol, plus besoin d'avoir une console root pour lancer pour gestionnaire de paquets graphiques sur mon serveur !)
* system-config-printer (trop marre de configurer mon imprimante avec emacs)
* Mugshot/OnlineDesktop (trop lol de buzzer les potes au taff entre deux opérations de maintenance.

C'est sûr, RedHat/Fedora n'ont rien apporté au desktop, surtout quand on compare ça à l'immense contribution de Canonical/Ubuntu, upstart, euh des photos de culs nus par défaut en wallpaper ?

smolt était un outil Fedora (comme l'était PackageKit, Codeina, system-config-printer, etc ...), depuis sa conception, il est ouvert à toutes les distributions.
Actuellement, smolt supporte OpenSuSE, Debian, Ubuntu, Archlinux, Frugalware et normalement toute distribution utilisant HAL.

D'ailleurs la licence de Linux précise que la "vaccination GPL" ne concerne pas les programmes propriétaire utilisant les appels systèmes.
Le but de la GPL n'est évidemment pas de conquérir le monde mais de coexister avec le propriétaire (à armes égales).

Il n'y a pas eu de détournement dans ce cas précis.
Les syndicats du personnel ont fait pression pour avoir des repas comestibles et ont gagné. Les étudiants acceptent de bouffer la merde qu'on leur sert.
Rajoute, des budgets très serrés, une solidarité à sens unique entre personnel et étudiant, bah le résultat était plus que prévisible.

Aux étudiants de réclamer le droit à des repas décents, je suis certain que les resto U réfléchiraient à deux fois avant de proposer n'importe quoi si les étudiants les boycottaient pendant une semaine. Tu t'imagines, une semaine de bouffe pour des milliers d'étudiants partir à la poubelle ?
Malheureusement, pour les avoir vu à l'oeuvre, les syndicats étudiants sont incroyablement incompétents, l'échec des négociations leur est très souvent imputables.

Le contrat est censé transposer l'aspect technique dans un cadre juridique. Distinguer l'aspect juridique de l'aspect technique est un non-sens.
Ton juge pour déterminer si ton logiciel est un travail dérivé, s'appuiera sur le texte de la licence (qui est suffisamment explicite à ce sujet), l'avis des experts techniques et probablement de la position des auteurs de la GPL.
La GPL n'a pas été écrite à l'arrache sur un bout de nappe par RMS, des juristes (notamment Eben Moglen) ont participé au processus et ils ont tenu compte de l'aspect technique.



Une clause abusive, c'est une clause entrainant un déséquilibre significatif entre les droits et obligations des parties au contrat imposé par la partie la plus forte économiquement parlant.
Difficile dès lors de parler de clause abusive dans le cadre de la GPL ...



1. Ton exemple est encore faux.
Tu a le droit décrire un logiciel propriétaire spécifique à MySQL en utilisant JDBC, mais tu n'as le droit de distribuer les deux ensemble (que ce soit d'une façon ou d'une autre).
Si tu veux le faire, comme je l'ai dit précédemment, tu dois acheter une licence auprès de MySQL Labs.
C'est exactement la même chose qu'avec les pilotes binaires.

2. Tu as une définition abusive du terme "travail dérivé", si on prends ta définition, tu n'as pas le droit par exemple de fournir un IDE proprio avec GCC, ce qui est évidemment faux.
Même si en pratique, ta "coquille vide" ne tourne pas sans le composant GPL, tant qu'ils ne sont pas "intimes", c'est OK vis à vis de la GPl (Cf la faq GPL posté précédemment)



3. Elle est ou la contradiction ? Je t'ai dis que si tu veux redistribuer ton logiciel proprio + pilote JDBC ensemble, soit tu achètes une licence soit tu changes la licence de ton logiciel ?
Par contre, la GPL ne t'interdit pas de les associer dans le cadre d'une utilisation privée mais dès lors tu n'as plus le droit de le diffuser.

La GPL explique explicitement ce qu'est ou ce que n'est pas un "travail dérivé". Introduire la sortie d'un programme dans l'entrée d'un autre ne suffit pas à en faire un "travail dérivé".
Avec ta définition déformée de ce qu'est un travail dérivé, ce serait un bordel. Pour reprendre ton exemple avec JDBC, supposons que j'écrive un programme proprio utilisant JDBC que je vends avec MS SQL Server mais qui marche très bien également avec MySQL mais sans que je le distribue avec, donc mon programme devrait être sous GPL puisque c'est un travail dérivé.
Tu vois le problème ?

> Ca semble être une interprétation des gens de la FSF sur la licence GPL
En même temps, c'est eux qui l'ont écrite, ils savent peut-être mieux que toi ou moi ce que signifie la GPL. Sinon, le bout de texte en question fait partie de la licence, c'est la notice d'utilisation, même l'OSI l'a reprise ...
http://www.opensource.org/licenses/gpl-2.0.php



Tes exemples sont faux.
1. Tu passes par une couche d'abstraction en l'occurence JDBC, et tu n'es strictement lié qu'à celui-ci. Par contre, tu n'as pas le droit de distribuer ton pilote JDBC sous GPL avec ton programme mais l'utilisateur final peut les associer si il le souhaite.

Pour montrer que ton exemple est daubé, prenons le cas du pilote JDBC MySQL® Connector/J sous licence GPL. MySQL Labs précise que si tu ne veux pas être soumis à la GPL, tu dois leur acheter une licence.
Commercial licenses for either version can also be purchased from MySQL AB, for those who don't wish to be bound by the GPL.
http://www.mysql.com/products/connector/j/


2. Là, c'est du grand n'importe quoi. On te parle de lien dans le sens informatique du terme (http://fr.wikipedia.org/wiki/%C3%89dition_de_liens). Là, aucun lien n'est réalisé, tu récupéres la sortie d'un autre programme et tu l'introduit dans l'entrée d'un autre programme, c'est le principes des pipes.
Si je fais cat mon_fichier.txt | mon_programme_proprio_ala_con, si j'utilise GNU cat, mon_programme_proprio_ala_con n'a pas à passer sous GPL !


Pour te prouver que les notions de "travaux dérivés" et de "lien" ne sont pas opposé, un extrait de la FAQ GPL.

If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?
---------
It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case.

http://www.fsf.org/licensing/licenses/gpl-faq.html

En gros, dès que ton code devient intime avec du code sous GPL (même processus, partage de structure, appels de fonctions etc ...), ton code constitue un "travail dérivée" et doit être licencié sous une licence compatible GPL.

Les légendes urbaines ont la vie dure.
Il faut distinguer deux API dans le noyau Linux:
* les appels systèmes (kernel <-> userspace) utilisé par les programmes et qui est relativement stable.
* les appels internes au noyau Linux. Greg Kroah-Hartman l'explique très sur cette page (http://www.kroah.com/log/linux/stable_api_nonsense.html), c'est de la connerie. Si on veut faire une API stable, ça veut dupliquer les API (et risquer que les pilotes continuent à utiliser des API bogués), parfois il est impossible de corriger une faille de sécurité sans casser l'API.
Quant ton module est dans l'arbre des sources du noyau, il est automatiquement corrigé, si il ne l'est pas comme le module VMWare, bah, c'est à eux de le réparer.
Donc la vraie perte de temps, c'est d'avoir mis ce putain de module sous licence propriétaire et de ne pas l'avoir inclus dans l'arbre.
De plus, pour la plupart des modules, les changements sont quasiment invisibles.

Apple n'a pas un noyau dérivéde BSD, mais un noyau hybride XNU basé sur:
* un micro-noyau Mach.
* une couche de compatibilité BSD offrant une interface de programmation UNIX classique.
* l'I/O Kit: un framework (libre au passage) permettant d'écrire des pilotes matériels utilisant un dialecte C++ (de l'embedded C++, du C++ sans héritage multiple, exceptions, RTTI, templates etc ...)

Si l'API pour la programmation de pilotes pour XNU est stable, ce n'est pas grâce à BSD mais à l'I/O Kit.
De plus, XNU est un noyau à moitié mort avec des perfs merdiques comparés à Linux.

> La preuve, certain drivers Linux sont sous licence BSD
Au dernières nouvelles, la BSD (sans clause de publicité) est compatible GPL.
Prend une licence incompatible avec la GPL et hop, ça ne fonctionne plus. Au mieux, t'as prouvé que le code lié doit être sous GPL ou une licence compatible, au pire, c'est un mauvais exemple.

Extrait du texte de la GPLv2
This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License.

La même en Français:
La Licence Publique Générale ne vous permet pas d'incorporer votre programme dans des programmes propriétaires. Si votre programme est une bibliothèque logicielle, vous pourriez considérer comme plus utile de permettre de lier des applications propriétaires avec la bibliothèque. Si c'est ce que vous voulez, utiliser la Licence Publique Générale Moindre (LGPL) en lieu et place de cette licence.


C'est plus clair maintenant ?

Ce n'est pas une faille de la GPLv2, c'est l'interprétation de celle-ci par les constructeurs parce qu'elle leur convient.
La GPL dit clairement que tout logiciel lié à du code GPL (statiquement ou dynamiquement contrairement à la légende urbaine) doit être mis sous GPL, point barre. Le fait que le module ne soit pas un travail "directement" dérivé du noyau Linux ne constitue pas une excuse valable.

La GPL par contre ne t'interdit pas de concevoir ou d'utiliser un module propriétaire pour le noyau Linux mais t'interdit de redistribuer l'ensemble.
Les distributions fournissant dans un même ensemble un noyau Linux "teinté" sont dans l'illégalité -quoique contournable par une EULA mais dès lors la distribution n'est plus libre-, quant à ceux qui fournissent des modules précompilés, c'est borderline.

gthumb marche parfaitement, fais un rapport de bogue à ta distro ou change de distro.
Je trouve mirage plus lent que eog ou gthumb, voire même plus lent que f-spot (que tu ne cites pas).
Personnellement, j'utilise eog très léger, rapide excepté pour les scans de mangas pour lesquels j'utilise le très bon comix.

Et ça t'étonne encore ?
On leur fait bouffer de la merde, on les loge dans des cages à lapins amiantés pour les plus chanceux (des étudiants qui couchent dehors ce n'est pas si rare), on les emmerde avec des machins administratifs bidons, on leur paie la bourse avec des mois de retards etc ...
Le plus beau, c'est qu'ils subissent sans rechigner.

Il ne faut pas attendre grand-chose des syndicats étudiants qui n'ont pas fini leur crise gaucho-bobo-révoltés (et qui souvent ne connaissent pas les problèmes de la majorité des étudiants).
Peut-on reprocher aux syndicats du personnel de ne pas se laisser marcher sur les pieds ? bien évidemment que non, même si la solidarité étudiants-personnel est souvent à sens unique.

Le syndicalisme en France est décédé en 1968.

On peut retourner le problème: pourquoi la solution des groupes ne convient pas ? C'est souple, ça fait la même chose, alors pourquoi vouloir imposer les suggestions ?

RPM se veut un outil bas-niveau dans l'esprit Unix, il fait une chose et il le fait bien. Après, c'est à l'outil de plus haut niveau de proposer des fonctionnalités plus avancés comme les suggestions.
Pourquoi s'amuser à complexifier RPM alors qu'il l'est suffisamment si ce n'est déjà trop ?

Hein, Fedora offre les groupes (géré par le fichier comps.xml), OpenSuSE offre également des "recommendations" et des "suggestions" via son One-Click Install. (http://en.opensuse.org/Build_Service/Tutorial)

Rien n'empêche Mandriva d'implémenter dans son urpmi ce mécanisme, rien ne les empêche de discuter avec les autres distributions à base de RPM d'implémenter un mécanisme commun sans forcément le foutre dans RPM.

Extrait de South Park:
Stan: "J'ai appris que je ferais de m'habituer à choisir entre une poire à lavement et un sandwich au caca parce que ce sera le seul choix qu'il me sera proposé."
episode 808 "Douche and Turd"

Cairo ce n'est pas un toolkit graphique mais un système de "dessin", l'équivalent d'Arthur dans Qt4, GDI en Win32, Quartz sous OS X, ou feu GDK (enfin, pas totalement feu malheureusement)
Et oui, Cairo ça marche, Gecko, WebKit, Gtk+2, Poppler, Inkscape l'utilisent abondamment. Il y a de fortes chances pour que Cairo soit une brique essentielle de ta distribution.

Fedora 9 est passé au suivant.
Tu peux télécharger un snapshot de la version de développement qui est encore assez proche de Fedora 9.
Sinon rapport de bogue sur http://bugzilla.redhat.com

Avec les groupes dans un fichier xml comme dans un Fedora, tu as un système similaire. Dans un groupe, tu as les paquets essentiels et les paquets supplémentaires (ou suggérés).
L'avantage est que c'est plus souple à maintenir, je ne change qu'un fichier xml et non pas un fichier spec qui signifie recompilation du paquet, mise à jour inutile pour 99% des utilisateurs etc ..., si tu dois faire ça assez souvent, ça devient vite lourdingue. Les concepteurs de RPM ont fait choix, celui de laisser la gestion des groupes à l'outil de haut niveau.
Si tu veux un mécanisme de suggestions, il faut l'implémenter dans urpmi et non pas dans RPM.

C'était pas un troll mais un rapport de bogues assez poilant.
Linus a prouvé qu'il savait faire de l'humour sans forcément y insérer une pointe de troll.

Bon courage pour passer la totalité du noyau Linux sous GPLv3.
Vu le foutoir que cela a été pour KDE4, j'ose même pas imaginer pour le noyau Linux comptant des milliers de contributeurs (dont certains morts ou injoignables) et dont le développement porte sur près de 18 années.

Je mets ça sur l'incompétence de l'interne qui n'a pas su stopper l'hémorragie dans mon rapport, tout en le rassurant que je le "couvrirais".
Ensuite, je me tape l'infirmière après l'avoir baratiné sur comment j'ai sauvé des enfants tabassé par les méchants soldats Chinois au Tibet dans le débarras avant de reprendre le service.

18 ans plus tard, je suicide tout le monde avant que le pot aux roses soit découvert.

Non, ça je suis au courant (d'ailleurs, ce n'est pas un script, la fonctionnalité fait partie de Nautilus, pour s'en convaincre, suffit de copier Infinity sur une autre distro avec un GNOME récent).
Cette fonctionnalité existe depuis plus d'un an (Fedora 7 l'avait mais aucun wallpaper ne l'exploitait avant Fedora 8), et j'ai remarqué que si les utilisateurs appréciaient, finalement, peu de distributions l'ont adoptés.
Donc, je voulais savoir si Mandriva exploitait cette fonctionnalité ou avait développé son propre truc.

Tant qu'ils l'utilisent en __interne__.
Par contre, dès qu'ils te vendent un produit avec ce Linux patché comme c'est le cas avec la Boite Libre -sic-, ils doivent te filer les sources utilisés (et non pas te renvoyer vers un miroir des sources NON patchés).

On dirait le résumé de la journée typique d'un de nos commerciaux excepté l'arme.

> Pour finir, tout comme la dernière fedora, la teinte du fond d'écran varie en fonction de l'heure

C'est un script bourrin à la main ou bien ils utilisent la fonctionnalité de Nautilus ?