nullisimo a écrit 173 commentaires

Quand tu changes une structure "sensible" ou que tu ajoutes du code intrusif, il faut _toujours_ tout recompiler.
C'est sur lorsque tu modifies netcat c'est pas la meme chose que modifier le code du routing, UFS ou autres changements intrusifs.

C'est fallacieux de comparer un BSD a fedora. C'est pas du tout la meme contrainte.

Que Visual C++ soit plus rapide que gcc, ne lui donne aucun charme de plus.

Un compilo qui va "seulement" 2 fois plus vite que gcc a au moins le charme de compiler un OS complet en 2 fois moins de temps. Surtout quand il faut tester plus d'une dizaine d'archis.
C'est aussi pour ca qu'il est important pour un projet consequent de compiler rapidement, meme si le binaire final n'est pas super optimise, au moins le code a passe le test du "make word".

En quoi les réponses à ces questions justifient que Theo s'en prennent plus à Linux et à la GPL qu'aux boites proprios qui utilisent du code BSD ?

1. Parceque des boites payent des developpeurs BSD pour certains projets. Si on prend FreeBSD (pour changer), il y a du sponsoring. Et que, comme chez linux, ca reduit les couts de maintenance interne.

2. Parceque sous linux ca se voit. Et c'est purement de l'ego. Imaginons un cas simple. X ecrit un driver (grace au reverse engineering) d'un produit A pour mBSD . Y demande une double licence, X accepte et qq mois apres meurt. Y, entre temps, rajoute des fonctionnalites basiques qui se resume a des ecritures de registre, sous licence GPL. Et bien mBSD doit fournir les memes ressources que le projet de Y pour arriver a ce qu'a fait Y, en se basant sur le travail de X. Pendant ce temps on entend partout "ouais mBSD c'est de la merde, ils sont grave a la bourre pour le support de A'. Alors forcement ca perturbe...

Ce n'est pas ce que j'ai dit ni sous-entendu. J'ai dit :
- "Es-ce que le changement de licence est "éthique" vis à vis d'OpenBSD (et d'autres systèmes BSD) de la part du mainteneur Linux ? Je n'ai pas d'avis."
Mais y'a ceci en plus:
Ce que fait le mainteneur a des conséquences connues et accèptées des développeurs qui aiment la BSD.

Qui peut tendre a cette interpretation. Soit.

Je ne demande pas que ça se "généralise".
Je m'en doute.

Ce qui est faux. Proprio ou GPL, ça dépend de l'auteur du code. S'il ne veut pas, ben il ne veut pas. Et s'il veut, ben tant mieux (NB : je ne dis pas tant pis !).

Bien sur. Le maitainer actuel le fera, mais son successeur ? Le suivant ? Mais ce n'est pas faux. BSD -> GPL !-> BSD. Oui tu peux reutiliser le code, mais pas dans les memes conditions qu'initiallement. D'un point de vue BSD, c'est une regression (c'est meme redibitoire). La boite, elle contribuera sous licence BSD, et si ce n'est pas le cas (genre une licence GPL), ca sera refuse (et ca fera encore plus de bruit).

> et bien je pourrais rajouter sans aucune honte linux a cote de "ces pilleurs de code".

Minable.
C'est une figure de style.

Beaucoup de code du noyau de Linux est dans OpenBSD. Je trouve ça très bien.
La licence est respectee. Alors pas de soucis.

Des développeurs veulent que LEURS MODIFICATIONS soit sous GPL only. C'est leur choix !
Et ils ont bien raison, et que le source soit ouvert ou ferme, c'est pareil pour la communaute de l'auteur du code. On est d'accord je presume.
On peut donc dire que le code est verouille (par rapport a la version initiale), non ? On peut donc dire que l'auteur, a decide de se servir d'un code sous une licence, et a empecher toute recuperation de son travail sous la licence initiale.

Il n'ont pas volé BSD, ce qui a été fait pour BSD est toujours dispo.
Logique. mais ou veux-tu en venir ? Est-ce une maniere detournee de ne pas dire que le travail derive, et c'est ballot, ne pourra pas etre reutilise as-is par l'auteur original ?

Si ce qui arrive ne lui plait pas, ben qu'il utilise la GPL (au-lieu de la critiquer).
On y est :) Non, je ne ferai pas d'analogie deplacee ;-)

T'aimes pas qu'on critique la GPL? Soit. N'empeche que ce rapport de force profite, malgre sa legalite, unilateralement a des gens qui n'ont pas la meme conception du libre,

C'est pas parceque c'est la GPL, qu'on a pas le droit d'avoir un avis et de se formaliser des effets de bords de cette derniere.

Je sais, "dura lex, sed lex", toussa.

Quand y'a une violation dans le dépot cvs d'openBSD, qu'on le fait remarquer poliment, ça réagit avec beaucoup de plus de violence que ce que n'a fait le journal de "monsieur Red Hat".

Certes. Mais c'est incomparable. D'un cote, on a une violation de licence, de l'autre, une sorte de "fermeture" du code lors de l'evolution de ce dernier, un fork somme toute.

Ce sont deux cas d'ecole, des choses qu'on aimerait pas voir souvent, mais qui se produisent de temps en temps, et animent les forums et les mailing lists.
Ca arrive que des gens reecrivent "betement" du code juste pour changer la licence. Ca arrive que la GPL ait des effets de bord qui au final sont une sorte de proprietarisation. Ca arrive meme que les gens ne lisent pas les licences ou pire les assimilent par pattern matching sans voir les subtilites ! (cf le nombre de derivees BSD)

Note: s/poliment//

Et que ça part sur les insultes où on traite le dev linux comme un trou du cul inhumain.
C'est pour ca qu'il faut entretenir la vendetta ?

... est assez condescendant envers la communaute BSD.

Nonobstant l'utilisation de code GPL dans les BSD, ca ne justifie en rien tes propos (qu'on peut resumer a : "ouais c'est bien fait pour leur gueule"). Dans les divers BSD, la GPL est respectee et generalement ce sont plus des softs que du code brut qui sont utilises. Quand ces softs sont patches, il n'y a pas (generalement) de license specifique pour le patch.
Lorsque du code est utilise (ext2fs, reiserfs etc...), ca n'a aucune incidence sur le code BSD.

Maintenant, revenons a notre affaire. Techniquement. que ce soit une boite qui fait du proprio qui "pique" du code sous BSD, ou un dev linux qui colle de la GPL par dessus, c'est presque la meme chose. Sauf que dans le cas de l'introduction de la GPL, ca devient beaucoup plus complique de reinjecter du code sous BSD.
L'eusses-tu cru mais ca arrive (parfois) que des boites, qui utilisent du BSD, au bout de quelques mois, fournissent du code a eux, sous licence BSD. Certes le ration code reinjecte / code utilise est faible, mais il est quand meme toujours superieur au 0 qu'implique le relicencing GPL.

Ce sont les regles du jeu et ca ne me choque pas plus que ca. Mais la prochaine fois que je lirai des commentaires sur mon code sous BSD qui peut etre repris par une boite sans que je puisse jouir des modifications, et bien je pourrais rajouter sans aucune honte linux a cote de "ces pilleurs de code".

Je me prepare a avoir un -10 :)

Ah ! la mauvaise foi, l'ingorance et le nombrilisme seront toujours les principaux carburants de l'autocongratulation.

et hop...

http://www.itwire.com.au/index.php?option=com_content&ta(...)

et hop
http://fr.wikipedia.org/wiki/Pyramide_des_besoins

En rien, mais beaucoup de gens aiment faire des déclarations sur la GPL sans savoir de quoi ils parlent :). Je rappelle que pour la GPL, l'exécution de programme tiers et la génération de fichiers, quels qu'ils soient, ne sont pas considérés comme des travaux dérivés... (fort heureusement)

Le probleme avec gcc, ce n'est pas le code qu'il genere, ce sont les libs associees (ex libstc++). Elles sont actuellement sous GPLv2 avec une "runtime exception".
http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.htm(...)

Effectivement. Et ca risque de poser des problemes pour les *BSD... A suivre donc.
Sans compter que la GPLv3 interresse Sun, zfs et peut etre dtrace sous FreeBSD risquent de patir d'un relicencing.

Qui lancerait OpenOffice.org en root ?

Un acces root n'est pas necessaire pour faire une machine zombie...

Je croyais que debien etait supportee.

http://www.hp.com/hpinfo/newsroom/press/2006/060814a.html

Sinon, en ce qui concerne HP, le support hard se fait. En revanche si on soupconne un bug d'un firmware ou un probleme du type "mon volume est mort, je fais comment pour le recup?", faut envoyer de preference des logs d'une red hat supportee, meme si ca depend de l'erreur.

"Et qui configure les applications pour le système ? L'admin..."

et qui developpent ? les dev... :-)

Y'a de la matiere en plus...
http://citron-vert.info/spip.php?breve920

http://la_gauche.saimal.fr/
http://mail_la_droite_aussi.saimal.fr/

ouais mais les RFC c'est mieux ;-)

"C'est un point de détail, mais faut pas l'oublier :)"

bah dans le kernel linux, y'a plein de trucs experimentaux que les gens utilisent en prod.

oh que vois-je...
------> []

Et as-tu déjà donné du code sous license BSD, où es tu seulement quelqu'un qui apprécie la BSD pour la possibilité de propriétariser le code à ton compte ?

Je mets a disposition du code sous licence BSD, je ne le donne pas.

Y'en a ras le bol ! du "viral" et du "contaminer" !

A l'echelle humaine, un virus implique une reaction du systeme immunitaire.
Si cela est transposable a l'informatique (ce qui "capilotracte" ;)): Quelles sont les implications sur le le systeme immunitaire BSD de la GPL ?
1. en ce qui concerne le kernel, tous ce qui est GPL est disponible "par defaut" sous forme de modules. Aucune envie d'offrir un kernel de base non-BSD (ca c'est pour les vendors de boites noires)
2. les sources kernel/userland sont bien cloisonnese a des repertoires "gnu". histoire de facilement les detacher du build (meme si, en pratique, c'est impossible sans un minimum de bidouillages)
3. ca necessite des hacks infames pour etre "GPL compliant" dans les ports (principalement les ports emulators/linux*base)

On peut donc en conclure que inclure du code sous GPL impose un traitement particulier :-)

La GPL est contraignante. C'est pas un soucis au fond, quand le code est GPL, on sait a quoi s'attendre. C'est un peu comme les softs proprio ou les MFC... ca sert a rien de se rouler par terre en criant "c'est honteux", "c'est viral", "c'est anti-libre". Au fond c'est fourni as-is. On prend et on respecte la licence, ou bien on ferme sa gueule.

PS: je reponds "oui" a la question "est-ce que la GPL est virale ?", uniquement parce que j'ai un point de vue BSD :)

En ce qui concerne Xorg c'est principalement une question de timing et de tests.
Quelques (lire "Peu de") developpeurs travaillent sur la mise a jour de Xorg, et cela implique entre autres:
- ~250 ports en plus
- comme on se debarrasse de /usr/X11R6, il faut corriger/verifier des centaines de ports.

Pour etre au courant:
http://wikitest.freebsd.org/ModularXorg

que c'est malhonnete.

En premier lieu, ils devront importer GEOM. Et ce n'est pas une mince affaire (technique et politique),,,

alors que pour ULE....ben....on attends toujours quoi....
normal il n'est plus maintenu ;-)

Mais je vais apporter de l'eau a ton moulin... juste pour infos.
En suivant -CURRENT on peut se rendre compte que SCHED_CORE a fait son apparition, base sur ULE mais plus threads friendly. En parlant de threads, on remarque que KSE commence a etre attaque: performances variables face a libthr dans certains cas (MySQL), blocages important pour le portage sur sun4v (Kip Macy est tres virulent la dessus). Il y a meme un branche perforce ou le support KSE a ete vire (non sans humour Peter Wemm l'a nommee bike_sched). Certains ont la gueule de bois M:N, et se tournent vers le 1:1. Sun a fait la meme chose il y a deja qq annees.
gjournal, accueilli par la foule en delire, se heurte aussi a des opinions hostiles, tous simplement parceque certains attendent la journalisation native pour UFS. plutot qu'une journalisation un niveau en dessous avec des hooks dans le code du FS. Et j'en passe...

Mais je te rassure y'a pas mal de dev cools en cours ;-)
Dernier point, beaucoup de developpeurs proposent des backports de leur patches pour 6.x (c'etait plus difficile entre les 5.x et 6.0-CURRENT). C'est parfois dommage que ca n'atteigne pas le CVS...

FreeBSD-update n'est pas un projet SoC. C'est issue d'une levee de fonds par Colin Percival. Il ne permet pas _simplement_ de passer d'une version a une autre. En effet ce sont des updates pour une release et non pour une branche, je ne peux tout simplement pas passer de FreeBSD 6.2 a FreeBSD 6.3 via freebsd-update. Ca semble contournable, pour le client aucun pb, c'est surtout du cote du "serveur" (dont les sources sont enfin disponibles).
On notera aussi l'arrivee de OpenBSM [1] en experimental.


[1] http://www.trustedbsd.org/openbsm.html

ouaip :-)