Journal Launchpad, enfin Libre ?

Posté par  .
Étiquettes :
0
25
avr.
2008
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
  • # Enfin !

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    "It's weird that you have to screen-scrape ANY site to retrieve data that
    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

  • # Arg

    Posté par  . Évalué à 10.

    Hier j'ai critiqué Ubuntu de ne pas fournir les sources de launchpad...

    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  . Évalué à 0.

      Tu peux toujours, pour le moment, il dit juste "un jour on distribuera". Ca reste donc a l'état de promesse, tout en confirmant que Launchpad a été a la base concu pour etre une plateforme centralisée.
      • [^] # Re: Arg

        Posté par  . Évalué à 2.

        > Tu peux toujours, pour le moment, il dit juste "un jour on distribuera". Ca reste donc a l'état de promesse

        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  . Évalué à 4.

          Genre il avait pas conscience du problème avant... Ça fait 3 ans au moins que il dit que tant que launchpad est pas 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.
          • [^] # Re: Arg

            Posté par  . Évalué à 2.

            Ok, je vois l'idée.
          • [^] # Re: Arg

            Posté par  . Évalué à 4.

            > Ça fait 3 ans au moins que il dit que tant que launchpad est pas
            > 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  . Évalué à 4.

              Red Hat lance des projets (dont l'infrastructure Fedora) et met le tout en libre sans attendre que tout soit finaliser. C'est aussi ça le libre, partager/discuter/décider aussi lors de la concèption et avec tout ceux qui sont intéressés.
              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  (site web personnel) . Évalué à 4.

              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,
              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  . Évalué à 3.

                [...] 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)

                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  . Évalué à 3.

        The roadmap for Launchpad does get it to the point where it will more graciously handle that distributed nature, and at that point I will be more comfortable distributing it.

        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  . Évalué à 4.

          Ouais, et ce sera decentralise quand ? Elle est ou la roadmap ? Le Monsieur a aussi dit a debconf "There is no behind the scene agenda, there is no ubuntu-private". Et que LP avait ete fait explicitement pour centraliser les infos faire en sorte qu'on passe par lui. Il faut croire quoi dans tout ca ?
          • [^] # Re: Arg

            Posté par  . Évalué à 1.

            Ptet qu'il a changé son business plan, mais bon à la base launchpad était très central dans ce plan, et un des moyens les plus prometteur de faire de l'argent (c'est un service qui peut se vendre pour les trucs proprietaires, le bugtracker universel, toussa).
  • # Mauvais titre.

    Posté par  . Évalué à 1.

    Il faudrait dire : « Launchpad, enfin distribué ? »
  • # AGPL

    Posté par  . Évalué à 4.

    Bon choix pour eux, grâce à l'AGPL, ils s'assurent la possibilité de récupérer les modifications que des concurrents pourraient faire...

    Le GPL ne permet pas d'exercer ce genre de contrôle.
    • [^] # Re: AGPL

      Posté par  (site web personnel) . Évalué à 3.

      c'est vrai, si par exemple libpurple était sous AGPL on pourrait avoir le source de meebo*
      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  (site web personnel) . Évalué à 2.

        si une interface à la meebo t'intéresse, il y a ajaxbber qui lui ressemble pas mal. C'est encore en plein développement, mais c'est déjà utilisable :

        http://ajaxbber.sourceforge.net/
        • [^] # Re: AGPL

          Posté par  (site web personnel) . Évalué à 2.

          Le truc c'est que ajaxbber est un client qui se repose sur BOSH ( http://www.xmpp.org/extensions/xep-0124.html ) alors que meebo permet de se connecter sur tous les serveurs jabber de manière classique.
          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  (site web personnel) . Évalué à 2.

            Il y a 2 choses dans ce que tu dis là :
            - 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  (site web personnel) . Évalué à 2.

              Pour le premier point, ce n'est pas si trivial que ça je pense... Bon et de toute façon, je vais surtout regarder du coté de SparkWeb qui vient tout juste de devenir libre et qui sera normalement disponible demain.
              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.