Articles précédents : Logiciel
- [65] VIA annonce ouvrir une initiative de développement de pilotes open source
- [25] phpPgAdmin 4.2
- [3] Des nouvelles de Moodle : MoodleMoot et v1.9
- [1] Plomino, construire des applications métiers sous Plone
- [35] AbiWord 2.6.0
- [50] Freenet 0.7-rc1 est disponible
- [115] OpenOffice.org 2.4
- [20] Configurez votre pare-feu Netfilter avec Nuface 2.0
- [62] Inkscape 0.46 est disponible
- [24] freedom 2.10 : conversion de fichiers
Liens connexes
- Tethys SMTP Serveur (1233 hits)
- MailCatch (EN) (165 hits)
- MailCatch (FR) (949 hits)
- Lua (499 hits)
Dépêche modérée par
Dépêche éditée par
Logiciel : Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua
Posté par DarkGod (page perso, ). Modéré le 10 avril 2008.
Au programme, un serveur totalement écrit en Lua, extensible par un mécanisme de greffons, qui gère le format maildir++, les utilisateurs virtuels par SQL, une authentification SMTP simple, un fichier de configuration lisible...
Précision importante, Tethys est bien sûr Open Source en licence GPL3. Le premier exemple d'utilisation grand public de Tethys, le site d'emails temporaires MailCatch.com.
![[en]](../../../images/en.png)
Tethys SMTP Serveur (1233 hits)-
MailCatch (EN) (165 hits)
![[fr]](../../../images/fr.png)
MailCatch (FR) (949 hits)-
Lua (499 hits)
> Lire la dépêche (80 commentaires, moyenne: 2,8).
Pour le moment Tethys tourne donc depuis un an, maintenant sans soucis, en tant que serveur mail principal de l'auteur. Il est aussi à la base du service anti-spam MailCatch.com qui fournit un service de mails temporaires et qui est en quelque sorte la « preuve » de la viabilité du serveur. Étant tout jeune, il a besoin de notoriété pour avancer (notamment des testeurs divers et variés) et d'une floppée de greffons pour faire "mieux que les grands".
Lua rocks !
Oui, commentaire totalement inutile mais j'aime bien lua que je pratique assez régulièrement depuis 3ans.
Et étant donné mon pseudo... :D
Quels sont les avantages par rapport à Exim ?
Les méfaits de Sendmail ne sont plus à démontrer mais qu'en est-il d'une comparaison avec les autres MTA (Postfix, qmail, exim, ...).
Pour exim, et pour le peu d'information qui est donnée dans la dépèche :
Extensible par un mécanisme de greffons:
Il existe un patch pour exim mais pas out-of-the-box (Personnellement, j'en n'ai pas encore ressenti le besoin - j'ai toujours réussi à faire ce que je voulais).
qui gère le format maildir++:
http://www.exim.org/exim-html-current/doc/html/spec_html/ch2(...)
SQL :
http://www.exim.org/exim-html-current/doc/html/spec_html/ch0(...)
une authentification SMTP simple:
http://www.exim.org/exim-html-current/doc/html/spec_html/ch3(...)
un fichier de configuration lisible:
C'est le cas et bien documenté (+livres existants)
Performance
Une idée des performances de ce SMTP face aux autres ?
C'est un point important histoire de ne pas se retrouver à la ramasse si le traffic smtp augmente.
-
[^]Re: Performance
Posté par DarkGod (page perso, ) le 10/04/2008 à 17:20. (lien). Évalué à 2.Ils m'ont troller mon post!!! :<
Sinon pour la question du traffic je dois bien avouer que je n'en sais rien, je n'ai pas pu faire de test ultra poussés pour le moment. C'est d'ailleur une des raison pour lequeles j'ai créé mailcatch, comme ca je vais avoir du traffic et voir comment ca tient :)
Si des gens veulent m'aider en fesant des tests de cahrge, je suis preneur aussi!--
MailCatch.com: Service d'emails temporaires et anonymes-
[^]Re: Performance
Posté par Amaury () le 10/04/2008 à 18:36. (lien). Évalué à 4.le meilleur test de charge serait de passer ton smtp en open relay :-)
-
[^]Re: Performance
Posté par DarkGod (page perso, ) le 10/04/2008 à 19:09. (lien). Évalué à 2.Lol, oui mais non ;)
--
MailCatch.com: Service d'emails temporaires et anonymes
-
-
[+] A propos de la licence GPL
A propos des projets exotiques (par ex, dans des langages exotiques), i.e. pas grand public, je me demande si la licence GPL les sert ou les dessert.
(1) Point positif : l'obligation de devoir contribuer en retour, par ex, si modification, attire des contributions et "soude" encore plus, d'une certaine manière, la communauté => force d'attraction
(2) Point négatif : le risque d'être impacté par la licence GPL éloigne certains utilisateurs et possibles contributeurs => force de répulsion.
Sous un autre angle, je pense que la GPL est attractive pour les passionnés (Linux à ces débuts), genre, presque "groupe commando", ou pour les plans business genre "licence duale" (Asterisk, MySQL...). Mais si la poussée "passion" ou "business" n'est pas assez forte pour atteindre la v1.0 et une certaine taille de communauté/visibilité, je pense qu'il faut préférer plutôt la dissémination, avec une licence genre BSD.
A titre personnel, je n'aime généralement pas la licence GPL, encore moins les licences duales GPL, je préfère la licence LGPL, voire éventuellement jouer encore plus la carte de la dissémination à la BSD. En tout cas, perso, pour un projet comme celui-ci avec un langage exotique comme Lua, j'aurais préféfé une licence BSD...
Quels sont vos avis entre (1) et (2) ?
Merci
-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 10/04/2008 à 11:54. (lien). Évalué à 10.faire un troll anti-gpl sur linuxfr, c'est très fort...
-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 10/04/2008 à 12:01. (lien). Évalué à 4.Un troll anti-GPL ?
J'argumente (point positif, point négatif).
Je donne mon avis, mais j'insiste en disant bien qu'il n'est que perso.
Comme je n'ai pas d'avis bien tranché sur le sujet, que je suis curieux, et que je ne vois pas la réalité en noir et blanc, je serais ravi, vraiment, d'avoir l'avis d'autres personnes.
Ou tu vois un troll ?
-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 10/04/2008 à 13:18. (lien). Évalué à 10.ça : "le risque d'être impacté par la licence GPL éloigne certains utilisateurs et possibles contributeurs => force de répulsion."
C'est absurde.
Un codeur ne cherche pas des codeurs à tout prix. Si des codeurs arrivent et ne veulent pas de la GPL, c'est qu'ils ne veulent pas partager de code. Donc, il n'y a aucun intérêt de travailler avec eux.-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 10/04/2008 à 13:29. (lien). Évalué à 0.J'ai résumé mon propos pour ne pas m'étaler sur la licence GPL. Disons qu'au boulot, s'il y a à choisir entre plusieurs projets open source, s'il y a un en GPL et l'autre, non, à qualité à peu près égale, on ne choisit pas le projet GPL (je résume, hein). C'est peut être bête, mais ce sont les directives et on n'a pas forcément le temps de se pencher en détail sur la GPL, alors on fait comme ca. Par contre, on peut utiliser un projet LGPL ou BSD et avoir envie de contribuer (seulement) les parties de code que l'on veut.
En résumé, cela donne bien : "le risque d'être impacté par la licence GPL éloigne certains utilisateurs et possibles contributeurs => force de répulsion."
-
[^]Re: A propos de la licence GPL
Posté par FabienC () le 10/04/2008 à 13:44. (lien). Évalué à 2.Je ne comprends pas : tu veux pouvoir contribuer (seulement) les parties de code que l'on veut
qu'est ce qui te force à contribuer sur les parties de code que tu ne veux pas avec la GPL ?-
[^]Re: A propos de la licence GPL
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 10/04/2008 à 13:47. (lien). Évalué à 9.Le fait qu'ils n'ont rien compris à la GPL.
-
-
[^]Re: A propos de la licence GPL
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 10/04/2008 à 13:54. (lien). Évalué à 5.La licence GPL impose de distribuer les modifications apportées à un logiciel originellement distribué sous GPL si et seulement si tu le distribues à un tiers.
En quoi impose-t-elle de contribuer au projet original ? L'auteur original sera libre de reprendre ou non tes modifications si elles ont été publiées.
Ce qui limite l'entrée des logiciels placés sous GPL, c'est plutôt la mauvaise image de licence « virale » voire « communiste » qui fait peur sans raisons.
Si la véritable raison est plutôt « on n'a pas envie de fournir les sources des logiciels qu'on distribue mais on a envie de tirer partie des logiciels libres pour faciliter notre développement », dans ce cas, ce serait déjà plus honnête que d'attaquer frontalement la GPL. Les développeurs qui choississent la GPL en connaissance de cause le font justement pour éviter cela. Certains, comme ceux du projet Wine, l'ont fait après avoir vu ce que ça donnait.-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 10/04/2008 à 14:05. (lien). Évalué à 2.Diverses raisons que je rencontre ici ou là sont bien : « on n'a pas envie de fournir les sources des logiciels qu'on distribue mais on a envie de tirer partie des logiciels libres pour faciliter notre développement ».
Ceci étant, conformément à mon post initial, je ne cherche nullement à attaquer la GPL !
Je suis PRO-logiciel libre, je m'interrogeais "à voix haute" sur la meilleure manière "d'assurer la diffusion" d'un logiciel libre. En *caricaturant* : choc frontal (GPL) ou diffusion rampante (BSD) ? Les deux, je crois.
Merci pour l'exemple Wine.-
[^]Re: A propos de la licence GPL
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 10/04/2008 à 14:12. (lien). Évalué à 3.Si c'est la politique de ton entreprise, ils n'ont qu'à l'assumer.
Quand je vois des groupes qui se restreignent à l'emploi de certains équipement ou logiciels uniquement pour des raisons d'actionnariats ou de partenariats, c'est du même acabit : l'aspect technique passe en second plan.
-
[^]Re: A propos de la licence GPL
Posté par Plop () le 12/04/2008 à 23:05. (lien). Évalué à 3.on n'a pas envie de fournir les sources des logiciels qu'on distribue mais on a envie de tirer partie des logiciels libres pour faciliter notre développement
Le fameux syndrome du "tout pour ma gueule" ou encore "vas-y file moi ton code, c'est pour faire du pognon sur ton dos".
Heureusement qu'il y a des gens qui ont une vision plus large que cette simpliste version d'égoïsme.
La GPL existe uniquement pour montrer aux gens qui cherchent juste du code source à intégrer qu'on attend un retour. Pas financier comme dans le monde proprio mais un partage de connaissances. Et tant pis si ça défrise tes capitalistes fainéants de patrons.
Si le monde était parfait, tout le monde coderait en BSD et distribueraient les modifications, et un communisme humaniste régnerait sur la terre pour le bonheur de tous. Mais le monde n'est pas parfait. Il y a donc la GPL.--
http://linuxfr.org/board <-- des moules, du sang, de la violence-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 13/04/2008 à 11:35. (lien). Évalué à 1."La GPL existe uniquement pour montrer aux gens qui cherchent juste du code source à intégrer qu'on attend un retour. "
=> oui, mais note que ce retour des choses, ce juste retour des choses, il est aussi possible de l'obtenir avec la LGPL...
Je ne cherche pas ici à aller contre la GPL, car c'est une licence tout à fait honorable, qui a son utilité.
Cette histoire est compliquée :
- les développeurs ont peur que l'on utilise leur soft sur leur dos, i.e. sans un juste retour des choses,
- les "patrons" ont peur, pour des raisons de licence, de devoir livrer en open source le code qui les fait vivre.
Bref, il y a de la peur des 2 cotés.
Ce que je pense, c'est que la GPL, dans c-e-r-t-a-i-n-s cas, c'est un peu agiter le chiffon rouge qui va conforter les uns, énerver les autres et tout le monde va, en fait, au final, y perdre. Alors qu'il existe d'autres licences, tout aussi honorables, qui vont permettre à tout le monde d'y gagner plus, en mode gagnant-gagnant.
-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 13/04/2008 à 12:40. (lien). Évalué à 5.J'ai l'impression que de ne pas donner de modifs c'est surtout gagnant pour la boite. Si elle refuse de diffuser une partie et pas un autre, c'est bien qu'elle considère que c'est celle avec le plus de valeur. Il n'y a pas de relation gagnant-gagnant.
Si tu regardes les faits. La GPL a construit des écosystèmes complet avec Linux et ses distributions. Les BSD-like ont beaucoup moins de succès : ils ont surtout des projets qui ont marché mais sans que l'écosystème suive derrière.-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 13/04/2008 à 13:04. (lien). Évalué à 1.La EPL (Eclipse Public License) a construit aussi un écosystème complet (~ 15 millions de lignes de code, je n'ai pas les chiffres officiels sous la main). Construire un écosystème complet n'est donc pas une vertu de la GPL.
Je pourrais aussi citer, dans une moindre mesure, la LGPL avec JBoss et JOnAS.
A ce que je sache la EPL et la LGPL impliquent aussi un juste retour des choses du moment que l'on modifie le code correspondant. Et effrayent moins les industriels qui, du coup, participent à l'écosystème. Et des contribs du monde industriel à Eclipse, il y en a eu bcq !
Je ne vois pas le monde en binaire, GPL versus BSD.
Encore une fois, il y a pleins d'autres licences.
Je ne crois pas que le succès d'Eclipse (de par son archi à plugin) aurait eu le même succès avec la GPL.
D'où mon discours depuis le début : à chaque fois, il faut voir quelle est la licence qui convient le mieux.
-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 13/04/2008 à 15:02. (lien). Évalué à 1.La EPL (Eclipse Public License) a construit aussi un écosystème complet (~ 15 millions de lignes de code, je n'ai pas les chiffres officiels sous la main). Construire un écosystème complet n'est donc pas une vertu de la GPL.
Je pourrais aussi citer, dans une moindre mesure, la LGPL avec JBoss et JOnAS.
Tu me site 3 projets qui ont réussi mais qui sont loin d'être au niveau de réussite de la GPL. 15 millions de ligne de code, cela n'est même pas Linux entier. Alors si tu compares à une distribution...
Je ne vois pas le monde en binaire, GPL versus BSD. Encore une fois, il y a pleins d'autres licences.
Sauf que si ce sont des licences libres, et qu'elle revienne soit à une BSD soit à la GPL (la licence SUN par exemple)
Je ne crois pas que le succès d'Eclipse (de par son archi à plugin) aurait eu le même succès avec la GPL.
D'où mon discours depuis le début : à chaque fois, il faut voir quelle est la licence qui convient le mieux.
Disons que Eclipse comblait un manque. Souvent les plugin ne sont pas libre non plus, donc je ne prends pas ça pour un succès du libre.-
[^]Re: A propos de la licence GPL
Posté par Thibault (Jabber id, page perso, ) le 14/04/2008 à 19:36. (lien). Évalué à 2.Juste une remarque, en réalité le nombre de ligne de code dans le noyau Linux est largement inferieur à 15 millions, si je me souviens bien le noyau 2.2 c'est de l'ordre de 1 million et le 2.6.0 environ 6 millions.
-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 14/04/2008 à 21:00. (lien). Évalué à 1.J'ai été un peu optimiste sloccount donne 4.6 millions de ligne pour le linux-2.6.22 et wc 7.2 millions de ligne.
Mais cela m'étonnerait beaucoup que Eclipse est 15 millions de ligne de code.-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 14/04/2008 à 23:31. (lien). Évalué à 2.Il y a environ 3 ans, rien que l'IDE Eclipse possédait environ 6 millions de lignes de code. En tout, l'écosystème Eclipse tournait autour de 10 millions de lignes de code. Je cite de mémoire les chiffres de Mike Milinkovich.
Vu l'évolution d'Eclipse, les donations importantes de code réalisées depuis, je ne dois pas être loin du compte en estimant le nombre de lignes de code à 15 millions, vu le spectre couvert par tous les projets : http://www.eclipse.org/projects/listofprojects.php
Pour donner un ordre d'idée, la livraison de code initial d'IBM pour le projet WTP (bien avant la 1.0, alors que l'on doit être pas loin de la 3.0 maintenant) faisait environ 80 Mo (doc inclus). La compilation du code source livré prenait, from scratch, plus de 2 heures sur une bonne machine de build.
Après recherche, j'ai sous-estimé le nombre de lignes de code.
D'après http://www.eclipse.org/org/press-release/20070627_europarelease.php : la release Europa qui inclut 21 des projets Eclipse pesait 17 millions de lignes de code en juin 2007 ; sachant que cette release n'inclut pas tous les projets Eclipse.
-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 15/04/2008 à 09:45. (lien). Évalué à 2.C'est vrai que le temps de compilation est une bonne indication de la taille de code. Comparé un OS avec un IDE, c'est pas très faire play avec l'OS. (un code d'OS est infiniment plus complexe à écrire)
Mais si on prends KDE, il prends aussi des heures à calculer.
Disons aussi que la taille du code n'est pas représentatif du dynamisme d'un projet. Les derniers chiffres pour linux, c'est 1000 contributeurs, 100 sociétés, 3600 lignes de codes ajoutés par jour.
Je veux bien que Eclipse soit un succès mais bon...-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 15/04/2008 à 11:16. (lien). Évalué à 2.C'est vrai que le temps de compilation est une bonne indication de la taille de code. Comparé un OS avec un IDE, c'est pas très faire play avec l'OS. (un code d'OS est infiniment plus complexe à écrire)
Et je trouve que cela n'est pas très fair play de ta part que de prendre un des sujets secondaires que j'ai cité ici à titre indicatif (pour rappel, le sujet principal étant le nombre de lignes de code) pour le mettre au premier plan et me "tirer dessus".
Disons aussi que la taille du code n'est pas représentatif du dynamisme d'un projet. Les derniers chiffres pour linux, c'est 1000 contributeurs, 100 sociétés, 3600 lignes de codes ajoutés par jour.
Juste pour info, on peut trouver les chiffres pour Eclipse (ou plutôt qques chiffres pour Eclipse) dans la présentation EclipseCon suivante : http://www.eclipsecon.org/2008/index.php?page=sub/&id=19(...) - notamment dans le slide 46.
Je veux bien que Eclipse soit un succès mais bon...
;-)
Mouais, j'ai plutôt l'impression que tu commences à troller à ce propos. OK, hier, pour la comparaison de chiffres, maintenant tu me sors cette histoire du nombre de contributeurs et de société, et demain je-ne-sais-quoi. OK, c'est très bien, mais on s'éloigne (pour rien) du sujet initial qui était, quand même, il faut le rappeler, que la GPL est une très bonne licence, très utile, je n'en doute pas, mais qu'elle n'est pas la seule et que d'autres écosystèmes se sont batis et fonctionnent bien autour d'autres licences. Une des preuves : Eclipse.
Sur ce, tchao !-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 15/04/2008 à 13:58. (lien). Évalué à 2.L'origine de mon point de vue était de dire que la GPL a eu plus de succès dans ses réalisations que l'open source type BSD.
C'est toi qui a parlé des lignes de code comme mesures du succès. Linux est en effet 2 à 3 fois plus petit que Eclipse. Mais mon exemple concernait Linux dans son environnement : une distribution Linux.
Ensuite, j'ai rajouté que le nombre de ligne de code n'est pas forcément un bon repère surtout pour un OS où l'on recherche la légerté et un IDE dont le code non utilisé n'a pas d'impact.
D'aprés ta slide 46, Eclispe, c'est une trentaine de boite et 11 millions de lignes de code. Si tu compares cela à tout ce qui veut s'appeler "Gnu", il y a de la marge.
-
-
-
-
[^]Re: A propos de la licence GPL
Posté par ohnoes () le 15/04/2008 à 12:59. (lien). Évalué à 6.Mais cela m'étonnerait beaucoup que Eclipse est 15 millions de ligne de code.
C'est du java, l'une des plus grandes horreurs verbeuses de notre siècle. Le cobol d'aujourd'hui. C'est facile en Java d'écrire des milliers de lignes de code qui en feraient un quart dans un langage un peu plus décent. ilsPoussentMêmeLeViceJusqu'auxNomsDesMéthodes().
-
-
-
-
-
-
-
-
-
-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 10/04/2008 à 13:56. (lien). Évalué à 4.J'ai surtout l'impression que ta boite se fout de prendre le temps de comprendre la GPL et qu'elle doit encore réagir avec les fud d'il y a quelques années sur sa viralité (son coté vaccin pardon :).
C'était un fud trés efficace de certain commerciaux qui expliquait que si on laissait rentrer du code GPL tout le code de la boite devait devenir GPL. C'est parfaitement absurde, mais c'est le propre du FUD.
Comment veux tu que des partisans dela GPL réagissent à tes propos qui ne sont que dû qu'à la méconnaissance du sujet ? Ce n'est pas parce que ta boite est frileuse/réactionnaire/mal informé que cela doit rentrer en ligne de compte pour un projet.
"avoir envie de contribuer (seulement) les parties de code que l'on veut."
J'espère que tu puisse comprendre que c'est parfaitement inacceptable pour nombre de codeurs du libre. Vous utilisez un code que vous n'avez pas codé et vous refuser le seul retour exigé : les améliorations (et encore, cela n'est à fournir qu'à vos clients).
En résumé, cela donne bien : "le risque d'être impacté par la licence GPL éloigne certains utilisateurs et possibles contributeurs => force de répulsion."
Je crois que pas mal de codeurs te répondront "rien à foutre". Ils ont rien à gagner et tout à perdre avec des gens comme ta boite... Réutiliser du code libre, ce n'est pas faire l'aumône à son développeur...-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 10/04/2008 à 14:20. (lien). Évalué à 0.Oui, mais en entreprise, "temps de comprendre la GPL" = "temps" = $$$ ;-) Je fais avec.
Que pas mal de codeurs du libre préfèrent la GPL, c'est très bien. JE NE JUGE PAS. Je les comprends.
Mon post initial était : en tant que développeur PRO-logiciel libre, je m'interrogeais "à voix haute" sur la meilleure manière "d'assurer la diffusion" d'un logiciel libre. En *caricaturant* : choc frontal/pilonnage (GPL) ou diffusion rampante/encerclement (BSD) ? Genre, Linux et Apache+Eclipse. Les deux, je crois, et c'est très bien.
Comme le choix d'une licence, c'est "presque" comme un gout perso, je m'arrêterais là dans mon "petit sondage" relatif au succès-du-logiciel-libre-par-rapport-aux-licences.
Merci.
-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 10/04/2008 à 14:46. (lien). Évalué à 3.Les licences proprio sont infiniment plus longue et complexe que la GPL.
C'est vrai que cela change de lire "vous avez le droit de faire ceux-ci ou cela" alors qu'avec une licence proprio, tout est interdit de base.-
[^]Re: A propos de la licence GPL
Posté par baud123 (Jabber id, page perso, ) le 10/04/2008 à 16:23. (lien). Évalué à 4.C'est clair que les licences proprios requièrent systématiquement d'avoir le juridique dans la boucle au départ ou au grand minimum les acheteurs lors de renouvellements, tellement les conditions imposées sont draconiennes voire illégales... (sans parler des soit-disant serveurs de licences tous plus incompatibles les uns avec les autres et que j'ai rarement vu déployer efficacement).
àmha, il faudrait aussi faire gérer aux acheteurs et au juridique tout ce qui est licence libre : cela permettrait de recenser ce qui est effectivement utilisé (c'est parfois fait tant bien que mal avec tout ce qui est proprio, pourquoi ne pas le faire avec ce qui est libre aussi...), cela ferait sans nul doute grandement apprécier la simplicité des licences du libre en terme d'utilisation et de gestion, par rapport à l'imbroglio sans nom côté proprio.
-
-
-
-
-
-
-
-
[^]Re: A propos de la licence GPL
Posté par Sytoka Modon (page perso, ) le 10/04/2008 à 11:58. (lien). Évalué à 3.Dans un projet comme cela, je choisir la licence du langage. Donc si je fait du Perl, je vais mettre la même chose que Perl, c'est à dire Artistic Licence.
L'intérêt est de pouvoir utiliser tous les modules du langage sans se poser la moindre question.
Je ne sais pas sous quelle licence est le CPAN de LUA.-
[^]Même licence que le langage
Posté par Kerro () le 10/04/2008 à 13:06. (lien). Évalué à 2.Je pense que par "licence du langage" tu veux dire "licence du logiciel utilisé pour etc etc". Car le C n'a pas de licence, alors que GCC en a une.
Je ne comprends pas pourquoi tu préfères utiliser la même licence que le langage. Quel est ton raisonnement ou ton ressenti ?
Si un projet est codé en Perl ET en C. Je prends quoi comme licence ?
Celle de Perl, celle de GCC ?--
Qui a existé en premier: le compilateur ou son code source ?-
[^]Re: Même licence que le langage
Posté par Nicolas Boulay () le 10/04/2008 à 13:20. (lien). Évalué à 2.Perl est distribué dans une licence ainsi que tous les packages du CPAN. Si tout le monde utilise la même, la réutilisation est beaucoup plus simple.
gcc utilise la lgpl pour la libc qui se lie donc avec n'importe quoi.
-
-
-
[+] [^]Re: A propos de la licence GPL
Posté par Michel Galle () le 10/04/2008 à 12:00. (lien). Évalué à -6.je vais vous le dire avec politesse :
on en à rien à fiche d'un énième débat sur la GPL.
lisez les archives et cessez de polluer.
-
à titre personnel votre avis personnel est une nuisance
-
la GPL a maintes fois prouvés sa viabiltié commerciale, que cela soit pour IBM , SUN, NOKIA, APPLE ou MYSQL AB
un point c'est tout !
et mon avis, personnel, subjectif etc: c'est que je me contrefice des projets sous licences bsd tel freebsd, openbsd. le seul projet BSD professionnel et utile industriellement est openssh.
pour le reste, lachez nous, et retournez vous passionner sur les licences MIT, X11, APL, APL2, GPL3, BSD, EULA propriétaires, CPL, MSPL, etc.
MERCI !
(non, pas du tout énervé, juste fa-ti-gué et las-sé de ce genre de contributeurs)-
[^]Re: A propos de la licence GPL
Posté par TeXitoi (Jabber id, page perso, ) le 10/04/2008 à 14:44. (lien). Évalué à 4.Ferme ta session X, elle est pas GPL :P
-
[^]Re: A propos de la licence GPL
Posté par Arkem (page perso, ) le 12/04/2008 à 08:31. (lien). Évalué à 3.C'est pourtant la meilleur manière de lutter contre le FUD: au lieu d'envoyer ch... les gens, qui non seulement ne seront pas mieux renseignés mais en plus repartiront avec la désagréable impression que les pros-GPL sont des c..., ce qui ne fait que renforcer le FUD, on prend la peine de leur expliquer ou de leur passer un bon lien.
Et quand on est fatigué... on zappe et on passe au troll suivant ;)
--
Il vaut mieux mobiliser son intelligence sur des conneries que sa connerie sur des choses intelligentes (proverbe shadock)
-
-
[^]Re: A propos de la licence GPL
Posté par Gof (Jabber id, page perso, ) le 10/04/2008 à 12:59. (lien). Évalué à 6.> l'obligation de devoir contribuer en retour
La GPL n'oblige pas strictement de contribuer en retour. Des utilisateurs peuvent très bien ne pas publier les modifs qu'ils ont fait sur leur serveur qu'ils ont en production et qui serait super plus efficasse que le serveur officiel.
> Point négatif : le risque d'être impacté par la licence GPL éloigne certains
> utilisateurs et possibles contributeurs
La BSD attirerait peut être plus les développeurs qui voudrais forker le serveur pour en faire un truc proprio amélioré et le distribuer(vendre?). Mais est-ce ce que les développeurs originaux veulent ?--
:-D !!!NOUVEAU!!!-
[^]Re: A propos de la licence GPL
Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 10/04/2008 à 13:19. (lien). Évalué à 1.De plus, des modifs apportée sur un projet BSD "propriarisé" ne seront pas re-fournies aux développeurs d'origine, donc ça se mords la queue par rapport à ton point (2). D'où la détection de troll :-)
Néanmoins sur un plan business, on peut compter sur l'intégration du projet dans un packaging plus vaste/intéressant/facile/etc... c'est à la mode ce genre de business pour proposer aux PME de se passer du cauchemar Exchange !
D'où un choix GPL ma foi intéressant pour à peu près tous AMHA (le LGPL serait peut-être plus judicieux pour répondre à tous tes arguments).
mes 2 cents...
-
[^]Re: A propos de la licence GPL
Posté par Julien () le 10/04/2008 à 13:29. (lien). Évalué à 1.La GPL n'oblige pas strictement de contribuer en retour. Des utilisateurs peuvent très bien ne pas publier les modifs qu'ils ont fait sur leur serveur qu'ils ont en production et qui serait super plus efficasse que le serveur officiel.
A priori, c'est le cas en GPLv2 et c'est une des grosses différences de la GPLv3.
-
[^]Re: A propos de la licence GPL
Posté par Philippe Fremy (page perso, ) le 11/04/2008 à 10:52. (lien). Évalué à 8.La menace de non-contribution en retour est brandie en permanence dès qu'on parle de BSD. D'une part, ce risque existe aussi avec les autres licences libres. D'autre part, parce que ce risque existe ne veut pas dire qu'il est réalisé. Il y a des projets BSD qui reçoivent des retours sous forme de patch, de la part d'entreprises qui les utilisent.
Je partage l'avis de l'auteur du fil de discussion. Quand je vois des projets simplistes de bibliothèques, qui choisissent la GPL, je trouve ça plutôt ridicule.
Par exemple readline ( http://tiswww.case.edu/php/chet/readline/rltop.html ). On ne peut pas utiliser la bibliothèque fournissant readline si ne fait pas un programme sous GPL. C'est un choix de l'auteur que je peux comprendre, mais je trouve que c'est plus une perte pour le logiciel libre et les logiciels commerciaux qu'autre chose. Je m'explique :
- readline est trop petit pour déclencher un changement de licence d'un projet qui voudrait l'utiliser. Si un projet non GPL envisage d'utiliser readline, je doute qu'il décide de devenir GPL juste pour ça, readline n'est pas en soi un élément de motivation suffisant. On peut imaginer que pour des lib plus importantes, genre Qt, l'auteur se pose la question du changement de licence mais pour readline, faut arrêter de rigoler.
- du coup, readline est peu utilisé. Il y a pas mal de projets avec une ligne de commande qui auraient pu facilement en tirer partie, qui ne le font pas. Je pense que readline si situe juste à la limite du truc un peu chiant à développer, dont on peut se passer mais qui est très bien à avoir. Si c'est pas facile à utiliser, il y a peu de chances que un auteur se donne la peine de redévelopper readline dans une autre licence. Dans ce sens, je pense que c'est une perte pour le logiciel libre, puisque très peu d'utilisateurs veut dire très peu de retours ou de contribution. C'est aussi de mon point de vue une perte en terme de fonctionnalité puisque pas mal de logiciels libres ou commerciaux auraient pu en bénéficier mais ne le font pas.
Si j'avais été l'auteur de readline, je l'aurai mis en BSD.
En tant qu'auteur de logiciel, j'aime que mes logiciels soient diffusés au maximum, et ça ne me pose pas de problème que certains d'entre eux soient utilisés par des entreprises, qui ne me reversent ni argent, ni contribution à mon logiciel, ni contribution au logiciel libre en général. Ca me suffit de savoir que mon logiciel leur a été utile.-
[+] [^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 11/04/2008 à 11:37. (lien). Évalué à -1.Ah, superbe post ! Excellent.
Merci pour ces propos clairs et nets, et qui font écho à ce que je voulais dire.
L'exemple de "readline est trop petit pour déclencher un changement de licence d'un projet qui voudrait l'utiliser [...] du coup, readline est peu utilisé. Il y a pas mal de projets avec une ligne de commande qui auraient pu facilement en tirer partie, qui ne le font pas [...] Dans ce sens, je pense que c'est une perte pour le logiciel libre, puisque très peu d'utilisateurs veut dire très peu de retours ou de contribution. C'est aussi de mon point de vue une perte en terme de fonctionnalité puisque pas mal de logiciels libres ou commerciaux auraient pu en bénéficier mais ne le font pas."
=> c'est EXACTEMENT ça !
Je vais donner un autre exemple.
Depuis qques semaines, je cherche à créer mon propre projet open source Java sur Swing. J'ai tout d'abord recherché ce qui se faisait sur SourceForge pour éviter de réinventer la roue et éventuellement, me joindre à un projet open source existant.
Bon, je n'ai pas trouvé ce que je souhaitais, mais les projets qui m'intéressaient le plus étaient des projets GPL. Cette licence ne m'intéresse pas, mais là n'est pas le plus important. Le plus important, c'est que les 3 à 4 projets Swing intéressants trouvés sur SourceForge étaient... morts !
IMHO, ils étaient morts en partie à cause de la licence GPL. C'est une licence qui a son utilité, mais mal choisie, i.e. choisie pour un projet qui tient plus de la librairie comme "readline" que d'un projet qui fait sens comme un tout (ex, LimeWire), cette licence a, je crois, participé au fait que ces projets se sont retrouvés dans une impasse (idem "readline").
Et souvent, quand je scrute SourceForge, j'apercois plusieurs petits projets GPL morts, morts en partie à cause du mauvais choix de la licence GPL par rapport au type de projets en question. Et ces logiciels libres qui se retrouvent dans le mur, je trouve cela bien dommage.
C'est ce que je veux dire depuis mon post initial ici.
-
[^]Re: A propos de la licence GPL
Posté par Philippe Fremy (page perso, ) le 11/04/2008 à 14:25. (lien). Évalué à 9.Même si nous sommes d'accord sur le fond, il faudrait pas sauter tout de suite à une conclusion erronée. Que beaucoup de projets libres naissent et meurent, c'est un fait. Que le choix de la licence GPL en soit une des cause, je reste sceptique.
-
-
[^]Re: A propos de la licence GPL
Posté par briaeros007 () le 12/04/2008 à 08:30. (lien). Évalué à 1.Quand je vois des projets simplistes de bibliothèques, qui choisissent la GPL, je trouve ça plutôt ridicule.
A le choix des dvp est ridicule parce qu'ils veulent un certain truc, mais pas forcément dominer le monde...
Je note...
(Un raccourci rapide serait "ne pas vouloir dominer le monde est ridicule").
Puis pour une lib, tu peux toujours t'en sortir en linkant en dynamique et en créant une lib proprio avec la même api (que la lib proprio marche ou pas c'est pas grave).
-> on peut pas te dire que ton programme est gpl vu qu'il est fait pour tourner avec ta lib proprio (elle proprio).
Le fait de réutiliser l'API de readline n'est pas interdit par la GPL, ni l'utilisation d'un truc comme LD_PRELOAD ou autre...--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 12/04/2008 à 11:16. (lien). Évalué à 1.Ma foi, les projets *simplistes* de *bibliothèques* qui choisissent la GPL, je ne crois pas malheureusement qu'ils "risquent" de dominer le monde... Pour les raisons exprimées par Philippe plus haut, auxquelles je souscris.
""
Puis pour une lib, tu peux toujours t'en sortir en linkant en dynamique et en créant une lib proprio avec la même api (que la lib proprio marche ou pas c'est pas grave).
-> on peut pas te dire que ton programme est gpl vu qu'il est fait pour tourner avec ta lib proprio (elle proprio).
""
=> je ne crois pas que ce soit compatible avec la GPL (sauf erreur) et moins encore avec l'interprétation des avocats de MySQL par ex...
Mais c'est un domaine sujet à interprétation (outch). Bjorn, le directeur technique de la fondation Eclipse, exprime ses doutes, ses interrogations ici à propos de l'usage de la licence GPL pour MySQL : http://eclipse-projects.blogspot.com/2005/09/commercial-open-source.html - compliquée cette affaire, même pour un directeur technique dans le domaine de l'open source...
-
[^]Re: A propos de la licence GPL
Posté par briaeros007 () le 12/04/2008 à 16:31. (lien). Évalué à 1.=> je ne crois pas que ce soit compatible avec la GPL (sauf erreur) et moins encore avec l'interprétation des avocats de MySQL par ex...
On va prendre un cas simple :
J'ai fait une lib de pthreads en GPL.
Attaque donc tous les programmes proprio qui tourne sous linux en utilisant les pthreads alors ... (linkage dynamique)
Moi je pense pas que tu vas réussir à gagner, mais on sait jamais.
(Next step, je fait une librairie avec l'API de windows en GPL. J'attaque MS lui même \o/).--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 13/04/2008 à 12:43. (lien). Évalué à 2.
Attaque donc tous les programmes proprio qui tourne sous linux en utilisant les pthreads alors ... (linkage dynamique)
On s'en fout ici que le link sois dynamique. Les pthreads implémentent la norme posix. D'ailleurs, tout le monde s'en fout on est passé à NPTL depuis quelques années.
(Next step, je fait une librairie avec l'API de windows en GPL. J'attaque MS lui même \o/).
C'est toi qui réutilise le code là, pas MS....-
[^]Re: A propos de la licence GPL
Posté par briaeros007 () le 14/04/2008 à 09:49. (lien). Évalué à 1.Les pthreads implémentent la norme posix.
Ou ais je dis le contraire ?
A nulle part ... d'ailleur je l'ai même précisé dans mon arguments explicitant ce que je disais (commentaire un peu plus bas):
je me cite :
Donc le gars qui a fait la lib proprio qui a copié l'api de la lib gpl (ou inversement!) ou tout simplement suivi une norme
Donc on est bien d'accord : copier une API (que cela vienne d'une norme ou d'un programme GPL) n'est pas suffisant pour contrevenir à la GPL.
Donc le linkage dynamique d'un soft d'une licence X avec une lib en GPL devrait être autorisé.
Non?
C'est toi qui réutilise le code là, pas MS....
JE NE REUTILISE PAS DE CODE.
Je copie une API. Toute la nuance est là.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 14/04/2008 à 10:00. (lien). Évalué à 2.Donc le linkage dynamique d'un soft d'une licence X avec une lib en GPL devrait être autorisé.
Non?
Non. Le fait que le link est dynamique ne change rien à l'histoire.
Pour que tu puisses choisir ta licence pour une lib liée à de la GPL, il faut démontrer que le soft GPL en question est optionnel.
La technique d'écrire un soft proprio qui copie les API est possible et légal (c'est l'inverse de lesstif pour motif). Par contre, écrire un truc qui marchouille pour dans les faits utiliser uniquement la lib GPL et pouvoir dire: regardez j'ai un bout de machin pas GPL avec la même api. Cela s'appelle prendre le juge pour un con. Ils n'aiment pas en général...-
[^]Re: A propos de la licence GPL
Posté par briaeros007 () le 14/04/2008 à 10:09. (lien). Évalué à 0.Pour que tu puisses choisir ta licence pour une lib liée à de la GPL, il faut démontrer que le soft GPL en question est optionnel.
Ben je peut faire une lib proprio avec la même api (même si la lib proprio marche moyen voir pratiquement pas).
Rien n'interdis de diffuser un programme proprio qui plante, non ? (ie tu diffuse le soft avec la lib qui plantouille).
Cela s'appelle prendre le juge pour un con. Ils n'aiment pas en général...
Je ne serais pas aussi catégorique que toi
Rien n'oblige à fournir un programme qui marche à ce que je sache, si ?
Tu peux le faire pour une bonne raison : tu travaille toujours sur ta lib proprio.
a moins que le release early release often soit interdit dans ton pays ?--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
-
-
[^]Re: A propos de la licence GPL
Posté par Troy McClure (page perso, ) le 12/04/2008 à 12:12. (lien). Évalué à 2.Puis pour une lib, tu peux toujours t'en sortir en linkant en dynamique et en créant une lib proprio avec la même api (que la lib proprio marche ou pas c'est pas grave).
Je ne comprends pas comment tu peux suggèrer ce genre de trucs... Encourager les gens à contourner l'esprit de la gpl sur linuxfr c'est quand même un peu bizarre.-
[^]Re: A propos de la licence GPL
Posté par briaeros007 () le 12/04/2008 à 16:27. (lien). Évalué à 1.A mon sens, je n'encourage pas contourner l'esprit de la GPL.
L'esprit de la GPL c'est "tu modifie mon truc, tu l'améliore, tu me reverse les modifs".
Pas "tu fait un truc qui a strictement rien a voir mais tu ose me linker dynamiquement (comme la libc, malloc, des pthreads) alors tu dois tout me redonner".
Perso, je suis même pour considérer que le linkage dynamique ne devrais pas être considérer comme une distribution.
Exemple con :
Deux lib, une gpl, l'autre proprio, avec la même api et abi.
(ex donné plus haut).
Donc le gars qui a fait la lib proprio qui a copié l'api de la lib gpl (ou inversement!) ou tout simplement suivi une norme ... ne respecte rien sous pretexte qu'il a essayé de faire une lib qui pouvait convenir à plusieurs personnes, et qui peut s'interfacer avec des logiciels qui n'ont pas été prévu initialement pour ? (ou qui ont été prévu pour suivre une norme définissant une api précise)
(vive LD_PRELOAD).
Bordel, il viendra a PERSONNE l'idée que sous pretexte il y a une lib pthreads sous GPL que tous les programmes qui utilisent l'api POSIX pthread doivent etre sous GPL ?
Parce que d'après ce que tu me dis, considérer le contraire c'est contourner l'esprit de la GPL...--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 12/04/2008 à 16:40. (lien). Évalué à 3.La GPL ne parle jamais de library ou de link mais de travaux dérivés qui ont une signification légale.
Si tu construits une application qui n'utilise que MySQL, tu dois respecter leur licence. Si tu construits une application qui a besoin d'une base de données relationnelle, tu peux lui mettre la licence que tu veux.-
[^]Re: A propos de la licence GPL
Posté par briaeros007 () le 13/04/2008 à 10:33. (lien). Évalué à 1.la faq de la gpl si par contre.
Linking ABC statically or dynamically with other modules is making a combined work based on ABC. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
Et je suis désolé, mais pour moi ce n'est pas un travail dérivé si linké en dynamique. (car on peut utiliser d'autres lib que celle GPL si l'on souhaite. vive Ld_PRELOAD)
Sinon n'importe quel programme qui utilise pthread devra être sous gpl.
C'est à ça que je répondais.
Si tu construits une application qui n'utilise que MySQL, tu dois respecter leur licence. Si tu construits une application qui a besoin d'une base de données relationnelle, tu peux lui mettre la licence que tu veux.
Et tu te connecte comment à ta bd MySQL si tu as juste besoin d'un SGBDR ? Obligé de faire un fork puis faire un execvp ou un truc comme ça ? Ou tu utilise une de leur API (et tu peux aussi proposer de te connecter à postgresql, oracle, db2, ...) avec une lib de mysql(postgresql, oracle et db2) linké dynamiquement ?
Perso je sais pas trop comment marche les connecteurs aux DB donc si ça se trouve c'est pas du tout comme ça. Mais si il faut linker dynamiquement le connecteur, ben .. ça résoud pas le problème.
Et dire "ouais si ça dépend de mysql c'est pas bon, si ca dépend d'un SGBDR c'est bon" : tu le définis comment que ça dépend ou pas, si dans les deux cas tu as le connecteur qui est linké dynamiquement ? Par l'opération du saint esprit ?
[ps on ne parle pas là de rajouter une table ou modifier du code à mysql, mais bel et bien d'utiliser une api publique et de linker le code en dynamique, comme si j'utilisais pthread ou malloc ou ...)--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 13/04/2008 à 10:56. (lien). Évalué à 2.Même si tu te linkes dynamiquement, tu utilises une API particulière pour dialoguer avec la lib. En cela, même si tu te linkes dynamiquement, tu dépend de cette API => et là, on arrive bien à la notion de produit dérivé.
Cf. mon post plus bas pour cette histoire d'API, mon post qui commence par "Cette histoire de lib est un peu plus compliquée que cela...."
Pour te connecter à MySQL, si tu utilises un connecteur ODBC sous Microsoft ou JDBC en Java, à ce stade, tu n'es pas impacté par la licence GPL, même si le driver (la lib du connecteur) est en GPL. Pourquoi ? Parce que ODBC et JDBC sont des API de Microsoft et de SUN non-GPL et tu t'interfaces en fait avec elles (même si elles sont implémentées "par derrière" par un soft GPL).
Ensuite, il y a d'autes critères à prendre en compte.
Si tu utilises du SQL standard, à mon avis, tu n'es pas impacté par la licence GPL. Car tu ne dépend que du standard SQL, et pas de MySQL.
Si tu utilises des fonctionnalités particulières du SQL de MySQL => tu es par contre impacté par la licence GPL car tu dépend bien de particularités de MySQL propre à MySQL.
C'est comme cela que je c-o-m-p-r-e-n-d-s a-c-t-u-e-l-l-e-m-e-n-t les choses.
-
[^]Re: A propos de la licence GPL
Posté par briaeros007 () le 14/04/2008 à 10:01. (lien). Évalué à 2.tu dépend de cette API => et là, on arrive bien à la notion de produit dérivé.
Cf. mon post plus bas pour cette histoire d'API, mon post qui commence par "Cette histoire de lib est un peu plus compliquée que cela...."
Merci pour tes posts instructifs ;)
Mais quelques chose m'ennui quand même.
tu considère que copier une API non normé est "un produit dérivé" (je n'ai pas les bases juridiques ou autre pour appuyer dans un sens ou dans l'autre).
Si on sort une norme à partir d'une API d'un soft, la licence GPL qui s'appliquait ne s'applique plus ?
Si on sort un produit proprio, qu'on met l'api en publique, et que la GPL la copie. Le soft GPL peut nous attaquer en disant que c'est nous qui avons copié le soft ?
Une API est elle soumise au droit d'auteur aussi ? N'y a t'il pas des cas totalement triviaux dans les API ? (le but d'une API est d'être un minimum simple et cohérente. Il n'est donc pas impossible de se retrouver avec un certain nombre de fonction avec des noms et des paramètres identiques).
Une API ne peut elle pas faire partie du "droit à la citation"/"Fair use" ?
(si je copie un printf("toto\n"); dans un programme GPL, il y a assez peu de chance que l'on considère cela comme une violation manifeste du droit d'auteur).
enfin pour terminer :
Si tu utilises du SQL standard, à mon avis, tu n'es pas impacté par la licence GPL. Car tu ne dépend que du standard SQL, et pas de MySQL.
Si tu utilises des fonctionnalités particulières du SQL de MySQL => tu es par contre impacté par la licence GPL car tu dépend bien de particularités de MySQL propre à MySQL.
Donc si j'utilise un fork pour me connecter à la DB et j'envoie une requete sql spécifique mysql, je serais selon toi soumis à la GPL ?
Perso je pense pas (ie la reqûete est une donnée fournies, pas du code pour moi).--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 14/04/2008 à 12:17. (lien). Évalué à 1.Merci pour tes posts instructifs ;)
My pleasure ;-)
Mais quelques chose m'ennui quand même.
tu considère que copier une API non normé est "un produit dérivé" (je n'ai pas les bases juridiques ou autre pour appuyer dans un sens ou dans l'autre).
Oui, c'est ce que je considère actuellement, tjrs d'après ce que j'ai compris.
Si on sort une norme à partir d'une API d'un soft, la licence GPL qui s'appliquait ne s'applique plus ?
D'après ma réponse plus haut, je considère que la licence GPL continue à s'appliquer. Mais je ne suis pas avocat, hein !
Si on sort un produit proprio, qu'on met l'api en publique, et que la GPL la copie. Le soft GPL peut nous attaquer en disant que c'est nous qui avons copié le soft ?
2 petites précisions :
(a) l'API en question étant devenue publique, déjà, on ne peut pas dire que "la GPL la copie". Le soft sous GPL utilise simplement cette API.
(b) il faut savoir ce que veut dire mettre une API en publique. Si c'est utiliser une licence libre, il faut savoir qu'il existe des licences libres incompatibles : la licence Apache, par ex, est incompatible avec la GPL v2 et pas avec la GPL v3 (cf. http://www.gnu.org/licenses/license-list.fr.html ).
Donc, si un soft GPL utilise l'API publique :
(1) il faut déterminer si ce soft a déjà le droit de le faire, cf. (b)
(2) si (1) est ok, il n'y a pas conflit tant que le soft en question ne clame pas avoir le copyright/copyleft de l'API. Sinon, a priori, il s'agit grosso modo d'un conflit d'antériorité.
// Aparté-début :
D'après ce que j'ai compris, ce qui prime, d'une certaine manière, avant les licences, c'est la notion de copyright. Si tu disposes du copyright de ton logiciel libre, tu peux en changer de licence !
C'est pour moi à la base des licences duales. Si tu disposes du copyright, même pour un soft en GPL, tu as le "pouvoir" de relicencer ton soft sous une autre licence. D'où les licences duales. D'où le fait que IONA, pour un de ces projets open source, demandait aux contributeurs de céder à IONA le copyright : les développeurs externes étaient impactés par la licence open source, tandis que IONA, en interne, non, car ils possédaient du copyright. Enfin, c'est comme cela que je l'ai compris.
J'aimerais bien avoir l'avis, un de ces jours, d'un avocat là-dessus, sur le rapport copyright/licence. Histoire de vérifier ce que j'ai fini par comprendre...
// Aparté-fin.
Une API est elle soumise au droit d'auteur aussi ? N'y a t'il pas des cas totalement triviaux dans les API ? (le but d'une API est d'être un minimum simple et cohérente. Il n'est donc pas impossible de se retrouver avec un certain nombre de fonction avec des noms et des paramètres identiques).
Une API ne peut elle pas faire partie du "droit à la citation"/"Fair use" ?
(si je copie un printf("toto\n"); dans un programme GPL, il y a assez peu de chance que l'on considère cela comme une violation manifeste du droit d'auteur).
Bonnes questions. Je ne sais pas comment cela se passe pour les cas totalement triviaux !
Donc si j'utilise un fork pour me connecter à la DB et j'envoie une requete sql spécifique mysql, je serais selon toi soumis à la GPL ?
Perso je pense pas (ie la reqûete est une donnée fournies, pas du code pour moi).
Cette histoire de base de données GPL me casse encore plus la tête que pour les autres cas.
J'ai quand même un peu l'impression que MySQL joue aussi de son coté du FUD. Et qu'il y a au fond du FUD des 2 cotés...
Disons que si je n'utilise que du SQL standard, je suis certain de ne pas être impacté par la GPL.
Maintenant, si j'utilise une fonctionnalité spéciale de MySQL, j'ai dit précédemment que j'imaginais être impacté par la GPL, mais je n'en suis plus (si) sûr.
Ton post m'a fait réfléchir. J'ai relu le post de Bjorn, directeur technique de la fondation Eclipse : http://eclipse-projects.blogspot.com/2005/09/commercial-open(...)
Lui aussi s'emmelle les pinceaux ! Il clame bien qu'il n'est pas avocat.
Le seul commentateur du post de Bjorn indique que l'utilisation d'une base relationnelle GPL n'induit pas une "contamination" GPL car ce n'est pas créer un produit dérivé, mais utiliser un outil pour ce qu'il est. Par contre, en utilisant une base objet, oui, on est contaminé par la GPL.
Mais comme le dit ce commentateur, à l'instar de Bjorn : "And, of course, I'm not a layer too. Use at your own risk"
Maintenant, les avocats de MySQL pourraient éventuellement répliquer sur la définition d'une base relationnelle. Au sens large, MySQL est une base relationnelle. Au sens sans doute le plus restrictif, c'est sans doute un soft qui accepte telle ou telle norme SQL, et donc, sous cet angle, les extensions MySQL ne sont pas relationnelles, et sont bien spécifiques GPL. Sous cet angle encore, si tu fais un fork et envoie une requete sql spécifique mysql, comme je considère perso qu'une requête, c'est aussi du code, je dirais que oui, tu es impacté par la GPL.
Encore une fois, je ne suis pas avocat.
Nicolas écrivait plus haut : "Les licences proprio sont infiniment plus longue et complexe que la GPL." Mais vu qu'il ajoutait ensuite "qu'avec une licence proprio, tout est interdit de base", au final, c'était plutôt le contraire : les licences proprio apparaissent moins compliquées. De fait, perso, je n'ai pas encore de vision totalement claire de la GPL.
-
-
-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 13/04/2008 à 12:36. (lien). Évalué à 1.Tu réponds à un problème juridique par un problème technique.
La définition d'un produit dérivé est: "ton nouveau produit est-il autonome ou a-t-il besoin d'un autre morceau pour fonctionner" ?
Si il faut absolument MySQL pour le faire fonctionner, tu es un produit dérivé. Si tu peux utiliser n'importe quel aure db, tu es considéré comme autonome.
Dans le cas de MySQL, on parle de relation client/Serveur et même pas de link dynamique.
Concernant les pthreads c'est un mauvais exemple car il implémente juste une norme (posix).
On retrouve le concept sur les drivers Nvidia qui sont légaux dans linux car avant tout développé pour windows et pas uniquement pour linux.-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 13/04/2008 à 13:09. (lien). Évalué à 1.IMHO, tu te contredis avec 2 premières phrases :
"
(1) Tu réponds à un problème juridique par un problème technique.
(2) La définition d'un produit dérivé est: "ton nouveau produit est-il autonome ou a-t-il besoin d'un autre morceau pour fonctionner" ?
"
(1) oui, je réponds à un pb juridique par un pb technique (à un moment donné, il faut bien revenir à la réalité, et on fait bien de la technique)
(2) avec ta phrase (2), toi aussi tu te places sur le plan technique. Comment tu sais si un produit est autonome ou a besoin d'un autre pour fonctionner, sans te placer au bout du compte sur le plan technique ?
Bref, j'ai l'impression que l'on parle de la même choses, mais avec des mots différents ;-)-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 13/04/2008 à 15:04. (lien). Évalué à 2.Comment tu sais si un produit est autonome ou a besoin d'un autre pour fonctionner, sans te placer au bout du compte sur le plan technique ?
Disons que c'est tellement basique et vue de tellement haut que je n'appelle pas cela de la téchnique (link dynamique) mais du bon sens (indépendances de morceau).-
[^]Re: A propos de la licence GPL
Posté par briaeros007 () le 14/04/2008 à 10:02. (lien). Évalué à 1.l'API aussi c'est du basique et vue de haut... et pourtant c'est visiblement loin d'être si clair que ça.
--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
-
-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 13/04/2008 à 10:38. (lien). Évalué à 3.Cette histoire de lib est un peu plus compliquée que cela. J'ai commencé à y voir clair après avoir discuté avec le PDG d'une société francaise faisant dans la licence duale GPL, PDG qui avait fait appel à un des rares (et chers) avocats de la place de Paris pour monter son business model...
(cas-1) tu pars des API de SUN. Et tu utilises une implémentation GPL de ces API => tu n'es pas impacté par la licence GPL car tu t'interfaces, tu te linkes avec les API de SUN.
(cas-2) tu pars des API d'un logiciel GPL (j'entends ici une API définie par ce logiciel, une API non standard, non normée). Du moment que tu utilises ou copies cette API pour en faire un produit dérivé, tu t'interfaces avec cette API ou un de ses produits dérivés => tu es impacté par la licence GPL.
De fait, la bonne réponse est : cela dépend.
La réponse n'est pas apportée par le fait de se linker, mais de là d'où tu pars (l'API en question), i.e. la notion de produit dérivé.
-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 13/04/2008 à 10:43. (lien). Évalué à 2.a) Si tu es sous Linux, et tu te linkes avec l'API POSIX => tu te "linkes" avec POSIX (et pas Linux, même si Linux implémente, par derrière, cette API) => tu n'es pas impacté par par la GPL.
b) Si tu es sous Linux, et tu te linkes avec une des spécificités non normées de Linux => tu es impacté par la GPL.
Dans la majorité des cas, on doit être dans (a). Maintenant, j'ai dans l'idée que certaines personnes doivent éventuellement se retrouver, sans le savoir, dans le cas (b), en toute bonne foi, en se disant que si IBM, par ex, fait du business avec Linux et sans en être forcément impacté par la licence GPL, ils doivent pouvoir aussi le faire.
-
-
-
-
[^]Re: A propos de la licence GPL
Posté par Arkem (page perso, ) le 12/04/2008 à 08:43. (lien). Évalué à 1.Dans ce cas, il me semble que c'est le fait que ce soit une bibliothèque qui pose problème, pas la taille du programme.
Au risque de dire une bêtise, il me semble que la LGPL a précisément été inventée pour éviter ce genre de problème. À confirmer...--
Il vaut mieux mobiliser son intelligence sur des conneries que sa connerie sur des choses intelligentes (proverbe shadock)-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 12/04/2008 à 11:41. (lien). Évalué à 2.Non c'est l'inverse. La lgpl a été créé pour des trucs comme lesstif remplace motif.
La lgpl pousse à la réutilisation de lib mais pas à la contribution.
-
-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 12/04/2008 à 11:39. (lien). Évalué à 2.J'adore ta vision simpliste de readline... C'est un truc assez énorme, il suffit de voir la gestion toutes pourris de la ligne de commande sous sun par exemple.
readline n'est pas un petit projet.
C'est d'ailleurs un des principaux exemples de la FSF d'utilisation de la GPL au lieu de la LGPL, il site en général le nom des projets qui sont passés en libre "grâce" à readline.
-
-
-
[^]Re: A propos de la licence GPL
Posté par Arkem (page perso, ) le 12/04/2008 à 09:16. (lien). Évalué à 1.(2) Point négatif : le risque d'être impacté par la licence GPL éloigne certains utilisateurs et possibles contributeurs => force de répulsion.
Personnellement, je comprends qu'un développeur ne veuille pas passer ses propres projets sous GPL selon ce qu'il compte en faire, mais je ne comprends pas en quoi la GPL pourrait nuire à l'utilisateur. Je n'ai jamais entendu parlé d'une restriction ou obligation le concernant.
En fait, la principale dualité entre GPL et BSD tient au fait que la GPL ajoute une sécurité pour le développeur qui stipule que son projet ne peut être redistribué sous une autre licence sans passer par lui.
À moins que ce soit un développeur désireux de reprendre le projet à son compte que tu appelles utilisateur...--
Il vaut mieux mobiliser son intelligence sur des conneries que sa connerie sur des choses intelligentes (proverbe shadock)-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 12/04/2008 à 11:20. (lien). Évalué à 1."À moins que ce soit un développeur désireux de reprendre le projet à son compte que tu appelles utilisateur... "
Oui, c'est cela. Je n'ai pas été très précis dans mon 1er essai de formalisation de l'impact-des-licences-sur-la-viabilité-et-la-visibilité-des-projets-open-source.
-
[^]Re: A propos de la licence GPL
Posté par Nicolas Boulay () le 12/04/2008 à 11:43. (lien). Évalué à 1.Cela ressemble un tout petit peu beaucoup à du parasitisme quoi...
-
[^]Re: A propos de la licence GPL
Posté par ddevito (page perso, ) le 12/04/2008 à 11:54. (lien). Évalué à 1.Merde, je m'a encore gourré. Ait réagi trop rapidement.
Il fallait lire :
"
(2) Point négatif : le risque d'être impacté par la licence GPL éloigne certains développeurs-utilisateurs et possibles contributeurs => force de répulsion.
"
-
-
-
Différences entre Lua et OCaml ?
A première vue, Lua présente qques traits communs avec OCaml, par ex, le fait que les fonctions soient des citoyens de 1ère classe.
Est-ce que qqu'un qui connaitrait les 2 langages (on peut tjrs réver) peut préciser ici les différences entre les 2 ?
Merci
Soyons fou : quid d'une traduction (grandement automatique ? semi-automatique ?) de Lua vers OCaml par ex ?
-
[^]Re: Différences entre Lua et OCaml ?
Posté par Mildred (Jabber id, page perso, ) le 10/04/2008 à 12:19. (lien). Évalué à 4.Je connais bien Lua, mais pas du tout Ocaml. Mais un point qui semblerait un peu bloquant est qu'en Lua, la structure des tables est à la base du langage.
Les tables sont la seule structure de donnée du langage. Cela peut être utilisé comme un vecteur (on indexe par des entiers, les accès sont optimisés), comme un tableau associatif, comme une structure, comme un ensemble (les clefs sont les éléments de l'ensemble, les valeurs sont juste là pour indiquer si l'élément est présent ou non).
Et pour étendre les tables, on a ce qu'on appelle les métatables. Ce sont des tables attachées à des objets (généralement des tables, mais pas forcément). Les fonctions stockées à des index particuliers de la métatable permettent de modifier un comportement par défaut.
Par exemple, si la métatable d'un objet contient un objet à l'index "__index", alors lorsqu'on execute obj.key (qui en passant est juste un raccourci syntaxique pour obj["key"]), la fonction (mataméthode) sera appelée avec les paramètres obj et "key", et son résultat sera le résultat de l'expression obj.key.
Cela permet entre autre d'implémenter des modèles orientés objets dans le langage. Car à la base Lua ne propose aucun modèle objet. Cela vient avec des bibliothèques extérieures comme LOOP http://loop.luaforge.net.
-
[^]Re: Différences entre Lua et OCaml ?
Posté par loufoque () le 10/04/2008 à 14:31. (lien). Évalué à 10.Lua et OCaml n'ont rien à voir.
Si tu dois penser que tous les langages qui ont les fonctions en tant que first-class citicizens sont similaire à OCaml, alors 95% des langages de programmation le sont.
Une différence fondamentale entre Lua et OCaml c'est que déjà Lua est typé avec du duck-typing, alors que OCaml c'est du typage statique avec inférence et polymorphisme paramétrique.-
[^]Re: Différences entre Lua et OCaml ?
-
[^]Re: Différences entre Lua et OCaml ?
Posté par Larry Cow () le 10/04/2008 à 21:03. (lien). Évalué à 10.C'est typage statique avec inférence, que tu as pas compris?
Ou bien polymorphisme paramétrique?-
[^]Re: Différences entre Lua et OCaml ?
Posté par TeXitoi (Jabber id, page perso, ) le 11/04/2008 à 14:07. (lien). Évalué à 6.typage statique : Le travail sur les types est intégralement fait à la compilation (donc rien n'est fait à l'exécution). Le contraire est typage dynamique, comme python, perl, ruby... Deux avantages à cela:
- aucune verification de typage n'est nécessaire à l'exécution, ce qui fait gagner du temps à l'exécution.
- La vérification est faite à la compilation, donc si les types utilisés sont incohérents, le code ne compile pas, contrairement au typage dynamique, où une exception est levé à l'exécution.
inférence de type : il n'y a pas besoin de donner les types des variables, le compilateur les infèrent à partir du code. Par exemple :
let f n = string_of_int nLe compilateur va trouver tout seul que le type de n est entier et que le type de retour de la fonction est chaîne de caractères.
polymorphisme paramétrique : C'est la possibilité pour un type d'englober un ensemble de type, avec des paramètres permettant une réutilisation du type plus loin. Par exemple :
let to_list n = [n]la fonction to_list prend un paramètre (qui peut être de n'importe quel type) et le transforme en une liste de type "liste d'éléments du type du paramètre. Le fait que la fonction puisse prendre un paramètre de n'importe quel type est le polymorphisme, le fait de pouvoir exprimer le type de la fonction grâce au type du paramètre est le paramétrique. Le code au dessus a pour type :'a -> 'a listce qui signifie une fonction prenant comme paramètre un paramètre de n'importe quelle type que l'on appelle 'a, et qui retourne une liste de type liste de 'a.
-
-
-
[^]Re: Différences entre Lua et OCaml ?
Posté par Stéphane Davy () le 11/04/2008 à 13:08. (lien). Évalué à 3.Dans quel(s) livre(s) apprend-on à parler comme ça?
-
[^]Re: Différences entre Lua et OCaml ?
Posté par caouis () le 11/04/2008 à 14:55. (lien). Évalué à 2.Tu peut commencer par regarder wikipédia : type_informatique
mais tu trouvera plus d'information en anglais.
sinon il n'y a pas beaucoup de livre la dessus le seul que je connaisse c'est celui la : http://www.cis.upenn.edu/~bcpierce/tapl/
-
-
[+] Euh !
Moi c'est :
Le polymorphisme statique avec inférence paramétrique de type age !
...
Cette page a été générée par Templeet en 0.2744s (dont 0.0275 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.