[Diritto] reverse engineering e open source

Carmine Malice instarvega_capitanlug at yahoo.it
Fri Mar 26 11:07:15 CET 2004


Leonardo Boselli ha scritto:

> Il 26 Mar 2004 alle 10:07 Carmine Malice immise in rete
> 
>>>>>On Thu, 2004-03-25 at 13:16, Bud P. Bruegger wrote:
>>>>>
>>>>>>Non e' un reverse engineering l'intercettazione di operazioni?
>>>>>
>>>>>Come sempre si parla di reverse engineering con più accezioni, ma
>>>>>dal testo di legge mi sembra di capire che il legislatore intenda
>>>>>che il reverse engineering sia la decompilazione di codice oggetto
>>>>>con la conseguente trasformazione in codice sorgente leggibile
>>>>>all'uomo.
> 
> 
> forse si ... 
> 
> 
>>>>>D'altra parte le operazioni via rete o le chiamate al sistema sono
>>>>>comunicazione "pubblica" e non vedo quindi come si possa impedire
>>>>>l'uso di informazioni già pubbliche ovvero che non sono
>>>>>circoscritte all'interno del programma in oggetto.
>>>>
>>>>In un contesto dove l'interazione a livello macchina e' distinta
>>>>dall'interazione a livello umano *mediata* dalla (interazione a
>>>>livello) macchina la definizione "pubblicita'" non appare tanto
>>>>scontata.
> 
> 
> Occorre vedere anche a che livello si mnette l'"uomo" nessuno mi 
> impedisce di, anziché vedermi la presentazione sullo schermo o il foglio 
> stampato, di guardarmi i pacchetti che il sistema manda ai driver di 
> visualizzazione.  
> 

Sai, dipende: dipende dalla licenza...
I dischi con la colonna sonora di "Guerre Stellari" sono diffusissimi, 
eppure gli spartiti di John Williams sono introvabili: ovvero 
acquistabili pagando profumatamente...

> 
>>>Non ho capito cosa intendi.
>>
>>Intendo dire che se con 'le operazioni via rete o le chiamate al
>>sistema sono comunicazione "pubblica"' vuoi illustrare che e' facile
>>intercettare ("sniffare"?) le comunicazioni cio' non implica che sia
>>pubblicizzato il metodo ingegnosamente "trovato" per dare luogo a
>>quelle comunicazioni. E' come per la musica: le vibrazioni dell'aere
>>cui da' luogo una sonata sono agevolmente intercettabili ed
>>interpretabili ma la relativa codificazione su spartito e' tutelata
>>dal diritto d'autore (sempre forza Albano Carrisi).
> 
> 
> L'esempio secondo me NON è felice.

Invece lo trovo molto calzante: il codice sorgente sta al programma 
compilato come lo spartito sta alla sonata.

> il modo per trovare un modo di fare 
> quelle vibrazione (ossia costruire uno strumento) è sconnesso dalla 
> propietà intellettuale sul pezzo musicale.

Il punto non e' costruire un produttore di vibrazioni: e' ricostruire 
l'esatta strutturazione delle vibrazioni (lunghezza ed ampiezza d'onda, 
frequenza ecc. ecc.).

> Una cosa sono l'HW, il FW e SW e un altra cosa sono i DATI.
> 

No, invece: dati sono sia le informazioni rese intellegibili agli umani 
sia le informazioni nel senso di istruzioni informatiche, poi bisogna 
intendersi su quali stiamo trattando.
I dati informatici sono codice sorgente e binario, i dati musicali sono 
spartito e vibrazioni (sonata).
(Scusami: HW=hardware, SW=software, FW=???)

> 
>>>Per me è pubblico tutto ciò che transita sulla rete (o nel mio
>>>sistema operativo, o...), poco importa se per vedere ciò che
>>>transita mi servono programmi ad hoc o se abitualmente non si
>>>guarda.
> 
> 
> Concordo, con l'avvertenza importante che "pubblica" va inteso "esterno 
> al programma" . Così come una variabile public su una libreria, che fa 
> parte della interfaccia.
> E quindi il 64q ne consente la pubblicazione non in quanto "bene 
> pubblico" ma in quanto essenziale per la interoperabilità.
>  
> 
>>>>Il problema e': pare sia stabilita l'interoperabilita' *solo* fra il
>>>>programma licenziato ed il *singolo* programma creato personalmente
>>>>dai *singoli* licenziatari, o q.c. di analogo.
>>>
>>>Solo? In che senso? E dove sta scritto?
>>>Io negli articoli di cui stiamo parlando non ho trovato questa
>>>limitazione.
> 
> 
> neanche io ... 
>  
> 
>>Eccola:
>>
>>"Art. 64-quater (...)
>>1. L'autorizzazione del titolare dei diritti non é richiesta qualora
>>la riproduzione del codice del programma di elaboratore e la
>>traduzione della sua forma ai sensi dell'art. 64-bis, lettere a) e b),
>>compiute al fine di modificare la forma del codice, siano
>>indispensabili per ottenere le informazioni necessarie <<<per conseguire
>>l'interoperabilità, con altri programmi, di un programma per
>>elaboratore creato autonomamente>>> purché siano soddisfatte le seguenti
>>condizioni: (...)
>>c) le predette attività siano limitate alle parti del programma originale
>>necessarie per conseguire l'interoperabilità.
>>2. Le disposizioni di
>>cui al comma 1 non consentono che le informazioni ottenute in virtù
>>della loro applicazione: a) siano utilizzate a fini diversi dal
>>conseguimento dell'interoperabilità del programma creato
>>autonomamente; b) siano comunicate a terzi, fatta salva la necessità
>>di consentire l'interoperabilità del programma creato autonomamente;
>>c) siano utilizzate per lo sviluppo, la produzione o la
>>commercializzazione di un programma per elaboratore sostanzialmente
>>simile nella sua forma espressiva, o per ogni altra attività che violi
>>il diritto di autore. [...]"
> 
>  
> 
>>Effettivamente laddove si dice "Le disposizioni [...] non consentono
>>che le informazioni [...] siano comunicate a terzi, fatta salva la
>>necessità di consentire l'interoperabilità del programma creato
>>autonomamente" parrebbe rinvenirsi una possibilita' di applicare la
>>GPL (ecc. ecc.) *solo nel caso in cui* l'interoperabilita' fosse da
>>concepirsi fra il programma creato autonomamente e terzi programmi (in
>>pratica, la catena [programma licenziato]<-[programma creato
>>autonomamente]<-[terzi programmi]), mentre tale possibilita' sarebbe
>>esclusa qualora l'interoperabilita' presa in considerazione fosse solo
>>quella fra programma licenziato e programma creato autonomamente (in
>>pratica, la catena [programma licenziato]<-[programma creato
>>autonomamente]<-[terzi *utenti*]); inoltre precedentemente si dice "le
>>predette attività siano limitate alle parti del programma originale
>>necessarie per conseguire l'interoperabilità" che sembra moncare
>>notevolmente l'operazione detta in gergo "reverse engennering".
> 
> 
> Quello che dici non è chiaro, o meglio interpreta "ultra legis" :
> la legge dice al comma 2b che è leciso se finalizzato a consentire la 
> interoperabilità del proprio programma. Non specifica se col programma 
> originario o con terzi programmi.

Sta all'interpretazione: e chi piu' di un giudice...

> Se la interpretazione fosse restrittiva al secondo caso non potrebbe 
> essere impedito che la interoperabilità si possa riferire anche al 
> programma originario, visto che le specifiche di partenza sono le stesse, 
> se invece fosse solo al primo allora qualunque terzo potrebbe app;licare 
> la stessa norma sul nostro programma, e quindi ransitivamente ottenere 
> la interoperabilità sia col primo che col secondo.

Non sono sicuro di poter applicare proprieta' transitive (proprieta' 
transitive: dico bene?).

> Da cui si dimostra che 
> la interoperabilità va intesa in senso generale.
> 
> Parlando del caso particolre, ossia del programma di bud, che dovrebbe 
> essere inteso come un driver di periferica la cosa mi pare ancora più 
> tranquilla, visto che sembra trattarsi di un caso diverso:
> le api sono pubbliche, ma per i parametri ha dovuto andare a razzolare.

Ho affrontato un po' quest'aspetto, poi bisogna curarsi dei particolari.

> Nel caso in questione i parametri sono relativi a quella particolare 
> applicazione, in termini informatici "privati", ma di fatto fanno parte delle 
> chiavi per l'accesso ai dati, dati che sono di proprietà dell'utente della 
> smart-card (o comunque questi ha diritto all'uso di questi), e quindi 
> palesemente indispensabili per la interoperabilità.
> 
> Applicando estensivamente un'altra norma si potrebbe dire che non puoi 
> pubblicare questi dati, se non per coloro che hanno titolo ad usarli, d'altra 
> parte coloro che non hanno titolo ad usarli (non avendo smart card) non 
> sanno che farsene, essendo gli indirizzi dati "privati" a quella periferica.
> 
> --
> Leonardo Boselli
> Nucleo Informatico e Telematico del Dipartimento Ingegneria Civile
> Universita` di Firenze , V. S. Marta 3 - I-50139 Firenze
> tel +39 0554796431 cell +39 3488605348 fax +39 055495333
> http://www.dicea.unifi.it/~leo
> 



More information about the Diritto mailing list