Perso, j’aime bien Xtend. Et au fond, c’est (rétrospectivement ;-) logique d’une communauté de développeurs spécialisées dans le tooling définisse un nouveau langage faisant usage d’inférence de type…
Ce que j’aime bien dans Xtend, c’est que j’arrive aisément à imaginer comment les nouvelles fonctionnalités seront compilées en Java et donc, j’arrive facilement à me faire une idée du cout de ces nouvelles fonctionnalités.
Et les autres langages ont aussi des défauts :
- Groovy est associé à des couts d’exécution « cachés » (cf. points plus hauts).
- etc.
Bref, Xtend me semble combler un manque, et améliorer effectivement Java (+/- certaines fonctionnalités dont je n’ai pas encore bien vu l’utilité, ou pu estimer le cout induit, comme les « Create Functions » que je cite ici de mémoire).
Ce serait bien que le JCP (qui gouverne l'évolution de Java) en prenne de la graine. Cela semble d’ailleurs un peu arriver, timidement, avec la JEP 101 http://openjdk.java.net/jeps/101 listée ici http://blog.joda.org/2011/11/future-is-in-jeps.html
Il est dit que les processeurs RISC sont arrivés sur le devant de la scène en conjonction avec la maturité des compilateurs permettant d’optimiser le code produit. Java existe depuis plus de 10 ans, et ceux qui écrivent des compilateurs ont progressé, et ont montré, par ex, que l’inférence de type avait sa place dans des langages d’importance, comme C# ou Scala. Bref, il serait temps IMHO que le monde Java se réveille pour suivre un dépoussiérage à la façon de Xtend.
PS : je ne vois pas trop l'intérêt de rendre les ";" optionnels. Cela complexifie la règle : il peut y avoir 2 cas (";" présent ou non) au lieu d'un seul (";" obligatoire). Bref, cela demande IMHO plus de travail au cerveau des développeurs et, donc, je ne vois pas cette évolution aller dans le bon sens.
* Quid de l'utilisation de Cassandra pour définir un cache de données distribué ?
Imho, Cassandra possède pas mal de fonctionnalités pour définir un tel cache. Le top sera d'avoir un cache associé, coté client.
Est-ce que le "•Cache intégré par élément" dont il est question coté v0.6 est bien un cache associé coté client ?
Est-il possible de définir une politique de synchronisation/raffraichissement pour un tel cache coté client ?
Y a-t-il eu déjà des cas d'utilisation avérés de Cassandra comme cache distribué ?
* Quid de l'utilisation de Cassandra comme grille de données ("data grid") ?
Pareil, il me semble que l'ajout de fonctionnalités dans Cassandra, au fil du temps, va faire de Cassandra une possible grille de données.
Y a-t-il eu déjà des cas d'utilisation avérés de Cassandra comme grille de données ?
Qt est porté sous Windows, non ?
Ce serait bien d'avoir un port de KOffice sous Windows, cela lui donnerait bcq plus de visibilité.. et cela apporterait une concurrence bienvenue à OpenOffice.
C'est quoi le ratio Qt/libs KDE dans le code de KOffice ?
Avez-vous une idée ?
""
pour en revenir à ton idée : je ne crois pas que cela marche pour des raisons économiques. qui voudrait sacrifier son business ? un aggrégateur/réseau social comme facebook veut et garde ton clone numérique (et leurs nouvelles-déjà revues conditions d'utilisation font enfin un peu de remous). crois-tu qu'il cèderait facilement à ta requête qui est : laissez-moi déporter tout chez moi afin que je contrôle ce que je diffuse !
""
Il y a différentes étapes.
J'ai parlé tout d'abord d'une fonction d'import/export qui pourrait être offerte par les applis web 2.0. Une appli web 2.0 qui offrirait une telle fonctionnalité (pour un export par ex vers une box Internet) serait mieux perçue des utilisateurs et attireraient plus de clients.
Dans une démarche plus complète, si toutes les données sont, par ex, du coté de la box, un fournisseur d'appli web 2.0 peut toujours y trouver son avantage ; avec un peu d'imagination ;-)
Même si la box sert de stockage, tous les messages circulent sur les serveurs de l'appli web 2.0. Cette appli web 2.0 peut tjrs coller des pubs Google dans les pages web produits ou coller des pubs dans les messages envoyés ou recus. Bref, une appli web 2.0 qui ne serait pas lieu de stockage peut aussi s'y retrouver pour son business, ne serait-ce que parce que l'on passerait quand même par cette appli web 2.0 et que cela générerait du trafic !
Quant aux données d'authentification et des différents profils que l'on peut utiliser, on peut imaginer qu'ils résident aussi sur la box.
La montée en puissance des box Internet pourrait changer la donne, va surement la changer.
On va peut être avoir (voici qques idées préliminaires) :
- des services d'export/import et/ou de réplication de données : la base principale étant sur la box, les autres étant considérées comme des copies, ou la box étant considérée comme une unité de sauvegarde (d'où l'importance des standards),
- un redécoupage des données : les données fournis par l'utilisateur principal, les données brutes, étant originaires de la box (les serveurs disposant d'une fonction de cache) et les commentaires, par ex, stockés sur la base de l'application web 2.0.
- les données identitaires plus surement sur la box.
En tout cas, le jour où une box sera dotée d'une fonction de stockage, alors la première application web 2.0 s'appuyant dessus, d'une manière ou d'une autre, va avoir un avantage du point de vue des utilisateurs, cela pourrait faire boule de neige...
Peut-être qu'il faudrait soumettre l'idée à free ;-)
Et les autres FAI suivront...
Je cite :
""
Les données personnelles représentent actuellement la valeur que récupère une application en échange de son service, bien souvent « gratuit ». Dans la majorité des cas vous ne pourrez pas récupérer cette valeur sans être un geek, elle sera donc perdue en cas de changement de politique, faillite, perte de votre identifiant, crash de la base de données, etc. Mais comment rester maître de ses données alors ?
Elles devraient tout simplement être stockées chez vous, sur votre serveur. Et ce n'est pas une utopie à l'horizon 2022 ou 2012, en fait vous l'avez déjà. Ça s'appelle une freebox, une livebox ou un autre truc qui finit par box. Vos données vont migrer de votre desktop à ce serveur local, vous permettant de n'avoir plus qu'un tablette de navigation, mobile directement connectée au web.
""
Peut être que ces box ne joueront pas le rôle de serveur, mais on peut envisager au moins d'autres applications à minimal. J'en imagine au moins 2 :
- pour le stockage de nos différentes identités numériques et des préférences associées,
- pour la sauvegarde des données web 2.0 stockées sur d'autres applications.
Ce deuxième point ferait ainsi que les applications web 2.0 qui seraient mieux vues du coté des utilisateurs seraient les applications qui permettraient d'exporter les données sous un format standard, ce qui renforcerait l'importance des standards.
Un des vecteurs de la diffusion de OCaml sera peut être F#, le clone de OCaml from Microsoft.
J'ai lu récemment ici ( http://test.blog2geek.com/f-enfin-reconnu-845.html ) que "F# va bientôt devenir un langage officiel de la plateforme .NET. Il bénéficiera donc d'une intégration totale dans Visual Studio et VS sera distribué avec. ."
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.
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.
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.
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.
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.
"
(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 ;-)
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.
"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.
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.
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.
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é.
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.
"
"À 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.
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...
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.
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: Où est le regard critique ?
Posté par ddevito (site web personnel) . En réponse à la dépêche Découvrir Xtend, un langage extension de Java. Évalué à 3.
Perso, j’aime bien Xtend. Et au fond, c’est (rétrospectivement ;-) logique d’une communauté de développeurs spécialisées dans le tooling définisse un nouveau langage faisant usage d’inférence de type…
Ce que j’aime bien dans Xtend, c’est que j’arrive aisément à imaginer comment les nouvelles fonctionnalités seront compilées en Java et donc, j’arrive facilement à me faire une idée du cout de ces nouvelles fonctionnalités.
En gros, je suis d’accord avec Stephen Colebourne http://blog.joda.org/2011/07/kotlin-and-search-for-better-java_9066.html :
- Scala est trop complexe pour devenir le prochain mainstream language qui va détrôner à coup sûr Java
- Kotlin est associé à des choix syntaxiques en rupture avec Java et pour lesquels on se demande quelle est la valeur ajoutée : http://blog.joda.org/2011/07/reversed-type-declarations_4524.html
- Ceylon est dans le vapoware space
Et les autres langages ont aussi des défauts :
- Groovy est associé à des couts d’exécution « cachés » (cf. points plus hauts).
- etc.
Bref, Xtend me semble combler un manque, et améliorer effectivement Java (+/- certaines fonctionnalités dont je n’ai pas encore bien vu l’utilité, ou pu estimer le cout induit, comme les « Create Functions » que je cite ici de mémoire).
Ce serait bien que le JCP (qui gouverne l'évolution de Java) en prenne de la graine. Cela semble d’ailleurs un peu arriver, timidement, avec la JEP 101 http://openjdk.java.net/jeps/101 listée ici http://blog.joda.org/2011/11/future-is-in-jeps.html
Il est dit que les processeurs RISC sont arrivés sur le devant de la scène en conjonction avec la maturité des compilateurs permettant d’optimiser le code produit. Java existe depuis plus de 10 ans, et ceux qui écrivent des compilateurs ont progressé, et ont montré, par ex, que l’inférence de type avait sa place dans des langages d’importance, comme C# ou Scala. Bref, il serait temps IMHO que le monde Java se réveille pour suivre un dépoussiérage à la façon de Xtend.
PS : je ne vois pas trop l'intérêt de rendre les ";" optionnels. Cela complexifie la règle : il peut y avoir 2 cas (";" présent ou non) au lieu d'un seul (";" obligatoire). Bref, cela demande IMHO plus de travail au cerveau des développeurs et, donc, je ne vois pas cette évolution aller dans le bon sens.
# Cela arrrive au bon moment : l'idée est dans l'air du temps
Posté par ddevito (site web personnel) . En réponse à la dépêche Lancement de la bêta d’Elveos. Évalué à 1.
Récemment a été publié sur linuxfr: Commercial Co-financement d'un logiciel de transfert vers machine-outil sur un sujet analogue.
# Une excellente initiative
Posté par ddevito (site web personnel) . En réponse à la dépêche Lancement de la bêta d’Elveos. Évalué à 1.
C'est vraiment une initiative excellente !
J'en ai révé : "Revisiting donation/funding for open source projects - let's talk about FDD (Feature-Driven Development)" et vous l'avez fait (ce qui est, de loin, le plus important).
Merci
[^] # Re: Cas d'utilisation de Cassandra ?
Posté par ddevito (site web personnel) . En réponse à la dépêche La fondation Apache sort Cassandra 0.6. Évalué à 2.
Plus précisément :
* Quid de l'utilisation de Cassandra pour définir un cache de données distribué ?
Imho, Cassandra possède pas mal de fonctionnalités pour définir un tel cache. Le top sera d'avoir un cache associé, coté client.
Est-ce que le "•Cache intégré par élément" dont il est question coté v0.6 est bien un cache associé coté client ?
Est-il possible de définir une politique de synchronisation/raffraichissement pour un tel cache coté client ?
Y a-t-il eu déjà des cas d'utilisation avérés de Cassandra comme cache distribué ?
* Quid de l'utilisation de Cassandra comme grille de données ("data grid") ?
Pareil, il me semble que l'ajout de fonctionnalités dans Cassandra, au fil du temps, va faire de Cassandra une possible grille de données.
Y a-t-il eu déjà des cas d'utilisation avérés de Cassandra comme grille de données ?
Merci
# Cas d'utilisation de Cassandra ?
Posté par ddevito (site web personnel) . En réponse à la dépêche La fondation Apache sort Cassandra 0.6. Évalué à 2.
Bonjour,
Il m'a été signalé que
(1) Cassandra était plus d'actualité pour manipuler des To et que pour des Go, il valait mieux se tourner vers MySQL Cluster par ex.
(2) Cassandra fonctionnait mieux quand le rapport "lecture/écriture" était de 10, voire même de 100 !
(1) j'ai tendance à penser : qui peut le plus (Cassandra) peut le moins.
(2) Est-ce qu'il faut vraiment un tel ratio de 100 pour que Cassandra soit d'actualité ?
Merci de votre aide.
[^] # Re: KOffice pourrait-il tourner sous Windows ?
Posté par ddevito (site web personnel) . En réponse à la dépêche Sortie de KOffice 2.0.0. Évalué à 2.
Mais je n'avais rien trouvé dans la page de download : http://www.koffice.org/wordpress/category/news/downloads/
# KOffice pourrait-il tourner sous Windows ?
Posté par ddevito (site web personnel) . En réponse à la dépêche Sortie de KOffice 2.0.0. Évalué à 2.
Qt est porté sous Windows, non ?
Ce serait bien d'avoir un port de KOffice sous Windows, cela lui donnerait bcq plus de visibilité.. et cela apporterait une concurrence bienvenue à OpenOffice.
C'est quoi le ratio Qt/libs KDE dans le code de KOffice ?
Avez-vous une idée ?
Merci
[^] # Re: Les box Internet auront un rôle à jouer - Re: Dommage
Posté par ddevito (site web personnel) . En réponse à la dépêche Qui a intérêt à transformer Internet en Minitel ?. Évalué à 1.
pour en revenir à ton idée : je ne crois pas que cela marche pour des raisons économiques. qui voudrait sacrifier son business ? un aggrégateur/réseau social comme facebook veut et garde ton clone numérique (et leurs nouvelles-déjà revues conditions d'utilisation font enfin un peu de remous). crois-tu qu'il cèderait facilement à ta requête qui est : laissez-moi déporter tout chez moi afin que je contrôle ce que je diffuse !
""
Il y a différentes étapes.
J'ai parlé tout d'abord d'une fonction d'import/export qui pourrait être offerte par les applis web 2.0. Une appli web 2.0 qui offrirait une telle fonctionnalité (pour un export par ex vers une box Internet) serait mieux perçue des utilisateurs et attireraient plus de clients.
Dans une démarche plus complète, si toutes les données sont, par ex, du coté de la box, un fournisseur d'appli web 2.0 peut toujours y trouver son avantage ; avec un peu d'imagination ;-)
Même si la box sert de stockage, tous les messages circulent sur les serveurs de l'appli web 2.0. Cette appli web 2.0 peut tjrs coller des pubs Google dans les pages web produits ou coller des pubs dans les messages envoyés ou recus. Bref, une appli web 2.0 qui ne serait pas lieu de stockage peut aussi s'y retrouver pour son business, ne serait-ce que parce que l'on passerait quand même par cette appli web 2.0 et que cela générerait du trafic !
Quant aux données d'authentification et des différents profils que l'on peut utiliser, on peut imaginer qu'ils résident aussi sur la box.
[^] # Re: Les box Internet auront un rôle à jouer - Re: Dommage
Posté par ddevito (site web personnel) . En réponse à la dépêche Qui a intérêt à transformer Internet en Minitel ?. Évalué à 1.
A propos du fait de rassembler nos données perso en un endroit plus sécurisé, j'en ai fait un post :
"About gathering web 2.0 personal data into one safer place"
http://www.jroller.com/dmdevito/entry/about_gathering_web_2_(...)
La montée en puissance des box Internet pourrait changer la donne, va surement la changer.
On va peut être avoir (voici qques idées préliminaires) :
- des services d'export/import et/ou de réplication de données : la base principale étant sur la box, les autres étant considérées comme des copies, ou la box étant considérée comme une unité de sauvegarde (d'où l'importance des standards),
- un redécoupage des données : les données fournis par l'utilisateur principal, les données brutes, étant originaires de la box (les serveurs disposant d'une fonction de cache) et les commentaires, par ex, stockés sur la base de l'application web 2.0.
- les données identitaires plus surement sur la box.
En tout cas, le jour où une box sera dotée d'une fonction de stockage, alors la première application web 2.0 s'appuyant dessus, d'une manière ou d'une autre, va avoir un avantage du point de vue des utilisateurs, cela pourrait faire boule de neige...
Peut-être qu'il faudrait soumettre l'idée à free ;-)
Et les autres FAI suivront...
[^] # Les box Internet auront un rôle à jouer - Re: Dommage
Posté par ddevito (site web personnel) . En réponse à la dépêche Qui a intérêt à transformer Internet en Minitel ?. Évalué à 2.
Beaucoup de gens ont déjà des serveurs potentiels chez eux, ce sont les box Internet.
Je crois aussi que les box Internet auront un rôle à jouer.
Pour ma part, j'ai trouvé l'idée du rôle (accru) de ces box dans l'article "Le Web Sémantique ou l'importance des données liées"
Source : http://www.biologeek.com/conferences,web-semantique/le-web-s(...)
Je cite :
""
Les données personnelles représentent actuellement la valeur que récupère une application en échange de son service, bien souvent « gratuit ». Dans la majorité des cas vous ne pourrez pas récupérer cette valeur sans être un geek, elle sera donc perdue en cas de changement de politique, faillite, perte de votre identifiant, crash de la base de données, etc. Mais comment rester maître de ses données alors ?
Elles devraient tout simplement être stockées chez vous, sur votre serveur. Et ce n'est pas une utopie à l'horizon 2022 ou 2012, en fait vous l'avez déjà. Ça s'appelle une freebox, une livebox ou un autre truc qui finit par box. Vos données vont migrer de votre desktop à ce serveur local, vous permettant de n'avoir plus qu'un tablette de navigation, mobile directement connectée au web.
""
Peut être que ces box ne joueront pas le rôle de serveur, mais on peut envisager au moins d'autres applications à minimal. J'en imagine au moins 2 :
- pour le stockage de nos différentes identités numériques et des préférences associées,
- pour la sauvegarde des données web 2.0 stockées sur d'autres applications.
Ce deuxième point ferait ainsi que les applications web 2.0 qui seraient mieux vues du coté des utilisateurs seraient les applications qui permettraient d'exporter les données sous un format standard, ce qui renforcerait l'importance des standards.
# OCaml propulsé par F#
Posté par ddevito (site web personnel) . En réponse à la dépêche Ocaml Meeting 2009. Évalué à 1.
J'ai lu récemment ici ( http://test.blog2geek.com/f-enfin-reconnu-845.html ) que "F# va bientôt devenir un langage officiel de la plateforme .NET. Il bénéficiera donc d'une intégration totale dans Visual Studio et VS sera distribué avec. ."
Bonne nouvelle.
D'autre part, comme je l'ai écrit ici ( http://www.jroller.com/dmdevito/entry/thoughts_about_java_c_(...) ) et là (http://www.jroller.com/dmdevito/entry/more_ramblings_on_prog(...) ), Java et C#, en incorporant de plus en plus de traits fonctionnels et d'inférence de type, se transforment petit à petit en un langage qui se rapproche de OCaml. Sans doute vaut-il mieux développer directement en OCaml ;-) !?
D'ailleurs, le consortium OCaml ( http://caml.inria.fr/consortium/index.en.html ) a l'air d'incorporer de plus en plus d'entreprises. Pourvu que cela dure.
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 2.
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 ddevito (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 2.
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 ddevito (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 1.
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 ddevito (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 1.
"
(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 ddevito (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 1.
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 ddevito (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 1.
=> 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 ddevito (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 2.
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 ddevito (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 2.
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 ddevito (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 3.
(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 (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 1.
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.
"
[^] # Re: A propos de la licence GPL
Posté par ddevito (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 1.
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 ddevito (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 1.
""
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 ddevito (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à -1.
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 ddevito (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 0.
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.