> Il faut apporter autre chose que du logiciel: du service, de l'innovation ou des normes.
Ce que tu me dis, c'est que le modele que j'ai nomme 2 est viable. Quand tu construis du service sur du logiciel libre, tu peux gagner de l'argent et j'en suis heureux.
Mais il n'en reste pas moins que si par exemple, je porte KOffice sur MacOs et je veux le vendre, j'aurais du mal. Parce qu'une fois que j'aurais package mon CD et depense mes MF, un petit malin risque de me piquer des clients en vendant mon propre travail (le packaging, pas KOffice)!
> Un programme en LGPL definie une norme ou un
> protocole que va defendre l'equipe de
> developpement, qui permettra aux utilisateurs
> tierces parties de construire au dessus.
> Ceci permet d'obtenir des retombees sonnantes et
> trebuchantes.
Tu te place dans une optique particuliere qui est celle du developpement d'une librairie de reference. C'est le cas ou plusieurs societes ont interet a mutualiser leurs developpement en choisissant du LGPL plutot que du proprietaire.
Mais dans le cas d'un produit, si ton programme est LGPL, les gens pourront l'utiliser sans te verser un centime, meme si ils font du code proprietaire.
Si ton programme est sous GPL, ils vont devoir soit faire un programme GPL, soit t'achter une licence. C'est un encouragement a faire du GPL. Dans les deux cas (tu gagnes de l'argent ou ils font un prog GPL), la communaute du logiciel libre est gagnante. Et c'est pour ca que RMS encourage la GPL plutot que la LGPL, avec raison.
> L'exemple typique est TrollTech.
Qt est justement en GPL et non en LGPL. L'exemple typique que tu cherches, c'est Gtk. Parce que Qt est GPL ou commercial, ceux qui l'ont developpe gagnent de l'argent avec et peuvent ameliorer Qt, embaucher d'autres developpeurs a plein temps. On y gagne.
Parce que Gtk est LGPL, tout le monde peut l'utiliser pour faire du closed-source sans donner d'argent aux auteurs. Du coup, les gens ont moins de temps a y consacrer et le toolkit va moins s'ameliorer. Tu depens du bon-vouloir des utilisateurs qui peuvent se dire "tiens, si on lui filait 100 balles". Bof!
[^] # Re: abaisser la barriere
Posté par Philippe F (site web personnel) . En réponse à la dépêche Viabilite économique de la GPL. Évalué à 1.
Ce que tu me dis, c'est que le modele que j'ai nomme 2 est viable. Quand tu construis du service sur du logiciel libre, tu peux gagner de l'argent et j'en suis heureux.
Mais il n'en reste pas moins que si par exemple, je porte KOffice sur MacOs et je veux le vendre, j'aurais du mal. Parce qu'une fois que j'aurais package mon CD et depense mes MF, un petit malin risque de me piquer des clients en vendant mon propre travail (le packaging, pas KOffice)!
> Un programme en LGPL definie une norme ou un
> protocole que va defendre l'equipe de
> developpement, qui permettra aux utilisateurs
> tierces parties de construire au dessus.
> Ceci permet d'obtenir des retombees sonnantes et
> trebuchantes.
Tu te place dans une optique particuliere qui est celle du developpement d'une librairie de reference. C'est le cas ou plusieurs societes ont interet a mutualiser leurs developpement en choisissant du LGPL plutot que du proprietaire.
Mais dans le cas d'un produit, si ton programme est LGPL, les gens pourront l'utiliser sans te verser un centime, meme si ils font du code proprietaire.
Si ton programme est sous GPL, ils vont devoir soit faire un programme GPL, soit t'achter une licence. C'est un encouragement a faire du GPL. Dans les deux cas (tu gagnes de l'argent ou ils font un prog GPL), la communaute du logiciel libre est gagnante. Et c'est pour ca que RMS encourage la GPL plutot que la LGPL, avec raison.
> L'exemple typique est TrollTech.
Qt est justement en GPL et non en LGPL. L'exemple typique que tu cherches, c'est Gtk. Parce que Qt est GPL ou commercial, ceux qui l'ont developpe gagnent de l'argent avec et peuvent ameliorer Qt, embaucher d'autres developpeurs a plein temps. On y gagne.
Parce que Gtk est LGPL, tout le monde peut l'utiliser pour faire du closed-source sans donner d'argent aux auteurs. Du coup, les gens ont moins de temps a y consacrer et le toolkit va moins s'ameliorer. Tu depens du bon-vouloir des utilisateurs qui peuvent se dire "tiens, si on lui filait 100 balles". Bof!