Par exemple le script Python qui ne fait "que" glue. Ca veut dire que si je ne veux pas de python sur ma machine, il suffit dans 90% des cas de faire du copier coller les éléments shell pour passer le script à la main.
Ca serait tellement vrai si seulement le script ne se contentait que de faire des commandes shell en succession... C'est loin d'être le cas. On sort pas l'artillerie uniquement pour executer de la commande shell à la pelle.
Mais on va pas refaire le monde à coup de "chez moi, moi je".
Par contre avec LUA je vais être obligé de me plonger dans le truc pour faire du debug de script si je veux le faire fonctionner à la main. Ca peut aussi virer au jeu de piste avec des fonctions qui apellent d'autres fonctions LUA qui vont chercher des infos à droite, à gauche (base de données, device etc.)
Ca n'a rien d'une propriété du langage ou de l'outil, mais de la programmation. Je peux sortir des scripts Perl imbitables que ca n'y changerait rien. De même pour Python.
Je vais peut être dire une connerie, mais c'était pas un contexte Kerberos SAMBA avec des certificats auto-signés dans le LDAP ? Parce qu'en utilisation authentification sur un réseau pur Unix Kerberos V4 et V5 ca a toujours plutôt bien tourné. Pour les bindings python, j'en ai jamais eu besoin donc ca ne m'a jamais manqué.
Que dalle. Pour créer des comptes Kerberos, gérer un déport du contexte (ou même l'initialiser), soit c'est la magie PAM (donc, solution externe à Python, qui fait justement ce dont je parle), soit faire des os.system("ksu ") avec du pexpect partout. Moche, surtout quand il s'agit de créer des contextes sur un serveur Web (dans les endroits un peu sérieux ou mettre un dn + mdp associé dans un fichier à part pour faire des bind() n'est pas accepté).
Code source != fichier de config. Si le mec veut faire un programme, une interface graphique, un concentrateur de données etc. en Lua, qu'il y aille. Aucun soucis avec moi.
C'est le cas.
Là il s'agit de fichiers de conf, des trucs qui peuvent déjà avoir pas mal d'incidence en aval (genre une erreur dans php.ini qui va joyeusement vautrer MySQL et Apache). A ceci on vient rajouter une possibilité d'incidence en amont (genre le script qui remplace mon php.ini va aller faire mumuse avec mes locales, mes params mémoire ou que sais-je encore). Là c'est non. Tout de suite. En plus on rajoute un interpreteur LUA dans mes serveurs, lequel interpreteur va avoir besoin de droits spécifiques pour exécuter tel ou tel partie du script de conf, dans le kernel parce que c'est plus fun.
Tu discutes d'une implémentation qui n'existe pas, en raisonnant sur des hypothèses qui sont tiennes, après avoir relu un article sur linuxfr. Je t'invite donc dans ce cas à poser tes questions sur tech-userlevel@NetBSD.org et tech-toolchain@NetBSD.org.
Si les scripts d'install par défaut et les scripts de conf font du LUA, je ne vois pas comment je pourrais ne pas les utiliser à part en changeant de métier.
Pourrais-tu montrer les scripts d'install en question? Et les scripts de conf? Si non, encore une fois, pures spéculations. C'est de la critique gratuite pour satisfaire un besoin de critiquer...
Bref c'est une tendance que je n'aime pas. On aurait tout à gagner à ce focaliser sur les points forts du monde Unix plutôt que de chercher à copier des systèmes dont les choix de départ sont très différents des nôtres.
Quels points forts?
La pluralité des API, avec les environnements Linux qui réinventent/changent la roue tous les ans? Ou peut-être les 300 syscalls associés?
Des kernels qui font 20MiB ("small is beautiful", hein?)
Le choix d'avoir voulu externaliser la gestion du graphisme en dehors de l'OS (serveur X), et où maintenant les redites niveau gestion affichage (tty, pseudo tty, console...) sont éloquentes?
Un outil pour une tâche, avec des administrateurs actuels qui lancent python/perl/irb à la première occasion suivant affinité ("when all you have is a hammer, everything looks like a nail")
Le "tout est fichier"...
"Le monde Unix" dont tu parles est mort il y a quelques années maintenant, ou alors au stade de coma dépassé.
C'était à une époque ou les kernels ne faisaient pas dans les 20MiB l'image, où les API étaient simples mais pauvres, où l'usage/l'exploitation du système était reservé à une certaine élite et ne requérait pas le support de fonctionnalités très évoluées.
Les outils comme puppet, ou cfengine, interviennent à un niveau administration, maintenance, intégration. Cela implique que tu as déjà des templates/roles écrits permettant d'agir: cquelqu'un les a forément écrits, à un moment ou l'autre. Puppet/cfengine ne l'ont pas fait magiquement tout seul.
Encore une fois, un des objectifs est d'avoir une abstraction dans un langage qui permet d'exploiter des bibliothèques en C nombreuses et variées pour pouvoir les exposer plus facilement à des langages plus haut niveau.
Il n'est pas question d'avoir un fourre tout pour que Mr X, qui préfère exim, ait un module Lua qui lui permettra de configurer Postfix avec la magie LDAP. Non.
Vois ca comme ça: pour créer un utilisateur sous Unix, il est quasiment obligatoire de repasser par useradd(8). Si derrière, l'objectif est de faire un script python, qui au final, va appeler une pelle de commandes shell, le python n'a aucun d'intérêt, à part faire de la glue. Et quand il ne sait pas faire, on est coincé.
J'ai connu le temps ou pour exploiter des comptes avec un contexte Kerberos, il fallait jouer avec des variables d'environnement et des fichiers temporaires pour que ca marche, parce que la GSSAPI n'était pas exploitable dans Python... et quand on voit la gueule de l'API, on comprend pourquoi.
Autre exemple: éditer un fichier. Tu souhaites modifier /etc/motd en fonction de la journée. Aujourd'hui: tâche cron obligatoire, qui va appeler un script Perl (parce que le gars préférait Perl), qui va jouer au cat/grep/sed/ ~= <> FILE dedans.
Si tu veux te convaincre de l'utilité de la chose: je t'invite à lire le code source de net-snmp. Quand tu en auras marre de vomir à chaque ligne (entre les #ifdef__LINUX_VERSION_2.6__ && !__LINUX_VERSION_2.4__, les strncmp() dans TOUS les sens pour afficher les points de montage, les options de compil qui ont été activées on ne sait trop comment (merci les autodaubes!), j'espère que tu verras.
Donc oui, chat échaudé craint l'eau froide, le script qui configure automagiquement mes serveurs/params kernel j'en veux pas.
Personne n'obligera à les utiliser.
Il faut bien admettre que la tendance va vers cela, et qu'il n'y a pas beaucoup d'alternatives quand on veut passer à l'échelle (sauf à faire du cfengine/puppet, ce qui revient, au final, à créer des scripts de configuration automagiques... ou jouer avec kickstart -- aïe -- , même joueur joue encore).
PS: que je sache, l'outil omniprésent par excellence sous Unix, le shell, a son comportement contrôlé par un script shell lui même, non (.profile, .*rc, ...)? Ca n'a pas l'air d'avoir dérangé plus que ça ces 30 dernières années.
On va bientôt avoir des macro M4 qui via autoconf génèrent des fichiers XML avec du script LUA qui connecte des bases de données...
Ce que veut faire Marc est de proposer des modules permettant de contrôler la configuration du base system NetBSD via des modules Lua.
Les objectifs sont, entre autres:
1 - les API C actuellement présentes sont déjà très exhaustives en elles mêmes, et fournissent la majorité des fonctionnalités. Ce qu'il manque, ce sont des wrappers qui permettent de les exploiter dans des programmes avec des langages plus haut niveau.
Pour quelle raison? Une toute bête: scripter de la conf, sous Unix, ca se fait en shell/perl/python/ruby (suivant les affinités des individus...) à grands coups de pipes, popen(), execution de sed/awk/sh/grep/cat qui font que ca en devient bordélique, en plus de pousser à l'erreur. Qui ici vérifie proprement les codes d'erreurs retournés par system() quand il fait ces scripts? En toute honnêteté? Et qui ne se plaint pas quand la regexp de pexpect pète parce que dans la dernière version, "P" est devenu "p"?
Cela permet de pouvoir toucher à des configs clients et d'en déployer/rapporter/modifier facilement, à l'instar de WMI de Windows ou des plist MacOSX.
2 - pour Lunatik (un interpréteur Lua in kernel), et de façon plus générale, Lua+C, cela permet de fournir un environnement plus sûr que ce que donne le C et ses pointeurs. C'est pas comme si le jeu de ces dernières années était de retourner un kernel X ou Y en jouant sur des assignations à NULL ou des débordements de toute sorte, ou d'avoir un parsing de chaînes/octets moisi qui finit avec un exploit.
Il souhaite aussi voir ce que ça donne pour kauth(9), ce qui permettrait (pour l'instant, en théorie) de fournir un environnement pour construire ses propres modèles de sécu avec une vision développeur, plutôt qu'intégrateur (comme SELinux par exemple). Aujourd'hui, c'est C ou rien, ce qui pose un problème quand on développe des moniteurs de référence [1]...
J'attends avec impatience le moment ou je devrait mettre à jour MySQL-Client pour pouvoir recevoir mes mails...
C'est une vision de Linuxien ça. Le basesys d'un BSD forme un tout cohérent. Quand tu utilises le MDA du basesys, il n'est pas question de mettre à jour mysql-client-lib-2.6.7-1294.debian54.libc6.2 pour que ca marche/marche pas. Quand on met à jour, on met à jour l'ensemble du basesys, pas le MDA d'un coté et les "modules" d'un autre, avec une surprise au prochain redémarrage du service.
Quant au reste, le principe d'une interface bien conçue, c'est justement d'éviter cela. C'est pas comme si NetBSD avait accumulé une grosse expérience la dedans avec ses couches d'émulation et de compatibilité binaire depuis 15 ans.
j'aimerais bien savoir comment la sql query est secured aussi. Relation de confiance sur l'utilisateur/machhine ou bien il y a un autre fichier avec un mot de passe quelque part ?
C'est un exemple pour montrer un concept... La chose en est à peine à la conception qu'il faudrait déjà se taper les discussions sur la sémantique et l'implémentation détaillée.
Je ne vois pas trop ce que vient faire ici cette idée d'attaque de la communauté.
Les gens de la FSF pensent juste qu'il n'est pas éthique d'écrire du code propriétaire. Voir ce post pour une tentative d'explication : https://linuxfr.org//comments/932032.html#932032
Je ne partage pas le point de vue dans ton lien.
Le progrès engendré par le numérique a diminué les couts de _copie_ pour les rendre bas, voire nuls. Vrai.
En revanche, le numérique n'a certainement pas diminué les couts nécessaire à la création de l'original, de la première idée, qui demande un investissement pas nécessairement négligeable pour que cela soit inventif et nouveau, et affiche un réel progrès.
Si on veut inciter le boulanger à poursuivre à améliorer son pain (même si distribué à cout nul), il faut qu'il y trouve son compte.
Ce qui devrait relever d'un choix personnel et discrétionnaire c'est l'usage que tu as d'un logiciel, pas de faire ce que le développeur a décidé pour toi, du genre accepter de te faire gicler des fonctionnalités ou perdre le contrôle de tes données. La GPL vise à permettre ce choix à chacun.
Ce choix est déjà garanti dans la première partie de votre phrase:
"Ce qui devrait relever d'un choix personnel et discrétionnaire c'est l'usage que tu as d'un logiciel"
Tu noteras que personne n'oblige personne à insérer du code sous GPL dans ses logiciels. Je ne vois pas en quoi demander à ce que les programmes dérivés ne puissent permettre d'asservir les utilisateurs de ces programmes (en les empêchant d'accéder aux sources par exemple) est "un frein à la liberté".
C'est un frein à la liberté pour celui qui souhaite réutiliser les sources, sans pour autant devoir obéir à ce qu'un autre a décidé.
Ce qu'on appelle souvent "innovation" dans le monde industriel est souvent un moyen de faire du pognon, au détriment parfois du reste du monde. Les brevets par exemple sont dits faits pour la favoriser. [insérer ici le nom d'un éditeur de logiciel propriétaires que vous n'aimez pas] par exemple ne veut pas de code sous GPL mais pose des brevets : voilà qui favorise activement l'innovation, et la liberté surtout !
C'est une vision réductrice de discussion bar PMU, le "on nous ment on nous spolie", "le méchant industriel aura notre peau"...
Les brevets visaient à l'origine a participer à la création et l'innovation en permettant à un inventeur de jouir exclusivement de ses inventions, tout en permettant de les diffuser, pour que d'autres puissent en profiter et les améliorer à leur tour. Complètement à l'opposé du secret industriel.
Si le système a été perverti ensuite, c'est un autre débat. On a les gouvernants que l'on mérite. Mais c'est hors sujet.
Arf ? C'est ce que disent les éditeurs comme Microsoft : "la liberté est virale". Heureusement qu'eux luttent activement pour empêcher que ce virus ne se répande ! D'ailleurs je crois pas que Microsoft ne t'autorise à emprunter beaucoup de son code, même pour que tu fasses un programme sous BSD qui pourra redevenir privateur après.
Le fait que je ne puisse pas emprunter de son code ne m'empêche vraiment pas de dormir.
Ils contribuaient tellement bien à Linux qu'ils ont du développer leur propre version séparément pour Android.
C'est un problème?
Si quelqu'un ou quelque chose devait "libérer" GoogleFS, c'est Google. Pour que la GPL s'applique il doit y avoir distribution du code. Si tu veux modifier un prog sous GPL sans révéler tes modifications, tu le peux, à partir du moment où tu gardes les binaires pour toi.
Vision très réductrice.
Si je comprends bien, avoir un binaire sans les sources est privateur de liberté, mais un éditeur qui offre des services sans avoir de réel controle dessus (indexation des mails? moteur de recherche omniprésent?) n'en pose pas. Bon... faut croire que la carotte est bonne.
Parce que la GPL n'a pas pour objectif "d'asseoir" des technologies mais d'encourager le partage (et des technologies et des connaissances qui ont permis leur création) sans que cela se fasse au détriment des utilisateurs ?
L'innovation technologique, la recherche, la connaissance, a un cout. Et ce cout, suivant le contexte, doit être supporté. Pour un industriel, cela se fait en vendant des produits et des services, qui ne peuvent être partagés "gratuitement". Certains le font en espèces sonnantes et trébuchantes, d'autres en accumulant des informations pour mieux cibler la publicité.
Dans l'enseignement et la recherche publique, ce sont vos impots (ou ceux de vos parents) qui le permettent.
Faut arrêter avec l'idéologie du "je partage tout, même mon lit et mon porte monnaie..."
C'est à dire ? Il me semble qu'un code sous BSD qui utilise du code sous GPL a exactement les même problèmes qu'un code sous MPL qui utilise un code GPL.
Actuellement, je pensais à l'inverse. Vous pouvez copier/coller à peu près ce que vous voulez de code BSD, MPL est plus restrictif (granularité plus difficile à gérer). Entre autres.
Tout simplement parce que, pour moi, c'est du bon sens, et que c'est la moindre des choses.
C'est subjectif comme appréciation donc, le "bon sens" étant affaire d'appréciation. Vous devriez donc pouvoir admettre que d'autres personnes, physiques ou morales ne partagent pas votre opinion, sans la remettre en cause, et imposer votre point de vue.
Si Google mettait toutes ses technos en libre (pagerank, googlefs), l'entreprise aurait-elle les moyens de contribuer autant aux LLs? Existerait-elle d'ailleurs tel quel aujourd'hui?
Je ne pense pas. Je suis d'avis que c'est un équilibre, réglé en permanence, et qu'il ne faut pas adopter une vision aussi tranchée que celle prônée par quelques licences libres.
Qui dit que ça n'aurait pas été le cas avec une licence de type MPL ?
Je pense qu'une licence doit être simple pour être comprise et ne pas inspirer doute et peur à son sujet. La MPL n'en est pas une, de mon point de vue.
En plus, moi il me semble que c'est un argument tiré par les cheveux, un argument forcé qu'on a trouvé pour justifier la BSD.
Pas du tout, c'est historique... Le dernier exemple récent étant WebM.
Et retournement encore une fois le truc : imagine que Microsoft ait réussi à imposer ses merdes non standards comme les .doc, IE etc... grâce à du code BSD ?
Parce qu'il n'aurait pas pu avec du code GPL? Google a GoogleFS, pourtant Linux est GPL non?
Et le fait d'avoir le code y aurait changé quelque chose? Il va falloir vous mettre à l'idée que la licence n'y change rien. D'ailleurs, je renvoie à la première page de Chisnall, qui raconte l'histoire de l'objective C dans GCC [1].
Prenons un exemple pas totalement imaginaire.
Supposons que NTFS ait été développé grâce à du code soit sous BSD, soit sous MPL, et qu'il n'est pas documenté.
Dans le premier cas, pour pouvoir le lire sous Linux, je suis obligé de faire du reverse engineering de tout leur programme.
Dans le deuxième cas, ça sera peut être un peu plus facile puisque Microsoft aura diffusé le source d'une partie du programme.
Soyons clair: le problème ici ne vient pas du code, mais de la _documentation_. Il faut vraiment être timbré pour croire que du code se passe de spécifications, ou de commentaires, simplement parce qu'il sera rendu ouvert par une quelconque licence. Ce sont deux choses qui n'ont rien à voir.
La GPL ou la MPL ne vont pas "magiquement" aider à faire du RE d'ailleurs. Je te laisse t'en convaincre avec le travail de Damien (Bergamini) sur les drivers Intel, et la niouz de patrick_g [2]. Pourtant, le code de l'un est pseudo-ouvert GPL, et l'autre BSD. L'histoire du wrapper de 15k lignes doit rappeler une remarque que j'ai faite un peu au dessus.
J'aimerais que tu m'expliques en quoi la MPL est en désaccord avec le principe qui te fait adopter la licence BSD.
- mes principes ne s'appliquent pas suivant une granularité fichier/projet, mais sur du code. Je ne souhaite pas que l'on dénature du code simplement pour des considérations de "rangement."
- la MPL et la GPL (2,3) sont difficilement compatibles. La BSD ne me pose pas autant de problème quand il s'agit d'intégrer différentes sources.
- dernièrement, pour le projet sur lequel je travaille (NetBSD), chaque fois que je vois un projet qui commence à avoir du succès, il se retrouve sous "multi-licences" pour faciliter son usage. Ok, pourquoi pas, mais on se fait des noeuds au cerveau...
J'aimerais que tu m'expliques au nom de quoi quelqu'un qui modifie un code ne devrait pas partager ces changements (et uniquement ceux-ci).
Parce que je considère que la liberté se mesure à la longueur de la chaine, et que ca n'est pas à moi de fixer les règles d'usage de ce que font les autres. Je respecte le droit à disposer de soi même, de ses oeuvres, d'en diffuser (ou pas) leur contenu, y compris de s'inspirer du travail des autres.
L'innovation a toujours fonctionné comme cela, et non en dressant des barrières d'un coté ou de l'autre. Je considère que je n'ai pas à imposer mes valeurs aux autres via mon travail intellectuel.
Maintenant, inversons la charge: J'aimerais que tu m'expliques au nom de quoi quelqu'un qui modifie un code devrait-il partager ces changements?
Autrement dit, quel est l'intérêt de la licence BSD par rapport à la MPL ? (du point de vue du développeur/contributeur devant choisir entre les deux).
- La facilité d'inclure du code sous cette licence, sans s'arracher les cheveux.
- une excellente licence quand il s'agit de diffuser des idées et des implémentations. Si l'API socket, la pile TCP/IP, ou encore WebM (je lui souhaite) se sont imposés/s'imposeront, c'est en partie parce que les premières implémentations étaient BSD. Regardons dernièrement l'histoire de la doc GCC, ca fait peur, rien qu'en terme de qualité [1].
- pas de noeud au cerveau avec ces histoires de "compatibilité avec la GPL -- la FSF a déclaré que c'était compatible (de quel droit d'ailleurs? la FSF est souveraine en la matière?)
Je fonctionne comme un ingénieur, pas un avocat, un juriste, ou un leader d'opinion.
Sur le site officiel du projet NetBSD, voilà ce que l'on peut lire à propos de la licence BSD :
"While NetBSD uses the GNU toolchain (compiler, assembler, etc), and certain other GNU tools, the entire kernel and the core of the userland utilities are shipped under a BSD licence. This allows companies to develop products based on NetBSD without the requirement to make changes public (as with the GPL). While the NetBSD Project encourages companies and individuals to feed back changes to the tree, we respect their right to make that decision themselves."
Ils justifient la BSD, par la GPL.
Nulle part. On y explique que la décision de reverser du code (ou non) n'est pas du ressort de la licence, mais d'un choix personnel et discrétionnaire (les GPListes aiment bien parler de liberté, en voici une que leur licence ne respecte pas).
Or, ce qui rend impopulaire la GPL pour les entreprises, ce n'est pas le « requirement to make changes public » (l'obligation de rendre les changements publics), c'est l'obligation de rendre du code qui ne fait qu'utiliser du code sous GPL, lui même sous les conditions de la GPL.
Le problème ne se pose pas que pour les entreprises, mais les individus aussi... s'ils souhaitent utiliser du code sous GPL, alors tout leur projet passe systématiquement sous GPL. Les seuls contournements (bidouilles?) étant de jouer avec des bibliothèques, faire des wrappers... C'est aussi un frein à la liberté et l'innovation.
Ca serait bien d'éviter des clivages stupides "gentils libristes GPL" vs "méchante entreprise propriétaire".
La viralité de la GPL est un problème, l'obligation de rendre les changements publics aussi (sous certaines conditions cela dit...), et n'est pas à sous estimer. Google est un grand contributeur aux LLs, notamment Linux. La GPL n'a jamais libéré GoogleFS, que je sache? Et pourquoi avoir mis WebM sous BSD-like et non GPL, si ce n'est pour mieux asseoir une techno dans un monde industriel?
Ceux qui utilisent la licence BSD, le font parce qu'ils n'aiment pas la GPL.
N'importe quoi. Je développe sous BSD, et je ne code pas sous BSD parce que "je n'aime pas la GPL", mais simplement parce que la BSD se rapproche le plus de mes principes.
Si je devais résumer les objectifs de chacune, et là où je rejoins David Chisnall [1]:
- les gens de la FSF pensent que l'on attaque la communauté quand la quantité de logiciel proprio augmente, et qu'en ce sens, il faut placer du code sous une licence qui empêche d'en faire.
- ceux sous BSD, ou équivalent, considèrent que la communauté bénéficie de l'accroissement du nombre de projets pouvant tirer parti de code libre pour sa grande valeur ajoutée, sa qualité, j'en passe.
Point de vue différent, idéologie différente. Vous utilisez la licence qui adhère le plus à vos principes, point barre.
Si aucune modification n'a été apportée, on peut quand même modifier l'œuvre originale, sous BSD pure, qui contient le même code.
Exactement
Si une modification a été apportée, la nouvelle licence interdit de modificer l'œuvre modifiée.
Non, ça c'est une spécialité américaine. En France (et pour pratiquement le reste de l'Europe), il n'y a pas de droit d'intégrité pour le logiciel, comme prévu par la convention de Berne. Il ne peut s'opposer à une modification que s'il peut justifier d'un préjudice moral ou une atteinte à son honneur.
En l'état, c'est difficile à tenir en matière de logiciel, parce que la modification vise généralement à corriger ou étendre des fonctionnalités, ce qui a _priori_ n'est pas un préjudice. Le seul préjudice pourrait être financier, mais dans ce cas, c'est du ressort des droits patrimoniaux.
Le code original reste bien sûr disponible sous licence BSD, mais le code dérivé peut être sous n'importe quelle licence (y compris propriétaire), tant que les éventuelles obligations de la licence BSD sont respectées (clause de publicité).
Si le code est modifié, cela devient une oeuvre collaborative. Dans ce régime, seul le "nouveau" code pourra être distribué sous une licence compatible avec la BSD (GPL incluse), mais l'ancienne partie du code garde la licence d'origine et reste sous licence BSD, sauf autorisation des autres auteurs/créateurs.
Libre à celui de distribuer l'ensemble sous des termes différents et plus restrictifs, pour autant:
- la licence de la "vieille" partie ne change pas.
- il faut parler de code "mixte distribué sous BSD et GPL", et non de code "distribué sous GPL", ou de code "distribué sous GPL ou BSD."
Si on peut redistribuer du code sous BSD sous licence propriétaire, ca m'etonnerait qu'on ne puisse pas le redistribuer sous GPL.
Je répète: non.
D'abord, le code n'est pas redistribué sous licence propriétaire, il est redistribué sous une forme compatible avec ce que dit la licence BSD. A aucun moment la licence ne change, mais seulement la forme sous lequel le code est distribué. Ca n'en change pas la licence pour le bout de code BSD.
Ensuite, la BSD autorise à ne pas fournir les sources, ce qui est le cas pour ce que tu appelles du "propriétaire". Suivant sa version, elle peut faire l'objet d'une clause de publicité ou pas; c'est pas parce que la licence n'est pas dument mentionnée qu'elle a subitement changé.
Je répète: on ne peut pas distribuer du code BSD sous licence GPL. Au mieux, tu peux fournir du code sous licence BSD dans un projet GPL, mais ca ne veut pas dire pour autant que le code assujetti à la BSD a été GPLisé.
je ne pense pas qu'il y ait de contradiction. Tu peux redistribuer sous GPL un code sous BSD.
Certainement pas. On ne change pas les termes d'une licence sans le consentement de son auteur, notamment quand cette licence altère le mécanisme de distribution.
Je suis sûr que NetBSD a déjà réimplémenter des fonctions car ils se sont rendu compte que ça ne correspondait plus aux usages. (mais comme je ne lis pas les changelog NetBSD et qu'il n'y a pas de patrick_g-*-BSD, je ne peux pas de dire lesquels).
Il y a régulièrement des refontes, mais quand celles-ci touchent aux interfaces userland <> kernel, elles sont toujours rétro compatibles (y compris au niveau binaire). On maintient donc plusieurs versions, via les COMPAT_*, qui peuvent remonter très loin (jusqu'à la 0.8). A ma connaissance, il n'y a que NetBSD et Solaris qui fassent cet effort et qui peuvent remonter aussi loin.
En revanche, quand ca a lieu à l'intérieur du noyau et que ca reste dans son namespace, ou que les changements ne sont pas visibles directement par une interface "OS" (syscalls) on le fait. Quand les changements ont des impacts au niveau binaire (time_t 32 => 64 par exemple), on versionne les syscalls.
Avantages/inconvénients: avec le temps, il y a eu de gros efforts de faits sur la propreté et les couches d'abstractions (aide beaucoup pour la qualité, la doc et la portabilité). Inconvénient, les implémentations doivent arriver à un consensus, et ca peut prendre beaucoup du temps (on a l'impression que le projet stagne).
Mais le cas des BSD est assez différent de Linux niveau implémentation de la couche réseau. Les BSD préfèrent passer par des ioctl sur des devices (quitte à retravailler les commandes avant de les soumettre, cf ipf(4), pf(4), bpf(4)), tandis que Linux a choisi d'exposer son infra interne via le bloat abracadabrantesque qu'est /proc. C'est très commode à court terme, mais ca finit généralement par exploser en vol quand on doit rajouter des fonctionnalités sur le long terme. Je pense d'ailleurs que c'est le cas ici, et je trouve le choix sage (surtout niveau syntaxe, enfin...)
Il y a bien des domaines où la vente lié existe sans qu'il n'y ait des solutions pour l'éviter. Par exemple en automobile si tu veux acheter ta voiture avec des pneus GoodYear alors que le constructeur à un contrat avec Michelin alors ce n'est pas possible d'avoir d'autre pneus.
Si sur une Citroën C4 tu veux des vitres latérales feuilletées et bien tu es obligé de choisir le modèle de plus haut de gamme et de prendre plus le pack acoustique.
Éculé comme argument, et surtout, _faux_.
La vente liée concerne la vente d'un bien et d'un service, les pneus GoodYear et le pack acoustique sont des packs de _biens_.
La vente liée en automobile, si vous voulez une comparaison, serait de vendre une voiture et l'assurance qui va avec. J'attends de voir la chose.
La différence entre un bien et un service, c'est la notion de propriété. On est propriétaire des pneus GoodYear, et je peux en user comme bon me semble. Le logiciel vendu avec l'ordinateur ca n'est pas le cas, du fait qu'il soit un service.
Parce que:
- il n'y a pas eu encore suffisamment de prise de conscience (étatique et civile) de cette problèmatique: tout le monde achète du windows sans se poser de question, le coût de la chose étant caché (donne une impression de gratuité)
- parce que les commercants sont formés pour être sûrs d'eux même, et un individu n'osera pas, dans 95% des cas, remettre en cause ladite parole de "quelqu'un qui connaît son métier" (qui est de vendre, je rappelle :o )
- parce que les gens voulant faire respecter leurs droits sont obligées de se lancer dans des démarches qui sont pénibles: perte de temps => statu quo.
- lobbies et déresponsabilisation (c'est la faute du constructeur et non du distributeur - très commode excuse que celle là, qui est en plus un argument fallacieux: le distributeur doit aussi s'assurer de la léicité de ses ventes, cf dernièrement l'histoire entre FNAC et Sacem)
- possibilités de moyens de contournement: en gros, "va acheter ailleurs, tu peux". Donc les gens vont effectivement acheter ailleurs (rue montcaillou par exemple), ce qui ne règle pas le problème, mais ses symptomes.
C'est multi factoriel. Maintenant, avec l'impulsion d'associations comme l'april et les associations de consos, cela peut très bien changer rapidement, d'ou les initiatives comme celle-ci:
- c'est un produit complet identifié avec sa reference produit hp XXXX.
- c'est comme la memoire dans l'ordinateur, ce n'est pas de la vente lié, c'est un tous.
Faux.
La vente liée concerne le lien entre la vente de biens et les services, qui relève d'une licence d'exploitation (ce qui est différent du droit des biens, qui eux t'appertiennent intégralement - possession de la facture faisant foi).
Une barrette mémoire est un bien, un logiciel un service (dont tu n'as pas la propriété: quand tu achètes un logiciel, on t'accorde un droit d'exploitation, non de propriété).
La prochaine fois que tu retourneras voir ce vendeur, tu compares:
- la barrette mémoire à une roue de voiture (qui est un bien),
- le logiciel à une assurance (qui est un service).
Bref, c'est du pipeau intégral de vendeur; ca ne tient pas cinq minutes devant quelqu'un qui connait un minimum le code de la consommation.
En revanche, le vendeur peut se retracter, rien ne l'oblige à se conformer à tes exigences du respect du code; l'acheteur ne peut imposer au vendeur de changer son offre, seuls des organismes et des institutions habilités peuvent le faire, et sanctionner ledit vendeur si la chose passe devant Mr le Juge.
Mais il s'agit là d'un format libre, et contrairement au JPEG-2000, les développeurs pourront bosser dessus et rendre ce format pérene parce qu'ayant des applications concrètes.
1 - On entend tout et son contraire avec format libre.
Si c'est par "format libre de droit", JPEG 2000 l'est, dans sa première part (celle dont tout le monde a besoin pour en écrire un lecteur libre). Les autres parts, elle concerne les extensions, et des procédés industriels pour l'implémenter dans des appareils. Il est tout à fait normal que ces parties là soient protégés par de la propriété industrielle, on est plus dans le logiciel pur et dur ici.
Si par "format libre" on entend "j'en fait ce que je veux", c'est du nawak de libriste. C'est un effort de normalisation entre industriels, avec un man power derrière. Cela a un cout. Aucune norme n'est gratuite. A la limite le document peut être en libre accès, ca ne veut pas dire qu'il ne coute rien.
2 - Le JPEG 2000 a des applications concretes. Me concernant, je le vois passer en permanence pour de l'archivage de photos sur négatifs numérisées pour archivage.
Les ondelettes n'ont jamais eu pour objectifs de remplacer JPEG. C'est un algorithme différent du DCT utilisé par défaut dans l'actuel.
Le gros souci de JPEG, c'est... JPEG. Au départ, la norme (la 10918 j'entends) a eu des écueils, qui ont été constaté bien trop tard:
- aucune notion de lossless
- la DCT s'est révélée être désastreuse dans certaines applications, au niveau qualité d'image (restitution).
JPEG 2000 a capoté pour des raisons d'implémentation: les constructeurs ne se sont pas mis d'accord dessus, et des palliatifs pour le lossless sont arrivés très rapidement (le PNG et le DNG, suivant les objectifs).
Les artefacts de la DCT n'étant pas flagrants sur des photos (mais plus sur des diagrammes), personne n'a éprouvé la nécessité d'évoluer.
Maintenant, ca change: le JPEG-XR de Microsoft, c'est bien JPEG 2000 mais réchauffé. C'est la même chose, le marketing en plus. On s'attaque à Adobe et son DNG.
Je souhaite que ce DIS ne passe pas. La normalisation est une activité consensuelle, basée sur des compromis, et on a vu tout sauf cela dans ce BRM. Qu'on l'enterre, et définitivement.
Faut pas exagérer, les virus Linux, ça peut exister sans problèmes. Bon, évidemment, ça suppose sans doute que l'utilisateur lance sciemment le virus, mais bon… :-)
S'il faut comparer les systèmes sur le plan technique, il y a quand même de sacrés bémols pour des unix et dérivés:
- l'utilisateur par défaut n'est pas privilégié (et ne devrait pas l'être) (mais ça n'empêche pas les spambots ni la destruction des données personnelles - le système en revanche lui reste inviolé)
- l'exécution est un droit et non une extension, donc télécharger un fichier ne le rend pas exécutable.
Ce sont deux points qui même sous vista, ne sont pas corrigés (et ne le seront probablement jamais, vu que c'est structurel). A la place, on décharge la responsabilité sur l'utilisateur entièrement en l'assassinant de questions à chaque opération.
Il reste donc le problème des applis qui à terme joueront avec sudo pour outrepasser leurs droits et berner l'utilisateur. A ce stade, il faudra envisager les binaires signés numériquement (on en est pas encore là).
Si l'on en croit groklaw et les liens fournis, le SIS a décidé de laisser tomber le "oui" pour passer en "abstention", compte tenu des récentes remontées ainsi que de la fenêtre trop courte pour une re-étude de la norme.
Il paraîtrait que certains membres, qui sont "engagés" dans la voix du non, subissent des pressions de dernière minute pour changer leur position: France et République Tchèque.
Sans vouloir pousser au troll (mais si, allons y gaiement), les stratégies genre pump and dump pour noyer un vote décisionnel en jouant sur la quantité (et non la qualité des débats), c'est décidément nawak.
Mais pBpG dira qu'on ne fait pas mieux avec l'ODF -_- . Sur ce...
Merci de confirmer qu'avec ODF ces info seraient placees dans office-settings, donc illisibles tout comme avec openxml
Oui, comme tous les attributs spécifiques à une application, et ne faisant pas partie de la spécification.
Le seul souci, c'est que justement, avec l'ODF ces attributs ne sont pas nommés (comment pourrait on vu qu'ils ne sont connus que de l'application qui va les utiliser?)
Bah avec OOXML, c'est du bonus: on colle un attribut, mais en s'empresse d'y marquer "si vous voulez que ca marche, il faut que cle ressemble au rendu fait par l'application en question".
Non seulement Mr Lapalisse est passé par là, mais en plus, niveau archivage, c'est d'une connerie sans nom, car on inclut un attribut dans une norme qui, d'ici 20 ans, n'aura plus aucune application légitime capable de l'interpréter correctement (allons, je doute que notre cher ami Microsoft fournisse le logiciel en question d'ici ce temps?)
On complexifie donc une spécification simplement par laxisme, et on le couche tel quel dans le document afin de prévenir les "ah ben non, voyez, c'est dedans, faut faire avec". Si vous avez des documents word 95 ooxmlisés, on pourra avoir ces attributs à la con qui s'y traine.
ODF décharge cela sur l'application, ce qui est normal. Ca n'est pas à la norme de dire: "faites au mieux". C'est au programme de le faire, point barre. Ca n'a rien à faire dans une spec.
[^] # Re: Génial !
Posté par helkyn . En réponse au journal L'homme qui voulait scripter les fichiers de configuration. Évalué à 3.
Ca serait tellement vrai si seulement le script ne se contentait que de faire des commandes shell en succession... C'est loin d'être le cas. On sort pas l'artillerie uniquement pour executer de la commande shell à la pelle.
Mais on va pas refaire le monde à coup de "chez moi, moi je".
Par contre avec LUA je vais être obligé de me plonger dans le truc pour faire du debug de script si je veux le faire fonctionner à la main. Ca peut aussi virer au jeu de piste avec des fonctions qui apellent d'autres fonctions LUA qui vont chercher des infos à droite, à gauche (base de données, device etc.)
Ca n'a rien d'une propriété du langage ou de l'outil, mais de la programmation. Je peux sortir des scripts Perl imbitables que ca n'y changerait rien. De même pour Python.
Je vais peut être dire une connerie, mais c'était pas un contexte Kerberos SAMBA avec des certificats auto-signés dans le LDAP ? Parce qu'en utilisation authentification sur un réseau pur Unix Kerberos V4 et V5 ca a toujours plutôt bien tourné. Pour les bindings python, j'en ai jamais eu besoin donc ca ne m'a jamais manqué.
Que dalle. Pour créer des comptes Kerberos, gérer un déport du contexte (ou même l'initialiser), soit c'est la magie PAM (donc, solution externe à Python, qui fait justement ce dont je parle), soit faire des os.system("ksu ") avec du pexpect partout. Moche, surtout quand il s'agit de créer des contextes sur un serveur Web (dans les endroits un peu sérieux ou mettre un dn + mdp associé dans un fichier à part pour faire des bind() n'est pas accepté).
Code source != fichier de config. Si le mec veut faire un programme, une interface graphique, un concentrateur de données etc. en Lua, qu'il y aille. Aucun soucis avec moi.
C'est le cas.
Là il s'agit de fichiers de conf, des trucs qui peuvent déjà avoir pas mal d'incidence en aval (genre une erreur dans php.ini qui va joyeusement vautrer MySQL et Apache). A ceci on vient rajouter une possibilité d'incidence en amont (genre le script qui remplace mon php.ini va aller faire mumuse avec mes locales, mes params mémoire ou que sais-je encore). Là c'est non. Tout de suite. En plus on rajoute un interpreteur LUA dans mes serveurs, lequel interpreteur va avoir besoin de droits spécifiques pour exécuter tel ou tel partie du script de conf, dans le kernel parce que c'est plus fun.
Tu discutes d'une implémentation qui n'existe pas, en raisonnant sur des hypothèses qui sont tiennes, après avoir relu un article sur linuxfr. Je t'invite donc dans ce cas à poser tes questions sur tech-userlevel@NetBSD.org et tech-toolchain@NetBSD.org.
Si les scripts d'install par défaut et les scripts de conf font du LUA, je ne vois pas comment je pourrais ne pas les utiliser à part en changeant de métier.
Pourrais-tu montrer les scripts d'install en question? Et les scripts de conf? Si non, encore une fois, pures spéculations. C'est de la critique gratuite pour satisfaire un besoin de critiquer...
Bref c'est une tendance que je n'aime pas. On aurait tout à gagner à ce focaliser sur les points forts du monde Unix plutôt que de chercher à copier des systèmes dont les choix de départ sont très différents des nôtres.
Quels points forts?
La pluralité des API, avec les environnements Linux qui réinventent/changent la roue tous les ans? Ou peut-être les 300 syscalls associés?
Des kernels qui font 20MiB ("small is beautiful", hein?)
Le choix d'avoir voulu externaliser la gestion du graphisme en dehors de l'OS (serveur X), et où maintenant les redites niveau gestion affichage (tty, pseudo tty, console...) sont éloquentes?
Un outil pour une tâche, avec des administrateurs actuels qui lancent python/perl/irb à la première occasion suivant affinité ("when all you have is a hammer, everything looks like a nail")
Le "tout est fichier"...
"Le monde Unix" dont tu parles est mort il y a quelques années maintenant, ou alors au stade de coma dépassé.
C'était à une époque ou les kernels ne faisaient pas dans les 20MiB l'image, où les API étaient simples mais pauvres, où l'usage/l'exploitation du système était reservé à une certaine élite et ne requérait pas le support de fonctionnalités très évoluées.
Pour une argumentation que je rejoins totalement: voir celle de David (Chisnall) http://www.informit.com/articles/article.aspx?p=424451 .
[^] # Re: Beotien sans doute
Posté par helkyn . En réponse au journal L'homme qui voulait scripter les fichiers de configuration. Évalué à 1.
[^] # Re: Génial !
Posté par helkyn . En réponse au journal L'homme qui voulait scripter les fichiers de configuration. Évalué à 4.
Il n'est pas question d'avoir un fourre tout pour que Mr X, qui préfère exim, ait un module Lua qui lui permettra de configurer Postfix avec la magie LDAP. Non.
Vois ca comme ça: pour créer un utilisateur sous Unix, il est quasiment obligatoire de repasser par useradd(8). Si derrière, l'objectif est de faire un script python, qui au final, va appeler une pelle de commandes shell, le python n'a aucun d'intérêt, à part faire de la glue. Et quand il ne sait pas faire, on est coincé.
J'ai connu le temps ou pour exploiter des comptes avec un contexte Kerberos, il fallait jouer avec des variables d'environnement et des fichiers temporaires pour que ca marche, parce que la GSSAPI n'était pas exploitable dans Python... et quand on voit la gueule de l'API, on comprend pourquoi.
Autre exemple: éditer un fichier. Tu souhaites modifier /etc/motd en fonction de la journée. Aujourd'hui: tâche cron obligatoire, qui va appeler un script Perl (parce que le gars préférait Perl), qui va jouer au cat/grep/sed/ ~= <> FILE dedans.
Si tu veux te convaincre de l'utilité de la chose: je t'invite à lire le code source de net-snmp. Quand tu en auras marre de vomir à chaque ligne (entre les #ifdef__LINUX_VERSION_2.6__ && !__LINUX_VERSION_2.4__, les strncmp() dans TOUS les sens pour afficher les points de montage, les options de compil qui ont été activées on ne sait trop comment (merci les autodaubes!), j'espère que tu verras.
Donc oui, chat échaudé craint l'eau froide, le script qui configure automagiquement mes serveurs/params kernel j'en veux pas.
Personne n'obligera à les utiliser.
Il faut bien admettre que la tendance va vers cela, et qu'il n'y a pas beaucoup d'alternatives quand on veut passer à l'échelle (sauf à faire du cfengine/puppet, ce qui revient, au final, à créer des scripts de configuration automagiques... ou jouer avec kickstart -- aïe -- , même joueur joue encore).
PS: que je sache, l'outil omniprésent par excellence sous Unix, le shell, a son comportement contrôlé par un script shell lui même, non (.profile, .*rc, ...)? Ca n'a pas l'air d'avoir dérangé plus que ça ces 30 dernières années.
[^] # Re: Génial !
Posté par helkyn . En réponse au journal L'homme qui voulait scripter les fichiers de configuration. Évalué à 10.
Ce que veut faire Marc est de proposer des modules permettant de contrôler la configuration du base system NetBSD via des modules Lua.
Les objectifs sont, entre autres:
1 - les API C actuellement présentes sont déjà très exhaustives en elles mêmes, et fournissent la majorité des fonctionnalités. Ce qu'il manque, ce sont des wrappers qui permettent de les exploiter dans des programmes avec des langages plus haut niveau.
Pour quelle raison? Une toute bête: scripter de la conf, sous Unix, ca se fait en shell/perl/python/ruby (suivant les affinités des individus...) à grands coups de pipes, popen(), execution de sed/awk/sh/grep/cat qui font que ca en devient bordélique, en plus de pousser à l'erreur. Qui ici vérifie proprement les codes d'erreurs retournés par system() quand il fait ces scripts? En toute honnêteté? Et qui ne se plaint pas quand la regexp de pexpect pète parce que dans la dernière version, "P" est devenu "p"?
Cela permet de pouvoir toucher à des configs clients et d'en déployer/rapporter/modifier facilement, à l'instar de WMI de Windows ou des plist MacOSX.
2 - pour Lunatik (un interpréteur Lua in kernel), et de façon plus générale, Lua+C, cela permet de fournir un environnement plus sûr que ce que donne le C et ses pointeurs. C'est pas comme si le jeu de ces dernières années était de retourner un kernel X ou Y en jouant sur des assignations à NULL ou des débordements de toute sorte, ou d'avoir un parsing de chaînes/octets moisi qui finit avec un exploit.
Il souhaite aussi voir ce que ça donne pour kauth(9), ce qui permettrait (pour l'instant, en théorie) de fournir un environnement pour construire ses propres modèles de sécu avec une vision développeur, plutôt qu'intégrateur (comme SELinux par exemple). Aujourd'hui, c'est C ou rien, ce qui pose un problème quand on développe des moniteurs de référence [1]...
J'attends avec impatience le moment ou je devrait mettre à jour MySQL-Client pour pouvoir recevoir mes mails...
C'est une vision de Linuxien ça. Le basesys d'un BSD forme un tout cohérent. Quand tu utilises le MDA du basesys, il n'est pas question de mettre à jour mysql-client-lib-2.6.7-1294.debian54.libc6.2 pour que ca marche/marche pas. Quand on met à jour, on met à jour l'ensemble du basesys, pas le MDA d'un coté et les "modules" d'un autre, avec une surprise au prochain redémarrage du service.
Quant au reste, le principe d'une interface bien conçue, c'est justement d'éviter cela. C'est pas comme si NetBSD avait accumulé une grosse expérience la dedans avec ses couches d'émulation et de compatibilité binaire depuis 15 ans.
j'aimerais bien savoir comment la sql query est secured aussi. Relation de confiance sur l'utilisateur/machhine ou bien il y a un autre fichier avec un mot de passe quelque part ?
C'est un exemple pour montrer un concept... La chose en est à peine à la conception qu'il faudrait déjà se taper les discussions sur la sémantique et l'implémentation détaillée.
[1] http://en.wikipedia.org/wiki/Reference_monitor
[^] # Re: Utilisez la licence qui vous convient
Posté par helkyn . En réponse au journal Pourquoi vous ne devriez pas utiliser ni la GPL ni la BSD. Évalué à 1.
Les gens de la FSF pensent juste qu'il n'est pas éthique d'écrire du code propriétaire. Voir ce post pour une tentative d'explication : https://linuxfr.org//comments/932032.html#932032
Je ne partage pas le point de vue dans ton lien.
Le progrès engendré par le numérique a diminué les couts de _copie_ pour les rendre bas, voire nuls. Vrai.
En revanche, le numérique n'a certainement pas diminué les couts nécessaire à la création de l'original, de la première idée, qui demande un investissement pas nécessairement négligeable pour que cela soit inventif et nouveau, et affiche un réel progrès.
Si on veut inciter le boulanger à poursuivre à améliorer son pain (même si distribué à cout nul), il faut qu'il y trouve son compte.
[^] # Re: Utilisez la licence qui vous convient
Posté par helkyn . En réponse au journal Pourquoi vous ne devriez pas utiliser ni la GPL ni la BSD. Évalué à 1.
Ce choix est déjà garanti dans la première partie de votre phrase:
"Ce qui devrait relever d'un choix personnel et discrétionnaire c'est l'usage que tu as d'un logiciel"
Tu noteras que personne n'oblige personne à insérer du code sous GPL dans ses logiciels. Je ne vois pas en quoi demander à ce que les programmes dérivés ne puissent permettre d'asservir les utilisateurs de ces programmes (en les empêchant d'accéder aux sources par exemple) est "un frein à la liberté".
C'est un frein à la liberté pour celui qui souhaite réutiliser les sources, sans pour autant devoir obéir à ce qu'un autre a décidé.
Ce qu'on appelle souvent "innovation" dans le monde industriel est souvent un moyen de faire du pognon, au détriment parfois du reste du monde. Les brevets par exemple sont dits faits pour la favoriser. [insérer ici le nom d'un éditeur de logiciel propriétaires que vous n'aimez pas] par exemple ne veut pas de code sous GPL mais pose des brevets : voilà qui favorise activement l'innovation, et la liberté surtout !
C'est une vision réductrice de discussion bar PMU, le "on nous ment on nous spolie", "le méchant industriel aura notre peau"...
Les brevets visaient à l'origine a participer à la création et l'innovation en permettant à un inventeur de jouir exclusivement de ses inventions, tout en permettant de les diffuser, pour que d'autres puissent en profiter et les améliorer à leur tour. Complètement à l'opposé du secret industriel.
Si le système a été perverti ensuite, c'est un autre débat. On a les gouvernants que l'on mérite. Mais c'est hors sujet.
Arf ? C'est ce que disent les éditeurs comme Microsoft : "la liberté est virale". Heureusement qu'eux luttent activement pour empêcher que ce virus ne se répande ! D'ailleurs je crois pas que Microsoft ne t'autorise à emprunter beaucoup de son code, même pour que tu fasses un programme sous BSD qui pourra redevenir privateur après.
Le fait que je ne puisse pas emprunter de son code ne m'empêche vraiment pas de dormir.
Ils contribuaient tellement bien à Linux qu'ils ont du développer leur propre version séparément pour Android.
C'est un problème?
Si quelqu'un ou quelque chose devait "libérer" GoogleFS, c'est Google. Pour que la GPL s'applique il doit y avoir distribution du code. Si tu veux modifier un prog sous GPL sans révéler tes modifications, tu le peux, à partir du moment où tu gardes les binaires pour toi.
Vision très réductrice.
Si je comprends bien, avoir un binaire sans les sources est privateur de liberté, mais un éditeur qui offre des services sans avoir de réel controle dessus (indexation des mails? moteur de recherche omniprésent?) n'en pose pas. Bon... faut croire que la carotte est bonne.
Parce que la GPL n'a pas pour objectif "d'asseoir" des technologies mais d'encourager le partage (et des technologies et des connaissances qui ont permis leur création) sans que cela se fasse au détriment des utilisateurs ?
L'innovation technologique, la recherche, la connaissance, a un cout. Et ce cout, suivant le contexte, doit être supporté. Pour un industriel, cela se fait en vendant des produits et des services, qui ne peuvent être partagés "gratuitement". Certains le font en espèces sonnantes et trébuchantes, d'autres en accumulant des informations pour mieux cibler la publicité.
Dans l'enseignement et la recherche publique, ce sont vos impots (ou ceux de vos parents) qui le permettent.
Faut arrêter avec l'idéologie du "je partage tout, même mon lit et mon porte monnaie..."
[^] # Re: Utilisez la licence qui vous convient
Posté par helkyn . En réponse au journal Pourquoi vous ne devriez pas utiliser ni la GPL ni la BSD. Évalué à 3.
Actuellement, je pensais à l'inverse. Vous pouvez copier/coller à peu près ce que vous voulez de code BSD, MPL est plus restrictif (granularité plus difficile à gérer). Entre autres.
Tout simplement parce que, pour moi, c'est du bon sens, et que c'est la moindre des choses.
C'est subjectif comme appréciation donc, le "bon sens" étant affaire d'appréciation. Vous devriez donc pouvoir admettre que d'autres personnes, physiques ou morales ne partagent pas votre opinion, sans la remettre en cause, et imposer votre point de vue.
Si Google mettait toutes ses technos en libre (pagerank, googlefs), l'entreprise aurait-elle les moyens de contribuer autant aux LLs? Existerait-elle d'ailleurs tel quel aujourd'hui?
Je ne pense pas. Je suis d'avis que c'est un équilibre, réglé en permanence, et qu'il ne faut pas adopter une vision aussi tranchée que celle prônée par quelques licences libres.
Qui dit que ça n'aurait pas été le cas avec une licence de type MPL ?
Je pense qu'une licence doit être simple pour être comprise et ne pas inspirer doute et peur à son sujet. La MPL n'en est pas une, de mon point de vue.
En plus, moi il me semble que c'est un argument tiré par les cheveux, un argument forcé qu'on a trouvé pour justifier la BSD.
Pas du tout, c'est historique... Le dernier exemple récent étant WebM.
Et retournement encore une fois le truc : imagine que Microsoft ait réussi à imposer ses merdes non standards comme les .doc, IE etc... grâce à du code BSD ?
Parce qu'il n'aurait pas pu avec du code GPL? Google a GoogleFS, pourtant Linux est GPL non?
Et le fait d'avoir le code y aurait changé quelque chose? Il va falloir vous mettre à l'idée que la licence n'y change rien. D'ailleurs, je renvoie à la première page de Chisnall, qui raconte l'histoire de l'objective C dans GCC [1].
Prenons un exemple pas totalement imaginaire.
Supposons que NTFS ait été développé grâce à du code soit sous BSD, soit sous MPL, et qu'il n'est pas documenté.
Dans le premier cas, pour pouvoir le lire sous Linux, je suis obligé de faire du reverse engineering de tout leur programme.
Dans le deuxième cas, ça sera peut être un peu plus facile puisque Microsoft aura diffusé le source d'une partie du programme.
Soyons clair: le problème ici ne vient pas du code, mais de la _documentation_. Il faut vraiment être timbré pour croire que du code se passe de spécifications, ou de commentaires, simplement parce qu'il sera rendu ouvert par une quelconque licence. Ce sont deux choses qui n'ont rien à voir.
La GPL ou la MPL ne vont pas "magiquement" aider à faire du RE d'ailleurs. Je te laisse t'en convaincre avec le travail de Damien (Bergamini) sur les drivers Intel, et la niouz de patrick_g [2]. Pourtant, le code de l'un est pseudo-ouvert GPL, et l'autre BSD. L'histoire du wrapper de 15k lignes doit rappeler une remarque que j'ai faite un peu au dessus.
[1] http://www.informit.com/articles/article.aspx?p=1390172
[2] http://linuxfr.org/~patrick_g/21744.html
[^] # Re: Utilisez la licence qui vous convient
Posté par helkyn . En réponse au journal Pourquoi vous ne devriez pas utiliser ni la GPL ni la BSD. Évalué à 7.
- mes principes ne s'appliquent pas suivant une granularité fichier/projet, mais sur du code. Je ne souhaite pas que l'on dénature du code simplement pour des considérations de "rangement."
- la MPL et la GPL (2,3) sont difficilement compatibles. La BSD ne me pose pas autant de problème quand il s'agit d'intégrer différentes sources.
- dernièrement, pour le projet sur lequel je travaille (NetBSD), chaque fois que je vois un projet qui commence à avoir du succès, il se retrouve sous "multi-licences" pour faciliter son usage. Ok, pourquoi pas, mais on se fait des noeuds au cerveau...
J'aimerais que tu m'expliques au nom de quoi quelqu'un qui modifie un code ne devrait pas partager ces changements (et uniquement ceux-ci).
Parce que je considère que la liberté se mesure à la longueur de la chaine, et que ca n'est pas à moi de fixer les règles d'usage de ce que font les autres. Je respecte le droit à disposer de soi même, de ses oeuvres, d'en diffuser (ou pas) leur contenu, y compris de s'inspirer du travail des autres.
L'innovation a toujours fonctionné comme cela, et non en dressant des barrières d'un coté ou de l'autre. Je considère que je n'ai pas à imposer mes valeurs aux autres via mon travail intellectuel.
Maintenant, inversons la charge: J'aimerais que tu m'expliques au nom de quoi quelqu'un qui modifie un code devrait-il partager ces changements?
Autrement dit, quel est l'intérêt de la licence BSD par rapport à la MPL ? (du point de vue du développeur/contributeur devant choisir entre les deux).
- La facilité d'inclure du code sous cette licence, sans s'arracher les cheveux.
- une excellente licence quand il s'agit de diffuser des idées et des implémentations. Si l'API socket, la pile TCP/IP, ou encore WebM (je lui souhaite) se sont imposés/s'imposeront, c'est en partie parce que les premières implémentations étaient BSD. Regardons dernièrement l'histoire de la doc GCC, ca fait peur, rien qu'en terme de qualité [1].
- pas de noeud au cerveau avec ces histoires de "compatibilité avec la GPL -- la FSF a déclaré que c'était compatible (de quel droit d'ailleurs? la FSF est souveraine en la matière?)
Je fonctionne comme un ingénieur, pas un avocat, un juriste, ou un leader d'opinion.
[1] http://lwn.net/Articles/394219/
# Utilisez la licence qui vous convient
Posté par helkyn . En réponse au journal Pourquoi vous ne devriez pas utiliser ni la GPL ni la BSD. Évalué à 10.
"While NetBSD uses the GNU toolchain (compiler, assembler, etc), and certain other GNU tools, the entire kernel and the core of the userland utilities are shipped under a BSD licence. This allows companies to develop products based on NetBSD without the requirement to make changes public (as with the GPL). While the NetBSD Project encourages companies and individuals to feed back changes to the tree, we respect their right to make that decision themselves."
Ils justifient la BSD, par la GPL.
Nulle part. On y explique que la décision de reverser du code (ou non) n'est pas du ressort de la licence, mais d'un choix personnel et discrétionnaire (les GPListes aiment bien parler de liberté, en voici une que leur licence ne respecte pas).
Or, ce qui rend impopulaire la GPL pour les entreprises, ce n'est pas le « requirement to make changes public » (l'obligation de rendre les changements publics), c'est l'obligation de rendre du code qui ne fait qu'utiliser du code sous GPL, lui même sous les conditions de la GPL.
Le problème ne se pose pas que pour les entreprises, mais les individus aussi... s'ils souhaitent utiliser du code sous GPL, alors tout leur projet passe systématiquement sous GPL. Les seuls contournements (bidouilles?) étant de jouer avec des bibliothèques, faire des wrappers... C'est aussi un frein à la liberté et l'innovation.
Ca serait bien d'éviter des clivages stupides "gentils libristes GPL" vs "méchante entreprise propriétaire".
La viralité de la GPL est un problème, l'obligation de rendre les changements publics aussi (sous certaines conditions cela dit...), et n'est pas à sous estimer. Google est un grand contributeur aux LLs, notamment Linux. La GPL n'a jamais libéré GoogleFS, que je sache? Et pourquoi avoir mis WebM sous BSD-like et non GPL, si ce n'est pour mieux asseoir une techno dans un monde industriel?
Ceux qui utilisent la licence BSD, le font parce qu'ils n'aiment pas la GPL.
N'importe quoi. Je développe sous BSD, et je ne code pas sous BSD parce que "je n'aime pas la GPL", mais simplement parce que la BSD se rapproche le plus de mes principes.
Si je devais résumer les objectifs de chacune, et là où je rejoins David Chisnall [1]:
- les gens de la FSF pensent que l'on attaque la communauté quand la quantité de logiciel proprio augmente, et qu'en ce sens, il faut placer du code sous une licence qui empêche d'en faire.
- ceux sous BSD, ou équivalent, considèrent que la communauté bénéficie de l'accroissement du nombre de projets pouvant tirer parti de code libre pour sa grande valeur ajoutée, sa qualité, j'en passe.
Point de vue différent, idéologie différente. Vous utilisez la licence qui adhère le plus à vos principes, point barre.
[1] http://www.informit.com/articles/article.aspx?p=1390172
[^] # Re: Nintendo
Posté par helkyn . En réponse à la dépêche ScummVM dans des jeux Atari, au mépris de la GPL. Évalué à 1.
Exactement
Si une modification a été apportée, la nouvelle licence interdit de modificer l'œuvre modifiée.
Non, ça c'est une spécialité américaine. En France (et pour pratiquement le reste de l'Europe), il n'y a pas de droit d'intégrité pour le logiciel, comme prévu par la convention de Berne. Il ne peut s'opposer à une modification que s'il peut justifier d'un préjudice moral ou une atteinte à son honneur.
En l'état, c'est difficile à tenir en matière de logiciel, parce que la modification vise généralement à corriger ou étendre des fonctionnalités, ce qui a _priori_ n'est pas un préjudice. Le seul préjudice pourrait être financier, mais dans ce cas, c'est du ressort des droits patrimoniaux.
[^] # Re: Nintendo
Posté par helkyn . En réponse à la dépêche ScummVM dans des jeux Atari, au mépris de la GPL. Évalué à 2.
Si le code est modifié, cela devient une oeuvre collaborative. Dans ce régime, seul le "nouveau" code pourra être distribué sous une licence compatible avec la BSD (GPL incluse), mais l'ancienne partie du code garde la licence d'origine et reste sous licence BSD, sauf autorisation des autres auteurs/créateurs.
Libre à celui de distribuer l'ensemble sous des termes différents et plus restrictifs, pour autant:
- la licence de la "vieille" partie ne change pas.
- il faut parler de code "mixte distribué sous BSD et GPL", et non de code "distribué sous GPL", ou de code "distribué sous GPL ou BSD."
[^] # Re: Nintendo
Posté par helkyn . En réponse à la dépêche ScummVM dans des jeux Atari, au mépris de la GPL. Évalué à 1.
http://www.linuxtoday.com/news_story.php3?ltsn=2007-09-04-02(...)
[^] # Re: Nintendo
Posté par helkyn . En réponse à la dépêche ScummVM dans des jeux Atari, au mépris de la GPL. Évalué à 1.
Je répète: non.
D'abord, le code n'est pas redistribué sous licence propriétaire, il est redistribué sous une forme compatible avec ce que dit la licence BSD. A aucun moment la licence ne change, mais seulement la forme sous lequel le code est distribué. Ca n'en change pas la licence pour le bout de code BSD.
Ensuite, la BSD autorise à ne pas fournir les sources, ce qui est le cas pour ce que tu appelles du "propriétaire". Suivant sa version, elle peut faire l'objet d'une clause de publicité ou pas; c'est pas parce que la licence n'est pas dument mentionnée qu'elle a subitement changé.
Je répète: on ne peut pas distribuer du code BSD sous licence GPL. Au mieux, tu peux fournir du code sous licence BSD dans un projet GPL, mais ca ne veut pas dire pour autant que le code assujetti à la BSD a été GPLisé.
[^] # Re: Nintendo
Posté par helkyn . En réponse à la dépêche ScummVM dans des jeux Atari, au mépris de la GPL. Évalué à 3.
Certainement pas. On ne change pas les termes d'une licence sans le consentement de son auteur, notamment quand cette licence altère le mécanisme de distribution.
[^] # Re: Linux ou comment on utilisait de la merde pendant 10ans...
Posté par helkyn . En réponse à la dépêche nftables, successeur d'iptables. Évalué à 2.
Il y a régulièrement des refontes, mais quand celles-ci touchent aux interfaces userland <> kernel, elles sont toujours rétro compatibles (y compris au niveau binaire). On maintient donc plusieurs versions, via les COMPAT_*, qui peuvent remonter très loin (jusqu'à la 0.8). A ma connaissance, il n'y a que NetBSD et Solaris qui fassent cet effort et qui peuvent remonter aussi loin.
En revanche, quand ca a lieu à l'intérieur du noyau et que ca reste dans son namespace, ou que les changements ne sont pas visibles directement par une interface "OS" (syscalls) on le fait. Quand les changements ont des impacts au niveau binaire (time_t 32 => 64 par exemple), on versionne les syscalls.
Avantages/inconvénients: avec le temps, il y a eu de gros efforts de faits sur la propreté et les couches d'abstractions (aide beaucoup pour la qualité, la doc et la portabilité). Inconvénient, les implémentations doivent arriver à un consensus, et ca peut prendre beaucoup du temps (on a l'impression que le projet stagne).
Mais le cas des BSD est assez différent de Linux niveau implémentation de la couche réseau. Les BSD préfèrent passer par des ioctl sur des devices (quitte à retravailler les commandes avant de les soumettre, cf ipf(4), pf(4), bpf(4)), tandis que Linux a choisi d'exposer son infra interne via le bloat abracadabrantesque qu'est /proc. C'est très commode à court terme, mais ca finit généralement par exploser en vol quand on doit rajouter des fonctionnalités sur le long terme. Je pense d'ailleurs que c'est le cas ici, et je trouve le choix sage (surtout niveau syntaxe, enfin...)
[^] # Re: Le problème de la vente lié est très loin d'être réglé
Posté par helkyn . En réponse à la dépêche Vente liée/action de groupe dans le projet de loi de modernisation de l'économie. Évalué à 7.
Si sur une Citroën C4 tu veux des vitres latérales feuilletées et bien tu es obligé de choisir le modèle de plus haut de gamme et de prendre plus le pack acoustique.
Éculé comme argument, et surtout, _faux_.
La vente liée concerne la vente d'un bien et d'un service, les pneus GoodYear et le pack acoustique sont des packs de _biens_.
La vente liée en automobile, si vous voulez une comparaison, serait de vendre une voiture et l'assurance qui va avec. J'attends de voir la chose.
La différence entre un bien et un service, c'est la notion de propriété. On est propriétaire des pneus GoodYear, et je peux en user comme bon me semble. Le logiciel vendu avec l'ordinateur ca n'est pas le cas, du fait qu'il soit un service.
[^] # Re: Comme d'habitude, le vendeur raconte des bêtises
Posté par helkyn . En réponse au journal vente liée: discussion. Évalué à 10.
- il n'y a pas eu encore suffisamment de prise de conscience (étatique et civile) de cette problèmatique: tout le monde achète du windows sans se poser de question, le coût de la chose étant caché (donne une impression de gratuité)
- parce que les commercants sont formés pour être sûrs d'eux même, et un individu n'osera pas, dans 95% des cas, remettre en cause ladite parole de "quelqu'un qui connaît son métier" (qui est de vendre, je rappelle :o )
- parce que les gens voulant faire respecter leurs droits sont obligées de se lancer dans des démarches qui sont pénibles: perte de temps => statu quo.
- lobbies et déresponsabilisation (c'est la faute du constructeur et non du distributeur - très commode excuse que celle là, qui est en plus un argument fallacieux: le distributeur doit aussi s'assurer de la léicité de ses ventes, cf dernièrement l'histoire entre FNAC et Sacem)
- possibilités de moyens de contournement: en gros, "va acheter ailleurs, tu peux". Donc les gens vont effectivement acheter ailleurs (rue montcaillou par exemple), ce qui ne règle pas le problème, mais ses symptomes.
C'est multi factoriel. Maintenant, avec l'impulsion d'associations comme l'april et les associations de consos, cela peut très bien changer rapidement, d'ou les initiatives comme celle-ci:
http://www.racketiciel.info/guide/index
# Comme d'habitude, le vendeur raconte des bêtises
Posté par helkyn . En réponse au journal vente liée: discussion. Évalué à 10.
- c'est un produit complet identifié avec sa reference produit hp XXXX.
- c'est comme la memoire dans l'ordinateur, ce n'est pas de la vente lié, c'est un tous.
Faux.
La vente liée concerne le lien entre la vente de biens et les services, qui relève d'une licence d'exploitation (ce qui est différent du droit des biens, qui eux t'appertiennent intégralement - possession de la facture faisant foi).
Une barrette mémoire est un bien, un logiciel un service (dont tu n'as pas la propriété: quand tu achètes un logiciel, on t'accorde un droit d'exploitation, non de propriété).
La prochaine fois que tu retourneras voir ce vendeur, tu compares:
- la barrette mémoire à une roue de voiture (qui est un bien),
- le logiciel à une assurance (qui est un service).
Bref, c'est du pipeau intégral de vendeur; ca ne tient pas cinq minutes devant quelqu'un qui connait un minimum le code de la consommation.
En revanche, le vendeur peut se retracter, rien ne l'oblige à se conformer à tes exigences du respect du code; l'acheteur ne peut imposer au vendeur de changer son offre, seuls des organismes et des institutions habilités peuvent le faire, et sanctionner ledit vendeur si la chose passe devant Mr le Juge.
[^] # Re: Tiens les ondelettes... encore....
Posté par helkyn . En réponse à la dépêche Schrödinger 1.0 : le codec Dirac est prêt. Évalué à 0.
1 - On entend tout et son contraire avec format libre.
Si c'est par "format libre de droit", JPEG 2000 l'est, dans sa première part (celle dont tout le monde a besoin pour en écrire un lecteur libre). Les autres parts, elle concerne les extensions, et des procédés industriels pour l'implémenter dans des appareils. Il est tout à fait normal que ces parties là soient protégés par de la propriété industrielle, on est plus dans le logiciel pur et dur ici.
Si par "format libre" on entend "j'en fait ce que je veux", c'est du nawak de libriste. C'est un effort de normalisation entre industriels, avec un man power derrière. Cela a un cout. Aucune norme n'est gratuite. A la limite le document peut être en libre accès, ca ne veut pas dire qu'il ne coute rien.
2 - Le JPEG 2000 a des applications concretes. Me concernant, je le vois passer en permanence pour de l'archivage de photos sur négatifs numérisées pour archivage.
[^] # Re: Tiens les ondelettes... encore....
Posté par helkyn . En réponse à la dépêche Schrödinger 1.0 : le codec Dirac est prêt. Évalué à 10.
Le gros souci de JPEG, c'est... JPEG. Au départ, la norme (la 10918 j'entends) a eu des écueils, qui ont été constaté bien trop tard:
- aucune notion de lossless
- la DCT s'est révélée être désastreuse dans certaines applications, au niveau qualité d'image (restitution).
JPEG 2000 a capoté pour des raisons d'implémentation: les constructeurs ne se sont pas mis d'accord dessus, et des palliatifs pour le lossless sont arrivés très rapidement (le PNG et le DNG, suivant les objectifs).
Les artefacts de la DCT n'étant pas flagrants sur des photos (mais plus sur des diagrammes), personne n'a éprouvé la nécessité d'évoluer.
Maintenant, ca change: le JPEG-XR de Microsoft, c'est bien JPEG 2000 mais réchauffé. C'est la même chose, le marketing en plus. On s'attaque à Adobe et son DNG.
# NB
Posté par helkyn . En réponse au journal OOXML dans les choux d'ici 30 jours. Évalué à 10.
NBs ?? connais pas ...
National Bodies.
Je souhaite que ce DIS ne passe pas. La normalisation est une activité consensuelle, basée sur des compromis, et on a vu tout sauf cela dans ce BRM. Qu'on l'enterre, et définitivement.
[^] # Re: Carte vitale ?
Posté par helkyn . En réponse à la dépêche Medintux : Médecin, étudiant vous êtes concerné. Évalué à 1.
Bon courage à toute l'équipe d'ailleurs, continuez, c'est du super boulot :)
[^] # Re: Syndrome de Stockholm
Posté par helkyn . En réponse à la dépêche OpenXML recalé par l'ISO. Évalué à 1.
S'il faut comparer les systèmes sur le plan technique, il y a quand même de sacrés bémols pour des unix et dérivés:
- l'utilisateur par défaut n'est pas privilégié (et ne devrait pas l'être) (mais ça n'empêche pas les spambots ni la destruction des données personnelles - le système en revanche lui reste inviolé)
- l'exécution est un droit et non une extension, donc télécharger un fichier ne le rend pas exécutable.
Ce sont deux points qui même sous vista, ne sont pas corrigés (et ne le seront probablement jamais, vu que c'est structurel). A la place, on décharge la responsabilité sur l'utilisateur entièrement en l'assassinant de questions à chaque opération.
Il reste donc le problème des applis qui à terme joueront avec sudo pour outrepasser leurs droits et berner l'utilisateur. A ce stade, il faudra envisager les binaires signés numériquement (on en est pas encore là).
# Le SIS compte s'abstenir pour le 2 septembre
Posté par helkyn . En réponse au journal Microsoft a confirme avoir achete le vote de la Suede!. Évalué à 2.
http://www.groklaw.net/article.php?story=20070830155109351
Il paraîtrait que certains membres, qui sont "engagés" dans la voix du non, subissent des pressions de dernière minute pour changer leur position: France et République Tchèque.
Sans vouloir pousser au troll (mais si, allons y gaiement), les stratégies genre pump and dump pour noyer un vote décisionnel en jouant sur la quantité (et non la qualité des débats), c'est décidément nawak.
Mais pBpG dira qu'on ne fait pas mieux avec l'ODF -_- . Sur ce...
[^] # Re: quelques explications s'il vous plait
Posté par helkyn . En réponse à la dépêche Et la guerre des formats bureautique continue. Évalué à 8.
Oui, comme tous les attributs spécifiques à une application, et ne faisant pas partie de la spécification.
Le seul souci, c'est que justement, avec l'ODF ces attributs ne sont pas nommés (comment pourrait on vu qu'ils ne sont connus que de l'application qui va les utiliser?)
Bah avec OOXML, c'est du bonus: on colle un attribut, mais en s'empresse d'y marquer "si vous voulez que ca marche, il faut que cle ressemble au rendu fait par l'application en question".
Non seulement Mr Lapalisse est passé par là, mais en plus, niveau archivage, c'est d'une connerie sans nom, car on inclut un attribut dans une norme qui, d'ici 20 ans, n'aura plus aucune application légitime capable de l'interpréter correctement (allons, je doute que notre cher ami Microsoft fournisse le logiciel en question d'ici ce temps?)
On complexifie donc une spécification simplement par laxisme, et on le couche tel quel dans le document afin de prévenir les "ah ben non, voyez, c'est dedans, faut faire avec". Si vous avez des documents word 95 ooxmlisés, on pourra avoir ces attributs à la con qui s'y traine.
ODF décharge cela sur l'application, ce qui est normal. Ca n'est pas à la norme de dire: "faites au mieux". C'est au programme de le faire, point barre. Ca n'a rien à faire dans une spec.