Dans l'article <ee5ub7$2pmk$, Michel Talon disait :
Les paquets Debian ne sont pas liés aux releases, ce que tu dis est vrai pour la version Stable. Dans Unstable et Testing il y a justement des paquets qui arrivent constamment par le haut, sont testés aussi bien pour leur fonctionnement que pour leur compatibilité avec le reste, et s'ils résistent
Donc pour être à jour de plein de choses faut être en Unstable ou Testing. C'est complètement contraire au raisonnable, surtout dans le cas de serveurs sensés être stables.
C'est du n'importe quoi comme philosopie. Tout comme c'est n'importe qu'oi de faire des « backports » de patches parce qu'on ne modifie pas ce qui est dans Stable.
Par conséquent, à supposer que le mainteneur du paquet atk ne se soit pas bourré dans ses mentions, s'il sait que le paquet 2.3.4-1 contient l'ABI adéquate, mais pas les versions antérieures, ceci produit exactement l'effet que tu veux. J'ai cru comprendre que le pkgsrc de NetBSD avait le même genre de choses.
FreeBSD l'a aussi pour les ports et on peut forcer pour les paquets binaires mais ce n'est pas propre.
des paquets binaires présents en local, et ça a pris 4 ou 5 *heures*. Comme disent les anglais, la preuve est dans le pudding.
« Something's fishy there » comme disent nos amis Anglo-saxons. Une mise à jour via les paquets binaires ne prend pas autant de temps, il a du décider de recompiler. Tu peux forcer le mode binaire via « -PP ».
veux voir *tous* les paquets nécessaires à l'upgrade sans exception présents sur la machine avant de commencer à désinstaller ou upgrader quoi que ce soit,
portupgrade -rFPP
force la récupération des paquets binaires uniquement.
Pour dire des choses plus spécifiques à portupgrade, il n'est pas rare que l'option -P ne soit pas obéie, même quand il a le paquet binaire sous le nez, et même avec l'option -PP. Ce qui rend le fonctionnement non déterministe.
Dans ce cas, c'est un bug à signaler en tant que tel. Le pire que j'ai vu c'est qu'il ne trouve pas les paquets et donc refuse la mise à jour avec -PP.
-- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Dans l'article <ee5ub7$2pmk$1@asmodee.lpthe.jussieu.fr>,
Michel Talon <talon@lpthe.jussieu.fr> disait :
Les paquets Debian ne sont pas liés aux releases, ce que tu dis est vrai pour
la version Stable. Dans Unstable et Testing il y a justement des paquets qui
arrivent constamment par le haut, sont testés aussi bien pour leur
fonctionnement que pour leur compatibilité avec le reste, et s'ils résistent
Donc pour être à jour de plein de choses faut être en Unstable ou Testing.
C'est complètement contraire au raisonnable, surtout dans le cas de serveurs
sensés être stables.
C'est du n'importe quoi comme philosopie. Tout comme c'est n'importe qu'oi de
faire des « backports » de patches parce qu'on ne modifie pas ce qui est dans
Stable.
Par conséquent, à supposer que le mainteneur du paquet atk ne se soit pas
bourré dans ses mentions, s'il sait que le paquet 2.3.4-1 contient l'ABI
adéquate, mais pas les versions antérieures, ceci produit exactement l'effet
que tu veux. J'ai cru comprendre que le pkgsrc de NetBSD avait le même genre
de choses.
FreeBSD l'a aussi pour les ports et on peut forcer pour les paquets binaires
mais ce n'est pas propre.
des paquets binaires présents en local, et ça a pris 4 ou 5 *heures*. Comme
disent les anglais, la preuve est dans le pudding.
« Something's fishy there » comme disent nos amis Anglo-saxons. Une mise à jour via les paquets binaires ne prend pas autant de temps, il a du décider de recompiler. Tu peux forcer le mode binaire via « -PP ».
veux voir *tous* les paquets nécessaires à l'upgrade sans exception présents
sur la machine avant de commencer à désinstaller ou upgrader quoi que ce
soit,
portupgrade -rFPP
force la récupération des paquets binaires uniquement.
Pour dire des choses plus spécifiques à portupgrade, il n'est pas rare que
l'option -P ne soit pas obéie, même quand il a le paquet binaire sous le nez,
et même avec l'option -PP. Ce qui rend le fonctionnement non déterministe.
Dans ce cas, c'est un bug à signaler en tant que tel. Le pire que j'ai vu
c'est qu'il ne trouve pas les paquets et donc refuse la mise à jour avec -PP.
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- roberto@FreeBSD.org
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Dans l'article <ee5ub7$2pmk$, Michel Talon disait :
Les paquets Debian ne sont pas liés aux releases, ce que tu dis est vrai pour la version Stable. Dans Unstable et Testing il y a justement des paquets qui arrivent constamment par le haut, sont testés aussi bien pour leur fonctionnement que pour leur compatibilité avec le reste, et s'ils résistent
Donc pour être à jour de plein de choses faut être en Unstable ou Testing. C'est complètement contraire au raisonnable, surtout dans le cas de serveurs sensés être stables.
C'est du n'importe quoi comme philosopie. Tout comme c'est n'importe qu'oi de faire des « backports » de patches parce qu'on ne modifie pas ce qui est dans Stable.
Par conséquent, à supposer que le mainteneur du paquet atk ne se soit pas bourré dans ses mentions, s'il sait que le paquet 2.3.4-1 contient l'ABI adéquate, mais pas les versions antérieures, ceci produit exactement l'effet que tu veux. J'ai cru comprendre que le pkgsrc de NetBSD avait le même genre de choses.
FreeBSD l'a aussi pour les ports et on peut forcer pour les paquets binaires mais ce n'est pas propre.
des paquets binaires présents en local, et ça a pris 4 ou 5 *heures*. Comme disent les anglais, la preuve est dans le pudding.
« Something's fishy there » comme disent nos amis Anglo-saxons. Une mise à jour via les paquets binaires ne prend pas autant de temps, il a du décider de recompiler. Tu peux forcer le mode binaire via « -PP ».
veux voir *tous* les paquets nécessaires à l'upgrade sans exception présents sur la machine avant de commencer à désinstaller ou upgrader quoi que ce soit,
portupgrade -rFPP
force la récupération des paquets binaires uniquement.
Pour dire des choses plus spécifiques à portupgrade, il n'est pas rare que l'option -P ne soit pas obéie, même quand il a le paquet binaire sous le nez, et même avec l'option -PP. Ce qui rend le fonctionnement non déterministe.
Dans ce cas, c'est un bug à signaler en tant que tel. Le pire que j'ai vu c'est qu'il ne trouve pas les paquets et donc refuse la mise à jour avec -PP.
-- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Thierry Thomas
Mardi 12 septembre 2006 à 09:23 GMT, Michel Talon a écrit :
Pour dire des choses plus spécifiques à portupgrade, il n'est pas rare que l'option -P ne soit pas obéie, même quand il a le paquet binaire sous le nez, et même avec l'option -PP. Ce qui rend le fonctionnement non déterministe.
Je coupe le reste, parce qu'il y a des trucs qui m'échappent (une m. à j. binaire a toujours été très rapide chez moi...). L'option -P de portupgrade est déterministe, mais elle ne prend pas les packages dès qu'une option a été spécifiée : dans ce cas il faut utiliser -PP.
Pour répondre le mieux possible à la demande, il faut utiliser le port tinderbox, et construire les paquets binaires dedans. Bien sûr, ça prend du temps pour compiler, mais c'est utile pour m. à j. un ensemble de machines à coup sûr. Note : ça n'utilise pas de jail, mais un environnement chrooté, et l'arbre des ports - y compris les packages générés - est accessible par montage NFS ou nullfs. -- Th. Thomas.
Mardi 12 septembre 2006 à 09:23 GMT, Michel Talon a écrit :
Pour dire des choses plus spécifiques à portupgrade, il n'est pas rare que
l'option -P ne soit pas obéie, même quand il a le paquet binaire sous le nez,
et même avec l'option -PP. Ce qui rend le fonctionnement non déterministe.
Je coupe le reste, parce qu'il y a des trucs qui m'échappent (une m. à
j. binaire a toujours été très rapide chez moi...). L'option -P de
portupgrade est déterministe, mais elle ne prend pas les packages dès
qu'une option a été spécifiée : dans ce cas il faut utiliser -PP.
Pour répondre le mieux possible à la demande, il faut utiliser le port
tinderbox, et construire les paquets binaires dedans. Bien sûr, ça prend
du temps pour compiler, mais c'est utile pour m. à j. un ensemble de
machines à coup sûr. Note : ça n'utilise pas de jail, mais un
environnement chrooté, et l'arbre des ports - y compris les packages
générés - est accessible par montage NFS ou nullfs.
--
Th. Thomas.
Mardi 12 septembre 2006 à 09:23 GMT, Michel Talon a écrit :
Pour dire des choses plus spécifiques à portupgrade, il n'est pas rare que l'option -P ne soit pas obéie, même quand il a le paquet binaire sous le nez, et même avec l'option -PP. Ce qui rend le fonctionnement non déterministe.
Je coupe le reste, parce qu'il y a des trucs qui m'échappent (une m. à j. binaire a toujours été très rapide chez moi...). L'option -P de portupgrade est déterministe, mais elle ne prend pas les packages dès qu'une option a été spécifiée : dans ce cas il faut utiliser -PP.
Pour répondre le mieux possible à la demande, il faut utiliser le port tinderbox, et construire les paquets binaires dedans. Bien sûr, ça prend du temps pour compiler, mais c'est utile pour m. à j. un ensemble de machines à coup sûr. Note : ça n'utilise pas de jail, mais un environnement chrooté, et l'arbre des ports - y compris les packages générés - est accessible par montage NFS ou nullfs. -- Th. Thomas.
talon
Ollivier Robert wrote:
Dans l'article <ee5ub7$2pmk$, Michel Talon disait :
Les paquets Debian ne sont pas liés aux releases, ce que tu dis est vrai pour la version Stable. Dans Unstable et Testing il y a justement des paquets qui arrivent constamment par le haut, sont testés aussi bien pour leur fonctionnement que pour leur compatibilité avec le reste, et s'ils résistent
Donc pour être à jour de plein de choses faut être en Unstable ou Testing. C'est complètement contraire au raisonnable, surtout dans le cas de serveurs sensés être stables.
C'est du n'importe quoi comme philosopie. Tout comme c'est n'importe qu'oi de faire des « backports » de patches parce qu'on ne modifie pas ce qui est dans Stable.
Tout ça je ne te dis pas le contraire. Il faut savoir ce qu'on veut. Le gros avantage de Ubuntu, c'est qu'on a des paquets à peu prés à jour et à peu près stables.
des paquets binaires présents en local, et ça a pris 4 ou 5 *heures*. Comme disent les anglais, la preuve est dans le pudding.
« Something's fishy there » comme disent nos amis Anglo-saxons. Une mise à jour via les paquets binaires ne prend pas autant de temps, il a du décider de recompiler. Tu peux forcer le mode binaire via « -PP ».
Désolé, mais c'était avec l'option -PP, aucune recompilation, aussi l'option -O pour accélérer, les deux cdroms de FreeBSD-6.1 montés sur deux lecteurs, portupgrade allant effectivement chercher ses paquets là. La machine est un Athlon 1 Ghz avec 512 Megs de mémoire. Et j'avais même pris la peine de me mettre en mode console pour libérer des ressources. La seule commande portupgrade -R kde3 avec les options ci-dessus. Et oui ça prend ce type de temps je l'ai fait plusieurs fois sur plusieurs machines toujours avec le même genre de résultat.
--
Michel TALON
Ollivier Robert <roberto@removethis.eu.org> wrote:
Dans l'article <ee5ub7$2pmk$1@asmodee.lpthe.jussieu.fr>,
Michel Talon <talon@lpthe.jussieu.fr> disait :
Les paquets Debian ne sont pas liés aux releases, ce que tu dis est vrai pour
la version Stable. Dans Unstable et Testing il y a justement des paquets qui
arrivent constamment par le haut, sont testés aussi bien pour leur
fonctionnement que pour leur compatibilité avec le reste, et s'ils résistent
Donc pour être à jour de plein de choses faut être en Unstable ou Testing.
C'est complètement contraire au raisonnable, surtout dans le cas de serveurs
sensés être stables.
C'est du n'importe quoi comme philosopie. Tout comme c'est n'importe qu'oi de
faire des « backports » de patches parce qu'on ne modifie pas ce qui est dans
Stable.
Tout ça je ne te dis pas le contraire. Il faut savoir ce qu'on veut. Le gros
avantage de Ubuntu, c'est qu'on a des paquets à peu prés à jour et à peu
près stables.
des paquets binaires présents en local, et ça a pris 4 ou 5 *heures*. Comme
disent les anglais, la preuve est dans le pudding.
« Something's fishy there » comme disent nos amis Anglo-saxons. Une mise à
jour via les paquets binaires ne prend pas autant de temps, il a du décider
de recompiler. Tu peux forcer le mode binaire via « -PP ».
Désolé, mais c'était avec l'option -PP, aucune recompilation, aussi l'option
-O pour accélérer, les deux cdroms de FreeBSD-6.1 montés sur deux lecteurs,
portupgrade allant effectivement chercher ses paquets là. La machine est un
Athlon 1 Ghz avec 512 Megs de mémoire. Et j'avais même pris la peine de me
mettre en mode console pour libérer des ressources. La seule commande
portupgrade -R kde3 avec les options ci-dessus. Et oui ça prend ce type de
temps je l'ai fait plusieurs fois sur plusieurs machines toujours avec le
même genre de résultat.
Dans l'article <ee5ub7$2pmk$, Michel Talon disait :
Les paquets Debian ne sont pas liés aux releases, ce que tu dis est vrai pour la version Stable. Dans Unstable et Testing il y a justement des paquets qui arrivent constamment par le haut, sont testés aussi bien pour leur fonctionnement que pour leur compatibilité avec le reste, et s'ils résistent
Donc pour être à jour de plein de choses faut être en Unstable ou Testing. C'est complètement contraire au raisonnable, surtout dans le cas de serveurs sensés être stables.
C'est du n'importe quoi comme philosopie. Tout comme c'est n'importe qu'oi de faire des « backports » de patches parce qu'on ne modifie pas ce qui est dans Stable.
Tout ça je ne te dis pas le contraire. Il faut savoir ce qu'on veut. Le gros avantage de Ubuntu, c'est qu'on a des paquets à peu prés à jour et à peu près stables.
des paquets binaires présents en local, et ça a pris 4 ou 5 *heures*. Comme disent les anglais, la preuve est dans le pudding.
« Something's fishy there » comme disent nos amis Anglo-saxons. Une mise à jour via les paquets binaires ne prend pas autant de temps, il a du décider de recompiler. Tu peux forcer le mode binaire via « -PP ».
Désolé, mais c'était avec l'option -PP, aucune recompilation, aussi l'option -O pour accélérer, les deux cdroms de FreeBSD-6.1 montés sur deux lecteurs, portupgrade allant effectivement chercher ses paquets là. La machine est un Athlon 1 Ghz avec 512 Megs de mémoire. Et j'avais même pris la peine de me mettre en mode console pour libérer des ressources. La seule commande portupgrade -R kde3 avec les options ci-dessus. Et oui ça prend ce type de temps je l'ai fait plusieurs fois sur plusieurs machines toujours avec le même genre de résultat.
--
Michel TALON
didier gaumet
Le Tue, 12 Sep 2006 16:45:21 +0200, Patrick Lamaizière a écrit :
Euh, au cas où la radio est bien sur "on" ? iwicontrol permet de mettre en marche/arrêter l'émeteur.
vi-vi-vi, la TSF était branchée, ça causait dans le poste ;-) Par contre c'est ma compréhension des causes de mon échec qui est sur Off :-(
Merci.
Le Tue, 12 Sep 2006 16:45:21 +0200, Patrick Lamaizière a écrit :
Euh, au cas où la radio est bien sur "on" ? iwicontrol permet de mettre en
marche/arrêter l'émeteur.
vi-vi-vi, la TSF était branchée, ça causait dans le poste ;-)
Par contre c'est ma compréhension des causes de mon échec qui est sur
Off :-(
Le Tue, 12 Sep 2006 16:45:21 +0200, Patrick Lamaizière a écrit :
Euh, au cas où la radio est bien sur "on" ? iwicontrol permet de mettre en marche/arrêter l'émeteur.
vi-vi-vi, la TSF était branchée, ça causait dans le poste ;-) Par contre c'est ma compréhension des causes de mon échec qui est sur Off :-(
Merci.
Quentin Garnier
Il faut noter que l'agreement a une importance précise dans la mesure où TNF est titulaire du copyright d'une grande partie du code. D'accord, ça n'empêche pas nos grands amis d'OpenBSD d'attribuer le copyright à TNF pour du code d'origine pas forcément connue (du point de vue de TNF, j'entends).
Peux-tu préciser ta pensée ?
Oui, moi aussi j'ai pas très bien compris ce qu'il voulait dire.
Je pense qu'il évoque la situation d'un fichier (c) TNF importé chez OpenBSD, puis subissant des petites modifications ne méritant pas d'ajouter un copyright supplémentaire au fichier. On se retrouve avec un fichier marqué uniquement (c) TNF mais dont TNF n'a pas fournit tout le code, stricto sensu.
Est-ce bien celà qu'il fallait comprendre ?
Farpaitement. Merci d'avoir clarifié à ma place. Ce n'est pas que je crois tellement en un risque à ce niveau, mais je me demande sous quelles conditions la loi américaine permet ce transfer.
Quentin Garnier.
Il faut noter que l'agreement a une importance précise dans la mesure où
TNF est titulaire du copyright d'une grande partie du code. D'accord,
ça n'empêche pas nos grands amis d'OpenBSD d'attribuer le copyright à
TNF pour du code d'origine pas forcément connue (du point de vue de TNF,
j'entends).
Peux-tu préciser ta pensée ?
Oui, moi aussi j'ai pas très bien compris ce qu'il voulait dire.
Je pense qu'il évoque la situation d'un fichier (c) TNF importé chez
OpenBSD, puis subissant des petites modifications ne méritant pas
d'ajouter un copyright supplémentaire au fichier. On se retrouve avec un
fichier marqué uniquement (c) TNF mais dont TNF n'a pas fournit tout le
code, stricto sensu.
Est-ce bien celà qu'il fallait comprendre ?
Farpaitement. Merci d'avoir clarifié à ma place. Ce n'est pas que je
crois tellement en un risque à ce niveau, mais je me demande sous
quelles conditions la loi américaine permet ce transfer.
Il faut noter que l'agreement a une importance précise dans la mesure où TNF est titulaire du copyright d'une grande partie du code. D'accord, ça n'empêche pas nos grands amis d'OpenBSD d'attribuer le copyright à TNF pour du code d'origine pas forcément connue (du point de vue de TNF, j'entends).
Peux-tu préciser ta pensée ?
Oui, moi aussi j'ai pas très bien compris ce qu'il voulait dire.
Je pense qu'il évoque la situation d'un fichier (c) TNF importé chez OpenBSD, puis subissant des petites modifications ne méritant pas d'ajouter un copyright supplémentaire au fichier. On se retrouve avec un fichier marqué uniquement (c) TNF mais dont TNF n'a pas fournit tout le code, stricto sensu.
Est-ce bien celà qu'il fallait comprendre ?
Farpaitement. Merci d'avoir clarifié à ma place. Ce n'est pas que je crois tellement en un risque à ce niveau, mais je me demande sous quelles conditions la loi américaine permet ce transfer.
Quentin Garnier.
manu
Quentin Garnier wrote:
Farpaitement. Merci d'avoir clarifié à ma place. Ce n'est pas que je crois tellement en un risque à ce niveau, mais je me demande sous quelles conditions la loi américaine permet ce transfer.
Si on résume, X publie une oeuvre de Y et Z et prétends que Z est détenteur de tous les droits.
Il n'y a evidemment aucun transfer de droits, puisque seul le détenteur des droits peut les céder. L'oeuvre reste une oeuvre composite sur laquelle Y et Z détiennent des droits.
Notons au passage que pour avoir le droit de distribuer l'oeuvre, X doit avoir obtenu l'accord de Y et Z. Si Y n'a pas explicitement autorisé la distribution de l'oeuvre, alors X fait du piratage.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Quentin Garnier <cube@cubidou.net> wrote:
Farpaitement. Merci d'avoir clarifié à ma place. Ce n'est pas que je
crois tellement en un risque à ce niveau, mais je me demande sous
quelles conditions la loi américaine permet ce transfer.
Si on résume, X publie une oeuvre de Y et Z et prétends que Z est
détenteur de tous les droits.
Il n'y a evidemment aucun transfer de droits, puisque seul le détenteur
des droits peut les céder. L'oeuvre reste une oeuvre composite sur
laquelle Y et Z détiennent des droits.
Notons au passage que pour avoir le droit de distribuer l'oeuvre, X doit
avoir obtenu l'accord de Y et Z. Si Y n'a pas explicitement autorisé la
distribution de l'oeuvre, alors X fait du piratage.
Farpaitement. Merci d'avoir clarifié à ma place. Ce n'est pas que je crois tellement en un risque à ce niveau, mais je me demande sous quelles conditions la loi américaine permet ce transfer.
Si on résume, X publie une oeuvre de Y et Z et prétends que Z est détenteur de tous les droits.
Il n'y a evidemment aucun transfer de droits, puisque seul le détenteur des droits peut les céder. L'oeuvre reste une oeuvre composite sur laquelle Y et Z détiennent des droits.
Notons au passage que pour avoir le droit de distribuer l'oeuvre, X doit avoir obtenu l'accord de Y et Z. Si Y n'a pas explicitement autorisé la distribution de l'oeuvre, alors X fait du piratage.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Miod Vallat
Je pense qu'il évoque la situation d'un fichier (c) TNF importé chez OpenBSD, puis subissant des petites modifications ne méritant pas d'ajouter un copyright supplémentaire au fichier. On se retrouve avec un fichier marqué uniquement (c) TNF mais dont TNF n'a pas fournit tout le code, stricto sensu.
Est-ce bien celà qu'il fallait comprendre ?
Farpaitement. Merci d'avoir clarifié à ma place. Ce n'est pas que je crois tellement en un risque à ce niveau, mais je me demande sous quelles conditions la loi américaine permet ce transfer.
Peut-on vraiment parler de transfert à ce niveau ?
Tant que les modifications sont mineures (tiens, corriger une faute d'orthographe dans un commentaire, par exemple), on ne va pas rajouter de nom au copyright, ce serait de l'abus. Et le disclaimer ``NO WARRANTY'' protège l'auteur des problèmes causés par les modifications dont il n'a pas forcément connaissance.
Je pense qu'il évoque la situation d'un fichier (c) TNF importé chez
OpenBSD, puis subissant des petites modifications ne méritant pas
d'ajouter un copyright supplémentaire au fichier. On se retrouve avec un
fichier marqué uniquement (c) TNF mais dont TNF n'a pas fournit tout le
code, stricto sensu.
Est-ce bien celà qu'il fallait comprendre ?
Farpaitement. Merci d'avoir clarifié à ma place. Ce n'est pas que je
crois tellement en un risque à ce niveau, mais je me demande sous
quelles conditions la loi américaine permet ce transfer.
Peut-on vraiment parler de transfert à ce niveau ?
Tant que les modifications sont mineures (tiens, corriger une faute
d'orthographe dans un commentaire, par exemple), on ne va pas rajouter
de nom au copyright, ce serait de l'abus. Et le disclaimer ``NO
WARRANTY'' protège l'auteur des problèmes causés par les modifications
dont il n'a pas forcément connaissance.
Je pense qu'il évoque la situation d'un fichier (c) TNF importé chez OpenBSD, puis subissant des petites modifications ne méritant pas d'ajouter un copyright supplémentaire au fichier. On se retrouve avec un fichier marqué uniquement (c) TNF mais dont TNF n'a pas fournit tout le code, stricto sensu.
Est-ce bien celà qu'il fallait comprendre ?
Farpaitement. Merci d'avoir clarifié à ma place. Ce n'est pas que je crois tellement en un risque à ce niveau, mais je me demande sous quelles conditions la loi américaine permet ce transfer.
Peut-on vraiment parler de transfert à ce niveau ?
Tant que les modifications sont mineures (tiens, corriger une faute d'orthographe dans un commentaire, par exemple), on ne va pas rajouter de nom au copyright, ce serait de l'abus. Et le disclaimer ``NO WARRANTY'' protège l'auteur des problèmes causés par les modifications dont il n'a pas forcément connaissance.
espie
In article <45079eb0$0$514$, Miod Vallat wrote:
Tant que les modifications sont mineures (tiens, corriger une faute d'orthographe dans un commentaire, par exemple), on ne va pas rajouter de nom au copyright, ce serait de l'abus. Et le disclaimer ``NO WARRANTY'' protège l'auteur des problèmes causés par les modifications dont il n'a pas forcément connaissance.
Faut bien avouer que si on commence a rajouter son nom systematiquement, on va tres, tres vite se retrouver avec 1000 lignes de copyright pour 50 lignes de code. Surtout qu'en plus, personne n'utilise exactement la meme variante d'ecriture de la licence, y compris certains qui en profitent pour faire des licence Canada-Dry (Darren Reed pour les mal-comprenant).
In article <45079eb0$0$514$626a54ce@news.free.fr>,
Miod Vallat <miod@online.fr> wrote:
Tant que les modifications sont mineures (tiens, corriger une faute
d'orthographe dans un commentaire, par exemple), on ne va pas rajouter
de nom au copyright, ce serait de l'abus. Et le disclaimer ``NO
WARRANTY'' protège l'auteur des problèmes causés par les modifications
dont il n'a pas forcément connaissance.
Faut bien avouer que si on commence a rajouter son nom systematiquement,
on va tres, tres vite se retrouver avec 1000 lignes de copyright pour 50
lignes de code. Surtout qu'en plus, personne n'utilise exactement la meme
variante d'ecriture de la licence, y compris certains qui en profitent pour
faire des licence Canada-Dry (Darren Reed pour les mal-comprenant).
Tant que les modifications sont mineures (tiens, corriger une faute d'orthographe dans un commentaire, par exemple), on ne va pas rajouter de nom au copyright, ce serait de l'abus. Et le disclaimer ``NO WARRANTY'' protège l'auteur des problèmes causés par les modifications dont il n'a pas forcément connaissance.
Faut bien avouer que si on commence a rajouter son nom systematiquement, on va tres, tres vite se retrouver avec 1000 lignes de copyright pour 50 lignes de code. Surtout qu'en plus, personne n'utilise exactement la meme variante d'ecriture de la licence, y compris certains qui en profitent pour faire des licence Canada-Dry (Darren Reed pour les mal-comprenant).
talon
Miod Vallat wrote:
Je pense qu'il évoque la situation d'un fichier (c) TNF importé chez OpenBSD, puis subissant des petites modifications ne méritant pas d'ajouter un copyright supplémentaire au fichier. On se retrouve avec un fichier marqué uniquement (c) TNF mais dont TNF n'a pas fournit tout le code, stricto sensu.
Est-ce bien celà qu'il fallait comprendre ?
Farpaitement. Merci d'avoir clarifié à ma place. Ce n'est pas que je crois tellement en un risque à ce niveau, mais je me demande sous quelles conditions la loi américaine permet ce transfer.
Peut-on vraiment parler de transfert à ce niveau ?
Tant que les modifications sont mineures (tiens, corriger une faute d'orthographe dans un commentaire, par exemple), on ne va pas rajouter
Tu es le champion de l'humour, toi :-)
de nom au copyright, ce serait de l'abus. Et le disclaimer ``NO WARRANTY'' protège l'auteur des problèmes causés par les modifications dont il n'a pas forcément connaissance.
--
Michel TALON
Miod Vallat <miod@online.fr> wrote:
Je pense qu'il évoque la situation d'un fichier (c) TNF importé chez
OpenBSD, puis subissant des petites modifications ne méritant pas
d'ajouter un copyright supplémentaire au fichier. On se retrouve avec un
fichier marqué uniquement (c) TNF mais dont TNF n'a pas fournit tout le
code, stricto sensu.
Est-ce bien celà qu'il fallait comprendre ?
Farpaitement. Merci d'avoir clarifié à ma place. Ce n'est pas que je
crois tellement en un risque à ce niveau, mais je me demande sous
quelles conditions la loi américaine permet ce transfer.
Peut-on vraiment parler de transfert à ce niveau ?
Tant que les modifications sont mineures (tiens, corriger une faute
d'orthographe dans un commentaire, par exemple), on ne va pas rajouter
Tu es le champion de l'humour, toi :-)
de nom au copyright, ce serait de l'abus. Et le disclaimer ``NO
WARRANTY'' protège l'auteur des problèmes causés par les modifications
dont il n'a pas forcément connaissance.
Je pense qu'il évoque la situation d'un fichier (c) TNF importé chez OpenBSD, puis subissant des petites modifications ne méritant pas d'ajouter un copyright supplémentaire au fichier. On se retrouve avec un fichier marqué uniquement (c) TNF mais dont TNF n'a pas fournit tout le code, stricto sensu.
Est-ce bien celà qu'il fallait comprendre ?
Farpaitement. Merci d'avoir clarifié à ma place. Ce n'est pas que je crois tellement en un risque à ce niveau, mais je me demande sous quelles conditions la loi américaine permet ce transfer.
Peut-on vraiment parler de transfert à ce niveau ?
Tant que les modifications sont mineures (tiens, corriger une faute d'orthographe dans un commentaire, par exemple), on ne va pas rajouter
Tu es le champion de l'humour, toi :-)
de nom au copyright, ce serait de l'abus. Et le disclaimer ``NO WARRANTY'' protège l'auteur des problèmes causés par les modifications dont il n'a pas forcément connaissance.
