Bonjour
Je dois modifier une application python qui utilise wxpython pour la
faire passer a PyQt.
Pouvez vous m aidez sur la mani=E8re de proc=E9der ? n y a t il pas d
autre moyen que de r=E9=E9crire toute l'application en utilisant PyQt ce
qui risque d'=EAtre difficile car la taille du programme est assez
grande !
Bin oui : un logiciel spécifique vendu à un client spécifique, et qu'il n'est pas possible de mettre en GPL, le client souhaitant en conserver la propriété exclusive.
C'est donc pour faire du logiciel propriétaire, et dans ce cas le client ne peut pas accepter de se plier aux règles qui prévalent dans ce monde ? Sinon OK, pour des applications comme linux, ou python, il y a une vraie raison stratégique à adopter des licences qui s'apparente à la LGPL, mais Stallman le dit lui-même, la vrai logiciel libre c'est celui sous GPL. http://www.gnu.org/licenses/why-not-lgpl.fr.html
Il va bien falloir qu'un jour les entreprises arrêtent de tirer du profit du monde du libre sans ne rien changer à leurs pratiques. L'idée qu'une société à le choix, mais ne puisse tirer le meilleur parti des deux mondes est une idée qui va dans le bon sens AMHA.
Ce n'est pas une affaire pour MySQL (1 install sur 1 serveur), mais c'est plus embêtant pour une bibliothèqye IHM. A moins que je n'ai pas bien compris ce système de licences...
D'après moi, cela va plus loin, vous ne pouvez tout simplement pas distribuer un code qui fonctionne avec QT sous licence autre que GPL (la notion de lien dans la GPL vaut également pour les liens dynamiques).
-- Maric Michaud - www.aristote.info
jean-michel bain-cornu wrote:
Bin oui : un logiciel spécifique vendu à un client spécifique, et qu'il
n'est pas possible de mettre en GPL, le client souhaitant en conserver
la propriété exclusive.
C'est donc pour faire du logiciel propriétaire, et dans ce cas le client ne
peut pas accepter de se plier aux règles qui prévalent dans ce monde ?
Sinon OK, pour des applications comme linux, ou python, il y a une vraie
raison stratégique à adopter des licences qui s'apparente à la LGPL, mais
Stallman le dit lui-même, la vrai logiciel libre c'est celui sous GPL.
http://www.gnu.org/licenses/why-not-lgpl.fr.html
Il va bien falloir qu'un jour les entreprises arrêtent de tirer du profit du
monde du libre sans ne rien changer à leurs pratiques. L'idée qu'une
société à le choix, mais ne puisse tirer le meilleur parti des deux mondes
est une idée qui va dans le bon sens AMHA.
Ce n'est pas une affaire pour MySQL (1 install sur 1 serveur), mais
c'est plus embêtant pour une bibliothèqye IHM.
A moins que je n'ai pas bien compris ce système de licences...
D'après moi, cela va plus loin, vous ne pouvez tout simplement pas
distribuer un code qui fonctionne avec QT sous licence autre que GPL (la
notion de lien dans la GPL vaut également pour les liens dynamiques).
Bin oui : un logiciel spécifique vendu à un client spécifique, et qu'il n'est pas possible de mettre en GPL, le client souhaitant en conserver la propriété exclusive.
C'est donc pour faire du logiciel propriétaire, et dans ce cas le client ne peut pas accepter de se plier aux règles qui prévalent dans ce monde ? Sinon OK, pour des applications comme linux, ou python, il y a une vraie raison stratégique à adopter des licences qui s'apparente à la LGPL, mais Stallman le dit lui-même, la vrai logiciel libre c'est celui sous GPL. http://www.gnu.org/licenses/why-not-lgpl.fr.html
Il va bien falloir qu'un jour les entreprises arrêtent de tirer du profit du monde du libre sans ne rien changer à leurs pratiques. L'idée qu'une société à le choix, mais ne puisse tirer le meilleur parti des deux mondes est une idée qui va dans le bon sens AMHA.
Ce n'est pas une affaire pour MySQL (1 install sur 1 serveur), mais c'est plus embêtant pour une bibliothèqye IHM. A moins que je n'ai pas bien compris ce système de licences...
D'après moi, cela va plus loin, vous ne pouvez tout simplement pas distribuer un code qui fonctionne avec QT sous licence autre que GPL (la notion de lien dans la GPL vaut également pour les liens dynamiques).
-- Maric Michaud - www.aristote.info
jean-michel bain-cornu
Bin oui : un logiciel spécifique vendu à un client spécifique, et qu'il n'est pas possible de mettre en GPL, le client souhaitant en conserver la propriété exclusive.
C'est donc pour faire du logiciel propriétaire, et dans ce cas le client ne peut pas accepter de se plier aux règles qui prévalent dans ce monde ? Nuance : le *client* souhaite conserver la propriété des logiciels
développés pour lui, et *je* souhaite utiliser exclusivement des logiciels libres pour travailler. Il n'y a pas incompatibilité : la preuve, c'est ce que nous faisons, et qui fonctionne. Si j'attends d'un client qu'il se plie à ma conception de la production d'un logiciel, je ne travaille plus, je ne gagne plus ma vie (élémentaire). Pour moi, c'est un avantage technique (qualité des logiciels que j'utilise) et commercial (pas de licences à acheter, et donc pas de système commercial à faire vivre à mes dépends), et accessoirement, c'est un moyen de prouver que le concept du logiciel libre est valable. Pour lui, c'est une question de confidentialité de ses procédés par rapport à ses concurrents, et ça se défend.
Sinon OK, pour des applications comme linux, ou python, il y a une vraie raison stratégique à adopter des licences qui s'apparente à la LGPL, mais Stallman le dit lui-même, la vrai logiciel libre c'est celui sous GPL. http://www.gnu.org/licenses/why-not-lgpl.fr.html
Bin oui : un logiciel spécifique vendu à un client spécifique, et qu'il
n'est pas possible de mettre en GPL, le client souhaitant en conserver
la propriété exclusive.
C'est donc pour faire du logiciel propriétaire, et dans ce cas le client ne
peut pas accepter de se plier aux règles qui prévalent dans ce monde ?
Nuance : le *client* souhaite conserver la propriété des logiciels
développés pour lui, et *je* souhaite utiliser exclusivement des
logiciels libres pour travailler. Il n'y a pas incompatibilité : la
preuve, c'est ce que nous faisons, et qui fonctionne.
Si j'attends d'un client qu'il se plie à ma conception de la production
d'un logiciel, je ne travaille plus, je ne gagne plus ma vie (élémentaire).
Pour moi, c'est un avantage technique (qualité des logiciels que
j'utilise) et commercial (pas de licences à acheter, et donc pas de
système commercial à faire vivre à mes dépends), et accessoirement,
c'est un moyen de prouver que le concept du logiciel libre est valable.
Pour lui, c'est une question de confidentialité de ses procédés par
rapport à ses concurrents, et ça se défend.
Sinon OK, pour des applications comme linux, ou python, il y a une vraie
raison stratégique à adopter des licences qui s'apparente à la LGPL, mais
Stallman le dit lui-même, la vrai logiciel libre c'est celui sous GPL.
http://www.gnu.org/licenses/why-not-lgpl.fr.html
Bin oui : un logiciel spécifique vendu à un client spécifique, et qu'il n'est pas possible de mettre en GPL, le client souhaitant en conserver la propriété exclusive.
C'est donc pour faire du logiciel propriétaire, et dans ce cas le client ne peut pas accepter de se plier aux règles qui prévalent dans ce monde ? Nuance : le *client* souhaite conserver la propriété des logiciels
développés pour lui, et *je* souhaite utiliser exclusivement des logiciels libres pour travailler. Il n'y a pas incompatibilité : la preuve, c'est ce que nous faisons, et qui fonctionne. Si j'attends d'un client qu'il se plie à ma conception de la production d'un logiciel, je ne travaille plus, je ne gagne plus ma vie (élémentaire). Pour moi, c'est un avantage technique (qualité des logiciels que j'utilise) et commercial (pas de licences à acheter, et donc pas de système commercial à faire vivre à mes dépends), et accessoirement, c'est un moyen de prouver que le concept du logiciel libre est valable. Pour lui, c'est une question de confidentialité de ses procédés par rapport à ses concurrents, et ça se défend.
Sinon OK, pour des applications comme linux, ou python, il y a une vraie raison stratégique à adopter des licences qui s'apparente à la LGPL, mais Stallman le dit lui-même, la vrai logiciel libre c'est celui sous GPL. http://www.gnu.org/licenses/why-not-lgpl.fr.html
Laurent Pointal
Bin oui : un logiciel spécifique vendu à un client spécifique, et qu'il n'est pas possible de mettre en GPL, le client souhaitant en conserver la propriété exclusive. Concrètement, ça veut dire que je ne peux pas empaqueter MySQL (ou QT) avec mon logiciel (à cause du contrat signé avec mon client, et qui lui cède tous les droits de tout ce que je lui livre), et que je suis obliger de créer un process d'installation séparé où le client télécharge lui-même (officiellement) le logiciel. Ce n'est pas une affaire pour MySQL (1 install sur 1 serveur), mais c'est plus embêtant pour une bibliothèqye IHM. A moins que je n'ai pas bien compris ce système de licences...
AMA
S'il s'agit d'un logiciel de commande, destiné à être utilisé uniquement par le client, et pour lequel tu fournis toutes les sources, il devrais être possible que le contrat ne concerne que le travail que tu effectues toi, et que les librairies fournies sous license GPL le soient normalement, avec leurs sources si les client le demande.
Tant que ton client ne veut pas re-commercialiser le logiciel, il n'y a a-priori aucun problème, il aura les droits sur ton travail et pourra l'adapter comme il veut, et il pourra même modifier les libs sous GPL (tant qu'il ne les redistribue pas il n'aura pas à redistribuer les sources).
Bref, tu lui cèdes les droits sur ton travail, et comme tu lui donnes le code, tu respectes la GPL et tu peux y associer des libs sous GPL. Pas de problème tant qu'il n'y a pas redistribution par ton client.
Bin oui : un logiciel spécifique vendu à un client spécifique, et qu'il
n'est pas possible de mettre en GPL, le client souhaitant en conserver
la propriété exclusive.
Concrètement, ça veut dire que je ne peux pas empaqueter MySQL (ou QT)
avec mon logiciel (à cause du contrat signé avec mon client, et qui lui
cède tous les droits de tout ce que je lui livre), et que je suis
obliger de créer un process d'installation séparé où le client
télécharge lui-même (officiellement) le logiciel.
Ce n'est pas une affaire pour MySQL (1 install sur 1 serveur), mais
c'est plus embêtant pour une bibliothèqye IHM.
A moins que je n'ai pas bien compris ce système de licences...
AMA
S'il s'agit d'un logiciel de commande, destiné à être utilisé uniquement
par le client, et pour lequel tu fournis toutes les sources, il devrais
être possible que le contrat ne concerne que le travail que tu effectues
toi, et que les librairies fournies sous license GPL le soient
normalement, avec leurs sources si les client le demande.
Tant que ton client ne veut pas re-commercialiser le logiciel, il n'y a
a-priori aucun problème, il aura les droits sur ton travail et pourra
l'adapter comme il veut, et il pourra même modifier les libs sous GPL
(tant qu'il ne les redistribue pas il n'aura pas à redistribuer les
sources).
Bref, tu lui cèdes les droits sur ton travail, et comme tu lui donnes le
code, tu respectes la GPL et tu peux y associer des libs sous GPL. Pas
de problème tant qu'il n'y a pas redistribution par ton client.
Bin oui : un logiciel spécifique vendu à un client spécifique, et qu'il n'est pas possible de mettre en GPL, le client souhaitant en conserver la propriété exclusive. Concrètement, ça veut dire que je ne peux pas empaqueter MySQL (ou QT) avec mon logiciel (à cause du contrat signé avec mon client, et qui lui cède tous les droits de tout ce que je lui livre), et que je suis obliger de créer un process d'installation séparé où le client télécharge lui-même (officiellement) le logiciel. Ce n'est pas une affaire pour MySQL (1 install sur 1 serveur), mais c'est plus embêtant pour une bibliothèqye IHM. A moins que je n'ai pas bien compris ce système de licences...
AMA
S'il s'agit d'un logiciel de commande, destiné à être utilisé uniquement par le client, et pour lequel tu fournis toutes les sources, il devrais être possible que le contrat ne concerne que le travail que tu effectues toi, et que les librairies fournies sous license GPL le soient normalement, avec leurs sources si les client le demande.
Tant que ton client ne veut pas re-commercialiser le logiciel, il n'y a a-priori aucun problème, il aura les droits sur ton travail et pourra l'adapter comme il veut, et il pourra même modifier les libs sous GPL (tant qu'il ne les redistribue pas il n'aura pas à redistribuer les sources).
Bref, tu lui cèdes les droits sur ton travail, et comme tu lui donnes le code, tu respectes la GPL et tu peux y associer des libs sous GPL. Pas de problème tant qu'il n'y a pas redistribution par ton client.
jean-michel bain-cornu
S'il s'agit d'un logiciel de commande, destiné à être utilisé uniquement par le client, et pour lequel tu fournis toutes les sources, il devrais être possible que le contrat ne concerne que le travail que tu effectues toi, et que les librairies fournies sous license GPL le soient normalement, avec leurs sources si les client le demande.
Tant que ton client ne veut pas re-commercialiser le logiciel, il n'y a a-priori aucun problème, il aura les droits sur ton travail et pourra l'adapter comme il veut, et il pourra même modifier les libs sous GPL (tant qu'il ne les redistribue pas il n'aura pas à redistribuer les sources).
Bref, tu lui cèdes les droits sur ton travail, et comme tu lui donnes le code, tu respectes la GPL et tu peux y associer des libs sous GPL. Pas de problème tant qu'il n'y a pas redistribution par ton client.
Je suis globalement d'accord. Le problème existe pour des licences de type MySQL qui ne sont pas GPL à 100%, à savoir qu'on ne peut distribuer leurs logiciels que dans le cadre d'un logiciel GPL.
En résumé : - le logiciel que je livre à mon client est GPL : je peux livrer MySQL/QT inclus. - le logiciel que je livre est propriétaire (imposé par le client) : je ne peux pas livrer MySQL/QT, mon client doit se les procurer lui-même.
Par ailleurs, MySQL/Trolltech pourraient très bien changer de stratégie de licence, surtout s'ils étaient rachetés.
S'il s'agit d'un logiciel de commande, destiné à être utilisé uniquement
par le client, et pour lequel tu fournis toutes les sources, il devrais
être possible que le contrat ne concerne que le travail que tu effectues
toi, et que les librairies fournies sous license GPL le soient
normalement, avec leurs sources si les client le demande.
Tant que ton client ne veut pas re-commercialiser le logiciel, il n'y a
a-priori aucun problème, il aura les droits sur ton travail et pourra
l'adapter comme il veut, et il pourra même modifier les libs sous GPL
(tant qu'il ne les redistribue pas il n'aura pas à redistribuer les
sources).
Bref, tu lui cèdes les droits sur ton travail, et comme tu lui donnes le
code, tu respectes la GPL et tu peux y associer des libs sous GPL. Pas
de problème tant qu'il n'y a pas redistribution par ton client.
Je suis globalement d'accord.
Le problème existe pour des licences de type MySQL qui ne sont pas GPL à
100%, à savoir qu'on ne peut distribuer leurs logiciels que dans le
cadre d'un logiciel GPL.
En résumé :
- le logiciel que je livre à mon client est GPL : je peux livrer
MySQL/QT inclus.
- le logiciel que je livre est propriétaire (imposé par le client) : je
ne peux pas livrer MySQL/QT, mon client doit se les procurer lui-même.
Par ailleurs, MySQL/Trolltech pourraient très bien changer de stratégie
de licence, surtout s'ils étaient rachetés.
S'il s'agit d'un logiciel de commande, destiné à être utilisé uniquement par le client, et pour lequel tu fournis toutes les sources, il devrais être possible que le contrat ne concerne que le travail que tu effectues toi, et que les librairies fournies sous license GPL le soient normalement, avec leurs sources si les client le demande.
Tant que ton client ne veut pas re-commercialiser le logiciel, il n'y a a-priori aucun problème, il aura les droits sur ton travail et pourra l'adapter comme il veut, et il pourra même modifier les libs sous GPL (tant qu'il ne les redistribue pas il n'aura pas à redistribuer les sources).
Bref, tu lui cèdes les droits sur ton travail, et comme tu lui donnes le code, tu respectes la GPL et tu peux y associer des libs sous GPL. Pas de problème tant qu'il n'y a pas redistribution par ton client.
Je suis globalement d'accord. Le problème existe pour des licences de type MySQL qui ne sont pas GPL à 100%, à savoir qu'on ne peut distribuer leurs logiciels que dans le cadre d'un logiciel GPL.
En résumé : - le logiciel que je livre à mon client est GPL : je peux livrer MySQL/QT inclus. - le logiciel que je livre est propriétaire (imposé par le client) : je ne peux pas livrer MySQL/QT, mon client doit se les procurer lui-même.
Par ailleurs, MySQL/Trolltech pourraient très bien changer de stratégie de licence, surtout s'ils étaient rachetés.
hg
Maric Michaud wrote:
par ailleurs le développement de gtk pourrait devenir tellement lent que gnome passe sous QT,
??? c'est une blague, oui ?
hg
Maric Michaud wrote:
par ailleurs le développement de gtk pourrait devenir tellement lent que
gnome passe sous QT,
par ailleurs le développement de gtk pourrait devenir tellement lent que gnome passe sous QT,
??? c'est une blague, oui ?
hg
Maric Michaud
jean-michel bain-cornu wrote:
Tant que ton client ne veut pas re-commercialiser le logiciel, il n'y a a-priori aucun problème, il aura les droits sur ton travail et pourra l'adapter comme il veut, et il pourra même modifier les libs sous GPL (tant qu'il ne les redistribue pas il n'aura pas à redistribuer les sources).
Non, ce n'est pas ça, la GPL n'a aucun rapport avec le fait que vous commercialisiez ou non vos logiciels, elle protège les utilisateurs, et en l'occurence, dans l'esprit de la GPL, dans le cas d'un logiciel maison les utilisateurs peuvent tout aussi bien être vos clients utilisant votre site internet pour je ne sais quoi, que vos salariés ! Il y a eu un thread là-dessus sur c.l.p il n'y a pas bien longtemps.
Si vous utilisez une librairie ou un lggiciel GPL, ce que vous développez dessus doit être GPl ou compatible (notez que la LGPL ne l'est pas).
Bref, tu lui cèdes les droits sur ton travail, et comme tu lui donnes le code, tu respectes la GPL et tu peux y associer des libs sous GPL. Pas de problème tant qu'il n'y a pas redistribution par ton client.
Je suis globalement d'accord.
C'est complètement faux, il faut utiliser des soft sous licence LGPL pour pouvoir faire ça.
Le problème existe pour des licences de type MySQL qui ne sont pas GPL à 100%, à savoir qu'on ne peut distribuer leurs logiciels que dans le cadre d'un logiciel GPL.
Mais c'est justement le principe même de la GPL, vous confondez je crois les deux licences... jetez un oeil à l'article dont j'ai donné l'adresse dans un post précédent.
En résumé : - le logiciel que je livre à mon client est GPL : je peux livrer MySQL/QT inclus. - le logiciel que je livre est propriétaire (imposé par le client) : je ne peux pas livrer MySQL/QT, mon client doit se les procurer lui-même.
Non, justement, QT sous windows est strictement GPL, c'est ce qui vous empêche de redistribuer n'importe quel code (même un "import qt") sous une autre licence que GPL et ce même pour du développement maison.
En revanche lorsque Mysql est passé sous licencse GPL, il n'aurait plus été possible d'attaquer la base avec des logiciels autre qu'en GPL, c'est pourquoi ils ont introduit des exceptions à la GPL, concernant le liens avec le code client SQL, tout à fait comme Linux est sous GPL (pas LGPL) avec des exceptions, tout comme Python à sa propre licence (qui n'est pas censée être utiliser par les projet open source écrit en Python), etc...
Par ailleurs, MySQL/Trolltech pourraient très bien changer de stratégie de licence, surtout s'ils étaient rachetés.
Par ailleurs la communauté debian pourrait se couper en deux comme ça a failli être le cas, par ailleurs le développement de gtk pourrait devenir tellement lent que gnome passe sous QT, par ailleurs Guido pourrait avoir une crise cardiaque...
-- Maric Michaud - www.aristote.info
jean-michel bain-cornu wrote:
Tant que ton client ne veut pas re-commercialiser le logiciel, il n'y a
a-priori aucun problème, il aura les droits sur ton travail et pourra
l'adapter comme il veut, et il pourra même modifier les libs sous GPL
(tant qu'il ne les redistribue pas il n'aura pas à redistribuer les
sources).
Non, ce n'est pas ça, la GPL n'a aucun rapport avec le fait que vous
commercialisiez ou non vos logiciels, elle protège les utilisateurs, et en
l'occurence, dans l'esprit de la GPL, dans le cas d'un logiciel maison les
utilisateurs peuvent tout aussi bien être vos clients utilisant votre site
internet pour je ne sais quoi, que vos salariés ! Il y a eu un thread
là-dessus sur c.l.p il n'y a pas bien longtemps.
Si vous utilisez une librairie ou un lggiciel GPL, ce que vous développez
dessus doit être GPl ou compatible (notez que la LGPL ne l'est pas).
Bref, tu lui cèdes les droits sur ton travail, et comme tu lui donnes le
code, tu respectes la GPL et tu peux y associer des libs sous GPL. Pas
de problème tant qu'il n'y a pas redistribution par ton client.
Je suis globalement d'accord.
C'est complètement faux, il faut utiliser des soft sous licence LGPL pour
pouvoir faire ça.
Le problème existe pour des licences de type MySQL qui ne sont pas GPL à
100%, à savoir qu'on ne peut distribuer leurs logiciels que dans le
cadre d'un logiciel GPL.
Mais c'est justement le principe même de la GPL, vous confondez je crois les
deux licences... jetez un oeil à l'article dont j'ai donné l'adresse dans
un post précédent.
En résumé :
- le logiciel que je livre à mon client est GPL : je peux livrer
MySQL/QT inclus.
- le logiciel que je livre est propriétaire (imposé par le client) : je
ne peux pas livrer MySQL/QT, mon client doit se les procurer lui-même.
Non, justement, QT sous windows est strictement GPL, c'est ce qui vous
empêche de redistribuer n'importe quel code (même un "import qt") sous une
autre licence que GPL et ce même pour du développement maison.
En revanche lorsque Mysql est passé sous licencse GPL, il n'aurait plus été
possible d'attaquer la base avec des logiciels autre qu'en GPL, c'est
pourquoi ils ont introduit des exceptions à la GPL, concernant le liens
avec le code client SQL, tout à fait comme Linux est sous GPL (pas LGPL)
avec des exceptions, tout comme Python à sa propre licence (qui n'est pas
censée être utiliser par les projet open source écrit en Python), etc...
Par ailleurs, MySQL/Trolltech pourraient très bien changer de stratégie
de licence, surtout s'ils étaient rachetés.
Par ailleurs la communauté debian pourrait se couper en deux comme ça a
failli être le cas,
par ailleurs le développement de gtk pourrait devenir tellement lent que
gnome passe sous QT,
par ailleurs Guido pourrait avoir une crise cardiaque...
Tant que ton client ne veut pas re-commercialiser le logiciel, il n'y a a-priori aucun problème, il aura les droits sur ton travail et pourra l'adapter comme il veut, et il pourra même modifier les libs sous GPL (tant qu'il ne les redistribue pas il n'aura pas à redistribuer les sources).
Non, ce n'est pas ça, la GPL n'a aucun rapport avec le fait que vous commercialisiez ou non vos logiciels, elle protège les utilisateurs, et en l'occurence, dans l'esprit de la GPL, dans le cas d'un logiciel maison les utilisateurs peuvent tout aussi bien être vos clients utilisant votre site internet pour je ne sais quoi, que vos salariés ! Il y a eu un thread là-dessus sur c.l.p il n'y a pas bien longtemps.
Si vous utilisez une librairie ou un lggiciel GPL, ce que vous développez dessus doit être GPl ou compatible (notez que la LGPL ne l'est pas).
Bref, tu lui cèdes les droits sur ton travail, et comme tu lui donnes le code, tu respectes la GPL et tu peux y associer des libs sous GPL. Pas de problème tant qu'il n'y a pas redistribution par ton client.
Je suis globalement d'accord.
C'est complètement faux, il faut utiliser des soft sous licence LGPL pour pouvoir faire ça.
Le problème existe pour des licences de type MySQL qui ne sont pas GPL à 100%, à savoir qu'on ne peut distribuer leurs logiciels que dans le cadre d'un logiciel GPL.
Mais c'est justement le principe même de la GPL, vous confondez je crois les deux licences... jetez un oeil à l'article dont j'ai donné l'adresse dans un post précédent.
En résumé : - le logiciel que je livre à mon client est GPL : je peux livrer MySQL/QT inclus. - le logiciel que je livre est propriétaire (imposé par le client) : je ne peux pas livrer MySQL/QT, mon client doit se les procurer lui-même.
Non, justement, QT sous windows est strictement GPL, c'est ce qui vous empêche de redistribuer n'importe quel code (même un "import qt") sous une autre licence que GPL et ce même pour du développement maison.
En revanche lorsque Mysql est passé sous licencse GPL, il n'aurait plus été possible d'attaquer la base avec des logiciels autre qu'en GPL, c'est pourquoi ils ont introduit des exceptions à la GPL, concernant le liens avec le code client SQL, tout à fait comme Linux est sous GPL (pas LGPL) avec des exceptions, tout comme Python à sa propre licence (qui n'est pas censée être utiliser par les projet open source écrit en Python), etc...
Par ailleurs, MySQL/Trolltech pourraient très bien changer de stratégie de licence, surtout s'ils étaient rachetés.
Par ailleurs la communauté debian pourrait se couper en deux comme ça a failli être le cas, par ailleurs le développement de gtk pourrait devenir tellement lent que gnome passe sous QT, par ailleurs Guido pourrait avoir une crise cardiaque...
-- Maric Michaud - www.aristote.info
jean-michel bain-cornu
par ailleurs Guido pourrait avoir une crise cardiaque... dans ce cas, tu n'aurais qu'à prendre le learship ;-)
par ailleurs Guido pourrait avoir une crise cardiaque...
dans ce cas, tu n'aurais qu'à prendre le learship ;-)
