12Fermer14
ExtendeDLe 17/05/2007 à 20:37
Bonne nouvelle, apparemment ma clé USB répond correctement aux commandes SCSI, donc les transferts de type Bulk fonctionnent aujourd'hui.

Mon problème est maintenant une casse-tête de licence : les drivers USB de FreeBSD (dont mass storage que je porte en premier) reposent sur l'API usbdi que je dois implémenter (une 20aine de fonctions et quelques structures de données). Malheureusement le sous-système USB de FreeBSD est sous licence BSD 4 clauses, notamment incompatible avec la GPL.
Mon idée était d'avoir la couche basse (ucore) dans une bibliothèque séparée sous une licence lâche (genre BSD 2 clauses), de créer une lib spécifique d'adaptation implémentant usbdi (nécessairement sous BSD 4 clauses), et d'avoir umass dans une 3ème lib appelant la 2ème (elle aussi sous BSD 4 clauses). Comme ça si jamais des drivers GPL (genre Linux) étaient amenés à être portés, on créerait une lib équivalente à usbdi implémentant l'interface analogue de Linux, appelée par les drivers portés Linux. Tant que les libs sous GPL et les libs sous BSD 4 clauses ne sont pas liés dynamiquement en même temps la GPL n'est pas violée.

Le problème est la création de cette lib d'adaptation d'API usbdi : si la lib de couche basse ucore expose une API publique de fonctions, structures et constantes proches de usbdi de FreeBSD (mais par exemple sous des noms différents, et éventuellement quelques différences pour être compatible avec l'API Linux), et si usbdi fait simplement des casts des structures et de la délégation d'appel, est-ce que ça reste légal ou trop à la limite ?
Une autre solution radicale est de tout couvrir en BSD 4 clauses et s'interdir le portage de drivers GPL.

Noter que tous ces problèmes sont une fois de plus dû à l'aspect viral de la GPL.

Ca n'a rien à voir mais je viens de voir qu'il y avait plusieurs projets de nouveaux drivers prévus pour la 84+, notamment un driver d'imprimante qui commence à marcher.