Si les auteurs de TITI sont d'accord, c'est tout a fait possible. MySQL AB peut très bien décider d'arrêter la version GPL et de ne distribuer que la version commerciale (mais il y aura un fork libre dans les 10 min). C'est plus ou moins ce qui est arrivé à PHP-Nuke, il me semble (mais vu qu'a peu près tout le monde avait l'air d'accord pour dire que c'était une bouse, je crois pas qu'il y ai eu de fork ;-) ).
La BSD, tout comme la GPL, te garantissent que si tu as eu accès aux sources et que tu en a gardé une copie, alors le logiciel restera libre pour toi. (et tu auras le droit de redistribuer, de forker, ...).
La GPL apporte plusieurs garanties en plus, en particulier, le fait que même si tu n'as que le binaire, tu pourras avoir accès aux sources si tu le souhaite. Elle rends aussi beaucoup plus difficile le scénario "Temps 3", vu qu'il faut l'accord de tous les détenteurs de copyright, et il peut y en avoir beaucoup (cf. le gars qui voulait acheter un Linux sous licence BSD y'a quelques temps).
Il faut surtout qu'ils donnent l'autorisation à leur client de redistribuer et éventuellement de modifier les sources. C'est acceptable dans certains cas, mais si la boite avait un business model uniquement basé sur la vente, elle est morte.
C'est clair. Je vois pas bien la différence entre leur truc et un système ou tu ouvres une session avec cookie + HTTPS en répondant aux questions au début et en validant a la fin.
> Comme les licences non-compatibles GPL posent problème avec certains programmes libres.
Des licences libres qui t'imposent quoi que ce soit sur le code lié statiquement ou dynamiquement a un programme, je n'en connais pas des masses.
Pour tous les cas d'incompatibilité avec la GPL que je connaisse, si tu fait un travail dérivé contenant du code sous licence X (GPL incompatible) et du code GPL, tu violes la GPL, mais pas l'autre licence.
> Donc il n'y a pas de licence compatible GPL autre que la GPL d'origine ? C'est ce que tu affirmes.
Non. Ce que j'affirme, c'est que pour qu'une licence soit compatible GPL, il faut que cette licence te permette de redistribuer sous GPL. Va regarder dans la FAQ de la GPL si tu n'est pas convaincu. Allez, je cite :
Je maintiens, si tu renommes la GPL, et que tu l'appelle la licence toto, alors la licence toto ne t'autorise pas a distribuer le code sous la licence GNU GPL, donc, la licence toto n'est pas compatible GPL.
Tu regardes la LGPL par exemple. Ce qui fait qu'elle est compatible GPL, c'est cette petite phrase:
3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library.
(et au passage, la LGPL n'est donc pas compatible avec notre licence toto ci-dessus non plus)
> Tu demande à la GPL un truc que tu ne demandes pas à la licence SystemC
La licence de SystemC me perment de lier mon code à SystemC, quelle que soit la licence du code en question. J'en ai rien a fouttre que dans mon projet, SystemC soit sous une licence X ou Y. Ce que je veux, c'est pouvoir choisir la licence de mon code, et pouvoir utilser SystemC et GCC.
Si tu tiens a lire la licence de SystemC, c'est là, mais ça n'a rien de passionnant.
> Donc c'est illégal. Ou plus précisément tu n'as pas le droit de le distribuer.
T'es vraiment bouché sur ce coup. Le logiciel non libre est légal. Scoop !
Tu prends un programme sous licence BSD. Tu lui rajoute du code sous licence non libre (évidemment, tu prends pas une licence qui t'interdise la modification, mais, scoop nb 2, il y a des licences non libres qui autorisent les travaux dérivés et la redistribution). Tu obtiens un truc légal, mais non libre.
> Les incompatibilité sont toujours dans les deux sens.
C'est parfaitement faux.
Si je prends du code CDDL et du code GPL, et que je les met ensemble, j'obtient un truc que je n'ai pas le droit de distribuer parce qu'il y a incompatibilité. Si je le distribue, j'enfreint la propriété intellectuelle de l'auteur du code GPL, mais pas celle de l'auteur du code CDDL. En gros, si je fais un Solarinux qui mélange le code de Linux et celui d'OpenSolaris, SUN n'a aucun recours en justice puisque je ne viole pas leur licence. Les auteurs de Linux peuvent porter plainte par contre.
> SUN ne peut pas mettre de code libre dans son jdk.
Qu'est ce qui les en empêche ? Ils ne peuvent pas mettre de code GPL, mais si ils veulent mettre du code sous une license
> C'est le copy(left|right) qui fait qu'un programme est libre.
Du code sans copyright, c'est du domaine public et c'est libre.
Du code sans copyleft, c'est par exemple du code BSD, et c'est libre.
> N'importe quoi. Renseignes toi, il y a des licences compatibles avec le GPL et qui ne sont pas la GPL.
GPL, paragraphe 2-b) :
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
"This license", c'est la GPL et rien d'autre. Une GPL renommée n'est pas la GPL, et n'est pas compatible GPL.
Ce qui peut rendre une licence compatible GPL, c'est si cette licence t'autorise a distribuer le soft en GPL. La GPL n'autorise pas le changement de licence, une GPL renommée ne l'autoriserait pas non plus.
> Cette incompatibilité vient de la GPL *ET* de la licence de ton code.
Affirmation que j'accepterais si tu me donnes le paragraphe de la license SystemC (qui par ailleurs n'est pas mon code, mais du code que je réutilise) qui le rends incompatible avec la GPL. Pour le paragraphe de la GPL qui fout la merde, tu peux regarder 10 lignes plus haut.
> Il est donc illégale de mettre du code sous SunCommunity dans un projet libre qui par définition te permet de modifier le code.
C'est parfaitement légal, mais le résultat n'est pas libre. Sauf si le projet libre t'interdit de mettre du code SunCommunity, mais là, je crois que tu confonds copyleft et libre.
Si tu veux une licence libre incompatible GPL, je peux t'en fabriquer une quand tu veux : Tu prends la GPL, tu change son nom, et uniquement son nom, et tu as une licence GPL incompatible.
La licence de systemc n'y est pas listée, mais elle en fait partie. J'utilise SystemC dans mon programme.
> Alors là, je comprend encore moins. Il y a même des patchs pour gcc. Peux-tu patcher EDG ?
Je n'en aurais pas eu besoin. Au pire, ils fournissent les sources sous NDA, il y a peut-être moyen de patcher.
Mon propos, c'est simplement que c'est a moi de choisir la licence du code que j'écris. Un truc vraiment libre ne devrait rien m'imposer sur *mon* code quand je l'utilise.
> Le libre n'est pas synonyme de catastrophe économique.
En effet, y'a pleins de domaines où on peut faire des thunes avec du GPL/LGPL, mais il ne faut pas croire que ça s'applique partout. Dans le cas de EDG, si tu as un business model a leur proposer basé sur du libre, ne te gènes pas, mais mon avis est que c'est illusoire.
> > mais pas distribuable sous forme binaire a cause des restrictions de la GPL par rapport aux autres licenses.
> "Restrictions", tu absuses surtout que tu parles de licences proprio et libre.
Non, je parle de licences libres. L'exemple auquel je faisait allusion est mon parser systemc[1] qui est 100% libre, mais a le malheur d'utiliser a la fois du code GPL et du code sous licence SystemC.
> Les licences proprios ont plus de restrictions.
Je connais assez peu de bibliothèques proprio qui m'impose quoi que ce soit sur la licence du code qui utilise cette bibliothèque. Elles ont d'autres restrictions, mais pas celle là.
> Si tu veux des "hook" avec GCC [...] c'est parfaitement réalisable même avec
> un programme sous GPL. [...] tu peux parfaitement faire un front-end à GDB [...]
Ce n'est pas parce que deux outils ont le même nom (front-end) qu'ils ont quoi que ce soit en commun. Un front-end de compilateur n'a pas plus en commun avec un front-end a gdb qu'avec un fer a repasser.
> As-tu fais une recherche dans les mailing gcc pour vérifier si ton problème a été discuté ?
En parlant de ML de gcc, je peux pas résister, c'est un collector :
http://gcc.gnu.org/ml/gcc/2003-06/msg01125.html(...) The GCC design does not make it easy to use parts of gcc in other
programs. So there is no easy way to connect the GCC parser to some
other program. This is partly because of FSF policy. In an attempt to
prevent people from linking non-GPL code into gcc, some of the
interfaces are deliberately obscure. Thus it is usually easier to build
features into gcc.
Sinon, je n'ai pas un, mais deux problèmes. Le fait que je ne puisse pas distribuer tout ça sous forme précompilée. C'est peut-être négociable avec la FSF mais j'ai pas que ça a faire en ce moment (quelques mails envoyés a la FSF et la FSF europe, tous restés sans réponse). Sinon, pour le fait que des utilisateurs préfèreront un outil propriétaire au mien a cause de sa licence, franchement, j'ai pas d'espoir que la FSF change d'avis sur sa position GPL Vs LGPL.
> > Par contre, des produits propriétaires qui utilisent EDG, y'en a à la pelle.
>
> C'est très bien pour ceux qui aiment le proprio.
Bon, prends une boite qui veut utiliser un équivalent de NC-SystemC, de cadence, par exemple (pour donner un exemple que je connais un tout petit peu). Tu proposes quoi en libre ? Tu propose quoi a la boite qui veut quand même utiliser un équivalent ?
> Si EDG était sous GPL, il aurait le mêmes "problèmes" que GCC ?
Si EDG était GPL, la boite qui l'édite ne l'aurait jamais vendu et aurait mis la clé sous la porte.
> Si GCC était proprio, en quoi ça aiderait le libre ?
Si GCC était LGPL, ça éviterait de soutenir EDG qui fait du proprio.
Et accessoirement, ça me permettrait de distribuer une version précompilée de mon front-end SystemC qui est 100% libre, mais pas distribuable sous forme binaire a cause des restrictions de la GPL par rapport aux autres licenses. Mais bon, ça, c'est une autre histoire. Ca me permettrait aussi de laisser des boites construire leur produit sur mon outil libre, alors que là, on va se faire bouffer par le premier produit commercial et propriétaire concurrent.
> La version "stable" doit être exempt de TOUT bug
Non. Chez Debian, "stable" veut avant dire "qui ne change pas". A sa sortie, une Debian stable contient un bon nombre de bugs connus. (d'ou la notion de bugs "release critical")
Ben l'utilisateur du produit proprio avec des bouts de code LGPL, il est plus libre que l'utilisateur du produit proprio sans bouts de code LGPL.
Tu veux faire un produit qui manipule du C++ par exemple, et tu n'as pas trouvé de business model en faisant un truc 100% libre. Ben regardes ce qu'il y a dans la nature qui parse du C++. En gros, tu as EDG, GCC et doxygen. GCC et doxygen sont GPL. A ma connaissance, à l'heure ou je parle, aucune entreprise n'a réussi a vendre un produit basé sur le front-end C++ de GCC ou de doxygen. Par contre, des produits propriétaires qui utilisent EDG, y'en a à la pelle.
Sur cet exemple, a qui profite le copyleft fort de GCC et doxygen ? Ça profite à l'éditeur de EDG, bon vieux produit propriétaire des familles. L'utilisateur, il aurait peut-être bien aimé avoir un composant libre à la place.
L'entreprise n'a pas forcément le choix. Si tu as un tout petit module dans un coin de ton projet qui n'est pas a toi et qui n'est pas sous GPL, tu n'as pas le droit d'utiliser de code GPL.
En même temps, a un peu plus long terme, si ils contribuent au développement des outils Gnome & Kde, on aura peut-être plus d'outils de conf' communs a toutes les distribs. A mon avis, ce n'est pas un mal.
La sortie de Pinapa, c'est une structure abstraite. En gros, c'est l'arbre abstrait de GCC, décoré avec des infos sur l'architecutre de la plateforme que tu modélise. Bon, si tu n'a jamais fait de compil et/ou jamais fait de SystemC, ça ne va pas t'intéresser beaucoup. Je me suis permis de mettre ça en première page parce que c'est suffisament rare d'avoir des outils open source dans le monde du hardware que ça mérite d'être signalé (pas seulement Pinapa, mais aussi ses futurs copains de greensocs).
Ce que j'en tire moi, c'est une connection a des outils de preuve formelle (LusSy, qui lui n'est pas open-source). On prévoit de faire un outil de lint si on trouve la main d'oeuvre pour le faire.
De ce point de vue là, oui, ça pourrait être intéressant d'avoir un front-end qui puisse parser du SystemC, du VHDL, du Verilog, et qui crache une représentation commune à la sortie. D'ailleurs, Synopsys a un truc comme ça (sauf qu'ils ont bazardé a peu près toutes leurs activités autour de SystemC :-\ ).
Par contre, c'est un boulot énorme, et ce n'est clairement pas moi qui le ferait.
Pour ce qui est de cosimuler du RTL avec du SystemC, pas besoin de Pinapa. Pinapa n'est que le front-end, il ne génère pas de code (Le générateur de code, c'est GCC, sans Pinapa). Je ne connais pas trop GHDL, je suppose qu'il y a une interface avec le C au moins. A partir de la, on doit pouvoir faire une interface VHDL/SystemC, et obtenir un truc qui ressemble a NC-SystemC de Cadence. Bref, y'a des choses intéressantes, mais pas vraiment en relation avec Pinapa.
Pas du tout en ce qui me concerne, et l'intérêt serait limité.
ghdl permet de compiler du VHDL avec GCC pour faire de la simulation. Vu que SystemC est une bibliothèque pour C++, il n'y a pas besoin de ça pour faire de la simu. g++ -I/path/to/systemc/include -L/path/to/systemc/lib -lsystemc le fait d'office.
Par ailleurs, Pinapa me sert a faire de l'analyse statique de modèles transactionels (donc d'un niveau d'abstraction plus élevé que le VHDL). On ne traite pas la même catégorie de programmes.
> vu que t'ecris qu'un octet ca sera la meme chose sur toute les archi,
Ben justement non. Tu écrit un octet sur 4, la question, c'est si tu écris sur les bits de poids fort ou sur les bits de poids faibles, et ça, ça dépends de l'endianness de ta machine. Exemple:
$ cat endian.c
#include <stdio.h>
int main() {
int x = 0x01020304;
int * px = &x;
printf("%x\n", *px);
*(char *)px = 'a';
printf("%x\n", *px);
}
$ uname -a
SunOS asti 5.9 Generic_117171-09 sun4u sparc SUNW,Sun-Fire-V240
$ /usr/local/soft/gcc/3.0.2/bin/gcc endian.c
$ ./a.out
1020304
61020304
$ uname -a
Linux ecrins 2.4.27-2-k7-smp #1 SMP Thu Jan 20 11:33:07 JST 2005 i686 GNU/Linux
$ /usr/local/soft/gcc/3.0.2/bin/gcc endian.c
$ ./a.out
1020304
1020361
> D'ailleur si cela avait avoir avec la portabilite ca ferait longtemps que ca serait corrige
> dans certaines distributions multi-archi.
En C ANSI, tu peux très bien faire du code endian-dependant (il suffit d'avoir droit aux cast de pointeurs). Le C *peut* être portable, si on ne fait pas de conneries avec, mais c'est pas la philosophie du language de t'empêcher d'en faire.
> Bref Fedora continue d'etre une grosse experimentation a ciel ouvert.
C'est un objectif affiché de Fedora.
http://fedora.redhat.com/about/objectives.html(...) Be on the leading edge of open source technology, by adopting and helping develop new features and version upgrades. [...] Promote rapid adoption of new releases [...] Form the basis of Red Hat's commercially supported operating system products.
Que je traduirais grosso modo par "On se jette sur toutes les nouveautés, on fait ce qu'on peut pour que ça ne nous pète pas a la gueule, mais si ça casse, c'est toujours mieux que si ça cassait dans RHEL". (ce qui est assez logique vu que c'est principalement RedHat qui paye les développeurs ...)
> Pas de quoi attirer les foules a mon sens.
Tu en bénéficie pourtant probablement indirectement, même si tu n'utilises pas Fedora. Maintenant, si tu cherches des solutions éprouvées et longuement testées, Fedora n'est pas faite pour toi (< troll > prends une Debian stable plutôt </ troll >).
[^] # Re: vulgérisation sur les licences "libres"
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 2.
Projet TITI : Licence proprio sans les sources.
Si les auteurs de TITI sont d'accord, c'est tout a fait possible. MySQL AB peut très bien décider d'arrêter la version GPL et de ne distribuer que la version commerciale (mais il y aura un fork libre dans les 10 min). C'est plus ou moins ce qui est arrivé à PHP-Nuke, il me semble (mais vu qu'a peu près tout le monde avait l'air d'accord pour dire que c'était une bouse, je crois pas qu'il y ai eu de fork ;-) ).
La BSD, tout comme la GPL, te garantissent que si tu as eu accès aux sources et que tu en a gardé une copie, alors le logiciel restera libre pour toi. (et tu auras le droit de redistribuer, de forker, ...).
La GPL apporte plusieurs garanties en plus, en particulier, le fait que même si tu n'as que le binaire, tu pourras avoir accès aux sources si tu le souhaite. Elle rends aussi beaucoup plus difficile le scénario "Temps 3", vu qu'il faut l'accord de tous les détenteurs de copyright, et il peut y en avoir beaucoup (cf. le gars qui voulait acheter un Linux sous licence BSD y'a quelques temps).
[^] # Re: C'est fou ça...
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Le tribunal de Munich confirme de nouveau la validité de la GPL. Évalué à 3.
[^] # Re: support amélioré ???
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Télédéclaration française des revenus et logiciels libres. Évalué à 1.
[^] # Re: noexec ?
Posté par Matthieu Moy (site web personnel) . En réponse au message impossible d'executer un script dans le /home. Évalué à 2.
[^] # Re: FUSE
Posté par Matthieu Moy (site web personnel) . En réponse au journal Traducteurs : LeHurd vs Linux !. Évalué à 1.
"Passage à l'échelle".
[^] # Re: Une seule licence _vraiment_ libre : la GPL !
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 1.
Des licences libres qui t'imposent quoi que ce soit sur le code lié statiquement ou dynamiquement a un programme, je n'en connais pas des masses.
Pour tous les cas d'incompatibilité avec la GPL que je connaisse, si tu fait un travail dérivé contenant du code sous licence X (GPL incompatible) et du code GPL, tu violes la GPL, mais pas l'autre licence.
[^] # Re: Une seule licence _vraiment_ libre : la GPL !
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 1.
Non. Ce que j'affirme, c'est que pour qu'une licence soit compatible GPL, il faut que cette licence te permette de redistribuer sous GPL. Va regarder dans la FAQ de la GPL si tu n'est pas convaincu. Allez, je cite :
http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean(...)
The GPL permits such a combination provided it is released under the GNU GPL.
Je maintiens, si tu renommes la GPL, et que tu l'appelle la licence toto, alors la licence toto ne t'autorise pas a distribuer le code sous la licence GNU GPL, donc, la licence toto n'est pas compatible GPL.
Tu regardes la LGPL par exemple. Ce qui fait qu'elle est compatible GPL, c'est cette petite phrase:
3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library.
(et au passage, la LGPL n'est donc pas compatible avec notre licence toto ci-dessus non plus)
> Tu demande à la GPL un truc que tu ne demandes pas à la licence SystemC
La licence de SystemC me perment de lier mon code à SystemC, quelle que soit la licence du code en question. J'en ai rien a fouttre que dans mon projet, SystemC soit sous une licence X ou Y. Ce que je veux, c'est pouvoir choisir la licence de mon code, et pouvoir utilser SystemC et GCC.
Si tu tiens a lire la licence de SystemC, c'est là, mais ça n'a rien de passionnant.
http://www-verimag.imag.fr/~moy/vrac/License.pdf(...)
[^] # Re: Sun : Décisions contradictoires ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 3.
T'es vraiment bouché sur ce coup. Le logiciel non libre est légal. Scoop !
Tu prends un programme sous licence BSD. Tu lui rajoute du code sous licence non libre (évidemment, tu prends pas une licence qui t'interdise la modification, mais, scoop nb 2, il y a des licences non libres qui autorisent les travaux dérivés et la redistribution). Tu obtiens un truc légal, mais non libre.
> Les incompatibilité sont toujours dans les deux sens.
C'est parfaitement faux.
Si je prends du code CDDL et du code GPL, et que je les met ensemble, j'obtient un truc que je n'ai pas le droit de distribuer parce qu'il y a incompatibilité. Si je le distribue, j'enfreint la propriété intellectuelle de l'auteur du code GPL, mais pas celle de l'auteur du code CDDL. En gros, si je fais un Solarinux qui mélange le code de Linux et celui d'OpenSolaris, SUN n'a aucun recours en justice puisque je ne viole pas leur licence. Les auteurs de Linux peuvent porter plainte par contre.
> SUN ne peut pas mettre de code libre dans son jdk.
Qu'est ce qui les en empêche ? Ils ne peuvent pas mettre de code GPL, mais si ils veulent mettre du code sous une license
> C'est le copy(left|right) qui fait qu'un programme est libre.
Du code sans copyright, c'est du domaine public et c'est libre.
Du code sans copyleft, c'est par exemple du code BSD, et c'est libre.
[^] # Re: Une seule licence _vraiment_ libre : la GPL !
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 4.
GPL, paragraphe 2-b) :
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
"This license", c'est la GPL et rien d'autre. Une GPL renommée n'est pas la GPL, et n'est pas compatible GPL.
Ce qui peut rendre une licence compatible GPL, c'est si cette licence t'autorise a distribuer le soft en GPL. La GPL n'autorise pas le changement de licence, une GPL renommée ne l'autoriserait pas non plus.
> Cette incompatibilité vient de la GPL *ET* de la licence de ton code.
Affirmation que j'accepterais si tu me donnes le paragraphe de la license SystemC (qui par ailleurs n'est pas mon code, mais du code que je réutilise) qui le rends incompatible avec la GPL. Pour le paragraphe de la GPL qui fout la merde, tu peux regarder 10 lignes plus haut.
[^] # Re: Sun : Décisions contradictoires ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 2.
C'est parfaitement légal, mais le résultat n'est pas libre. Sauf si le projet libre t'interdit de mettre du code SunCommunity, mais là, je crois que tu confonds copyleft et libre.
[^] # Re: Une seule licence _vraiment_ libre : la GPL !
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 2.
La FSF, c'est le détenteur du copyright de GCC. C'est la FSF qui m'interdit, via la licence de GCC, de distribuer mon soft précompilé.
> Si ton programme est libre, je ne vois pas en quoi la GPL te pose problème.
Ben cherche.
Ce que c'est qu'une licence compatible/incompatible GPL.
http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean(...)
Une liste de licences libres mais GPL incompatibles.
http://www.gnu.org/philosophy/license-list.html#GPLIncompatibleLice(...)
Si tu veux une licence libre incompatible GPL, je peux t'en fabriquer une quand tu veux : Tu prends la GPL, tu change son nom, et uniquement son nom, et tu as une licence GPL incompatible.
La licence de systemc n'y est pas listée, mais elle en fait partie. J'utilise SystemC dans mon programme.
> Alors là, je comprend encore moins. Il y a même des patchs pour gcc. Peux-tu patcher EDG ?
Je n'en aurais pas eu besoin. Au pire, ils fournissent les sources sous NDA, il y a peut-être moyen de patcher.
Mon propos, c'est simplement que c'est a moi de choisir la licence du code que j'écris. Un truc vraiment libre ne devrait rien m'imposer sur *mon* code quand je l'utilise.
[^] # Re: Une seule licence _vraiment_ libre : la GPL !
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 2.
En effet, y'a pleins de domaines où on peut faire des thunes avec du GPL/LGPL, mais il ne faut pas croire que ça s'applique partout. Dans le cas de EDG, si tu as un business model a leur proposer basé sur du libre, ne te gènes pas, mais mon avis est que c'est illusoire.
> > mais pas distribuable sous forme binaire a cause des restrictions de la GPL par rapport aux autres licenses.
> "Restrictions", tu absuses surtout que tu parles de licences proprio et libre.
Non, je parle de licences libres. L'exemple auquel je faisait allusion est mon parser systemc[1] qui est 100% libre, mais a le malheur d'utiliser a la fois du code GPL et du code sous licence SystemC.
> Les licences proprios ont plus de restrictions.
Je connais assez peu de bibliothèques proprio qui m'impose quoi que ce soit sur la licence du code qui utilise cette bibliothèque. Elles ont d'autres restrictions, mais pas celle là.
> Si tu veux des "hook" avec GCC [...] c'est parfaitement réalisable même avec
> un programme sous GPL. [...] tu peux parfaitement faire un front-end à GDB [...]
Ce n'est pas parce que deux outils ont le même nom (front-end) qu'ils ont quoi que ce soit en commun. Un front-end de compilateur n'a pas plus en commun avec un front-end a gdb qu'avec un fer a repasser.
> As-tu fais une recherche dans les mailing gcc pour vérifier si ton problème a été discuté ?
En parlant de ML de gcc, je peux pas résister, c'est un collector :
http://gcc.gnu.org/ml/gcc/2003-06/msg01125.html(...)
The GCC design does not make it easy to use parts of gcc in other
programs. So there is no easy way to connect the GCC parser to some
other program. This is partly because of FSF policy. In an attempt to
prevent people from linking non-GPL code into gcc, some of the
interfaces are deliberately obscure. Thus it is usually easier to build
features into gcc.
Sinon, je n'ai pas un, mais deux problèmes. Le fait que je ne puisse pas distribuer tout ça sous forme précompilée. C'est peut-être négociable avec la FSF mais j'ai pas que ça a faire en ce moment (quelques mails envoyés a la FSF et la FSF europe, tous restés sans réponse). Sinon, pour le fait que des utilisateurs préfèreront un outil propriétaire au mien a cause de sa licence, franchement, j'ai pas d'espoir que la FSF change d'avis sur sa position GPL Vs LGPL.
[1]: http://greensocs.sourceforge.net/pinapa/(...)
[^] # Re: Une seule licence _vraiment_ libre : la GPL !
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 2.
>
> C'est très bien pour ceux qui aiment le proprio.
Bon, prends une boite qui veut utiliser un équivalent de NC-SystemC, de cadence, par exemple (pour donner un exemple que je connais un tout petit peu). Tu proposes quoi en libre ? Tu propose quoi a la boite qui veut quand même utiliser un équivalent ?
> Si EDG était sous GPL, il aurait le mêmes "problèmes" que GCC ?
Si EDG était GPL, la boite qui l'édite ne l'aurait jamais vendu et aurait mis la clé sous la porte.
> Si GCC était proprio, en quoi ça aiderait le libre ?
Si GCC était LGPL, ça éviterait de soutenir EDG qui fait du proprio.
Et accessoirement, ça me permettrait de distribuer une version précompilée de mon front-end SystemC qui est 100% libre, mais pas distribuable sous forme binaire a cause des restrictions de la GPL par rapport aux autres licenses. Mais bon, ça, c'est une autre histoire. Ca me permettrait aussi de laisser des boites construire leur produit sur mon outil libre, alors que là, on va se faire bouffer par le premier produit commercial et propriétaire concurrent.
[^] # Re: Plutôt une aubaine, mais est-ce le bon débat ?
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 3.
Non. Chez Debian, "stable" veut avant dire "qui ne change pas". A sa sortie, une Debian stable contient un bon nombre de bugs connus. (d'ou la notion de bugs "release critical")
[^] # Re: Sun, aucune licenses déclaré libre ??? Emmm....
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à 2.
OpenSolaris n'apporte rien au logiciel GPL. Le libre ne se limite pas a ça.
[^] # Re: Une seule licence _vraiment_ libre : la GPL !
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à -1.
Tu veux faire un produit qui manipule du C++ par exemple, et tu n'as pas trouvé de business model en faisant un truc 100% libre. Ben regardes ce qu'il y a dans la nature qui parse du C++. En gros, tu as EDG, GCC et doxygen. GCC et doxygen sont GPL. A ma connaissance, à l'heure ou je parle, aucune entreprise n'a réussi a vendre un produit basé sur le front-end C++ de GCC ou de doxygen. Par contre, des produits propriétaires qui utilisent EDG, y'en a à la pelle.
Sur cet exemple, a qui profite le copyleft fort de GCC et doxygen ? Ça profite à l'éditeur de EDG, bon vieux produit propriétaire des familles. L'utilisateur, il aurait peut-être bien aimé avoir un composant libre à la place.
[^] # Re: Pfff
Posté par Matthieu Moy (site web personnel) . En réponse au journal La terre est plate et Java est plus rapide que C++. Évalué à 3.
Bien relire le message du môsieur ...
[^] # Re: Rien de mal à être contaminé !
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche [débat] Pourquoi Sun rejette la GPL. Évalué à -3.
C'est la liberté, parait-il ...
[^] # Re: kunbuntu, oui!!
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 6.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Matthieu Moy (site web personnel) . En réponse au journal De gcc3 à gcc4 : Un code plus propre ?. Évalué à 2.
L'intérêt du cast ici, c'est de pouvoir accéder à la même valeur de plusieurs façons. Il se trouve que c'est pas portable.
[^] # Re: mmmh pas tout compris.
Posté par Matthieu Moy (site web personnel) . En réponse au journal Pinapa: Un parser SystemC open-source. Évalué à 3.
Ce que j'en tire moi, c'est une connection a des outils de preuve formelle (LusSy, qui lui n'est pas open-source). On prévoit de faire un outil de lint si on trouve la main d'oeuvre pour le faire.
[^] # Re: cool :)
Posté par Matthieu Moy (site web personnel) . En réponse au journal Pinapa: Un parser SystemC open-source. Évalué à 2.
Par contre, c'est un boulot énorme, et ce n'est clairement pas moi qui le ferait.
Pour ce qui est de cosimuler du RTL avec du SystemC, pas besoin de Pinapa. Pinapa n'est que le front-end, il ne génère pas de code (Le générateur de code, c'est GCC, sans Pinapa). Je ne connais pas trop GHDL, je suppose qu'il y a une interface avec le C au moins. A partir de la, on doit pouvoir faire une interface VHDL/SystemC, et obtenir un truc qui ressemble a NC-SystemC de Cadence. Bref, y'a des choses intéressantes, mais pas vraiment en relation avec Pinapa.
[^] # Re: cool :)
Posté par Matthieu Moy (site web personnel) . En réponse au journal Pinapa: Un parser SystemC open-source. Évalué à 2.
ghdl permet de compiler du VHDL avec GCC pour faire de la simulation. Vu que SystemC est une bibliothèque pour C++, il n'y a pas besoin de ça pour faire de la simu. g++ -I/path/to/systemc/include -L/path/to/systemc/lib -lsystemc le fait d'office.
Par ailleurs, Pinapa me sert a faire de l'analyse statique de modèles transactionels (donc d'un niveau d'abstraction plus élevé que le VHDL). On ne traite pas la même catégorie de programmes.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Matthieu Moy (site web personnel) . En réponse au journal De gcc3 à gcc4 : Un code plus propre ?. Évalué à 3.
Ben justement non. Tu écrit un octet sur 4, la question, c'est si tu écris sur les bits de poids fort ou sur les bits de poids faibles, et ça, ça dépends de l'endianness de ta machine. Exemple:
$ cat endian.c
#include <stdio.h>
int main() {
int x = 0x01020304;
int * px = &x;
printf("%x\n", *px);
*(char *)px = 'a';
printf("%x\n", *px);
}
$ uname -a
SunOS asti 5.9 Generic_117171-09 sun4u sparc SUNW,Sun-Fire-V240
$ /usr/local/soft/gcc/3.0.2/bin/gcc endian.c
$ ./a.out
1020304
61020304
$ uname -a
Linux ecrins 2.4.27-2-k7-smp #1 SMP Thu Jan 20 11:33:07 JST 2005 i686 GNU/Linux
$ /usr/local/soft/gcc/3.0.2/bin/gcc endian.c
$ ./a.out
1020304
1020361
> D'ailleur si cela avait avoir avec la portabilite ca ferait longtemps que ca serait corrige
> dans certaines distributions multi-archi.
En C ANSI, tu peux très bien faire du code endian-dependant (il suffit d'avoir droit aux cast de pointeurs). Le C *peut* être portable, si on ne fait pas de conneries avec, mais c'est pas la philosophie du language de t'empêcher d'en faire.
[^] # Re: Toujours plus de stabilite ?
Posté par Matthieu Moy (site web personnel) . En réponse au journal FC4T2 is out (i386, amd64, ppc). Évalué à 8.
C'est un objectif affiché de Fedora.
http://fedora.redhat.com/about/objectives.html(...)
Be on the leading edge of open source technology, by adopting and helping develop new features and version upgrades. [...] Promote rapid adoption of new releases [...] Form the basis of Red Hat's commercially supported operating system products.
Que je traduirais grosso modo par "On se jette sur toutes les nouveautés, on fait ce qu'on peut pour que ça ne nous pète pas a la gueule, mais si ça casse, c'est toujours mieux que si ça cassait dans RHEL". (ce qui est assez logique vu que c'est principalement RedHat qui paye les développeurs ...)
> Pas de quoi attirer les foules a mon sens.
Tu en bénéficie pourtant probablement indirectement, même si tu n'utilises pas Fedora. Maintenant, si tu cherches des solutions éprouvées et longuement testées, Fedora n'est pas faite pour toi (< troll > prends une Debian stable plutôt </ troll >).