Journal Drivers GPL à partir de spécifications sous NDA, bien ou pas ?

Posté par nonas le 16 février 2007 à 23:09.

Étiquettes : aucune

-1

fév.

2007

Greg K-H [1] s'est récemment proposé de développer des drivers GPL à partir de spécifications sous NDA (non-disclosure agreement : accord de non divulgation). [2]
Suite à cette annonce une discussion a démarré sur la mailing list misc@openbsd.org [3] dont un résumé est disponible sur kerneltrap. [4]

Ces drivers permettraient d'avoir plus de périphériques supportés nativement sous Linux, au détriment de la lisibilité et de la 'maintenabilité' du code. On imagine aisément qu'un driver développé à partir d'informations devant rester secrètes ne doit pas en dire trop, obligeant ainsi les gens qui voudraient contribuer ou écrire un autre driver pour le même matériel (sous une autre licence ou pas) à faire de l'ingénierie inverse sur ce driver GPL.

Voir aussi l'article par lequel j'ai eu vent de ça sur undeadly. [5]

Trolls mis à part (on est encore vendredi...), qu'en pensez-vous ?
Est-il préférable de ne pas avoir de drivers du tout ? ou des drivers sous GPL mais dont les spécifications ne seraient pas ouvertement disponibles sont-ils acceptables ?
Peut-on espérer voir des drivers (peu importe leur licence) dont les spécifications soient pleinement disponibles et accessibles ?
Comment l'Open Source Development Lab et la Linux Foundation [6] peuvent-ils garantir la non-divulgation des spécifications ?

[1] http://www.kroah.com/linux/
[2] http://lkml.org/lkml/2007/1/29/345
[3] http://marc.theaimsgroup.com/?l=openbsd-misc&m=117143918(...)
[4] http://kerneltrap.org/node/7729
[5] http://undeadly.org/cgi?action=article&sid=2007021613373(...)
[6] http://www.linux-foundation.org/en/Main_Page

PS : c'est mon premier journal, ne soyez pas indulgents, soyez justes ! ;-)

# un peu ...

Posté par Marc Poiroud (site web personnel) le 16 février 2007 à 23:41. Évalué à 10.

L'idéal est d'avoir un pilote libre pleinement exploitable, mais c'est pas le cas ...

Donc faire entrer les contructeurs en leur permettant de faire un pilote pour Linux en cachant leur « propriété » c'est déjà un grand pas !

C'est la technique du vendeur de tapis ... mettre un pied dans l'embrasure de la porte ! Quand les constructeurs prendront conscience que linux est viable financierement alors ils feront des pilotes libres mais pour le moment il faut faire des compromis et l'initiative de GKH est originale et mérite d'être soutenue.
- [^] # Re: un peu ...
  
  Posté par Uriel Corfa le 17 février 2007 à 00:05. Évalué à 5.
  
  Quand les constructeurs prendront conscience que linux est viable financierement alors ils feront des pilotes libres
  
  Pas sur. Ils feront peut etre juste des pilotes binaires compatibles linux, hein...
  - [^] # Re: un peu ...
    
    Posté par eon2004 le 17 février 2007 à 00:23. Évalué à 5.
    
    ben non, si c'est GPL, justement...
# ....

Posté par M le 16 février 2007 à 23:59. Évalué à 7.

obligeant ainsi les gens qui voudraient contribuer ou écrire un autre driver pour le même matériel (sous une autre licence ou pas) à faire de l'ingénierie inverse sur ce driver GPL.
Ben c'est toujours mieux que de le faire sur de l'assembleur ou a partir du sniffage de ce que fait le driver proprio.

De plus la license GPL autorise l'etude du code, alors que la decompilation n'est pas authorisée partout.
# déjà vu

Posté par BAud (site web personnel) le 17 février 2007 à 00:05. Évalué à 3.

on en a déjà parlé sur https://linuxfr.org/~patrick_g/23652.html

mais il est effectivement difficile de faire le tour du sujet tant que des entreprises ne se prononceront pas sur l'intérêt qu'elles peuvent avoir à ne pas contribuer au libre ou nous mettre des bâtons dans les roues...

AMHA un NDA de 6 mois voire un an est presqu'acceptable (mais dans ce cas ce NDA doit être rémunéré : les sources des firmwares et les documentations doivent être fournis dès le début sous une licence libre). Si la doc' fournie s'avère inutilisable ou sous une licence non libre, autant faire du reverse... Mais s'il y a effectivement un contact technique chez le constructeur, cela peut valoir le coup, même si le NDA est clairement un frein à des développements rapides et efficaces.

J'entends bien sûr le NDA comme une solution temporaire : dès sa fin, tout se retrouve sur un svn public (source et doc') pour permettre à tout le monde de travailler (enfin) proprement et commencer à inclure les pilotes directement dans le noyau. Si au minimum le source peut être dans un svn public malgré le NDA, ça aide beaucoup pour faciliter les contributions et l'intégration.
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 17 février 2007 à 01:02. Évalué à 8.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: déjà vu
    
    Posté par alexissoft le 17 février 2007 à 09:09. Évalué à 6.
    
    Personnellement, j'ai déjà essayé de discuter avec Lexibook pour avoir les spécifications de leur protocole de communication série entre l'ordinateur et leurs petits agendas électroniques tout pourris qui font que téléphone et agenda comme fonction les plus avancée (et encore).
    
    Vous allez pas me dire que c'est quelque chose de très important à garder confidentiel parce que les concurrents ils pourraient piquer notre IMMENSE valeur industrielle dessus (surtout que le proto en question il est vraiment mal fait).
    
    Bah non, ils ont refusé ...
  - [^] # Re: déjà vu
    
    Posté par imr le 17 février 2007 à 10:08. Évalué à 5.
    
    Puisque nVidia ne fait plus de pilote pour ces "vieilles" cartes, pourquoi ne pas lâcher les specs ?
    Je parie pour des NDA, des licences et des brevets.
  - [^] # mais enfin
    
    Posté par Bayet Thierry le 17 février 2007 à 11:54. Évalué à 3.
    
    C'est quoi donc que cette manière de penser des constructeurs?
    
    Un moteur de voiture, si je veux en faire le tour, je le fais, si je veux faire des modifications, je les fais, je peux avoir toutes les spécificités. Il me restera ensuite à être en conformité avec les lois de mon pays pour que je puisse rouler avec.
    
    Pas pour le matériel électronique? Je l'achète j'ai donc droit à savoir tout ce qui le concerne.
    
    Non, ce qu'il faut, c'est se tourner vers les élus afin d'obliger les constructeurs à faire ce qui est logique, obligatoire même, à savoir donner les spécificité de leur matériel. Qu'on ne vienne pas me dire que c'est pour empêcher leur rivaux à connaitre leur matos, c'est des fadaises.
    
    Il faut être fort, refuser les NDA, continuer à placer le matériel non compatible sur des endroits bien en vues, afin de faire de la contre-publicité (par ex: peut servir de presse papier (pour une imprimante) comme c'est le cas du site des imprimante), et chaque fois qu'on veux acheter du matos, on le demande au constructeur... Vous n'avez pas les drivers? ok je vais acheter ailleur...
    
    Et si chaque fois que du nouveau matériel sors, chaque citoyen du monde fait pareil ... (monde libre)
    
    aller j'arrête de rêver.
    - [^] # Re: mais enfin
      
      Posté par M le 17 février 2007 à 12:28. Évalué à 3.
      
      Un moteur de voiture, si je veux en faire le tour, je le fais, si je veux faire des modifications, je les fais, je peux avoir toutes les spécificités. Il me restera ensuite à être en conformité avec les lois de mon pays pour que je puisse rouler avec.
      Heu desormais les moteurs de voiture embarque de l'ectronique : injection et tout plein d'autre chose qui tourne autour.
      Et a mon avis tu n'a pas n'a pas acces a ce qui tourne dedans (ni d'ailleur au shema mecanique detaillé de ton moteur).
      
      Apres tu es libre de demonter dans ton coin ton moteur (tout comme quelqu'un desassemblerait un logiciel). Par contre si tu t'amuse a le modifier, et la le diffuser/l'utiliser dans les lieu publiques, il y a certaines conditions a respecter (faire homologuer tes modifs, ...).
# FAQ de Greg KH sur sa proposition

Posté par Smarter le 17 février 2007 à 14:24. Évalué à 10.

Greg a fait une faq sur la proposition qu'il a fait: http://www.kroah.com/log/linux/free_drivers_faq.html
Il y a notamment ce passage intéressant:

Q: How are you going to write a GPL driver by signing an NDA? Is it going to require a binary blob or some other way of obfuscating the code?
A: No, not at all. I have written many drivers after signing NDAs with companies. They are usually signed either to keep information about the device private until it is announced at a specific date, or to just keep the actual specification documents from being released to the public directly. All code created by this NDA program is to be released under the GPL for inclusion in the main kernel tree, nothing will be obfuscated at all.

qu'on pourrait traduire par:

Q: Comment allez-vous faire pour écrire un pilote GPL en signant une NDA? Est-ce qu'il y aura un blob binaire ou une autre façon de brouiller le code?
R: Non, pas du tout. J'ai écris beaucoup de pilotes après avoir signé des NDA avec des compagnies. Elles sont la plupart du temps signés pour garder privé des informations sur le pilote avant qu'il soit annoncé à une certaine date, ou juste pour ne pas donner directement la documentation au public. Tous le code qui sera créé avec le programme NDA sortira sous GPL pour être inclus dans le tronc principal du noyau, rien ne sera brouiller.
# Ce journal pourrait être une news

Posté par chl (site web personnel) le 17 février 2007 à 21:06. Évalué à 3.

Tout est dans le titre
# Code==spec.

Posté par Grumbl le 18 février 2007 à 10:53. Évalué à -1.

Un bon code source écrit proprement est souvent plus lisible et plus informatif qu'une spécification.

Donc, si on peut avoir le code source rédigé par un vrai bon sans la spécif, on ne perd vraiment pas grand chose.
- [^] # Re: Code==spec.
  
  Posté par Meku (site web personnel) le 18 février 2007 à 12:49. Évalué à 4.
  
  Encore faut-il que le code soit complet, absolument correct par rapport à la spec (modulo les erreurs provenant de la spec bien sûr), et implémentant absolument tout ce qui est écrit dedans, y compris les erreurs, cas extrêmes ou effets de bords possibles dans telle ou telle situation, sous forme de commentaire ou de code...
  
  Parce que ce serait con d'être bloqué sur un bug bizarroïde lors du port du driver sur une architecture ou un autre système, alors que dans la spec il y avait quelque part une petite ligne qui pouvait aider le programmeur à torcher ce bug rapidement.
  
  (Enfin c'est valable dans le cas où la spec est à peu près bien, parce que des fois...)
  - [^] # Re: Code==spec.
    
    Posté par Grumbl le 19 février 2007 à 08:09. Évalué à 2.
    
    Voilà : généralement, les specs., c'est des docs pourries que les managers pressés veulent voir sorties pour le moins cher possible et qui n'insistent surtout pas trop sur les faiblesses du design.
    
    Le code au moins, ça ne ment pas.

Suivre le flux des commentaires

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