Mark Suttlerworth à récemment déclaré [1] qu'il allait livrer les sources de Launchpad [2] sous une licence Libre : Affero GPL [3]
Launchpad is a free software hosting and development website.
Launchpad à été développé pour le projet Ubuntu par Canonical et est, comme l'indique Wikipedia [4], un portail web incluant les outils suivants :
-Le projet Bazaar, permettant aux développeurs d’organiser le développement de paquets (sorte de CVS).
-Le bug tracker Malone, permettant la gestion des rapports de bug provenants directement des utilisateurs.
-Le projet Answers, qui permet aux utilisateurs de poser leurs questions et d’effectuer des demandes de support.
-Le bountie tracker, permettant d’ajouter ou de participer à la donation de primes (en USD) aux développeurs en contrepartie de fonctionnalités nouvelles.
- Le projet Rosetta, qui permet aux utilisateurs de participée traduire le projet.
-Le projet Blueprint, qui indique les divers objectifs à atteindre pour la prochaine version du projet.
1 : https://lists.ubuntu.com/archives/gobuntu-devel/2008-April/0(...)
2 : https://launchpad.net/
3 : http://fr.wikipedia.org/wiki/Affero_GPL
4 : http://fr.wikipedia.org/wiki/Ubuntu
Présentation launchpad : https://launchpad.net/+about
Journal Launchpad, enfin Libre ?
25
avr.
2008
# Enfin !
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
you co-own, so Launchpad will shortly offer direct API's where you can
retrieve, as often as you want"
presque 2 ans que Conseil est bloqué pour précisemment cette raison. Pfff, enfin !
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Enfin !
Posté par JereMe . Évalué à 8.
# Arg
Posté par IsNotGood . Évalué à 10.
Et si je critique Adobe de ne pas fournr les sources de flash, ça va suffir pour qu'ils les mettent sous GPL ?
[^] # Re: Arg
Posté par imalip . Évalué à 0.
[^] # Re: Arg
Posté par IsNotGood . Évalué à 2.
Certes. M'enfin, il faut lire le thread. Au début Mark parle de Gobuntu. Puis au fil de la discussion vient le "problème" launchpad. Ça ne semble pas un coup marketing mais véritablement une prise de conscience du "problème".
Mais t'as raison, et le titre du journal est juste : "Launchpad, enfin Libre ?"
[^] # Re: Arg
Posté par ribwund . Évalué à 4.
[^] # Re: Arg
Posté par IsNotGood . Évalué à 2.
[^] # Re: Arg
Posté par herodiade . Évalué à 4.
> indispensable il peut pas ouvrir le code sinon ca fragmenterait.
>
> Le but c'est d'être la plate-forme incontournable et de ne liberer
> que si aucun concurrent ne peut se mettre à l'égal.
Oui pour la première assertion, la seconde, concernant le but, me semble une interprétation hative.
Dans le fil de discussion lié par la dépêche, Mark Shuttleworth indique que la libération de Launchpad est proche parce qu'il est désormais en mesure de répliquer les données, en fonctionnant plus ou moins en « peer to peer », de façon distribuée.
En ce moment, les développeurs de Launchpad finalisent une API permettant de transférer/échanger/synchroniser/répliquer le contenu à distance, de façon programatique, entre plusieurs installations de Launchpad, et entre des Launchpads, des Bugzilla, des Mantis, des Savannah, des Trac, etc.
Ainsi Launchpad pourra garder sa pertinence (rassembler le plus de données possibles sur une même interface, faciliter les échanges et réduire la fragmentation entre les projets opensource, puisque les diverses copies installées sur internet pourront se synchroniser) sans être centralisé (sans nécessiter d'avoir un seul point d'entrée / une seule installation du logiciel). Et la crainte d'augmenter la fragmentation disparaît.
Si Shuttleworth dit vrai, ce timing me semble légitime, et éclaire rétrospectivement son argument pour ne pas libérer Launchpad immédiatement (« nous le libérerons lorsque le code sera suffisamment avancé ») : il fallait attendre que soient implémentées les fonctionnalités permettant à plusieurs instances/installations séparées du logiciel de fonctionner tout en continuant d'assurer l'objectif fondamental de LP, rassembler/dé-fragmenter l'information.
Pour rappel, LP a toujours été présenté comme un outil destiner à faciliter les échanges entres projets opensource, l'intégration et la centralisation des informations. C'est dans ce but qu'il fut développé (à l'époque, il existait déjà de simples bugtrackers, des outils de suivis de projet, etc déjà tout faits). Il est assez normal qu'il ne soit releasé qu'à partir du moment ou il respecte le contrat, à partir du moment où il peut faire ce pour quoi il est conçu et ce au nom de quoi il se vends (et non l'exact opposé).
Pour faire une analogie simple, c'est un peu comme si vous développiez un nouveau serveur de son et l'annonciez comme « l'API qui va enfin résoudre le merdier du à la multiplicité (alsa, oss, esd, arts, nas, jack, ...) des API exclusives (accès verrouillé au dsp) et plus ou moins incompatibles ». Si vous distribuez votre API alors qu'elle est encore incompatible avec les autres, et que des logiciels commencent à l'utiliser, vous avez simplement renforcé le problème et ajouté votre pierre au merdier. Même si votre logiciel est génial, vous avez aggravé le problème. C'est pourquoi PulseAudio n'a été inclus par défaut dans les grandes distributions (Fedora en premier) qu'à partir du moment où il était capable de cohabiter proprement avec les principaux systèmes « legacy » (via l'émulation esd, les hooks dans alsa-lib, etc.). Question de sens des responsabilités.
Maintenant, on peut légitimement se demander pourquoi il a fallu tant de temps à Canonical pour faire de LP un logiciel « distribué » (à tout les sens du terme)...
[^] # Re: Arg
Posté par IsNotGood . Évalué à 4.
Des exemples d'initiatives toutes fraiches :
http://ovirt.org/
http://freeipa.org/
http://cobbler.et.redhat.com/
http://cft.et.redhat.com/
NB: on n'a pas vu de fork etc...
[^] # Re: Arg
Posté par CrEv (site web personnel) . Évalué à 4.
Maintenant, on peut légitimement se demander pourquoi il a fallu tant de temps à Canonical pour faire de LP un logiciel « distribué » (à tout les sens du terme)...
Moi ce que je me demande, c'est surtout s'il n'aurait pas été bénéfique, surtout en terme de temps, de passer sur un mode de développement ouvert tout de suite (y compris avec une roadmap stricte, c'est pas le problème) pour bénéficier justement de la "force de frappe" du libre : le nombre de développeurs.
Si ce projet est si intéressant, alors il n'aurait pas eu de mal à trouver des développeurs pour s'y mettre et donc gagner du temps.
Parce que tout ça, moi je le vois surtout comme une volontée de contrôle bien plus important que dans les autres distribs.
Si je ne me trompe pas, la majorité des développements de red hat sont en open source, tous les dev de mandriva sont en gpl (pour novel, suse, je me prononcerai pas je ne sais pas)
M'enfin tout ça pour dire que je suis content que launchpad se libère enfin mais je trouve très domage cette volonté constante d'emprisoner les utilisateurs / développeurs chez ubuntu, ce qui est à mon avis contraire aux intérêts et aux buts du Libre.
[^] # Re: Arg
Posté par Spyhawk . Évalué à 3.
Moi je sais, alors je réponds :)
Tous les developpements et toute l'infrastructure d'openSUSE est libre (GPL) et disponible, tout le developpement est ouvert et accessible (mailing lists des dev, svn, etc.). Pour le côté SUSE Entreprise, seuls les correctifs (rpms binaires et sources) des correctifs ne sont pas disponible publiquement (au contraire de RH qui fournit les sources rpm).
A noter, un exemple, qui ressemble _extrement_ au cas de Lauchpad de Canonical, est le Build Service d'openSUSE.
Le Build Service à pour vocation de créer, de façon centralisée et simplifiée, des paquets RPM/DEB pour plusieurs distribution à partir du même code source (un seul fichier .spec). Il permet de lier des projets entre eux et d'augmenter l'interaction et le dynamisme des projets, pas forcément lié à la distribution openSUSE.
Très récemment, une nouvelle fonction de distribution p2p est apparue (soit, exactement ce que Canonical veut/est en train d'implémenter) est disponible. On peut ainsi installer une version locale du Build Service et faire la synchronisation vers un autre Build Service.
Dès le départ, les sources (en rpm/tar.gz) du Build Service étaient disponibles.
Que Mark Shuttleworth prétende que Lauchpad est closed source pour le bien des projets est du foutage de gueule royal. Je pense que ce n'est que par la pression des "Libristes" (entre autres ceux de GoButuntu et GNewSense) que Shuttleworth va ouvrir les sources (bientôt? ça fait 2 ans qu'il nous sort la même salade), et que Launchpad a été pensé à la base comme pièce maitresse de la stratégie de Canonical pour se rendre indispensable.
[^] # Re: Arg
Posté par ZeroHeure (site web personnel) . Évalué à 3.
je comprends peut-être mal, mais ne dit-il pas au contraire qu'il le distribuera quand il pourra être décentralisé?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Arg
Posté par imalip . Évalué à 4.
[^] # Re: Arg
Posté par ribwund . Évalué à 1.
# Mauvais titre.
Posté par Barnabé . Évalué à 1.
# AGPL
Posté par ragoutoutou . Évalué à 4.
Le GPL ne permet pas d'exercer ce genre de contrôle.
[^] # Re: AGPL
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Et ça, ce serait cool !
(D'où y a pas que les sites qui peuvent être mis en AGPL)
* CF http://forum.meebo.com/viewtopic.php?=&p=79107 dernier commentaire, de meebomark
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: AGPL
Posté par Mat (site web personnel) . Évalué à 2.
http://ajaxbber.sourceforge.net/
[^] # Re: AGPL
Posté par Maxime (site web personnel) . Évalué à 2.
Je sais que par exemple moi j'ai des problèmes car sur mon serveur je n'autorise que les connexions cryptés et ça complique énormément les choses (en tout cas avec openfire, m'enfin, ça a peut-être changé depuis la dernière fois).
[^] # Re: AGPL
Posté par Mat (site web personnel) . Évalué à 2.
- la connexion à tous les serveurs jabber de manière classique
- les connexions cryptées
Pour le 1er point rien n'empêche de reprendre l'interface et d'implémenter une partie serveur qui utilise libpurple (ok, ca n'a rien de trivial, y'a un vrai boulot derrière)
Pour le 2nd point, ajaxbber repose sur JsJac, peut être que de ce côté là il y a la possibilité de crypter les connexions ? En parcourant vite fait la doc, j'ai vu traîner un crypt.js
[^] # Re: AGPL
Posté par Maxime (site web personnel) . Évalué à 2.
Je ne sais pas s'il va me permettre de faire ce que je veux faire mais vu que c'est un produit qui était intégré avec OpenFire entreprise...
Pour le second point, le problème est situé du coté de la conf du serveur. L'intérêt de BOSH c'est de pouvoir passer sur de l'http en particulier sur le port 80 (avec un simple proxypass dans la conf d'apache et c'est bon). Le problème c'est qu'on peut pas faire la même chose avec l'https. Bref, un véritable casse-tête entre le SSL d'apache et le TLS du serveur...
Alors que meebo c'est simple et ça marche sur tous les serveurs. Donc on revient à faire le 1. Malheureusement je n'ai pas le temps de le faire moi...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.