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...)
| 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).
| 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).
| 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).
Oui. Une license est toujours négociable -- en particulier GPL ;-)
-- Gaby
--=-=-=--
Jean-Marc Bourguet
Loïc Joly writes:
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.
C'est une chose de s'interfacer avec quelque chose que tu as légalement par une autre voie, c'est une autre de pouvoir distribuer quelque chose, surtout une version modifiée.
Autrement dit je ne serais surpris outre mesure si, pour le cas du générateur de GNU C par exemple, on pourrait se trouver dans la situation où on peut l'écrire et le distribuer avec la licence que l'on veut sauf si on distribue simultanément gcc auquel cas on devrait tout mettre sous GPL.
Ce que je ne vois pas, c'est pourquoi un choix technique d'organisation (bibliothèque statique, dynamique ou forme de RPC) changerait le fait que l'ensemble soit un dérivé ou non du logiciel modifié.
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 <loic.actarus.joly@wanadoo.fr> writes:
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.
C'est une chose de s'interfacer avec quelque chose que tu as
légalement par une autre voie, c'est une autre de pouvoir
distribuer quelque chose, surtout une version modifiée.
Autrement dit je ne serais surpris outre mesure si, pour le
cas du générateur de GNU C par exemple, on pourrait se
trouver dans la situation où on peut l'écrire et le
distribuer avec la licence que l'on veut sauf si on
distribue simultanément gcc auquel cas on devrait tout
mettre sous GPL.
Ce que je ne vois pas, c'est pourquoi un choix technique
d'organisation (bibliothèque statique, dynamique ou forme de
RPC) changerait le fait que l'ensemble soit un dérivé ou non
du logiciel modifié.
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
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.
C'est une chose de s'interfacer avec quelque chose que tu as légalement par une autre voie, c'est une autre de pouvoir distribuer quelque chose, surtout une version modifiée.
Autrement dit je ne serais surpris outre mesure si, pour le cas du générateur de GNU C par exemple, on pourrait se trouver dans la situation où on peut l'écrire et le distribuer avec la licence que l'on veut sauf si on distribue simultanément gcc auquel cas on devrait tout mettre sous GPL.
Ce que je ne vois pas, c'est pourquoi un choix technique d'organisation (bibliothèque statique, dynamique ou forme de RPC) changerait le fait que l'ensemble soit un dérivé ou non du logiciel modifié.
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
Matthieu Moy
Jean-Marc Bourguet writes:
Ce que je ne vois pas, c'est pourquoi un choix technique d'organisation (bibliothèque statique, dynamique ou forme de RPC) changerait le fait que l'ensemble soit un dérivé ou non du logiciel modifié.
Et c'est pourtant le cas. Le texte de la GPL reste assez flou sur la définition de travaux dérivés (c'est la loi sur le copyright qui donne la définition précise), mais il est admis que tout ce qui tourne dans le même processus que du code GPL est considéré comme travail dérivé. (c'est d'ailleurs la raison d'être de la LGPL). Par contre, un truc qui arrive souvent, c'est d'avoir un front-end graphique pour un programme GPL, et le front-end n'est alors pas considéré comme travail dérivé quand il utilise le programme en temps que tel, alors qu'il l'aurait été si il avait "bibliothéquisé" le programme.
-- Matthieu
Jean-Marc Bourguet <jm@bourguet.org> writes:
Ce que je ne vois pas, c'est pourquoi un choix technique
d'organisation (bibliothèque statique, dynamique ou forme de
RPC) changerait le fait que l'ensemble soit un dérivé ou non
du logiciel modifié.
Et c'est pourtant le cas. Le texte de la GPL reste assez flou sur la
définition de travaux dérivés (c'est la loi sur le copyright qui donne
la définition précise), mais il est admis que tout ce qui tourne dans
le même processus que du code GPL est considéré comme travail dérivé.
(c'est d'ailleurs la raison d'être de la LGPL). Par contre, un truc
qui arrive souvent, c'est d'avoir un front-end graphique pour un
programme GPL, et le front-end n'est alors pas considéré comme travail
dérivé quand il utilise le programme en temps que tel, alors qu'il
l'aurait été si il avait "bibliothéquisé" le programme.
Ce que je ne vois pas, c'est pourquoi un choix technique d'organisation (bibliothèque statique, dynamique ou forme de RPC) changerait le fait que l'ensemble soit un dérivé ou non du logiciel modifié.
Et c'est pourtant le cas. Le texte de la GPL reste assez flou sur la définition de travaux dérivés (c'est la loi sur le copyright qui donne la définition précise), mais il est admis que tout ce qui tourne dans le même processus que du code GPL est considéré comme travail dérivé. (c'est d'ailleurs la raison d'être de la LGPL). Par contre, un truc qui arrive souvent, c'est d'avoir un front-end graphique pour un programme GPL, et le front-end n'est alors pas considéré comme travail dérivé quand il utilise le programme en temps que tel, alors qu'il l'aurait été si il avait "bibliothéquisé" le programme.
-- Matthieu
Jean-Marc Bourguet
Matthieu Moy writes:
Jean-Marc Bourguet writes:
Ce que je ne vois pas, c'est pourquoi un choix technique d'organisation (bibliothèque statique, dynamique ou forme de RPC) changerait le fait que l'ensemble soit un dérivé ou non du logiciel modifié.
Et c'est pourtant le cas. Le texte de la GPL reste assez flou sur la définition de travaux dérivés (c'est la loi sur le copyright qui donne la définition précise), mais il est admis que tout ce qui tourne dans le même processus que du code GPL est considéré comme travail dérivé.
1/ Il y a qu'un tribunal qui peut decider de maniere definitive si quelque chose est un travail derive. Et seul l'auteur peut demander au juge de decider. Le tribunal va decider sur le cas particulier et l'analyse de ses attendus va permettre d'estimer dans quelle mesure le cas particulier est etendable.
2/ Le copyright est essentiellement une question de distribution.
3/ Je ne suis pas sur du tout qu'un plug-in (qui tourne dans le meme processus), qu'un script (qui tourne aussi dans le meme processus) soit des travaux derives.
(c'est d'ailleurs la raison d'être de la LGPL).
Par contre, un truc qui arrive souvent, c'est d'avoir un front-end graphique pour un programme GPL, et le front-end n'est alors pas considéré comme travail dérivé quand il utilise le programme en temps que tel, alors qu'il l'aurait été si il avait "bibliothéquisé" le programme.
Mais ces front-ends sont distribues separement. Comme je l'ai ecrit je ne serait pas surpris si on arrivait a une situation ou distribuer l'ensemble fasse de cette ensemble un travail derive et distribuer ne le fasse pas.
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
Ce que je ne vois pas, c'est pourquoi un choix technique
d'organisation (bibliothèque statique, dynamique ou forme de
RPC) changerait le fait que l'ensemble soit un dérivé ou non
du logiciel modifié.
Et c'est pourtant le cas. Le texte de la GPL reste assez flou sur la
définition de travaux dérivés (c'est la loi sur le copyright qui
donne la définition précise), mais il est admis que tout ce qui
tourne dans le même processus que du code GPL est considéré comme
travail dérivé.
1/ Il y a qu'un tribunal qui peut decider de maniere definitive si
quelque chose est un travail derive. Et seul l'auteur peut demander
au juge de decider. Le tribunal va decider sur le cas particulier et
l'analyse de ses attendus va permettre d'estimer dans quelle mesure le
cas particulier est etendable.
2/ Le copyright est essentiellement une question de distribution.
3/ Je ne suis pas sur du tout qu'un plug-in (qui tourne dans le meme
processus), qu'un script (qui tourne aussi dans le meme processus)
soit des travaux derives.
(c'est d'ailleurs la raison d'être de la LGPL).
Par contre, un truc qui arrive souvent, c'est d'avoir un front-end
graphique pour un programme GPL, et le front-end n'est alors pas
considéré comme travail dérivé quand il utilise le programme en
temps que tel, alors qu'il l'aurait été si il avait "bibliothéquisé"
le programme.
Mais ces front-ends sont distribues separement. Comme je l'ai ecrit
je ne serait pas surpris si on arrivait a une situation ou distribuer
l'ensemble fasse de cette ensemble un travail derive et distribuer ne
le fasse pas.
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
Ce que je ne vois pas, c'est pourquoi un choix technique d'organisation (bibliothèque statique, dynamique ou forme de RPC) changerait le fait que l'ensemble soit un dérivé ou non du logiciel modifié.
Et c'est pourtant le cas. Le texte de la GPL reste assez flou sur la définition de travaux dérivés (c'est la loi sur le copyright qui donne la définition précise), mais il est admis que tout ce qui tourne dans le même processus que du code GPL est considéré comme travail dérivé.
1/ Il y a qu'un tribunal qui peut decider de maniere definitive si quelque chose est un travail derive. Et seul l'auteur peut demander au juge de decider. Le tribunal va decider sur le cas particulier et l'analyse de ses attendus va permettre d'estimer dans quelle mesure le cas particulier est etendable.
2/ Le copyright est essentiellement une question de distribution.
3/ Je ne suis pas sur du tout qu'un plug-in (qui tourne dans le meme processus), qu'un script (qui tourne aussi dans le meme processus) soit des travaux derives.
(c'est d'ailleurs la raison d'être de la LGPL).
Par contre, un truc qui arrive souvent, c'est d'avoir un front-end graphique pour un programme GPL, et le front-end n'est alors pas considéré comme travail dérivé quand il utilise le programme en temps que tel, alors qu'il l'aurait été si il avait "bibliothéquisé" le programme.
Mais ces front-ends sont distribues separement. Comme je l'ai ecrit je ne serait pas surpris si on arrivait a une situation ou distribuer l'ensemble fasse de cette ensemble un travail derive et distribuer ne le fasse pas.
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
adebaene
Matthieu Moy wrote in message news:...
Jean-Marc Bourguet writes:
Ce que je ne vois pas, c'est pourquoi un choix technique d'organisation (bibliothèque statique, dynamique ou forme de RPC) changerait le fait que l'ensemble soit un dérivé ou non du logiciel modifié.
Et c'est pourtant le cas. Oui mais *pourquoi* faire cette distinction? C'est un détail technique
qui n'a pas d'impact sur le fonctionnel de la bilbiothèque (seule élément qui devrait rentrer en ligne de compte du point de vue légal AMHA).
Le texte de la GPL reste assez flou sur la définition de travaux dérivés (c'est la loi sur le copyright qui donne la définition précise), mais il est admis que tout ce qui tourne dans le même processus que du code GPL est considéré comme travail dérivé. Et si je suis sur un système qui n'a pas de notion de processus - une
console de jeux par exemple ?
Bref, on sent quand même que la GPL a été écrite par des informaticiens et pas par des juristes...
Arnaud
Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> wrote in message news:<vpqoelv9mdy.fsf@ecrins.imag.fr>...
Jean-Marc Bourguet <jm@bourguet.org> writes:
Ce que je ne vois pas, c'est pourquoi un choix technique
d'organisation (bibliothèque statique, dynamique ou forme de
RPC) changerait le fait que l'ensemble soit un dérivé ou non
du logiciel modifié.
Et c'est pourtant le cas.
Oui mais *pourquoi* faire cette distinction? C'est un détail technique
qui n'a pas d'impact sur le fonctionnel de la bilbiothèque (seule
élément qui devrait rentrer en ligne de compte du point de vue légal
AMHA).
Le texte de la GPL reste assez flou sur la
définition de travaux dérivés (c'est la loi sur le copyright qui donne
la définition précise), mais il est admis que tout ce qui tourne dans
le même processus que du code GPL est considéré comme travail dérivé.
Et si je suis sur un système qui n'a pas de notion de processus - une
console de jeux par exemple ?
Bref, on sent quand même que la GPL a été écrite par des
informaticiens et pas par des juristes...
Ce que je ne vois pas, c'est pourquoi un choix technique d'organisation (bibliothèque statique, dynamique ou forme de RPC) changerait le fait que l'ensemble soit un dérivé ou non du logiciel modifié.
Et c'est pourtant le cas. Oui mais *pourquoi* faire cette distinction? C'est un détail technique
qui n'a pas d'impact sur le fonctionnel de la bilbiothèque (seule élément qui devrait rentrer en ligne de compte du point de vue légal AMHA).
Le texte de la GPL reste assez flou sur la définition de travaux dérivés (c'est la loi sur le copyright qui donne la définition précise), mais il est admis que tout ce qui tourne dans le même processus que du code GPL est considéré comme travail dérivé. Et si je suis sur un système qui n'a pas de notion de processus - une
console de jeux par exemple ?
Bref, on sent quand même que la GPL a été écrite par des informaticiens et pas par des juristes...
Arnaud
Gabriel Dos Reis
(Arnaud Debaene) writes:
[...]
| Bref, on sent quand même que la GPL a été écrite par des | informaticiens et pas par des juristes...
