Journal Chronique d'une violation de licence ordinaire...

Posté par .
Tags : aucun
0
7
sept.
2004
Lors d'un petit browsage de web, je tombe là dessus :
http://www.tvix.co.kr/Eng/Products/TViX.aspx(...)

Il s'agit d'un player de DivX et autres fichiers audio/vidéo, équipé d'un disque dur et qui se branche sur l'USB2 côté PC pour se faire remplir, et sur la télé/chaine-hifi pour se faire vider. Là je me dis "forcement, c'est encore un petit linux...", mais un petit google ne me donne pas la confirmation.

Je télécharge donc le firmware sur le site du constructeur, et je vérifie un peu tout ça :
% cd /tmp
% wget http://demod.dvico.com/down/tvixfw1.4-eng.zip(...)
% unzip -e tvixfw1.4-eng.zip
Archive: tvixfw1.4-eng.zip
inflating: flash.bin
inflating: tvixfw.bin
% file tvixfw.bin
tvixfw.bin: romfs filesystem, version 1 3078912 bytes, named DVDPLAYER 0.0.0 Wed Aug 18 19:4.
% sudo mkdir /mnt/romfs
% sudo modprobe loop
% sudo mount -o loop /tmp/tvixfw.bin /mnt/romfs
% ls /mnt/romfs
bin cdrom dev etc fipmodule.o fonts hd HDD1 HDD2 HDD3 HDD4 img khwl.o linux.bin.gz minimod proc

Ah bah oui, un de plus :)
Et les licences, elles sont où ? Et les sources ?

Bon, finalement, en googlant un peu mieux je trouve une mention du mot Linux chez le constructeur, dans la FAQ :
Q) I can see the file name on my PC. But I can’t see it on TVIX.
A) Our device is based on Linux. So it doesn’t support files which is over 2GB. If you want to make our device to support the file, you should divide that file into the files are less than 2GB.

Arf, les ingrats...

Bon, à l'examen, le contenu de leur firmware ne révèle que qlqs executables statiques. Statique ? Hmmm... J'espère qu'ils n'utilisent pas la µClibc, parce que la LGPL impose quand même quelques condition pour être liée statiquement à un exécutable. Cf. les articles 5 et 6 de la LGPL (en français pour les grosses flemmes comme moi) :
http://www.linux-france.org/article/these/licence/lgpl/lgpl-3.html(...)

Voyons ça...
% strings /mnt/romfs/bin/aviplay | sort -u > /tmp/aviplay-strings.txt
% strings /usr/i386-linux-uclibc/lib/libuClibc-0.9.26.so | sort -u > /tmp/uclibc-strings.txt
% cat /tmp/aviplay-strings.txt /tmp/uclibc-strings.txt | sort | uniq -d
127

Oh c'est fout ça, 127 messages identiques entre leur binaire proprio et la µClib... Pour ceux qui auraient eu la flemme de lire les articles LGPL, le site de µClibc fait un petit résumé du service minimum obligatoire :
http://www.uclibc.org/FAQ.html#licensing(...)
Faute d'avoir une appli libre, on devrait au moins avoir accès à une appli linkée dynamiquement (en plus biensûr d'avoir une mention explicite de l'utilisation de la µClibc, de sa licence, etc.)

Passons maintenant au noyau. On remarque tout de suite les fichiers "fipmodule.o" et "khwl.o" à la racine. Oh, attendez, Sigma Designs, ça vous dit qqch ? Ces 2 modules sont en fait caractéristiques de leurs produits, on les retrouve dans de nombreux autres firmware depuis longtemps. Voir par exemple :
http://lkml.org/lkml/2003/11/29/45(...)

Rien de bien neuf ici donc, juste un n-ième produit dérivé Sigma, qui comme ses copains oublie de mentionner que le noyau Linux est sous GPL, ce genre de détails...
Après, est-ce que leur noyau est modifié, on peut supposer que non (si ils voulaient aller aussi loin, il ne se seraient même pas embêtés à mettre le driver proprio en module...). M'enfin j'ai pas du tout les capacités pour le vérifier formellement.

Enfin pour être complet, un coup d'oeil à "flash.bin" :
% file flash.bin
flash.bin: POSIX tar archive
% tar xvf flash.bin
tvixfw/
tvixfw/logo.png
tvixfw/flash.fuf
tvixfw/fipm.o
tvixfw/khwl.o
tvixfw/flash
tvixfw/mtd/
tvixfw/mtd/mtdcore.o
tvixfw/mtd/mtdchar.o
tvixfw/mtd/chips/
tvixfw/mtd/chips/chipreg.o
tvixfw/mtd/chips/cfi_probe.o
tvixfw/mtd/chips/cfi_cmdset_0002.o
tvixfw/mtd/chips/gen_probe.o
tvixfw/mtd/chips/jedec_probe.o
tvixfw/mtd/maps/
tvixfw/mtd/maps/jaspermap.o

Quelques `strings` plus loin, on se rend compte qu'il s'agit d'un ensemble de modules noyau, certain GPL, d'autres proprio made in Sigma. En fait j'aurais pu commencer par là, car tout indique très clairement qu'on a affaire au SDK de Sigma. Par exemple :
% strings tvixfw/mtd/chips/cfi_probe.o
kernel_version=2.4.17-uc0
license=GPL
author=David Woodhouse <dwmw2@infradead.org> et al.
description=Probe code for CFI-compliant flash chips
/sigma/EM85xx.dvd/uClinux-2.4/include/linux/dcache.h
/sigma/EM85xx.dvd/uClinux-2.4/include/linux/sched.h
[...]

Bon voilà, le fruit d'une petite exploration dans un firmware. Perso c'était la première fois que je mettais vraiment le nez dans ce genre de truc, c'est un peu pour ça que je vous l'ai raconté au fur et à mesure, même si finalement la conclusion est qu'il s'agit d'une violation de licence déjà tristement banale... Je rapporterai quand même tout ça aux intéressés, je doute que ça change grand chose, mais au moins google aura trace que DViCO Inc. sont des méchants. Nah !
  • # lkml

    Posté par . Évalué à 5.

    Je suis sur que certaines personnes sur la lkml seraient interessees aussi...
  • # FSF

    Posté par . Évalué à 7.

    Dans ce cas précis, je crois que c'est la FSF (et ses avocats) qui sont les plus à même de réagir.
  • # .

    Posté par . Évalué à 2.

    Pour la licence je ne sais pas, mais pour les sources rien ne specifie qu'il faille qu'elles soient facilement telechargeable à partir du site web du distributeur.

    Tu leur as demandé si tu pouvais avoir les sources, ou comment les avoir ?
    • [^] # Re: .

      Posté par . Évalué à 7.

      > Tu leur as demandé si tu pouvais avoir les sources, ou comment les
      > avoir ?

      Pas encore. Tu as raison ceci dit, que les sources ne soient pas proposée par défaut ne constitue pas une violation en soit (idem pour la version dynamiquement linkée des exécutables utilisant la µClibc d'ailleurs). L'absence de toute mention de la licence par contre oui.

      Mais c'est clair que de toute façon, avant de rapporter la chose à la LKML (pour la violation de GPL du noyau) ou à la FSF (pour la violation de LGPL de µClibc), je vais les contacter... on peut toujours rêver :)
      • [^] # Re: .

        Posté par . Évalué à 5.

        Euh, si tu as téléchargé le binaires, alors tu aurais du avoir une proposition de telecharger les sources. Sinon violation.
        De même tu as raison sur l'absence de mention de la licence : violation.

        Par contre au niveau du contact, tu peux uniquement les informer brievement de la situation mais ne soit pas trop insistant si aucun code que tu possèdes ne voit ca licence violée par eux. Seuls les détenteurs des droits d'auteurs peuvent agir effectivement (c'est pour ca qu'il faut informer les détenteurs des droits d'auteurs rapidement).
        • [^] # Re: .

          Posté par . Évalué à 4.

          > Euh, si tu as téléchargé le binaires, alors tu aurais du avoir une
          > proposition de telecharger les sources. Sinon violation.

          Ah, je croyais que si on pouvait les obtenir sur demande, c'était suffisant. Mais en fait tu as raison, je viens de relire l'article 3, et même si ils ne veulent pas mettre un lien vers les sources GPL, ils devraient au moins dire un truc du genre "le source de machin est dispo gratos sur demande". Là ils ne disent rien, donc violation. Bien vu.
  • # oubli

    Posté par . Évalué à 2.

    Oh, j'avais oublié de regarder leur exécutable "minimod"...

    % strings /mnt/romfs/minimod | sort -u > /tmp/minimod-strings.txt
    % strings /bin/busybox | sort -u > /tmp/busybox-strings.txt
    % cat /tmp/busybox-strings.txt /tmp/minimod-strings.txt | sort | uniq -d | wc -l
    66

    Allez, j'ajoute busybox à la liste des soft spoliés. Remarquez, ça n'a rien d'étonnant, c'est le trio classique finalement.
    • [^] # Re: oubli

      Posté par (page perso) . Évalué à 4.

      Bon je ne trouve pas que tes preuves soient des vraies preuves. Je sais je pinaille un peu mais :
      % strings /bin/tar |sort -u >tar-strings.txt
      % strings /bin/bash |sort -u >bash-strings.txt
      % cat tar-strings.txt bash-strings.txt | sort | uniq -d |wc -l
      137

      Tout ça ne veut pas dire que tar est une copie de bash.

      Attention, je ne mets pas en doute le fait qu'ils aient pris des softs libres (d'autant plus que aviplay est surement le player de http://avifile.sf.net(...)) mais je trouve juste que tes preuves ne sont pas tangibles.
      • [^] # Re: oubli

        Posté par . Évalué à 4.

        J'ai mis seulement le compte des lignes là, mais en fait j'ai regardé le détail, et c'est vraiment très clair.

        Dans ton exemple, les chaines en question sont principalement des noms de symboles, parceque tes binaires sont liés dynamiquement à la même bibliothèque (libc), et font bien sûr en partie appel aux même fonctions.

        Mais ce que moi j'ai comparé, ce sont des binaires statiques strippé, où l'on ne retrouve pas ces chaines ci. Celles qui restent sont presques toutes des vraies chaines du programmes (en gros les messages balancés sur stderr/stdout). Je te colle en exemple, pour pas faire trop long, celles communes à busybox et minimod et qui sont de longueur >=20 et qui ne concernent pas le format ELF :

        % cat /tmp/busybox-strings.txt /tmp/minimod-strings.txt | sort | uniq -d | grep "...................." | grep -v -i elf
        A module named %s already exists
        Can't allocate kernel memory for module; needed %lu bytes
        can't handle sections of type %ld
        Could not load the module
        couldn't find the kernel version the module was compiled for
        improperly terminated string argument for %s
        invalid argument syntax for %s
        invalid parameter %s
        kernel-module version mismatch
        local symbol %s with index %ld exceeds local_symtab_size %ld
        Not configured to support old kernels
        parameter type 'c' for %s must be followed by the maximum size
        query_module: QM_INFO: %s
        query_module: QM_SYMBOLS: %s
        RELA relocations not supported on this architecture
        relocation entry size mismatch: %lu != %lu
        section header size mismatch: %lu != %lu
        %s of type %ld for %s
        string too long for %s (max %ld)
        %s was compiled for kernel version %s
        symbol for parameter %s not found
        symbol size mismatch: %lu != %lu
        too few values for %s (min %d)
        too many values for %s (max %d)
        Unhandled relocation
        unknown parameter type '%c' for %s
        unresolved symbol %s
        Warning: kernel-module version mismatch
        Warning: unhandled reloc %d
        while this kernel is version %s
        while this kernel is version %s.


        Bien sûr, ça n'a rien d'une preuve absolue et ça peut être par hasard que dans les deux code le dernier message c'est trouvé écrit un coup avec un point et un coup sans, m'enfin bon, faut pas pousser :)

        Si on prend à titre de comparaison le même test effectué entre busybox et insmod+modprobe+rmmod, on trouve seulement 3 chaines (alors que eux pourraient légitimement partager du code) :


        % ( strings /sbin/insmod ; strings /sbin/modprobe ; strings /sbin/rmmod ) | sort -u > /tmp/modutils-strings.txt
        % cat /tmp/modutils-strings.txt /tmp/busybox-strings.txt | sort | uniq -d | grep "...................." | grep -v -i elf
        Invalid module format
        Module has wrong symbol version
        Unknown symbol in module


        Ça donne une idée de combien ce genre de coincidence est improbable.
      • [^] # ...

        Posté par . Évalué à 3.

        $ (od -s15 -A n /bin/bash | sort -u; od -s15 -A n /bin/tar | sort -u) | sort | uniq -d | grep -v ^_ | wc -l
        4
        • [^] # Re: ...

          Posté par . Évalué à 2.

          Ah, 'od', j'avais complètement oublié son existence. Merci :)
        • [^] # Re: ...

          Posté par . Évalué à 1.

          tu debute en bash, non ?
          lol
          bravo !
  • # Réponse du fabricant

    Posté par . Évalué à 3.

    Suite à un courrier où je rappelais très gentiment au fabriquant (DViCO) les différents points sur lesquels il ne respectait pas les licences GPL et LGPL, j'ai reçu cette réponse, un peu laconique :
    Dear Sir,

    All the linux kernel software is from the chip manufacturer.
    We forwarded you mail to the chip manufacturer and we are waiting for the answers from them.

    Best Regards,

    « C'est pas nous c'est Sigma... »
    Ils n'ont pas compris que c'est bien à eux de régler le problème puisque c'est eux qui diffuse publiquement les binaires. Sigma au contraire ne diffuse son kit de développement que aux boites qui font des produits basés sur leurs technos, et en ça n'est tenu à rien vis-à-vis de l'utilisateur final.

    Je laisse passer qlqs jours pour voir si qqch revient après une éventuelle réponse de Sigma, et puis sinon faudra que je passe à la phase délation.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.