[Diritto] reverse engineering e open source

[Simo Sorce]

Lo mando solo a te, dimmi se è meglio evitare di spedirlo o se posso
andare.

Simo.



Premessa: sarò duro.

NON mi interessa portare avanti questa discussione sterile visto che si
sta parlando con un sordo che non vuol sentire.

Fondamentalmente Carmine ti manca un requisito base per disquisire di
queste cose: non hai la più pallida idea di cosa sia il software ne
tanto meno di come si produce. Fra l'altro da quel che leggo, non hai
neanche le idee ben chiare sulla differenza che intercorre tra leggi
della fisica (e la loro scoperta), creazioni dell'ingegno e invenzioni.

No, scrivere due righe di un file batch non conta, come il saper
cambiare una gomma non conta come esperienza nel campo di costruzione
delle automobili.

Mancando le basi non vale poi tanto la pena discutere e annoiare la
lista, quindi se la discussione vi ha già annoiato fate un piacere a voi
stessi e fate un bel C-D.

Vorrei aggiungere che ho sempre inteso il tutto riferendomi al tema
principale del problema dell'interoperabilità e della LdA.

Detto questo mi dedico a rispondere ad alcune inesattezze dovute alle
premesse.


Carmine Malice wrote:
> Appunto.
> Ma possiamo seriamente assumere che uno riesca a reimplementare
> (p.e.) il filesystem NTFS (tutte le sue funzionalita', modalita',
> usi ecc.) scrivendo *del tutto autonomamente* un codice
> completamente diverso?

La risposta semplice ai fini della tutela giuridica è: si!

Carmine Malice wrote: 
> 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.

No, perchè del metodo usato da MS per creare le informazioni non mi
frega un fico secco, mi interessa solo il risultato che ottengo con un
procedimento differente (anche se ovviamente analogo).

> 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).
Certo ma l'esempio non c'entra assolutamente nulla. Le vibrazioni
dell'aere come dici tu sono l'equivalente del codice oggetto di un
determinato sorgente se vuoi fare un bruttissimo paragone (molto poco
calzante).

Ma NON sono il codice oggetto di un qualsiasi sorgente ma di un ben
determinato sorgente.

Se volessi continuare a mantenere questo infelice paragone potremmo dire
che la musica produce una reazione in chi ascolta, ebbene se io analizzo
la reazione e produco un'altro brano musicale che produce la stessa
reazione, ho fatto reverse engeneering e ho riprodotto il risultato, ma
con una sonata _differente_ che ha a sua volta uno spartito _differente_
e non in relazione col primo.
Ora ripeto questo esempio è infelice, il software _molto_ più complesso
della musica comune per cui è molto più semplice fare cose che hanno
risultati identici (l'emozione non la sonata, teniamolo bene in mente)
con istruzioni differenti rispetto alla musica.

> >>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.
> 
> Eccola:
> 
> "Art. 64-quater
[snip]

mi piace molto vedrti cercare di fare il professorino, ma questo
articolo non afferma in nessun punto che puoi interoperare *solo* con
quel programma, tanto più che parla specificamente di _modificare_ il
codice originale. Nel caso di modifica al codice originale del programma
con cui vogliamo interoperare, è chiaro che solo chi ha la licenza di
quel programma può usarlo, perchè comunque si sta creando un'opera
derivata e tutti i diritti d'autore sono in capo all'autore originale
(tranne per la parte modificata).
Detto questo però il programma terzo con cui si va ad interoperare
può essere un programma qualsiasi prodotto in qualunque numero e foggia
e distribuito a volontà. Infatti la LdA pone obblighi *solo* sul
programma oggetto di privativa, non può certo estendere limitazioni a
programmi terzi di cui il licenziatario potrebbe non avere alcun
diritto, e anzi sui quali il licenziatario potrebbe effettuare una
modifica proprio per rendere ancora migliore l'interoperabilità tra i
due, finendo per modificare ben 2 programmi per farli parlare meglio tra
loro, sempre restando nell'ambito del 64quater.

> 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".

Continui a spararle grosse ... le parti necessarie a conseguire
l'interoperabilità sono quelle strettamente indispensabili ma anche
strettamente necessarie, quindi ho tutto quel che serve per conseguire
l'interoperabilità e non mi serve un capello di più.


> 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.

No, devi prima capire di cosa stai parlando e poi cercare di affrontare
un argomento. I dati, in questi casi, sono le informazioni _elaborate_
dal programma, non sono il programma in nessuna forma, ne codice oggetto
ne sorgente.

> I dati informatici sono codice sorgente e binario, i dati musicali
> sono spartito e vibrazioni (sonata).

E io sono babbo natale, e questa mail non esiste perchè non è il dato
trasformato dal mio programma di posta.


> Chiaro: non il "goto" in se', ma una determinata stringa (scusatemi,
> ma le mie abilita' di programmatore si fermano ai file batch del DOS
> ed ai rudimenti del bash scripting).
> Il "goto" in se' e' sotto il diritto d'autore ("proprieta'
> intelletuale", anche se cio' vi fa inorridire: ma e' un concetto
> giuridico di antica dignita') del creatore del tale linguaggio di
> programmazione.

Siamo alla fiera delle castronerie giuridiche e informatiche.

1. il goto non è tutelabile dal diritto d'autore quanto non lo sono la
nota Do o la parola ciao.
2. è abbastanza usuale considerare che una singola riga di codice non
sia materia sufficiente per giungere in capo al diritto d'autore in
quanto manca in sostanza di creatività e originalità. Si può
empiricamente dire che in media sono necessarie almeno 15 righe di
codice per arrivare a determinare una funzionalità sufficiente ad
ascrivergli carattere di creatività e originalità e quindi far ricadere
il codice summenzionato sotto il diritto d'autore.

Detto in soldoni il programma:

main() {
goto end;
end:
}

NON è tutelabile perchè manca di creatività e originalità.


> Il dottrinario, l'avvocato, il giudice - come dici tu - HANNO il caso
> appena gli atti gli arrivano sulla scrivania, ma il parere, l'arringa,
> la sentenza arrivano anche dopo mesi: perche' ci vuole molto studio.
> Non pretenderai che io adesso qui per posta elettronica arrivi ad
> avere perfettamente delineato e sviscerato il fenomeno cui ha dato
> luogo Bud P. Bruegger oppure il tuo arido caso di scuola (ammesso che
> sia).

Se non hai capito il caso taci allora, questa lista non è un luogo per
tentare di fare esercizio di arte oratoria.

Il sig. Bud P. Bruegger ha chiesto un consiglio se non sai che pesci
prendere almeno evita di sparare a zero su cose che dimostri di non
conoscere e che non lo aiutano in alcun modo.


> Vi sfugge che il fondamento delle normative su diritto d'autore e su 
> invenzioni brevettabili e' lo stesso: tutela del lavoro creativo.

No, il diritto d'autore tutela le creazioni, il brevetto industriale le
invenzioni. Sono due cose _molto_ diverse.

Ne il diritto d'autore, ne il brevetto industriale tutelano le leggi
fisiche, i procedimenti logici o gli algoritmi matematici.
Ovvero le idee non sono tutelate, ne è tutelata la loro espressione
(diritto d'autore) o la loro traduzione in processi industriali che
danno luogo sostanzialmente a nuovi insegnamenti sull'uso delle forze
della natura (brevetto industriale). D'altra parte la tutela delle idee
in se sarebbe un mostrogiuridico inaffrontabile, visto che le idee non
nascono spontanemanete come i funghi ma sono _necessariamente_ frutto di
elaborazione di idee precedenti. In sostanza non esiste idea "originale"
nel senso stretto del termine, ma esistono solo idee "derivate" per cui
la tutela non avrebbe molto senso perchè non sarebbe facilmente
individuabile ne l'autore nei i coautori anche perchè le idee sono
frutto dei tempi nel 99% dei casi e non delle singole menti e infatti,
nel software è evidente, le stesse idee nascono contemporaneamente in
più teste. È la capacità di realizzarle la parte difficile (e che quindi
può aver senso "tutelare") a cui solo pochi arrivano.


Il problema _GROSSO_ di molti giusristi è che NON conoscono che
superficialmente la materia e non riescono quindi a comprendere quando
si trovano davanti ad una cosa piuttosto che ad un'altra.
Per dare un esempio, ho sentito ieri ad un workshop, un avvocato esperto
in diritto industriale di cui non faccio il nome, che ha ammesso
candidamente di non sapere bene cosa fosse il software "opensource" (e
si che è da un po' di anni ormai che se ne parla nella nostra
"industria" ma si è subito detta convinta che non ci siano conflitti tra
questo tipo di software e i brevetti. Fortunatamente subito dopo
un'altro giurista che invece ha avuto la pazienza di capire di cosa
parla prima di aprire bocca ha escluso qualsiasi tipo di compatibilità
tra la tutela brevettuale del software e il software libero.

Questo diviene un problema sociale allorquando essi influenzano la
creazione di norme giuridiche assurde che non si reggono in piedi di
fronte alla materia che vogliono regolare. Purtroppo come molte altre
classi di professionisti, i giuristi tendono a pensarsi come ad una deus
ex machina che detiene in mano la verità assoulta e che gli altri siano
dei miseri imbecilli al loro confronto. Al quale non importa dei
dettagli che non siano quella della retorica giudiziaria e che fa e
disfa ragionamenti, logici sul piano formale, ma sostanzialmente fallaci
sul piano sostanziale.

Non sono tutti così e ne conosco parecchi, anche su questa lista, che
non solo conoscono la materia sottostante le norme che adoperano ma che
hanno anche l'umiltà di consultarsi ed ascoltare le persone esperte
della materia in modo da comprendere più a fondo il fenomeno sul quale
sono chiamati a dare poi opinione nel campo giuridico.






-- 
Simo Sorce - simo.sorce at xsec.it
Xsec s.r.l. - http://www.xsec.it
via Garofalo, 39 - 20133 - Milano
mobile: +39 329 328 7702
tel. +39 02 2953 4143 - fax: +39 02 700 442 399