[Diritto] Brevetto software e diritto d'autore

[Andrea Glorioso]

>>>>> "gf" =3D=3D Giustino Fumagalli <giustinofumagalli@yahoo.it> writes:

    gf> Forse scrivo con tono polemico..ma non c'=E8 polemica
    gf> assicuro... =20

Per quel che mi riguarda non rilevo polemica, non preoccuparti.

    gf> sul caso SCO ho gi=E0 risposto...

Non direi proprio, a  meno che la risposta non   sia "non lo so",  nel
qual caso siamo al punto di partenza e possiamo  depennare il caso SCO
vs IBM vs Linux vs  il resto del mondo (una  sorta di Royal Rumble per
chi ha di questi piacevoli ricordi) dagli esempi in oggetto.

    gf> Sbagliate a pensare che le interfaccie non centrino nulla con
    gf> i brevetti.. il vero business =E8 l=EC... con quel diritto blocchi
    gf> chiunque.. quale sistema o software vive oggid=EC stand-alone ?=20

Io lo so benissimo che  brevettare un'interfaccia e` fonte di guadagno
assicurato;  quello che   dico e` che   le   normative che  dovrebbero
tutelare contro la "proprietarizzazione"  delle interfacce  (posto che
intendiamo le stesse cose, io mi riferisco  alla API di un sistema) ci
sono gia`,  e sono le   normative anti-trust  e quelle che  permettono
l'interoperabilita`.

Nessun bisogno di tirare in ballo brevetti,  di matrice statunitense o
con una presunta "seconda via" europea, per tutelarci in questo senso.

Ma poi scusa, per tutelarci contro  la proprietarizzazione di qualcosa
usiamo un meccanismo proprietarizzante?

    gf> Ripeto Gli  algoritmi   NON   SONO   BREVETTABILI,   la  forma
    gf> brevettabile =E8 (o  almeno  dovrebbe essere nelle intenzioni)un
    gf> sistema (compiuto) basato  su nuovi algoritmi.. ma  non intesi
    gf> come codice, ma   come  meccanismo operativo.  =20

E la differenza qual e`?

Quand'e` che  un  meccanismo operativo  diventa  codice?   Qual  e` il
confine?

Se la  risposta   e` "non  lo  so", va  bene,  sono  domande piuttosto
difficili,  ma  allora prima   rispondiamo  a queste   domande e   poi
decidiamo di    permettere la brevettazione   di  questi   fantomatici
"meccanismi operativi".

    gf> Il problema =E8 distinguere tra algoritmo  di base e non, quindi
    gf>  non   brevettabile  o  potenzialmente  brevettabile...qui  il
    gf>  processo =E8 compito dell'ufficio  brevetti  capire se il nuovo
    gf>   trovato =E8   composto     o   se =E8  qualcosa di     elemenare
    gf> (atomico).. lavoro non facile..

Fammi  capire:  abbiamo un  ufficio brevetti che   ha accettato non so
quante domande  di  brevetto nonostante  in   Europa la materia  fosse
rigidamente vincolata, pero` ti aspetti che lo stesso ufficio brevetti
sia in grado  di distinguere tra "algoritmo  elementare" (o atomico) e
"algoritmo composto"?

E tutto questo  quando  nemmeno *noi*   (a  meno che qualcuno   non mi
illumini) che  lavoriamo nel settore siamo  stati o  siamo in grado di
dare un barlume di  giustificazione per classificare un algoritmo come
atomico o come composito?  E non mi riferisco solo  a questa lista, in
tutti gli altri forum di discussione non ho ancora trovato qualcuno in
grado di fornire una risposta a questa domanda.

Sono davvero  perplesso, e lo  dica senza  polemica.  O forse  mi  sta
sfuggendo qualcosa di fondamentale.

Comunque, per riassumere, le mie domande sono divenute tre:

1) Quali sono i 50/100 brevetti sul software che riguardano delle
"vere invenzioni"?

2) qual e` la differenza tra algoritmo "di base" (o atomico) e
algoritmo composto?

3)  qual e`   il  criterio  in  base al  quale   si  decide quando  un
"meccanismo operativo" diventa "codice" (e viceversa) ?

Con calma, quando puoi, rispondimi per piacere a queste domande, cosi`
mi chiarisco le idee.

ciao,

andrea
--
Love is blindness I don't want to see              andrea glorioso
Won't you wrap the night around me    =20
In a parked car in a crowded street              www.gnutemberg.org
You see your love made complete                 sama@perchetopi.org