Je ne résiste pas au plaisir de vous citer un texte de SCO
relatif au fait qu'il peut révoquer les licences Unix de SGI et
IBM:
http://www.theregister.co.uk/content/4/33326.html
You can.t take code based on a license you signed, change it a little
and then give it away for free (as in the case of XFS from SGI). If SCO
allowed companies to contribute derivative UNIX code to Linux and give
it away for free, it would destroy the value of all other versions of
UNIX, including SCO.s own, not to mention the versions of UNIX made by
SUN, HP, IBM, SGI, Sequent, Hitachi, Fujitsu, Siemens, and every other
one of the 6,000 other licensees. Why would SCO not have such a
provision in their licenses? This line of thinking is absolutely
ludicrous.
Je pense que vous pouvez voir là clairement que SCO prétend que XFS
est dérivé de Unix et donc lui appartient purement et simplement.
Voilà où mènent les idées absurdes de Stallmann et de la FSF, comme
je me tue à le dire. La clause virale n'est rien d'autre qu'une forme de
vol du travail d'autrui.
In article (Dans l'article) , Emmanuel Florac wrote (écrivait) :
Ben heureusement, parce que sinon on peut pas parler d'une reussite.
Où sont ces benchmarks? Non, je veux dire, c'est évident que pour faire un firewall je choisirais plutôt OpenBSD, pour faire un serveur de fichiers Linux ou FreeBSD...
Bah, de nos jours en quoi est-ce que OpenBSD ferait un meilleur firewall que liux ou freebsd ?
Le logiciel de firewall pf est particulièrement excellent. Celà dit il existe comme port pour FreeBSD.
--
Michel TALON
azathoth <azathoth@alussinan.org> wrote:
In article (Dans l'article) <MPG.1a03aacb4840066d98cf90@news.free.fr>,
Emmanuel Florac <eflorac@verisign.com> wrote (écrivait) :
Ben heureusement, parce que sinon on peut pas parler d'une reussite.
Où sont ces benchmarks? Non, je veux dire, c'est évident que pour faire
un firewall je choisirais plutôt OpenBSD, pour faire un serveur de
fichiers Linux ou FreeBSD...
Bah, de nos jours en quoi est-ce que OpenBSD ferait un meilleur
firewall que liux ou freebsd ?
Le logiciel de firewall pf est particulièrement excellent. Celà dit
il existe comme port pour FreeBSD.
In article (Dans l'article) , Emmanuel Florac wrote (écrivait) :
Ben heureusement, parce que sinon on peut pas parler d'une reussite.
Où sont ces benchmarks? Non, je veux dire, c'est évident que pour faire un firewall je choisirais plutôt OpenBSD, pour faire un serveur de fichiers Linux ou FreeBSD...
Bah, de nos jours en quoi est-ce que OpenBSD ferait un meilleur firewall que liux ou freebsd ?
Le logiciel de firewall pf est particulièrement excellent. Celà dit il existe comme port pour FreeBSD.
--
Michel TALON
Stephane TOUGARD
Michel Talon wrote:
Bah, de nos jours en quoi est-ce que OpenBSD ferait un meilleur firewall que liux ou freebsd ? Le logiciel de firewall pf est particulièrement excellent. Celà dit
il existe comme port pour FreeBSD.
J'ai installe des FW avec ipchains, ipf, pf et quelques autres. Tres franchement, j'ai jamais trouve pf particulierement plus excellent que les autres.
Tu as des cas precis a exposer ?
Michel Talon wrote:
Bah, de nos jours en quoi est-ce que OpenBSD ferait un meilleur
firewall que liux ou freebsd ?
Le logiciel de firewall pf est particulièrement excellent. Celà dit
il existe comme port pour FreeBSD.
J'ai installe des FW avec ipchains, ipf, pf et quelques autres. Tres
franchement, j'ai jamais trouve pf particulierement plus excellent que
les autres.
Bah, de nos jours en quoi est-ce que OpenBSD ferait un meilleur firewall que liux ou freebsd ? Le logiciel de firewall pf est particulièrement excellent. Celà dit
il existe comme port pour FreeBSD.
J'ai installe des FW avec ipchains, ipf, pf et quelques autres. Tres franchement, j'ai jamais trouve pf particulierement plus excellent que les autres.
Tu as des cas precis a exposer ?
talon
Stephane TOUGARD wrote:
Michel Talon wrote:
Bah, de nos jours en quoi est-ce que OpenBSD ferait un meilleur firewall que liux ou freebsd ? Le logiciel de firewall pf est particulièrement excellent. Celà dit
il existe comme port pour FreeBSD.
J'ai installe des FW avec ipchains, ipf, pf et quelques autres. Tres franchement, j'ai jamais trouve pf particulierement plus excellent que les autres.
Tu as des cas precis a exposer ?
Oui, je suis plus habitué à ipf, mais je sais que sur des sites ayant *beaucoup* de connections, par exemple des sites tournant edonkey, le moteur à états de ipf a tendance à saturer, ce qui entraîne des ralentissements considérables. Ceci car ipf garde les états dans une table hashée, tandis que pf les garde dans un arbre balancé, si bien qu'il ne perd jamais les pédales quel que soit le nombre de connections. A part ça, la syntaxe, trés proche de celle de ipf a été légèrement améliorée. En plus pf a été couplé au logiciel de "bandwith limiting", ce qui fournit une solution trés pratique pour équilibrer les réseaux, etc.
Evidemment, à coté de ces outils, ipchains, iptables et le firewall maison de Freebsd, ipfw, font pâle figure, ne serait-ce que par la merdicité de la syntaxe, Linux remportant la palme de loin.
--
Michel TALON
Stephane TOUGARD <stephane@unices.org> wrote:
Michel Talon wrote:
Bah, de nos jours en quoi est-ce que OpenBSD ferait un meilleur
firewall que liux ou freebsd ?
Le logiciel de firewall pf est particulièrement excellent. Celà dit
il existe comme port pour FreeBSD.
J'ai installe des FW avec ipchains, ipf, pf et quelques autres. Tres
franchement, j'ai jamais trouve pf particulierement plus excellent que
les autres.
Tu as des cas precis a exposer ?
Oui, je suis plus habitué à ipf, mais je sais que sur des sites ayant
*beaucoup* de connections, par exemple des sites tournant edonkey,
le moteur à états de ipf a tendance à saturer, ce qui entraîne des
ralentissements considérables. Ceci car ipf garde les états dans une
table hashée, tandis que pf les garde dans un arbre balancé, si bien
qu'il ne perd jamais les pédales quel que soit le nombre de connections.
A part ça, la syntaxe, trés proche de celle de ipf a été légèrement
améliorée. En plus pf a été couplé au logiciel de "bandwith limiting",
ce qui fournit une solution trés pratique pour équilibrer les réseaux,
etc.
Evidemment, à coté de ces outils, ipchains, iptables et le
firewall maison de Freebsd, ipfw, font pâle figure, ne serait-ce que par
la merdicité de la syntaxe, Linux remportant la palme de loin.
Bah, de nos jours en quoi est-ce que OpenBSD ferait un meilleur firewall que liux ou freebsd ? Le logiciel de firewall pf est particulièrement excellent. Celà dit
il existe comme port pour FreeBSD.
J'ai installe des FW avec ipchains, ipf, pf et quelques autres. Tres franchement, j'ai jamais trouve pf particulierement plus excellent que les autres.
Tu as des cas precis a exposer ?
Oui, je suis plus habitué à ipf, mais je sais que sur des sites ayant *beaucoup* de connections, par exemple des sites tournant edonkey, le moteur à états de ipf a tendance à saturer, ce qui entraîne des ralentissements considérables. Ceci car ipf garde les états dans une table hashée, tandis que pf les garde dans un arbre balancé, si bien qu'il ne perd jamais les pédales quel que soit le nombre de connections. A part ça, la syntaxe, trés proche de celle de ipf a été légèrement améliorée. En plus pf a été couplé au logiciel de "bandwith limiting", ce qui fournit une solution trés pratique pour équilibrer les réseaux, etc.
Evidemment, à coté de ces outils, ipchains, iptables et le firewall maison de Freebsd, ipfw, font pâle figure, ne serait-ce que par la merdicité de la syntaxe, Linux remportant la palme de loin.
--
Michel TALON
Vincent Bernat
OoO En ce début d'après-midi nuageux du dimanche 02 novembre 2003, vers 14:06, Stephane TOUGARD disait:
J'ai installe des FW avec ipchains, ipf, pf et quelques autres. Tres franchement, j'ai jamais trouve pf particulierement plus excellent que les autres.
Tu as des cas precis a exposer ?
Je ne me lance pas dans la comparaison ipf/pf, mais d'un point de vue général, pf permet de faire des choses très simplement, dont le scrubbing et la gestion des queues dans une syntaxe simple et claire. Ensuite, il n'a, à mon sens, pas autant de flexibilité qu'iptables. -- Identify bad input; recover if possible. - The Elements of Programming Style (Kernighan & Plaugher)
OoO En ce début d'après-midi nuageux du dimanche 02 novembre 2003,
vers 14:06, Stephane TOUGARD <stephane@unices.org> disait:
J'ai installe des FW avec ipchains, ipf, pf et quelques autres. Tres
franchement, j'ai jamais trouve pf particulierement plus excellent que
les autres.
Tu as des cas precis a exposer ?
Je ne me lance pas dans la comparaison ipf/pf, mais d'un point de vue
général, pf permet de faire des choses très simplement, dont le
scrubbing et la gestion des queues dans une syntaxe simple et
claire. Ensuite, il n'a, à mon sens, pas autant de flexibilité
qu'iptables.
--
Identify bad input; recover if possible.
- The Elements of Programming Style (Kernighan & Plaugher)
OoO En ce début d'après-midi nuageux du dimanche 02 novembre 2003, vers 14:06, Stephane TOUGARD disait:
J'ai installe des FW avec ipchains, ipf, pf et quelques autres. Tres franchement, j'ai jamais trouve pf particulierement plus excellent que les autres.
Tu as des cas precis a exposer ?
Je ne me lance pas dans la comparaison ipf/pf, mais d'un point de vue général, pf permet de faire des choses très simplement, dont le scrubbing et la gestion des queues dans une syntaxe simple et claire. Ensuite, il n'a, à mon sens, pas autant de flexibilité qu'iptables. -- Identify bad input; recover if possible. - The Elements of Programming Style (Kernighan & Plaugher)
Stephane TOUGARD
Michel Talon wrote:
Oui, je suis plus habitué à ipf, mais je sais que sur des sites ayant *beaucoup* de connections, par exemple des sites tournant edonkey, le moteur à états de ipf a tendance à saturer, ce qui entraîne des ralentissements considérables. Ceci car ipf garde les états dans une table hashée, tandis que pf les garde dans un arbre balancé, si bien qu'il ne perd jamais les pédales quel que soit le nombre de connections. A part ça, la syntaxe, trés proche de celle de ipf a été légèrement améliorée. En plus pf a été couplé au logiciel de "bandwith limiting", ce qui fournit une solution trés pratique pour équilibrer les réseaux, etc.
N'ayant jamais reussi a saturer un firewall, ni meme a pousser son loadavg a plus 0.10 a cause de sa fonction de firewall (pourtant j'en ai eu sur des gros noeuds et qui tournaient sur des Pentium), je ne peux pas te repondre sur ses problemes particuliers de charges.
Tout le monde ne gere pas des fw avec 3 cartes GB sur un 80386.
Evidemment, à coté de ces outils, ipchains, iptables et le firewall maison de Freebsd, ipfw, font pâle figure, ne serait-ce que par la merdicité de la syntaxe, Linux remportant la palme de loin.
Mouais, tant qu'on peut definir la gueule d'un paquet et ce qu'il est bon d'en faire, c'est histoire de religion. C'est la syntaxe de Perl qui est mieux que celle de Python, mais dans les faits les deux produits se valent.
Michel Talon wrote:
Oui, je suis plus habitué à ipf, mais je sais que sur des sites ayant
*beaucoup* de connections, par exemple des sites tournant edonkey,
le moteur à états de ipf a tendance à saturer, ce qui entraîne des
ralentissements considérables. Ceci car ipf garde les états dans une
table hashée, tandis que pf les garde dans un arbre balancé, si bien
qu'il ne perd jamais les pédales quel que soit le nombre de connections.
A part ça, la syntaxe, trés proche de celle de ipf a été légèrement
améliorée. En plus pf a été couplé au logiciel de "bandwith limiting",
ce qui fournit une solution trés pratique pour équilibrer les réseaux,
etc.
N'ayant jamais reussi a saturer un firewall, ni meme a pousser son
loadavg a plus 0.10 a cause de sa fonction de firewall (pourtant j'en ai
eu sur des gros noeuds et qui tournaient sur des Pentium), je ne peux
pas te repondre sur ses problemes particuliers de charges.
Tout le monde ne gere pas des fw avec 3 cartes GB sur un 80386.
Evidemment, à coté de ces outils, ipchains, iptables et le
firewall maison de Freebsd, ipfw, font pâle figure, ne serait-ce que par
la merdicité de la syntaxe, Linux remportant la palme de loin.
Mouais, tant qu'on peut definir la gueule d'un paquet et ce qu'il est
bon d'en faire, c'est histoire de religion. C'est la syntaxe de Perl qui
est mieux que celle de Python, mais dans les faits les deux produits se
valent.
Oui, je suis plus habitué à ipf, mais je sais que sur des sites ayant *beaucoup* de connections, par exemple des sites tournant edonkey, le moteur à états de ipf a tendance à saturer, ce qui entraîne des ralentissements considérables. Ceci car ipf garde les états dans une table hashée, tandis que pf les garde dans un arbre balancé, si bien qu'il ne perd jamais les pédales quel que soit le nombre de connections. A part ça, la syntaxe, trés proche de celle de ipf a été légèrement améliorée. En plus pf a été couplé au logiciel de "bandwith limiting", ce qui fournit une solution trés pratique pour équilibrer les réseaux, etc.
N'ayant jamais reussi a saturer un firewall, ni meme a pousser son loadavg a plus 0.10 a cause de sa fonction de firewall (pourtant j'en ai eu sur des gros noeuds et qui tournaient sur des Pentium), je ne peux pas te repondre sur ses problemes particuliers de charges.
Tout le monde ne gere pas des fw avec 3 cartes GB sur un 80386.
Evidemment, à coté de ces outils, ipchains, iptables et le firewall maison de Freebsd, ipfw, font pâle figure, ne serait-ce que par la merdicité de la syntaxe, Linux remportant la palme de loin.
Mouais, tant qu'on peut definir la gueule d'un paquet et ce qu'il est bon d'en faire, c'est histoire de religion. C'est la syntaxe de Perl qui est mieux que celle de Python, mais dans les faits les deux produits se valent.
Miod Vallat
Peut-être, mais ton postulat de départ est faux... Il y a des vendeurs en boîte de BSD. Notre ami Miod te diras même que c'est la seule façon officielle de se procurer OpenBSD. Voir les sites
Non, tu as tord.
Peut-être, mais ton postulat de départ est faux... Il y a des
vendeurs en boîte de BSD. Notre ami Miod te diras même que c'est la
seule façon officielle de se procurer OpenBSD. Voir les sites
Peut-être, mais ton postulat de départ est faux... Il y a des vendeurs en boîte de BSD. Notre ami Miod te diras même que c'est la seule façon officielle de se procurer OpenBSD. Voir les sites
Non, tu as tord.
azathoth
In article (Dans l'article) <bo3u61$5v8$, Michel Talon wrote (écrivait) :
Le logiciel de firewall pf est particulièrement excellent. Celà dit il existe comme port pour FreeBSD.
Donc ce n'est pas OpenBSD qui est si bien mais pf.
Ceci dit dans le cas d'un firewall, comme il est rare que l'on dépasse vraiment le stade du filtrage de paquet simple, un autre firewall peut très bien faire l'affaire.
D'ailleurs puisque ce forum concerne linux et non les logiciels libres uniquement, on ne trouve pas que des firewall libre sous linux Par exemple il existe une distribution redhat patché par Checkpoint pour faire tourner Firewall-1 et cela fonctionne très bien.
In article (Dans l'article) <bo3u61$5v8$1@asmodee.lpthe.jussieu.fr>,
Michel Talon <talon@lpthe.jussieu.fr> wrote (écrivait) :
Le logiciel de firewall pf est particulièrement excellent. Celà dit
il existe comme port pour FreeBSD.
Donc ce n'est pas OpenBSD qui est si bien mais pf.
Ceci dit dans le cas d'un firewall, comme il est rare que l'on dépasse
vraiment le stade du filtrage de paquet simple, un autre firewall peut
très bien faire l'affaire.
D'ailleurs puisque ce forum concerne linux et non les logiciels libres
uniquement, on ne trouve pas que des firewall libre sous linux Par
exemple il existe une distribution redhat patché par Checkpoint pour
faire tourner Firewall-1 et cela fonctionne très bien.
In article (Dans l'article) <bo3u61$5v8$, Michel Talon wrote (écrivait) :
Le logiciel de firewall pf est particulièrement excellent. Celà dit il existe comme port pour FreeBSD.
Donc ce n'est pas OpenBSD qui est si bien mais pf.
Ceci dit dans le cas d'un firewall, comme il est rare que l'on dépasse vraiment le stade du filtrage de paquet simple, un autre firewall peut très bien faire l'affaire.
D'ailleurs puisque ce forum concerne linux et non les logiciels libres uniquement, on ne trouve pas que des firewall libre sous linux Par exemple il existe une distribution redhat patché par Checkpoint pour faire tourner Firewall-1 et cela fonctionne très bien.
Miod Vallat
Sans vouloir faire tourner la soupe, si on suit Bernstein, c'est également autorisé par la GPL.
Je suppose qu'on peut distribuer des patches en licence BSD pour un sift GPL...
Bien sûr.
Par contre, si tu souhaites que ton patch soit adopté par le mainteneur du logiciel, et donc présent dans la prochaine version, tu dois lui accorder le droit de l'utiliser sous licence GPL, car c'est la seule façon par laquelle il pourra _distribuer_ cette version incorporant ton patch.
Sans vouloir faire tourner la soupe, si on suit Bernstein, c'est
également autorisé par la GPL.
Je suppose qu'on peut distribuer des patches en licence BSD pour un sift
GPL...
Bien sûr.
Par contre, si tu souhaites que ton patch soit adopté par le mainteneur
du logiciel, et donc présent dans la prochaine version, tu dois lui
accorder le droit de l'utiliser sous licence GPL, car c'est la seule
façon par laquelle il pourra _distribuer_ cette version incorporant ton
patch.
Sans vouloir faire tourner la soupe, si on suit Bernstein, c'est également autorisé par la GPL.
Je suppose qu'on peut distribuer des patches en licence BSD pour un sift GPL...
Bien sûr.
Par contre, si tu souhaites que ton patch soit adopté par le mainteneur du logiciel, et donc présent dans la prochaine version, tu dois lui accorder le droit de l'utiliser sous licence GPL, car c'est la seule façon par laquelle il pourra _distribuer_ cette version incorporant ton patch.
Miod Vallat
Désolé d'arriver un peu après la bataille, pas eu le temps, toussa, mais là on vient de me livrer un vax près de trois fois plus rapide que l'ancien, du coup j'ai un peu mieux de temps libre... [*]
Non, ca serait plutot : "Mais pourquoi ?" la licence BSD n'offre aucune garantie particuliere, elle brille surtout par son absence de fondement. C'est une licence que j'utilise lorsque je livre un truc a un client et que je veux garder tous les droits dessus en les lui laissant egalement.
Je pourrais d'ailleurs tout aussi bien dire "Faites en ce que vous voulez, ca ne me regarde pas, j'en ferai ce que j'en veux ca ne vous regarde pas". Certe, cela a son utilite, mais philosophiquement, c'est plutot faiblard.
Un point intéressant - et, de mon point de vue, certainement pas faiblard - de la licence BSD que je n'ai pas vu abordé dans cet étripage de mauvaise foi de groupe, (on dit aussi débat, me souffle-t-on), c'est sa parfaite adéquation aux implémentations de référence.
TCP/IP serait-il aussi développé de nos jours, s'il n'avait pas existé, dès le début, une implémentation de référence, utilisable libre de droits, par tous les constructeurs de matériel ? Il est permis d'en douter.
De nos jours, il n'est toujours pas nécessairement possible d'avoir, dans son matériel, un système libre (linux, eCos ou autre) embarqué, avec le logiciel en GPL. Et disposer d'un code éprouvé, et explicitement destiné à être utilisé dans ce cadre, est un net avantage.
Les développeurs d'Ogg Vorbis, par exemple, ne s'y sont pas trompés, en décidant de diffuser leur code sous licence BSD, afin de faciliter le développement et la diffusion de matériel capable de gérer leur format.
[*] authentique
Désolé d'arriver un peu après la bataille, pas eu le temps, toussa, mais
là on vient de me livrer un vax près de trois fois plus rapide que
l'ancien, du coup j'ai un peu mieux de temps libre... [*]
Non, ca serait plutot : "Mais pourquoi ?" la licence BSD n'offre aucune
garantie particuliere, elle brille surtout par son absence de fondement.
C'est une licence que j'utilise lorsque je livre un truc a un client et
que je veux garder tous les droits dessus en les lui laissant egalement.
Je pourrais d'ailleurs tout aussi bien dire "Faites en ce que vous
voulez, ca ne me regarde pas, j'en ferai ce que j'en veux ca ne vous
regarde pas". Certe, cela a son utilite, mais philosophiquement, c'est
plutot faiblard.
Un point intéressant - et, de mon point de vue, certainement pas
faiblard - de la licence BSD que je n'ai pas vu abordé dans cet
étripage de mauvaise foi de groupe, (on dit aussi débat, me
souffle-t-on), c'est sa parfaite adéquation aux implémentations de
référence.
TCP/IP serait-il aussi développé de nos jours, s'il n'avait pas existé,
dès le début, une implémentation de référence, utilisable libre de
droits, par tous les constructeurs de matériel ? Il est permis d'en
douter.
De nos jours, il n'est toujours pas nécessairement possible d'avoir,
dans son matériel, un système libre (linux, eCos ou autre) embarqué,
avec le logiciel en GPL. Et disposer d'un code éprouvé, et explicitement
destiné à être utilisé dans ce cadre, est un net avantage.
Les développeurs d'Ogg Vorbis, par exemple, ne s'y sont pas trompés, en
décidant de diffuser leur code sous licence BSD, afin de faciliter le
développement et la diffusion de matériel capable de gérer leur format.
Désolé d'arriver un peu après la bataille, pas eu le temps, toussa, mais là on vient de me livrer un vax près de trois fois plus rapide que l'ancien, du coup j'ai un peu mieux de temps libre... [*]
Non, ca serait plutot : "Mais pourquoi ?" la licence BSD n'offre aucune garantie particuliere, elle brille surtout par son absence de fondement. C'est une licence que j'utilise lorsque je livre un truc a un client et que je veux garder tous les droits dessus en les lui laissant egalement.
Je pourrais d'ailleurs tout aussi bien dire "Faites en ce que vous voulez, ca ne me regarde pas, j'en ferai ce que j'en veux ca ne vous regarde pas". Certe, cela a son utilite, mais philosophiquement, c'est plutot faiblard.
Un point intéressant - et, de mon point de vue, certainement pas faiblard - de la licence BSD que je n'ai pas vu abordé dans cet étripage de mauvaise foi de groupe, (on dit aussi débat, me souffle-t-on), c'est sa parfaite adéquation aux implémentations de référence.
TCP/IP serait-il aussi développé de nos jours, s'il n'avait pas existé, dès le début, une implémentation de référence, utilisable libre de droits, par tous les constructeurs de matériel ? Il est permis d'en douter.
De nos jours, il n'est toujours pas nécessairement possible d'avoir, dans son matériel, un système libre (linux, eCos ou autre) embarqué, avec le logiciel en GPL. Et disposer d'un code éprouvé, et explicitement destiné à être utilisé dans ce cadre, est un net avantage.
Les développeurs d'Ogg Vorbis, par exemple, ne s'y sont pas trompés, en décidant de diffuser leur code sous licence BSD, afin de faciliter le développement et la diffusion de matériel capable de gérer leur format.
[*] authentique
Alexis Guillaume
Par contre, si tu souhaites que ton patch soit adopté par le mainteneur du logiciel, et donc présent dans la prochaine version, tu dois lui accorder le droit de l'utiliser sous licence GPL, car c'est la seule façon par laquelle il pourra _distribuer_ cette version incorporant ton patch.
Hein ? Puisque le code BSD peut être repris sous forme propriétaire, pourquoi ne pourrait-il pas l'être sous GPL ?
-- Alexis Guillaume <http://cowsoft.free.fr> : ressources universitaires en vrac
"Il est minuit. La pluie fouette les vitres."
Par contre, si tu souhaites que ton patch soit adopté par le mainteneur
du logiciel, et donc présent dans la prochaine version, tu dois lui
accorder le droit de l'utiliser sous licence GPL, car c'est la seule
façon par laquelle il pourra _distribuer_ cette version incorporant ton
patch.
Hein ? Puisque le code BSD peut être repris sous forme propriétaire,
pourquoi ne pourrait-il pas l'être sous GPL ?
--
Alexis Guillaume
<http://cowsoft.free.fr> : ressources universitaires en vrac
Par contre, si tu souhaites que ton patch soit adopté par le mainteneur du logiciel, et donc présent dans la prochaine version, tu dois lui accorder le droit de l'utiliser sous licence GPL, car c'est la seule façon par laquelle il pourra _distribuer_ cette version incorporant ton patch.
Hein ? Puisque le code BSD peut être repris sous forme propriétaire, pourquoi ne pourrait-il pas l'être sous GPL ?
-- Alexis Guillaume <http://cowsoft.free.fr> : ressources universitaires en vrac
