À l'occasion du rachat de la branche ADSL par Ikanos Communications et de la sortie d'un chipset eagle4, un nouveau pilote étant nécessaire, l'équipe eagle-usb.org a réitéré sa demande d'avoir au minimum un firmware/DSPcode distribuable, à défaut de libre. C'est ce que vient d'accepter Ikanos Communication, en plaçant le firmware USB et le DSPcode des chipsets eagle4 sous licence BSD (sans fournir le code source, la clause 1 ne les y obligeant pas).
Le pilote ueagle-atm, déjà inclus au noyau Linux depuis le 2.6.15, pourra ainsi être distribué en BSD+GPL et le firmware USB/DSPcode associés en BSD (non-free malheureusement même si distribuable, un peu comme un freeware). C'est une bonne nouvelle dans le monde des constructeurs de modems de reconnaître l'utilité d'une licence du monde du libre pour faciliter la distribution de ses firmwares.
Il reste tout de même à obtenir le même genre de licence pour les firmwares/DSPcodes des précédentes versions de chipset eagle. Espérons que le bon fonctionnement du nouveau pilote ueagle-atm et ce choix d'une licence reconnue dans le monde du libre encourageront Ikanos à continuer sur sa lancée (des encouragements seront sans doute nécessaires).
Un pilote ueagle-atm gérant (en plus) ce nouveau chipset devrait être bientôt disponible. Vous pouvez participer aux tests du pilote en développement (ueagle-atm4), si Orange (FAI français) vous a fourni un Fast 800 E4. Le soutien de Sagem (et de ses clients FAI) a été décisif pour lancer les développements d'un pilote pour ce nouveau chipset. Il est néanmoins dommage de n'avoir pas mis dans la boucle immédiatement l'équipe d'eagle-usb.org qui aurait pu orienter les développements directement vers le pilote ueagle-atm, déjà inclus dans le noyau Linux et pérenne. C'est un axe d'amélioration pour les entreprises d'impliquer directement les développeurs du libre (ce qui fait gagner du temps à tout le monde).
Moins d'une semaine après la confirmation officielle de la licence retenue par Ikanos, un pilote en version alpha a été publié par les développeurs d'eagle-usb.org. Maintenant, il reste à obtenir de la documentation de la part d'Ikanos pour fiabiliser son fonctionnement.
Espérons aussi que cette démarche pourra s'étendre aux autres constructeurs de matériel : quel est en effet l'intérêt de se priver d'utilisateurs pour un élément comme les pilotes (et leurs firmwares) qui n'est pas leur coeur de métier ?
Je vous recommande aussi le site de vendorwatch qui identifie les constructeurs sympathiques avec le libre (ou pas).
Aller plus loin
- L'annonce sur eagle-usb.org (13 clics)
- Les tests de ueagle-atm4 (4 clics)
- Le forum de support utilisateur (2 clics)
# Libre mais closed source ?
Posté par ☂ Tramo . Évalué à 4.
Donc après les logiciels open source mais non libres (dont on peut lire le code mais pas distribuer de version modifiée), voici venir les logiciels libres mais closed source (dont on peut distribuer une version modifiée, mais sans avoir lu le code avant) ?
Ou alors, est-ce que la licence BSD n'est pas une licence aussi libre qu'on nous l'a toujours fait croire ?
[^] # Re: Non Libre et closed source mais distribuable
Posté par BAud (site web personnel) . Évalué à 9.
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 (site web personnel) . Évalué à -2.
[^] # Re: Non Libre et closed source mais distribuable
Posté par Mjules (site web personnel) . Évalué à 7.
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 BAud (site web personnel) . Évalué à 10.
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 . Évalué à 1.
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 BAud (site web personnel) . Évalué à 2.
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 BAud (site web personnel) . Évalué à 2.
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 BAud (site web personnel) . Évalué à 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 . Évalué à 1.
# Confusion permanente entre modalité de distribution & licence
Posté par yojik77 . Évalué à 3.
Je frémis un peu.
Un produit intellectuel immatériel, relevant de la propriété intellectuelle, n'a jamais besoin d'une licence, laquelle apporte une précision sur les conditions juridiques d'emploi du "produit" concerné mais présente un caractère suppletif (s'il n'y en a pas, al sagesse du Législateur a pourvu à vos besoins avec le règime légal de propriété intellectuelle).
L'analogie qui rend ça clair n'implique pas de voiture rouge, c'est simplement le mariage : vous ave tous le droit de vous échiner sur un contrat de mariage avec des 10aines de pages de conditions diverses (type pre-nup Kennedy-Onassis qui aurait été un modèle du genre...) et d'accepter au passage de vous faire détrousser par un notaire... ;-D
http://vosdroits.service-public.fr/particuliers/F948.xhtml?&(...)
.. mais vous pouvez aussi vous en remettre, sans effort supplémentaire, à la sagesse législative en retenant le règime dit (justement) "légal", c'est-à-dire la communauté réduite aux acquets (= aux achats d'après mariage, grosso modo).
http://vosdroits.service-public.fr/particuliers/F835.xhtml
Ca se concluera vite fait devant l'Officier d'Etat-Civil : 'il n'a pas été établi de contrat de mariage"....
Donc le fait de ne pas choisir volontairement l'un des règimes matrimoniaux existants ne signifie jamais que vous n'avez pas choisi un règime matrimonial : vous avez simplement choisi le règime par défaut (ou pour un juriste : le règime "de droit commun").
*****
A défaut de licence, les modalités de distribution (en France et certainement aussi aux USA) relève, simplement et naturellement, du bon vouloir du titulaire des droits de copie (copyright). C'est simple et sans bavure.
Ca me rappelle un gars scandalisé, ici-même sur linuxfr, s'émouvant qu'un projet freeware ne mentionnait pas de license sur son site web, comme si c'était un point nécessaire et obligatoire....
Bonne route,
Yojik
[^] # Re: Confusion permanente entre modalité de distribution & licence
Posté par Jak . Évalué à 3.
Et bien il avait raison de s'en émouvoir : en effet, le droit français s'applique par défaut, et celui-ci interdit la distribution sans autorisation de l'auteur. De ce fait, le logiciel ne peut en aucun cas être considéré comme un freeware ou un logiciel libre.
[^] # Re: Confusion permanente entre modalité de distribution & licence
Posté par BAud (site web personnel) . Évalué à 3.
Par ailleurs, j'ai déjà répondu à cette question sur notre mailing-list : https://mail.gna.org/public/ueagleatm-dev/2006-01/msg00010.h(...)
ADI nous avait dit que le "domaine public" leur irait bien, mais n'étant pas juriste d'une part, ne connaissant pas ce qui est possible au Canada (et aux US) et ayant l'information qu'en France (l'exemple que je connais) il n'est pas possible de placer soi-même quelque chose dans le domaine public, nous avons préféré travailler à obtenir une licence identifiée (et connue plutôt qu'un nième truc réécrit en dépit du bon sens).
En effet, même s'il est clair que _notre_ redistribution du firmware / DSPcode ne sera pas remise en cause par ADI (ou Ikanos) - au besoin je m'appuierai, de bonne foi, sur leur souhait que ce soit disponible pour l'utilisateur - cela ne permet pour autant pas aux distributions (Linux, *BSD, autres) d'avoir cette garantie (une licence connue permet de décider beaucoup plus facilement, plutôt que de traiter au cas par cas...). Si vous avez des juristes qui peuvent nous aider sur le sujet, nous sommes bien sûr preneur (Nathanael Nerode nous a bien orienté initialement AMHA).
Cela est-il plus clair ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.