Je suis développeur Java principalement (bouuuh, bouuuh, ...), et C++
occasionnel.
J'ai eu l'occasion de discuter ici ou ailleurs avec certains habitués
(Fabien, Kame, Christophe de mémoire). On avait notamment discuté des
avantages/inconvénients respectifs de Java et C++... A cette ocasion
j'avais découvert des alternatives propres à certaines pratiques que
je considère comme douteuses dans l'usage du C++ que je connais
(C/C++, principalement sous VC++).
Actuellement je suis ammené à faire de + en + de C/C++ ce qui
m'emmerde profondément. ça n'est pas que je n'aime pas C++, mais
fesant pas mal de Java, je ne supporte pas les absurdités de la
programmation C/C++ sous Windows. Pourquoi éxiste-t-il 873
redéfinition d'un entier 32 bit??? Les programmeur de chez MS sont
payés au #define? Pourquoi dans VC++ on doit choisir entre CString qui
est non portable, et "char *" qui est légèrement primitif!!! (J'ai
une idée de la réponse...). On devrait disposer avec chaque
environnement C++ d'un bibliothèque portable reprenant au minimum les
fonctions des packages java.lang et java.util de java...
Il me semble qu'il y a un fossé (20 ans et pas mal de bon sens) entre
ce que je lis ici et ce que je constate dans la "vraie vie" (du moins,
la mienne)!!! Que me conseilleriez-vous pour me sortir de cette
panade?
Comment faire du C++ propre et portable (GUI portable en option) en
alternative à VC++. Ou, comment et avec quoi bossez-vous? Quel IDE,
quel compilo et surtout quelle(s) bibliothèque(s) pour remplacer les
MFC? Le tout à l'echelle d'une PME et sans obliger tous mes collègues
à migrer avec moi (même si certains me suivraient bien volontier). Je
sais, je suis très éxigeant, mais bon, je viens de java ;-)
Au passage, je suis bien intéressé par des bons livres (de préférence
en français, mais pas obligatoirement) sur la bonne programmation
(C/)C++... Mais j'imagine qu'en faisant qq recherches je trouverais la
réponse dans les archives... (si vous avez un lien vers un post
intressant...)
Microsoft travaille ardemment sur la correction des failles de sécutité en récrivant les bibliothèques ou en les corrigeant .... Quelques exemples ici : http://www.microsoft.com/france/msdn/technologies/outils/vstudio/info/info.asp?mar=/france/msdn/technologies/technos/securite/info/2004-06-02-secure03102004.html
Prenez le temps de lire l'article.
Si c'est portable, si c'est proposé comme future C standart, ca pourrait etre un solution... Ah, on me dit dans l'oreille qu'aucune de ces deux possibilitées n'est envisagée, bon, ben voila, j'en lirait pas plus, et les fonction *_s resterons chez MS.
Woodoochild wrote:
Bonjour,
Microsoft travaille ardemment sur la correction des failles de sécutité en
récrivant les bibliothèques ou en les corrigeant ....
Quelques exemples ici :
http://www.microsoft.com/france/msdn/technologies/outils/vstudio/info/info.asp?mar=/france/msdn/technologies/technos/securite/info/2004-06-02-secure03102004.html
Prenez le temps de lire l'article.
Si c'est portable, si c'est proposé comme future C standart, ca pourrait
etre un solution...
Ah, on me dit dans l'oreille qu'aucune de ces deux possibilitées n'est
envisagée, bon, ben voila, j'en lirait pas plus, et les fonction *_s
resterons chez MS.
Microsoft travaille ardemment sur la correction des failles de sécutité en récrivant les bibliothèques ou en les corrigeant .... Quelques exemples ici : http://www.microsoft.com/france/msdn/technologies/outils/vstudio/info/info.asp?mar=/france/msdn/technologies/technos/securite/info/2004-06-02-secure03102004.html
Prenez le temps de lire l'article.
Si c'est portable, si c'est proposé comme future C standart, ca pourrait etre un solution... Ah, on me dit dans l'oreille qu'aucune de ces deux possibilitées n'est envisagée, bon, ben voila, j'en lirait pas plus, et les fonction *_s resterons chez MS.
Martinez Jerome
Gabriel Dos Reis wrote:
Martinez Jerome writes:
| Peut-etre que le consortium C++ n'est pas allé assez loin dans les ^^^^^^^^^^^^^^ | spécifications de ce type...
Kesako?
Honte à moi, j'ai mélangé les mots. L'entité qui s'occupe de normaliser le C++ (je ne connais pas son nom)
| Peut-etre que le consortium C++ n'est pas allé assez loin dans les ^^^^^^^^^^^^^^ | spécifications de ce type...
Kesako?
Honte à moi, j'ai mélangé les mots. L'entité qui s'occupe de normaliser le C++ (je ne connais pas son nom)
Arnaud Meurgues
Martinez Jerome wrote:
Si c'est portable, si c'est proposé comme future C standart, ca pourrait etre un solution... Ah, on me dit dans l'oreille qu'aucune de ces deux possibilitées n'est envisagée, bon, ben voila, j'en lirait pas plus, et les fonction *_s resterons chez MS.
?? pas Envisagées par qui ??
" [...]Microsoft a présenté sa dernière proposition au comité de normalisation. Vous en trouverez une version préliminaire à l'adresse http://std.dkuug.dk/jtc1/sc22/wg14/www/docs/n1031.pdf "
-- Arnaud (Supprimez les geneurs pour me répondre)
Martinez Jerome wrote:
Si c'est portable, si c'est proposé comme future C standart, ca pourrait
etre un solution...
Ah, on me dit dans l'oreille qu'aucune de ces deux possibilitées n'est
envisagée, bon, ben voila, j'en lirait pas plus, et les fonction *_s
resterons chez MS.
?? pas Envisagées par qui ??
"
[...]Microsoft a présenté sa dernière proposition au comité de
normalisation. Vous en trouverez une version préliminaire à l'adresse
http://std.dkuug.dk/jtc1/sc22/wg14/www/docs/n1031.pdf
"
--
Arnaud
(Supprimez les geneurs pour me répondre)
Si c'est portable, si c'est proposé comme future C standart, ca pourrait etre un solution... Ah, on me dit dans l'oreille qu'aucune de ces deux possibilitées n'est envisagée, bon, ben voila, j'en lirait pas plus, et les fonction *_s resterons chez MS.
?? pas Envisagées par qui ??
" [...]Microsoft a présenté sa dernière proposition au comité de normalisation. Vous en trouverez une version préliminaire à l'adresse http://std.dkuug.dk/jtc1/sc22/wg14/www/docs/n1031.pdf "
-- Arnaud (Supprimez les geneurs pour me répondre)
Arnaud Meurgues
Martinez Jerome wrote:
L'entité qui s'occupe de normaliser le C++ (je ne connais pas son nom)
Le "comité de normalisation" ?
-- Arnaud (Supprimez les geneurs pour me répondre)
Martinez Jerome wrote:
L'entité qui s'occupe de normaliser le C++ (je ne connais pas son nom)
Le "comité de normalisation" ?
--
Arnaud
(Supprimez les geneurs pour me répondre)
L'entité qui s'occupe de normaliser le C++ (je ne connais pas son nom)
Le "comité de normalisation" ?
-- Arnaud (Supprimez les geneurs pour me répondre)
kanze
Gabriel Dos Reis wrote in message news:...
Matthieu Moy writes:
| Fabien LE LEZ writes: | | > On Wed, 21 Jul 2004 10:52:40 +0200, "Mickael Pointier" | > : | > | >>Ne prend pas ton cas pour une généralité: Il n'y a pas que le "gratuit" et | >>le "libre" dans la vie. | > | > Certes. Mais ton argument n'explique pas pour autant pourquoi tant de | > bibliothèques open-source sont écrites en C. | | Parce que c'est le plus réutilisable, principalement : D'une | bibliothèque écrite en C, tu peux faire des bindings vers d'autres | langages sans trop de problèmes.
La même chose est possible en C++ -- jamais entendu parler de spécification de linkage/langage (chose que tu n'as pas en C) ?
| Avec une API en C++ plein de | templates, d'héritage, ... tu es bien embêté quand tu veux appeler ta | bibliothèque depuis un language qui n'a pas toutes ces fonctionalités.
C'est un non-argument : si tu veux faire un binding, certainement, tu ne veux pas utiliser les fonctionnalités avancées dans _l'interface_ mais rien ne t'empêche de les utiliser dans l'implémentation. Et même si c'était utilisé dans la partie interface, rien n'empêche de mettre le « extern "X" » autour du wrapper idione.
Techiniquement, au moin, si tu compiles ton code avec un compilateur C++, il faut que main() soit compile avec un compilateur C++. Pratiquement, ca depend du compilateur et ce que tu fais dans ton code -- typiquement, si tu n'utilises pas de variables non-locales a duree de vie statique, il y a des chances a ce que ca marche. En supposant, evidemment, que l'utilisateur linke avec les bibliotheques C++ quand meme.
Pour diffuser une bibliotheque a utilisation generale, c'est quand meme genant. Dire au programmeur C qu'il faut qu'il invoque g++ (et non gcc) lors de l'edition des liens, par exemple ? Ou meme qu'il faut qu'il procure une bibliotheque C++, quand elle n'est pas livree avec son compilateur C. (C'etait le cas dans la passee avec Sun cc, par exemple.)
-- James Kanze
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message news:<m3k6wsz9ta.fsf@uniton.integrable-solutions.net>...
| Fabien LE LEZ <gramster@gramster.com> writes:
|
| > On Wed, 21 Jul 2004 10:52:40 +0200, "Mickael Pointier"
| > <mpointier@edengames.moc>:
| >
| >>Ne prend pas ton cas pour une généralité: Il n'y a pas que le "gratuit" et
| >>le "libre" dans la vie.
| >
| > Certes. Mais ton argument n'explique pas pour autant pourquoi tant de
| > bibliothèques open-source sont écrites en C.
|
| Parce que c'est le plus réutilisable, principalement : D'une
| bibliothèque écrite en C, tu peux faire des bindings vers d'autres
| langages sans trop de problèmes.
La même chose est possible en C++ -- jamais entendu parler de
spécification de linkage/langage (chose que tu n'as pas en C) ?
| Avec une API en C++ plein de
| templates, d'héritage, ... tu es bien embêté quand tu veux appeler ta
| bibliothèque depuis un language qui n'a pas toutes ces fonctionalités.
C'est un non-argument : si tu veux faire un binding, certainement, tu
ne veux pas utiliser les fonctionnalités avancées dans _l'interface_
mais rien ne t'empêche de les utiliser dans l'implémentation.
Et même si c'était utilisé dans la partie interface, rien n'empêche de
mettre le « extern "X" » autour du wrapper idione.
Techiniquement, au moin, si tu compiles ton code avec un compilateur
C++, il faut que main() soit compile avec un compilateur C++.
Pratiquement, ca depend du compilateur et ce que tu fais dans ton
code -- typiquement, si tu n'utilises pas de variables non-locales
a duree de vie statique, il y a des chances a ce que ca marche.
En supposant, evidemment, que l'utilisateur linke avec les bibliotheques
C++ quand meme.
Pour diffuser une bibliotheque a utilisation generale, c'est quand
meme genant. Dire au programmeur C qu'il faut qu'il invoque g++ (et
non gcc) lors de l'edition des liens, par exemple ? Ou meme qu'il faut
qu'il procure une bibliotheque C++, quand elle n'est pas livree avec
son compilateur C. (C'etait le cas dans la passee avec Sun cc, par
exemple.)
| Fabien LE LEZ writes: | | > On Wed, 21 Jul 2004 10:52:40 +0200, "Mickael Pointier" | > : | > | >>Ne prend pas ton cas pour une généralité: Il n'y a pas que le "gratuit" et | >>le "libre" dans la vie. | > | > Certes. Mais ton argument n'explique pas pour autant pourquoi tant de | > bibliothèques open-source sont écrites en C. | | Parce que c'est le plus réutilisable, principalement : D'une | bibliothèque écrite en C, tu peux faire des bindings vers d'autres | langages sans trop de problèmes.
La même chose est possible en C++ -- jamais entendu parler de spécification de linkage/langage (chose que tu n'as pas en C) ?
| Avec une API en C++ plein de | templates, d'héritage, ... tu es bien embêté quand tu veux appeler ta | bibliothèque depuis un language qui n'a pas toutes ces fonctionalités.
C'est un non-argument : si tu veux faire un binding, certainement, tu ne veux pas utiliser les fonctionnalités avancées dans _l'interface_ mais rien ne t'empêche de les utiliser dans l'implémentation. Et même si c'était utilisé dans la partie interface, rien n'empêche de mettre le « extern "X" » autour du wrapper idione.
Techiniquement, au moin, si tu compiles ton code avec un compilateur C++, il faut que main() soit compile avec un compilateur C++. Pratiquement, ca depend du compilateur et ce que tu fais dans ton code -- typiquement, si tu n'utilises pas de variables non-locales a duree de vie statique, il y a des chances a ce que ca marche. En supposant, evidemment, que l'utilisateur linke avec les bibliotheques C++ quand meme.
Pour diffuser une bibliotheque a utilisation generale, c'est quand meme genant. Dire au programmeur C qu'il faut qu'il invoque g++ (et non gcc) lors de l'edition des liens, par exemple ? Ou meme qu'il faut qu'il procure une bibliotheque C++, quand elle n'est pas livree avec son compilateur C. (C'etait le cas dans la passee avec Sun cc, par exemple.)
-- James Kanze
kanze
"Alain Naigeon" wrote in message news:<40fd78c2$0$4221$...
"Fabien LE LEZ" a écrit dans le message news:
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome :
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le développement pourra-t-il continuer ?
A question classique, réponse classique (et souvent vérifiée) : un bon logiciel trouve un repreneur, tout simplement en raison du potentiel de sa base installée.
Dans la pratique, que le logiciel soit gratuit ou qu'il soit payant, qu'il soit open source ou non, si personne veut continuer son developpement, tu es dans la merde. A moins d'etre une vraiement grosse boite, tu ne vas pas pouvoir reprendre le developpement d'un logiciel non-trivial.
Dans la pratique, en revanche, je constate que la raison la plus frequente de l'arret de developpement d'un logiciel n'est pas la faillite d'une boite, ou une decision des developpeurs d'abandonner. C'est suite a l'achat du logiciel par une autre boite concurrente, en vue de supprimer un concurrent. (J'ai vu au moins deux logiciels interessants disparaitre apres leur achat par Rogue Wave. Qui par hazard avait un logiciel concurrent moins interessant a proposer.)
Ce qui est, j'avoue, un argument pour des logiciels libres (qu'on ne peut pas acheter).
-- James Kanze
"Alain Naigeon" <anaigeon@free.fr> wrote in message news:<40fd78c2$0$4221$626a14ce@news.free.fr>...
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message news:
18hqf0lthki9c676apkrls2cvaqs5dsoc3@4ax.com...
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome
<jerome.martinez@aenlever-orangefrance.com.invalid>:
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le
développement pourra-t-il continuer ?
A question classique, réponse classique (et souvent vérifiée) :
un bon logiciel trouve un repreneur, tout simplement en
raison du potentiel de sa base installée.
Dans la pratique, que le logiciel soit gratuit ou qu'il
soit payant, qu'il soit open source ou non, si personne
veut continuer son developpement, tu es dans la merde.
A moins d'etre une vraiement grosse boite, tu ne vas pas
pouvoir reprendre le developpement d'un logiciel non-trivial.
Dans la pratique, en revanche, je constate que la raison
la plus frequente de l'arret de developpement d'un logiciel
n'est pas la faillite d'une boite, ou une decision des
developpeurs d'abandonner. C'est suite a l'achat du logiciel
par une autre boite concurrente, en vue de supprimer un
concurrent. (J'ai vu au moins deux logiciels interessants
disparaitre apres leur achat par Rogue Wave. Qui par hazard
avait un logiciel concurrent moins interessant a proposer.)
Ce qui est, j'avoue, un argument pour des logiciels libres
(qu'on ne peut pas acheter).
"Alain Naigeon" wrote in message news:<40fd78c2$0$4221$...
"Fabien LE LEZ" a écrit dans le message news:
On Tue, 20 Jul 2004 17:54:30 +0200, Martinez Jerome :
- Qt est commercial : entreprise qui developpe
Au fait, si jamais l'entreprise qui développe fait faillite, le développement pourra-t-il continuer ?
A question classique, réponse classique (et souvent vérifiée) : un bon logiciel trouve un repreneur, tout simplement en raison du potentiel de sa base installée.
Dans la pratique, que le logiciel soit gratuit ou qu'il soit payant, qu'il soit open source ou non, si personne veut continuer son developpement, tu es dans la merde. A moins d'etre une vraiement grosse boite, tu ne vas pas pouvoir reprendre le developpement d'un logiciel non-trivial.
Dans la pratique, en revanche, je constate que la raison la plus frequente de l'arret de developpement d'un logiciel n'est pas la faillite d'une boite, ou une decision des developpeurs d'abandonner. C'est suite a l'achat du logiciel par une autre boite concurrente, en vue de supprimer un concurrent. (J'ai vu au moins deux logiciels interessants disparaitre apres leur achat par Rogue Wave. Qui par hazard avait un logiciel concurrent moins interessant a proposer.)
Ce qui est, j'avoue, un argument pour des logiciels libres (qu'on ne peut pas acheter).
-- James Kanze
kanze
Gabriel Dos Reis wrote in message news:...
Jean-Marc Bourguet writes:
| Fabien LE LEZ writes: | | > On Wed, 28 Jul 2004 02:36:46 +0200, drkm : | > | > > Oops. La discussion tournait en partie autour de la *L*GPL. J'ai | > >loupé une lettre. Désolé. | > | > D'ailleurs, il me semble que parler de "LGPL" est un peu un abus de | > langage : la LGPL n'est pas une GPL "édulcorée", mais au contraire une | > licence à la philosophie tout à fait différente. | > - GPL : si vous utilisez mon code, vous sortez du monde | > "classique" et vous entrez dans le monde "GPL". | > - LGPL : vous faites ce que vous voulez de mon code, mais soyez | > sympa, laissez mon nom dans un coin. | | Pas tout a fait. La LGPL, vous pouvez utiliser mon code sans le | modifier mais si vous le modifiez tout passe en GPL (ou en LGPL je | sais plus). | | Avec des problemes de formulation pour les templates et les inline et | donc gcc utilise quelque chose d'autre pour la bibliotheque C++ | standard (GPL avec une clause d'exemption) plutot que la LGPL. Gaby | pourra confirmer ou infirmer vraissemblablement.
Tu as parfiatement raison.
Note que c'est aussi possible d'utiliser un logiciel GPL avec un logiciel proprietaire sans contamination. A condition de l'" isoler " suffisamment. Je ne suis pas sur ce que veut dire suffisamment ici, mais Sun Workshop est bien livre avec emacs (ou xemacs, ou les deux), sans que Stallman s'est plaint. Linke statiquement, ce n'est surement pas isole suffisamment. Un dll dans un autre repertoire ? Je n'en sais rien.
Un autre approche interessant serait un wrapper Corba des fonctions, avec toute la partie GPL dans un processus a part. La non plus, je ne saurais dire si l'isolation est suffisante ou non.
-- James Kanze
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message news:<m3isc840a9.fsf@uniton.integrable-solutions.net>...
Jean-Marc Bourguet <jm@bourguet.org> writes:
| Fabien LE LEZ <gramster@gramster.com> writes:
|
| > On Wed, 28 Jul 2004 02:36:46 +0200, drkm <usenet.fclcxx@fgeorges.org>:
| >
| > > Oops. La discussion tournait en partie autour de la *L*GPL. J'ai
| > >loupé une lettre. Désolé.
| >
| > D'ailleurs, il me semble que parler de "LGPL" est un peu un abus de
| > langage : la LGPL n'est pas une GPL "édulcorée", mais au contraire une
| > licence à la philosophie tout à fait différente.
| > - GPL : si vous utilisez mon code, vous sortez du monde
| > "classique" et vous entrez dans le monde "GPL".
| > - LGPL : vous faites ce que vous voulez de mon code, mais soyez
| > sympa, laissez mon nom dans un coin.
|
| Pas tout a fait. La LGPL, vous pouvez utiliser mon code sans le
| modifier mais si vous le modifiez tout passe en GPL (ou en LGPL je
| sais plus).
|
| Avec des problemes de formulation pour les templates et les inline et
| donc gcc utilise quelque chose d'autre pour la bibliotheque C++
| standard (GPL avec une clause d'exemption) plutot que la LGPL. Gaby
| pourra confirmer ou infirmer vraissemblablement.
Tu as parfiatement raison.
Note que c'est aussi possible d'utiliser un logiciel GPL avec
un logiciel proprietaire sans contamination. A condition de
l'" isoler " suffisamment. Je ne suis pas sur ce que veut
dire suffisamment ici, mais Sun Workshop est bien livre avec
emacs (ou xemacs, ou les deux), sans que Stallman s'est plaint.
Linke statiquement, ce n'est surement pas isole suffisamment.
Un dll dans un autre repertoire ? Je n'en sais rien.
Un autre approche interessant serait un wrapper Corba des fonctions,
avec toute la partie GPL dans un processus a part. La non plus,
je ne saurais dire si l'isolation est suffisante ou non.
| Fabien LE LEZ writes: | | > On Wed, 28 Jul 2004 02:36:46 +0200, drkm : | > | > > Oops. La discussion tournait en partie autour de la *L*GPL. J'ai | > >loupé une lettre. Désolé. | > | > D'ailleurs, il me semble que parler de "LGPL" est un peu un abus de | > langage : la LGPL n'est pas une GPL "édulcorée", mais au contraire une | > licence à la philosophie tout à fait différente. | > - GPL : si vous utilisez mon code, vous sortez du monde | > "classique" et vous entrez dans le monde "GPL". | > - LGPL : vous faites ce que vous voulez de mon code, mais soyez | > sympa, laissez mon nom dans un coin. | | Pas tout a fait. La LGPL, vous pouvez utiliser mon code sans le | modifier mais si vous le modifiez tout passe en GPL (ou en LGPL je | sais plus). | | Avec des problemes de formulation pour les templates et les inline et | donc gcc utilise quelque chose d'autre pour la bibliotheque C++ | standard (GPL avec une clause d'exemption) plutot que la LGPL. Gaby | pourra confirmer ou infirmer vraissemblablement.
Tu as parfiatement raison.
Note que c'est aussi possible d'utiliser un logiciel GPL avec un logiciel proprietaire sans contamination. A condition de l'" isoler " suffisamment. Je ne suis pas sur ce que veut dire suffisamment ici, mais Sun Workshop est bien livre avec emacs (ou xemacs, ou les deux), sans que Stallman s'est plaint. Linke statiquement, ce n'est surement pas isole suffisamment. Un dll dans un autre repertoire ? Je n'en sais rien.
Un autre approche interessant serait un wrapper Corba des fonctions, avec toute la partie GPL dans un processus a part. La non plus, je ne saurais dire si l'isolation est suffisante ou non.
-- James Kanze
Fabien LE LEZ
On 30 Jul 2004 20:03:55 -0700, :
Qui par hazard
Je trouve le jeu de mots entre le mot anglais "hazard" (danger) et le mot français "hasard", particulièrement pertinent, même s'il n'est pas volontaire ;-)
-- ;-)
On 30 Jul 2004 20:03:55 -0700, kanze@gabi-soft.fr:
Qui par hazard
Je trouve le jeu de mots entre le mot anglais "hazard" (danger) et le
mot français "hasard", particulièrement pertinent, même s'il n'est pas
volontaire ;-)
Je trouve le jeu de mots entre le mot anglais "hazard" (danger) et le mot français "hasard", particulièrement pertinent, même s'il n'est pas volontaire ;-)
-- ;-)
Jean-Marc Bourguet
writes:
Note que c'est aussi possible d'utiliser un logiciel GPL avec un logiciel proprietaire sans contamination. A condition de l'" isoler " suffisamment.
Pour qu'il y ait « contamination », il faut et il suffit que ce soit un « dérivé » du logiciel GPL au sens des réglementations et des traités sur le copyright.
Je ne suis pas sur ce que veut dire suffisamment ici,
Je crois qu'en ultime recours, seul un tribunal peut trancher.
mais Sun Workshop est bien livre avec emacs (ou xemacs, ou les deux), sans que Stallman s'est plaint.
Les modifications faites dans xemacs (pas vu emacs même s'il est capable de fonctionner avec) se résume à du lisp. En fait on peut ne pas utiliser la version fournie mais une qu'on a compilée soit même sans rien perdre en fonctionnalité (je n'en suis pas aussi sur pour les versions de vim et de l'autre editeur fournit). Pour xemacs, tout ce qu'il font c'est fournir une version compilée.
Linke statiquement, ce n'est surement pas isole suffisamment. Un dll dans un autre repertoire ? Je n'en sais rien.
Je crains qu'il n'y ait pas de réponse absolue quant à savoir où se trouve la frontière. Et j'ai l'impression qu'en cas de jugement, le contexte jouerait beaucoup.
Un autre approche interessant serait un wrapper Corba des fonctions, avec toute la partie GPL dans un processus a part. La non plus, je ne saurais dire si l'isolation est suffisante ou non.
Même pour des exécutables séparés communiquant par fichier, je ne suis pas sûr. Si tu modifies gcc par exemple pour accepter en entrée un format équivalent à une de ses structures intermédiaires, et que tu fais un parseur générant un tel fichier et que tu ne le fournis pas sous GPL, je ne serais pas étonné que tu sois condamnable . Maintenant si tu fais un parseur qui ne génère que du C à la sauce GNU, la différence est minime (je doute qu'un autre compilateur accepte toutes les extensions), qu'en est'il? Et si tu vends différentes version ayant pour cible différents compilateurs (genre como)? Et si ton parseur génère du C ISO mais a une option pour utiliser les extensions de GCC? Je crains que ça dépende du pays, des juges et de la qualité des avocats et des experts...
La politique de la FSF est intéressante (évitant les procés mais arrachant suffisemment de concession pour pouvoir prétendre qu'un procés n'aurais plus d'objet).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index. html Site de usenet-fr: http://www.usenet-fr.news.eu.org
kanze@gabi-soft.fr writes:
Note que c'est aussi possible d'utiliser un logiciel GPL
avec un logiciel proprietaire sans contamination. A
condition de l'" isoler " suffisamment.
Pour qu'il y ait « contamination », il faut et il suffit que
ce soit un « dérivé » du logiciel GPL au sens des
réglementations et des traités sur le copyright.
Je ne suis pas sur ce que veut dire suffisamment ici,
Je crois qu'en ultime recours, seul un tribunal peut
trancher.
mais Sun Workshop est bien livre avec emacs (ou xemacs, ou
les deux), sans que Stallman s'est plaint.
Les modifications faites dans xemacs (pas vu emacs même s'il
est capable de fonctionner avec) se résume à du lisp. En
fait on peut ne pas utiliser la version fournie mais une
qu'on a compilée soit même sans rien perdre en
fonctionnalité (je n'en suis pas aussi sur pour les versions
de vim et de l'autre editeur fournit). Pour xemacs, tout ce
qu'il font c'est fournir une version compilée.
Linke statiquement, ce n'est surement pas isole
suffisamment. Un dll dans un autre repertoire ? Je n'en
sais rien.
Je crains qu'il n'y ait pas de réponse absolue quant à
savoir où se trouve la frontière. Et j'ai l'impression
qu'en cas de jugement, le contexte jouerait beaucoup.
Un autre approche interessant serait un wrapper Corba des
fonctions, avec toute la partie GPL dans un processus a
part. La non plus, je ne saurais dire si l'isolation est
suffisante ou non.
Même pour des exécutables séparés communiquant par fichier,
je ne suis pas sûr. Si tu modifies gcc par exemple pour
accepter en entrée un format équivalent à une de ses
structures intermédiaires, et que tu fais un parseur
générant un tel fichier et que tu ne le fournis pas sous
GPL, je ne serais pas étonné que tu sois condamnable .
Maintenant si tu fais un parseur qui ne génère que du C à la
sauce GNU, la différence est minime (je doute qu'un autre
compilateur accepte toutes les extensions), qu'en est'il?
Et si tu vends différentes version ayant pour cible
différents compilateurs (genre como)? Et si ton parseur
génère du C ISO mais a une option pour utiliser les
extensions de GCC? Je crains que ça dépende du pays, des
juges et de la qualité des avocats et des experts...
La politique de la FSF est intéressante (évitant les procés
mais arrachant suffisemment de concession pour pouvoir
prétendre qu'un procés n'aurais plus d'objet).
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index. html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Note que c'est aussi possible d'utiliser un logiciel GPL avec un logiciel proprietaire sans contamination. A condition de l'" isoler " suffisamment.
Pour qu'il y ait « contamination », il faut et il suffit que ce soit un « dérivé » du logiciel GPL au sens des réglementations et des traités sur le copyright.
Je ne suis pas sur ce que veut dire suffisamment ici,
Je crois qu'en ultime recours, seul un tribunal peut trancher.
mais Sun Workshop est bien livre avec emacs (ou xemacs, ou les deux), sans que Stallman s'est plaint.
Les modifications faites dans xemacs (pas vu emacs même s'il est capable de fonctionner avec) se résume à du lisp. En fait on peut ne pas utiliser la version fournie mais une qu'on a compilée soit même sans rien perdre en fonctionnalité (je n'en suis pas aussi sur pour les versions de vim et de l'autre editeur fournit). Pour xemacs, tout ce qu'il font c'est fournir une version compilée.
Linke statiquement, ce n'est surement pas isole suffisamment. Un dll dans un autre repertoire ? Je n'en sais rien.
Je crains qu'il n'y ait pas de réponse absolue quant à savoir où se trouve la frontière. Et j'ai l'impression qu'en cas de jugement, le contexte jouerait beaucoup.
Un autre approche interessant serait un wrapper Corba des fonctions, avec toute la partie GPL dans un processus a part. La non plus, je ne saurais dire si l'isolation est suffisante ou non.
Même pour des exécutables séparés communiquant par fichier, je ne suis pas sûr. Si tu modifies gcc par exemple pour accepter en entrée un format équivalent à une de ses structures intermédiaires, et que tu fais un parseur générant un tel fichier et que tu ne le fournis pas sous GPL, je ne serais pas étonné que tu sois condamnable . Maintenant si tu fais un parseur qui ne génère que du C à la sauce GNU, la différence est minime (je doute qu'un autre compilateur accepte toutes les extensions), qu'en est'il? Et si tu vends différentes version ayant pour cible différents compilateurs (genre como)? Et si ton parseur génère du C ISO mais a une option pour utiliser les extensions de GCC? Je crains que ça dépende du pays, des juges et de la qualité des avocats et des experts...
La politique de la FSF est intéressante (évitant les procés mais arrachant suffisemment de concession pour pouvoir prétendre qu'un procés n'aurais plus d'objet).
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index. html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Loïc Joly
Jean-Marc Bourguet wrote:
Même pour des exécutables séparés communiquant par fichier, je ne suis pas sûr. Si tu modifies gcc par exemple pour accepter en entrée un format équivalent à une de ses structures intermédiaires, et que tu fais un parseur générant un tel fichier et que tu ne le fournis pas sous GPL, je ne serais pas étonné que tu sois condamnable .
Je n'en suis pas sur, en France tout du moins. En effet, s'interfacer avec un logiciel fait (ou faisait, ça a peut-être changé) partie du droit français. Il y avait même autorisation de décompiler un logiciel, quelle que soit sa license, s'il n'y avait pas d'autres moyen d'obtenir la spécification de ses formats de fichier.
Mais bon, c'est sur que là, on commence à entrer dans la zone du flou juridique, et comme on dit, mieux vaut un mauvais compromis qu'un procès, même gagné.
-- Loïc
Jean-Marc Bourguet wrote:
Même pour des exécutables séparés communiquant par fichier,
je ne suis pas sûr. Si tu modifies gcc par exemple pour
accepter en entrée un format équivalent à une de ses
structures intermédiaires, et que tu fais un parseur
générant un tel fichier et que tu ne le fournis pas sous
GPL, je ne serais pas étonné que tu sois condamnable .
Je n'en suis pas sur, en France tout du moins. En effet, s'interfacer
avec un logiciel fait (ou faisait, ça a peut-être changé) partie du
droit français. Il y avait même autorisation de décompiler un logiciel,
quelle que soit sa license, s'il n'y avait pas d'autres moyen d'obtenir
la spécification de ses formats de fichier.
Mais bon, c'est sur que là, on commence à entrer dans la zone du flou
juridique, et comme on dit, mieux vaut un mauvais compromis qu'un
procès, même gagné.
Même pour des exécutables séparés communiquant par fichier, je ne suis pas sûr. Si tu modifies gcc par exemple pour accepter en entrée un format équivalent à une de ses structures intermédiaires, et que tu fais un parseur générant un tel fichier et que tu ne le fournis pas sous GPL, je ne serais pas étonné que tu sois condamnable .
Je n'en suis pas sur, en France tout du moins. En effet, s'interfacer avec un logiciel fait (ou faisait, ça a peut-être changé) partie du droit français. Il y avait même autorisation de décompiler un logiciel, quelle que soit sa license, s'il n'y avait pas d'autres moyen d'obtenir la spécification de ses formats de fichier.
Mais bon, c'est sur que là, on commence à entrer dans la zone du flou juridique, et comme on dit, mieux vaut un mauvais compromis qu'un procès, même gagné.
