Libre mais closed source ?

• [^]Re: Non Libre et closed source mais distribuable

  Posté par baud123 (Jabber id, page perso, ) le 01/12/2006 à 17:28. (lien). Évalué à 9.

  La licence BSD appliquée à du code source est tout autant libre que la GPL.
  Appliquée à un binaire, elle en permet la distribution sans restriction : j'avais pris sciemment l'exemple du freeware pourtant, n'ai-je pas été assez clair ?
  
  Il faut bien voir que dans le monde des firmwares (micro-logiciels si vous préférez), les licences sont rarement précisées ou sont non libres ou inutilisables (gênant la distribution notamment). Il suffit de voir à combien de reprises s'y est pris Intel pour ses chipsets wifi...

  • [+] [^]Re: Non Libre et closed source mais distribuable

    Posté par pix (page perso, ) le 01/12/2006 à 17:44. (lien). Évalué à -2.

    Un troll potentiel se trouve dans le message précédant, saurez vous le reconnaître ?

    --
    La hiérarchie, c'est comme les étagères : plus c'est haut, moins ça sert.

    [^]Re: Non Libre et closed source mais distribuable

    Posté par Mjules (page perso, ) le 01/12/2006 à 22:14. (lien). Évalué à 7.

    Je suis pas sur de bien comprendre, cela veut il dire que si je prend le firmware (sous licence BSD donc), j'ai le droit de le modifier comme je l'entend (modulo le fait que je sois capable de comprendre le binaire) ?
    
    Est ce que ça va permettre de distribuer le firmware dans une distribution libre ? et dans une distribution très à cheval sur ça (Debian par ex) ?

    • [^]Re: Non Libre et closed source mais distribuable

      Posté par baud123 (Jabber id, page perso, ) le 01/12/2006 à 23:38. (lien). Évalué à 10.

      cela veut il dire que si je prend le firmware (sous licence BSD donc), j'ai le droit de le modifier comme je l'entend (modulo le fait que je sois capable de comprendre le binaire) ?
      
      oui, c'est tout l'intérêt de la BSD : une licence connue et qui donne quelques droits supplémentaires.
      En France, le reverse-engineering est de toute façon autorisé à des fins d'interopérabilité (notion parfois difficile à mettre en avant...).
      L'intérêt était de toute façon avant tout pour nous de pouvoir le distribuer et le transformer (au besoin) dans un format lisible par le pilote ueagle-atm (d'où l'intérêt de pouvoir le modifier, droit donné par la licence BSD).
      
      permettre de distribuer le firmware dans une distribution libre ? et dans une distribution très à cheval sur ça (Debian par ex) ?
      
      Il y a 2 écoles :
      - ceux qui disent que vu que ça s'exécute dans le modem, on s'en fout que ce soit libre, l'important est que ce soit distribuable (Marco d'Ittri fait partie de ceux-là il me semble, même si sa position n'est pas si tranchée... les BSDistes qui sont pragmatiques auront sans doute cette approche, c'est le minimum que Theo de Raadt demande avec des spécifications aussi)
      - ceux qui disent que du firmware cela reste du logiciel (la traduction française de firmware est d'ailleurs micro-logiciel), qu'il n'y a donc pas de raison que ça ne puisse pas être libre (je ferais plutôt partie de cette branche)
      
      Même pour debian, la position n'est pas complètement tranchée sur l'inclusion (ou pas) de ces "blobs" (n'étant pas développeur debian j'essaye surtout de retranscrire ce que j'ai compris des discussions que j'ai pu suivre régulièrement sur debian-legal) : en gros, ils peuvent aller dans non-free, sans risque la licence étant identifiée. Je doute qu'ils puissent aller dans contrib ou dans main (il faudrait tout de même le code source AMHA).
      C'est notamment pourquoi nous avons fait le travail de séparation du pilote et du firmware / DSPcode (historiquement le firmware était dans un .h et compilé avec le pilote du modem, maintenant il est chargé par le module firmware_class ce qui permet de l'avoir dans un fichier distinct, charge aux distributions de l'inclure ou pas sur leurs CD).
      En fait, le problème se pose surtout pour des pilotes qui ne peuvent pas utiliser d'autre firmware que celui fourni car, dans ce cas, du libre est "lié" à du closed-source (un peu comme les logiciels libres tournant sur windows).
      Dans notre cas, il est tout à fait imaginable qu'un firmware open-source et libre soit développé, le pilote est donc bien libre, ce qui a facilité son inclusion au noyau Linux...
      
      En bref, pour l'inclusion de firmware et DSPcode :
      Une distribution telle que Ubuntu ne se fera sans doute pas trop de souci à tout mettre sur le CD principal, pour Mandriva la version free ne l'aura peut-être pas, la version non-free l'aura sûrement (firmware et DSPcode sont distribuables avec une licence identifiée), pour Debian ce sera sans doute dans les dépôts non-free (et pas sur le CD), idem pour Fedora je pense.
      C'est dommage pour un pilote permettant d'accéder à Internet hein ;-) mais il faut bien voir que le problème n'est pas du côté des distributions mais bien des constructeurs... (c'est bien à eux qu'il faut poser la question "voulez-vous que cela fonctionne directement pour tout le monde ou compliquer la tâche de vos utilisateurs/clients à l'installation ?").

      • [^]Des infos sur le cas ubuntu, et quelques questions

        Posté par Cathou () le 04/12/2006 à 23:21. (lien). Évalué à 1.

        Ces infos peuvent t'être utiles pour la veille dans la section ueagle-atm de ton forum.
        
        Déja il faut savoir que la variante Ubuntu, Kubuntu, Xubuntu, Edubuntu est sans incidence. Ce qui compte c'est les noyaux dispos sur les dépots, et comment ils ont été packagés.
        
        --------------------------------------
        
        Breezy (ubuntu 5.10)
        Noyaux: 2.6.12
        Durée de vie: 10.2005 -> 04.2007
        
        Les utilisateurs compil(ai)ent la tarball eagle-usb 2.3.2, vu que les paquets disponibles sur les dépots ubuntu ne rendent pas le modem fonctionnel. De plus, la version de gcc fournie dans le cd d'install n'est pas la même que celle qui a servi à compiler le noyau.. Chapeau ubuntu :((
        Vu la version des noyaux, il me semble que ueagle-atm pourrait également être installé.. enfin bref
        
        --------------------------------------
        
        Dapper (ubuntu 6.06.1 LTS)
        Noyaux: 2.6.15
        Durée de vie: 06.2006 -> 06.2009
        
        C'est pire que tout. Alors que ueagle-atm.c est présent dans le noyau vanilla, les packageurs ont décidé de le zapper. Mais usbatm.ko est présent dans les noyaux installables quant à lui, ainsi que.. eagle-usb.ko !
        
        C'est une situation exécrable pour qui veut installer le pilote ueagle-atm en compilant la tarball 1.3 car il faut prendre de multiples précautions que tout le monde ne (com)prend pas. Blacklister eagle-usb, supprimer usbatm.ko du noyau, faire un depmod -a AVANT de compiler sinon ueagle-atm.ko risque d'être lié à l'ancien usbatm.ko et générer des conflits de symboles, voir par exemple http://forum.eagle-usb.org/viewtopic.php?t=4271
        
        Et ceci se renouvèle quand ubuntu met automatiquement le noyau à jour depuis les dépots de sécurité. Cauchemar des newbies qui se retrouvent sans internet du jour au lendemain sans comprendre..
        
        --------------------------------------
        
        Edgy (ubuntu 6.10)
        Noyaux: 2.6.17
        Durée de vie: 10.2006 -> 04.2008
        
        Cette fois, le pilote ueagle-atm est à 100% dans les noyaux mais malheureusement, eagle-usb aussi. Les deux pilotes sont simultanément chargés au boot. Les packageurs n'ont toujours pas compris.. Heureusement, blacklister suffit à rétablir la situation.
        
        --------------------------------------
        
        Feisty (ubuntu 7.04?)
        Noyaux: 2.6.19 pour le moment, probablement 2.6.20 à la sortie
        Durée de vie: 04.2007? -> 10.2008?
        
        Apparemment les packageurs ont fini par comprendre. Le pilote eagle-usb a disparu des noyaux. Il suffit de déposer les firmwares pour rendre le modem fonctionnel.
        
        --------------------------------------
        
        Questions:
        
        - Est-ce que Ikanos a un pouvoir juridique sur les firmwares pre-Eagle4 *tels qu'ils sont* ou bien est-ce ADI qui a les billes?
        
        - Si c'est ADI, avez-vous rompu les amarres?
        
        - Est-ce que l'équipe ueagle-atm peut avoir les specs des chipsets eagle via Ikanos?
        
        - En imaginant que sans aide d'ADI/Ikanos vous sortiez des firmwares pre-Eagle4 sous licence libre, de quelle manière la société qui a les droits sur les firmwares pre-Eagle4 peut-elle se plaindre de contrefaçon? Bien sûr je ne dis pas qu'il suffit d'ajouter un nop, mais qui peut juger qu'un firmware est 'suffisamment' différent d'un autre?
        
        - En mettant les firmwares pre-Eagle4 sous une forme digéragle par le pilote ueagle-atm, n'avez-vous pas créé de la valeur qui vous permet de revendiquer des droits dessus?
        
        - Si je veux faire un paquet debian 'non-free' qui installe les firmwares pre-Eagle4, qu'est-ce que je dois mentionner comme copyright? Et comme licence?
        
        --------------------------------------------------
        
        Au sujet de ce que tu disais sur l'inclusion de blobs dans une distro:
        Je ne connais pas l'actualité Mandriva, mais Mandriva a la réputation depuis plusieurs années de prendre en charge le Fast800 'out of the box'. Or la présence des firmwares est indispensable pour cela. Par le passé Mandriva n'a donc eu aucun scrupule à inclure des blobs sur ses CD d'install.
        
        En revanche, ubuntu a également inclus du non-libre (ex: pilotes nvidia) sur ses cd d'install mais:
        - pas *encore* les firmwares pre-Eagle4
        - l'utilisateur doit activer les dépots qui lui donnent accès aux paquets "restricted" (équivalent du non-free debian)
        
        C'est juste une info, je n'ai pas de recul pour juger la vertu d'une distro dans ce cas précis.
        
        Chapeau bas pour la solution E4. L'avancée juridique est bien entendu encourageante. Pour ma part, je suis impressionnée par la réactivité technique. Quand on regarde dans la ML, les dates sont très révélatrices et Matthieu Castet a fait très fort. Toi aussi sans doute.

        • [^]Re: *buntu

          Posté par baud123 (Jabber id, page perso, ) le 05/12/2006 à 13:14. (lien). Évalué à 2.

          merci pour ces infos sur les *buntu
          
          Cela tient pour les autres distributions aussi, il serait bon d'intervenir sur la ML de dév pour traiter le packaging par distribution upstream (donc avec nous) https://gna.org/mail/?group=ueagleatm (en anglais si possible ça nous évitera les mix qui arrivaient sur la ML eagle-usb).
          
          Pour eagle-usb, le packaging était intégré dans notre cvs, pour ueagle-atm il est tout à fait possible de continuer
          - cela nous permet de prendre en compte les distributions "connues" directement et notamment de transmettre les pré-requis (disponibilité du kernel source sur les CD/DVD d'install', compatibilité de la version gcc fournie avec celle utilisée pour le kernel... sinon c'est tout de suite la galère pour les utilisateurs
          - ce n'est pas du travail en doublon pour la distribution puisqu'ils bénéficient assez directement des impacts du développement, plutôt que de refaire le boulot derrière
          
          Idem, pour les documentations, un petit message sur la ML pour signaler une doc' permet d'éviter d'avoir à parcourir les referrers pour les retrouver... elles pourraient être stockées sur notre wiki d'ailleurs pour ceux qui acceptent sa licence http://atm.eagle-usb.org/wakka.php?wiki=WikiLicense
          
          Pour les autres questions, je te réponds un peu plus tard...

          [^]Re: quelques questions

          Posté par baud123 (Jabber id, page perso, ) le 05/12/2006 à 15:42. (lien). Évalué à 2.

          Ikanos a *racheté* la branche ADSL de ADI (donc les contrats / technos et les personnes je suppose, par exemple notre interlocuteur était à ADI auparavant...), je suppose donc qu'ils ont bien tous les actifs. J'avais trouvé quelques infos sur le web http://dev.eagle-usb.org/wakka.php?wiki=IkanosInfos
          
          Par conséquent, il est de la responsabilité de Ikanos de s'assurer que ce qu'ils affirment (changement de licence) est effectivement faisable, ce pourquoi c'est un représentant désigné chez eux qui a fait l'annonce sur notre ML publique archivée. Nous ne faisons que redistribuer ce qui nous a été officiellement fourni avec une licence identifiée, nous n'avons pas les moyens d'accéder aux contrats de Ikanos (et nous n'en avons pas besoin).
          Nous n'avons pas rompu les amarres avec ADI, nous n'avons simplement pas de contact chez eux maintenant (m'enfin plus d'un an de silence de leur part aussi...).
          
          Pour les specs des chipsets, ce n'est pas gagné hormis les descriptions floues des documentations commerciales disponibles sur le net... ce serait pas mal pour les chipsets obsolètes.
          
          Pour le firmware vraiment libre, la rétro-ingénierie à des fins d'interopérabilité est possible en France. Il me semble que nous sommes dans ce cas. Après si c'est procéder comme sur pwc initialement (un chipset de webcam), par décompilation c'est effectivement limite : pour bien faire, la décompilation est utilisable pour déterminer des spécifications puis réimplémenter à partir de ces spécifications selon le principe de la salle propre (ou mur chinois) http://en.wikipedia.org/wiki/Clean_room_design
          
          Le changement de format du firmware/DSPcode est permis explicitement par la licence BSD, nous ne faisons qu'appliquer la licence (et pour moi c'est elle qui crée de la valeur vu qu'elle nous permet de travailler).
          Sinon c'est effectivement le travail d'intégration au kernel qui a une valeur (surtout du point de vue utilisateur et donc directement sur le constructeur : clairement les pilotes propriétaires sont une plaie inmaintenable qui ne résistent pas au moindre changement d'ABI et ce sont bien ces blobs proprios qui font perdre toute crédibilité aux constructeurs, là où leur valeur ajoutée est d'avoir du matériel qui "juste marche").
          
          Pour les firmwares / DSPcode eagle4, un paquet debian donnera la licence BSD avec comme copyright Ikanos. Notre copyright côté eagle-usb.org est plutôt sur les outils permettant de les changer de format et tu trouveras ce qu'il faut dans notre SVN.
          Comme indiqué avant, cela nous intéresse d'avoir le packaging intégré à notre SVN pour pouvoir le maintenir par la suite (il suffit de l'envoyer sur la ML de dév, nous donnerons un accès au SVN si besoin).

          [^]concernant les blobs

          Posté par baud123 (Jabber id, page perso, ) le 05/12/2006 à 16:17. (lien). Évalué à 2.

          Pour préciser un peu ce que tu dis : oui Mandriva a intégré eagle-usb avec le firmware/DSPcode depuis au moins Mandriva 9.2.
          C'est depuis ueagle-atm que nous avons commencé à pointer du doigt clairement que le firmware/DSPcode ne faisaient pas un tout avec le pilote et qu'à ce titre ne pouvaient pas bénéficier de la licence libre du pilote, cela reste une interprétation corroborée par le manque de source tout de même (ceci étant facilité par la non inclusion du firmware dans un .h ... chargement par firmware_class... depuis ueagle-atm).
          
          Mandriva avec sa version 2007 a choisi de sortir une version free et une non-free respectant ce principe, le firmware se retrouve donc non distribué sur le CD free (qui signifie libre comme tout le monde a compris).
          
          Concernant Ubuntu, le travail d'intégration n'a pas eu lieu à ma connaissance.
          Il n'y a pas de souci pour rajouter un packageur sur notre SVN (s'il peut respecter les DFSG ce serait pas mal aussi pour éviter d'avoir 2 types de paquets .deb).
          
          Pour rappel sur les blobs, ce qui était reproché à raison à Ubuntu c'est de _travailler à rajouter_ des blobs au kernel ET en même temps annoncer "100% free" pour leur CD : c'est induire l'utilisateur en erreur, autant mettre "100% gratis" pour être honnête : en gros respecter la répartition de ce qui est indiqué sur http://www.ubuntu.com/ubuntu/components . Je ne doute pas que cette approche trompeuse soit rectifiée rapidement, tout comme Mandriva a travaillé à clarifier le libre du non libre (ou Debian ou Fedora...). D'autre part, l'aide des distributions pour appuyer les demandes des développeurs libres auprès des constructeurs serait un plus... (les distributions signent bien des contrats de certification de temps en temps).
          
          L'utilisation de dépôts estampillés restricted ou non-free contribue à clarifier et permet d'identifier ce qui est explicitement non libre (après cela signifie regarder la licence au cas par cas pour vérifier que c'est distribuable sans trop de risque pour la distrib'), le jour où cela devient libre (par fourniture du code ou réécriture du code), cela peut sortir de non-free (ou alors, si cela devient interdit au détriment des utilisateurs... au constructeur de faire le choix de ses clients).

  [^]Re: Libre mais closed source ?

  Posté par Aldoo (Jabber id, ) le 01/12/2006 à 23:37. (lien). Évalué à 1.

  Bah le libre closed source, on était déjà habitués avec les Creative Commons ! (Eh mince, j'ai marché dedans avec 38 minutes de retard !)