I puristi opensource uccideranno Linux

[superbubba]

Si, è quello che penso, dopo aver letto lo sfogo dello sviluppatore del modulo per le webcam Philips.

Il problema? Una parte di codice binary-only che serve al modulo per far funzionare la webcam alla massima risluzione.

Adesso si è rotto le scatole (giustamente) e così faranno molti altri.

http://www.smcc.demon.nl/webcam/

[ilsensine]

Hai letto anche la storia sulle varie ml?
Mi dispiace per questo avvenimento, ma ci sono delle motivazioni tecnico/legali che hanno forzato la scelta di Greg KH.

[matzuk]

Purtroppo ha ragione (poi non so se ci sono questioni legali dietro) ma il ragionamento regge.
L'ideologia che c'è dietro a Linux spesso rende meno chiara la situazione (vedi fork degli stessi progetti, progetti molto simili o il fatto stesso che le software house non vogliano sviluppare molto per linux)

[ilsensine]

Originariamente inviato da matzuk
Purtroppo ha ragione (poi non so se ci sono questioni legali dietro) ma il ragionamento regge.
L'ideologia che c'è dietro a Linux spesso rende meno chiara la situazione

Il contrario, è stata proprio la definizione _chiara_ dei punti che un driver non libero deve soddisfare che ha condotto a questa scelta.

vedi fork degli stessi progetti, progetti molto simili

Il fork dei progetti non ha a che vedere direttamente con questo caso

o il fatto stesso che le software house non vogliano sviluppare molto per linux

Non mischiare sw house in generale con i produttori di driver. Qui stiamo parlando di kernel.
Alcuni produttori (nvidia & co) hanno preso atto di come debba essere sviluppato un driver closed per linux, e non hanno alcun problema.

[kibuzo]

mah

[elypepe]

Originariamente inviato da kibuzo
mah

non sono d'accordo!!

Slackware Gnu-Linux openSource ilsensine

[maxithron]

L'arrabbiatura invece io non la capisco dato che la linea di condotta dei mantainer è perfettamente coerente con il modo di pensare opensource.

Si tratta semplicemente di aver rifiutato di mettere una funzione come la definisce l'autore "partial" closed sourceness.

Sul resto delle ragioni dell'autore, personalmente ritengo che si debbano sempre valutare le "due campane" per avere un'idea più chiara.

Ma non so perchè ci sia rimasto male, se non è riuscito a far introdurre una parte "closed" all'interno del kernel. D'altronde, basterebbe poi cominciare col metterne una, e poi tutti quelli che sviluppano drivers, potrebbero desiderare la stessa cosa, minacciando poi di sospendere sempre il tutto.

Tecnicamente purtroppo non sono in grado di capire perchè detta funzione debba rimanere per forza closed, ma credo che comunque un danno, indirettamente, anzichè linux, lo possa avere direttamente la philips perchè gli utenti linux non acquisteranno questo prodotto se non più supportato.

[elypepe]

Originariamente inviato da maxithron
ma credo che comunque un danno, indirettamente, anzichè linux, lo possa avere direttamente la philips perchè gli utenti linux non acquisteranno questo prodotto se non più supportato.

sono d'accordo, di solito cerco prodotti compatibili con linux, caso contrario non li acquisto.

[AnonimoVeneziano]

Originariamente inviato da maxithron
L'arrabbiatura invece io non la capisco dato che la linea di condotta dei mantainer è perfettamente coerente con il modo di pensare opensource.

Si tratta semplicemente di aver rifiutato di mettere una funzione come la definisce l'autore "partial" closed sourceness.

Sul resto delle ragioni dell'autore, personalmente ritengo che si debbano sempre valutare le "due campane" per avere un'idea più chiara.

Ma non so perchè ci sia rimasto male, se non è riuscito a far introdurre una parte "closed" all'interno del kernel. D'altronde, basterebbe poi cominciare col metterne una, e poi tutti quelli che sviluppano drivers, potrebbero desiderare la stessa cosa, minacciando poi di sospendere sempre il tutto.

Tecnicamente purtroppo non sono in grado di capire perchè detta funzione debba rimanere per forza closed, ma credo che comunque un danno, indirettamente, anzichè linux, lo possa avere direttamente la philips perchè gli utenti linux non acquisteranno questo prodotto se non più supportato.

Non è successo proprio così

Leggi meglio

Ciao

[maxithron]

Originariamente inviato da AnonimoVeneziano
Non è successo proprio così

Leggi meglio

Ciao

Ciao Anonimo ben tornato!!

incollo un attimo sta cosa:

"As most of you probably know, the driver consists of two parts, PWC which is available as source and part of the kernel, and PWCX, the binary-only decompressor part. PWC itself works, but with limitations in framerate and resolution; to get the full benfits of the cam, you must use PWCX.

However, in order for the PWCX module to function, it needs to register itself with the PWC module; for this purpose, PWC exports a function outside of the kernel, a so-called hook. And this is where it's all about. The kernel maintainers simply do not want to allow any kind of hook or function or mechanism, specifically written to make it possible to load a binary-only module. So this week Greg Kroah, the USB maintainer, decided to remove that hook from PWC, making it impossible to load PWCX on a standard kernel; you'd have to patch your kernel first, and only then would it start working again."

In grassetto ho evidenziato quello che credo sia il punto centrale della discussione, ma c'è ne anche un altro:

"So there. This has not been a rash, or one-day decision. Since the inception of PWC it has been an uphill battle because of the (partial) closed-sourceness. There's nothing I can do about that; I'm bound by an NDA, and despite that I've always managed, or managed or worked around it. But this is the last straw. I've been maintaning this driver for the past 5 years or so, and appearantly it has all been in vain. That hurts."

In merito all'alternativa che invece propone, cioè un add-on module, dice che è stata respinta ma non mi sembra che indichi la motivazione.

[AnonimoVeneziano]

Beh, da quanto ho capito io questo aveva il suo bel driver dentro il kernel .

Sto driver era un driver Open Source, ma aveva una funzione che poteva caricare un modulo esterno binario . Tecnicamente questo non è una violazione dell' Open Source , dato che tutto il codice nel kernel è in sorgente sotto GPL.

Un bel giorno i maintainer hanno deciso di rimuovere il driver che era già dentro da un po' (almeno, questo è quello che ho capito) , e il tipo si è incavolato .

Comunque sono sicuro che ci saranno stati anche altri motivi , che noi non sappiamo come ha detto ilsensine

Ciao max e grazie per il bentornato

Ciao

[VICIUS]

Capisco che vedersi fermato il lavoro di anni cosi possa essere frustrante pero ha avuto, secondo me, una reazione sagerata cancellando tutto il sito, bugtrack e mailing lists. In questo modo se qualcuno avesso voluto continuare il suo lavoro magari trovando una soluzione al problema avrebbe pottuto continuare da dove si era fermato lui.

ciao

[12pippopluto34]

AFAIK il kernel e' sotto GPL per cui, per la nota proprieta' ''virale'' della stessa, anche i driver distribuiti coi sorgenti di Linux devono essere GPL.

Invece il tizio aveva un pezzo di driver, castrato, dentro il kernel e l'altro invece, che permette il pieno utilizzo della periferica in questione, closed.

Cosi' su due piedi mi suona un po' come l'inculata di roba tipo shareware/trialware: prima ti ci faccio fare la bocca, poi pero' paghi e se ti serve una mano per il futuro prega che ti aiuti, altrimenti t'attacchi e ti compri una periferica nuova.

Ma soprattutto credo che il problema sia proprio nella licenza del kernel che, non essendo soddisfatta dai requisiti del driver suddetto, non ne puo' permettere la ridistribuibilita' assieme ai sorgenti, quindi l'integrazione nelle distro.

Un po' come avviene con i driver 3D.

O sbaglio (quasi sicuramente)?

[ThePapri]

Penso che la politica della philips sia ostruzionistica nei confronti del software libero. Un po' di tempo fa avevano pubblicato nelle FAQ di un loro masterizzatore che non era compatibile con sistemi GNU/Linux e che funzionava solo sotto windows.
Ho pubblicato su newsforge il link alla FAQ e dopo due giorni è stata tolta perché penso gli siano arrivate qualche centinaia o migliaia di mail di protesta (infatti quel masterizzatore funziona perfettamente sotto GNU/Linux).

Però non ho capito se la philips fa parte di quei produttori che si sono accordati con microsoft o fa parte di quelli che non vogliono pubblicare o rendere pubbliche le specifiche dei propri prodotti hardware per paura che qualche concorrente ne aprofitti (quando un concorrente si può comprare il pezzo hardware e smontarlo per vedere come è fatto!)

[NeSs1dorma]

ma che sfiga!
Ho appena preso una Logitech Quickcam Pro 4000 proprio perchè avevo letto che questo driver per le Philips la supportava perfettamente!!
Oggi sono andato per scaricarlo.. e ho letto questo... non è piu reperibile da nessuna parte? ma porca puzzola..
E adesso? come la uso questa webcam sotto le mie Deb-Mdk-Suse?
chi mi da qualche idea?
thanks

[ilsensine]

Credo che vada fatta un pò di chiarezza sull'accaduto.

Il kernel e la GPL
Il solo codice ammesso nel kernel deve essere licenziato sotto GPL v.2. Punto. Nessuna altra licenza è ammessa; licenze multiple (ad es. GPL/BSD) sono ammesse.
L'utilizzo della GPL pura, in teoria, rende la creazione di driver proprietari impossibile. In realtà non è proprio così: i driver closed source, rari in passato e purtroppo sempre più frequenti, sono tollerati purché soddisfino certi requisiti.
Fino a un pò di tempo fa non c'erano regole chiare sui driver closed source; la loro proliferazione ha reso necessario definire dei paletti.

Le regole per i driver closed source
Un driver closed source è tollerato se soddisfa i seguenti requisiti:
1) Deve essere chiaro che non è basato dal kernel linux, o che include una qualsiasi tecnica del kernel linux.
Il driver nvidia ad esempio soddisfa questo punto, in quanto è basato sul driver di windows, con del glue code per l'adattamento al kernel linux.
2) Nessuna parte del kernel deve essere presente per i soli ed esclusivi comodi di driver closed source.
Questo include anche le tecnologie utilizzate nel kernel: ad es. quando si è deciso di passare allo stack 4k, mentre alcuni "nemici" dei cosiddetti "puristi dell'opensource" si lamentavano indignati di non poter più usare il driver nvidia, la nvidia - che ha un rispetto degli sviluppatori linux superiore alle aspettative di molti - ha silenziosamente adattato il proprio driver alla nuova realtà, senza lamentarsi con nessuno.
Questo include anche le tecniche per aggirare alcune limitazioni ai driver closed source presenti nel kernel (i driver non-gpl non possono usare alcune funzioni del kernel, gli è proibito dal loader dei moduli).
3) Quando è presente in memoria un driver closed source, l'utente deve essere informato che il proprio kernel è "tainted" (minacciato).
I driver linuxant violavano in passato questa regola. Sono stati pubblicamente smascherati, e non ci hanno fatto una bella figura.
Faccio notare che anche un driver open source può "minacciare" il kernel, se compie determinate operazioni. I driver closed source lo "minacciano" per definizione, in quanto nessuno può escludere che compiano operazioni pericolose.

Il driver pwc
Per poter utilizzare le webcam ad alte risoluzioni, è necessario far comprimere alla webcam le immagini, e decomprimerle (640x480 a parecchi fps non ci passano nel bus usb 1.1). Alla Philips non hanno voluto divulgare il loro superbo metodo di compressione (che sembra essere null'altro che un rozzo jpeg basato su dct 4x4). Lo sviluppatore del driver pwc ha inserito le routine di decompressione nel modulo closed source pwcx; ha creato quindi nel driver pwc delle funzioni che il driver pwcx può "utilizzare" per notificare la propria presenza, e per interfacciarsi con esso (un "hook", come viene chiamato). Il driver pwc viola quindi la regola 2) dell'elenco precedente. Punto.
Il driver pwc senza il driver pwcx lo si può usare, a risoluzioni non eccessive e a frame rate limitati. Io stesso l'ho usato in ambito lavorativo; per questo lo conosco bene, me lo sono letto tutto e sapevo degli hook.

Greg KH
Quando Greg si è accorto di questa violazione, è stato _costretto_ a rimuovere l'hook. Nemosoft (autore di pwc) ha reagito in maniera impulsiva e infantile, chiedendo la rimozione in toto del modulo dal kernel. Quello che avrebbe dovuto fare, invece, era prendere atto dell' "errore tecnico": accettare nel kernel un driver pwc senza hook, e distribuire _esternamente_al_kernel_ ciò che voleva (un driver pwc con hook, oppure un driver come ad es. quelli nvidia, con parte closed source + parte di interfaccia). Le soluzioni di certo non mancavano.
Greg KH ha una grossa colpa: non essersi accorto prima della violazione effettuata nel modulo pwc.

...e in futuro?
Mi sembra chiaro, da quello che leggo sulla lkml, che ci sarà un altro mantainer e un driver pwc senza hook. Probabilmente verrà mantenuto anche un driver esterno, comprendente anche le funzioni del pwcx.
La cosa migliore sarebbe spostare la parte closed source (una semplice decompressione) in user space: Nemosoft ha detto che aveva intenzione di fare una cosa simile, e ciò rende ancora più assurdo il suo comportamento puerile dopo la rimozione degli hook.

[linux_goblin]

sono fondamentalmente d'accordo con ilsensine - anche io sono uno sfortunato possessore di webcam philips e usandola con il solo pwc ha una qualità veramente pessima (non paragonabile al funzionamento con altri sistemi operativi proprietari)

chi è da incolpare (a parer mio) è la philips perchè doveva fare il driver per linux (e non nascondersi dietro ad un volenteroso programmatore come Nemosoft - che è libero di comportarsi come vuole)

ciao,
Marco - Goblin

[peppedx]

Sec me solo è un pò un circolo vizioso...ma per ottenere il supporto dai produttori di hardware dobbiamo impegnarci a far diffondere linux...in questo hanno un ruolo importantissimo quelli che stanno nelle scuole prof./tecnici di laboratorio e nelle università! Adesso mi son potuto avvicinare al linux solo quando l'ho potuto coniugare alla mia attività, dio solo sa quanto mi sarebbe piaciuto quando andavo alla scuola sup avere un sistema aperto pieno di strumenti di sviluppo e sorgenti (certo non rimpiango il turbo pascal ! )

[Ziosilvio]

Originariamente inviato da ilsensine
Credo che vada fatta un pò di chiarezza sull'accaduto.

*** CUT ***

Ottimo intervento, ho solo un appunto da fare:

3) Quando è presente in memoria un driver closed source, l'utente deve essere informato che il proprio kernel è "tainted" (minacciato).

Non minacciato ma insudiciato o anche infettato.
(In inglese, "to taint" puo' significare "guastare", "inquinare", o "marchiare negativamente".)

[homero]

il kernel deve essere open source per forza di cose.... punto e basta....

come quando chi acquista l'hardware sceglie hardware compatibile con windows XP allo stesso modo chi sceglie linux si compri hardware compatibile linux punto e basta.

ho una scheda di acquisizione della philips che ha i driver soltanto per NT4 e non sono riuscito in alcun modo a farla funzionare sotto win2000 o XP, soluzione ho cambiato scheda di acquisizione invece di avere il dual boot come ho fatto nei primi tempi.

lo stesso con linux, codice proprietario nel kernel e' una contaminazione in alcun modo ingiustificata, le ragioni sono gia' state espresse mentre vorrei aggiungere che le schede nvidia sono pienamente supportate da xfree86 nelle loro funzioni base, al contrario le funzioni OpenGL di accellerazione3d sono svolte dai driver proprietari....che non sono integrati nel kernel....