[Diritto] FLA: una risposta ad Andrea Monti
Giovanni Biscuolo
diritto@softwarelibero.it
12 Apr 2003 15:22:21 +0200
--=-eVUjpCNH+43UclMxahXc
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
Ciao,
invio qui alcune considerazioni sulla risposta di Monti a Rossato.
Mi piacerebbe scriverle su Freego.it, ma non riesco a raggiungerlo da
diverse settimane e non capisco perch=E8.
Premetto che sono moderatamente ignorante in materia, ma quel poco che
so mi consente di dire che...
> Fiduciary License Agreement: la risposta di Andrea Monti
> inviato da [18]Davide Barbieri
> =20
> 9 apr 2003, ore 09:31 - letto 60 volte.
> =20
> Riceviamo da Andrea Monti, la sua risposta alla critiche riportate
> dall'[19]articolo di Andrea Rossato, che ovviamente pubblichiamo.
=20
[...]
> Ti ringrazio quindi, innanzi tutto, per lo stile adottato.
> Preliminarmente devo presumere che concordi su quanto non hai
> contestato. E cio=E8, per esempio, sulla discutibilit=E0 etica (ancora
> prima che sull'opportunit=E0 e sul valore giuridico) della scelta dell=
a
> giurisdizione tedesca e del foro di Amburgo ai fini della decisione di
> eventuali controversie.
Su questo ci sarebbe da discutere, ma non mi sembra affatto il punto pi=F9
importante della questione.
=20
> O sul curioso "glissare" sull'aspetto economico (perch=E9 gli eventual=
i
> introiti derivanti dal "merchandising" delle licenze non dovrebbero,
> almeno parzialmente essere restituiti al programmatore).
Introiti da "merchandising delle licenze"??? Cosa significa???
Se parliamo di commercio di Software Libero, chiunque pu=F2 vendere
Software Libero, e nessuno =E8 tenuto a "restituire" un bel nulla al
programmatore
Parliamo di "commercio di licenze" d'uso stile EULA di Microsoft?=20
Per contratto FSFE concede il software *solo* nei termini della GNU GPL
o della GNU LGPL. La GNU (L)GPL non si "vende".
Di che altro parliamo?
[...]
> =20
> 1 - sull'art.120 l.d.a.
Questo =E8 un punto fondamentale, su quale vale la pena soffermarsi e
cercare di sviscerarlo.
> Il FLA recita testualemente:
> =20
> > The rights and licences granted under this agreement by Beneficiary
> > shall also include future developments, future corrections of
> > errors or faults and other future modifications and
> > derivative works of the software that Beneficiary obtains copyright own=
ership
> > in.
L'art. 3 del FLA dice chiaramente che il "software that Beneficiary
obtains copyright in" =E8 quello indicato nel contratto o in un allegato
al contratto datato e firmato da entrambi i contraenti. Quindi il
software oggetto del contratto =E8 chiaramente identificato, non sono
"tutte le opere o categorie di opere che l'autore possa creare" che
l'art. 120 LdA cita.
Dove sta il problema: nei "derivative works"?
=C8 anche solo remotamente possibile poter definire come "categorie di
opere" i "derivative works"?
Mi pare di no.
Innanzi tutto i "derivative works" non sono opere originali, e questo
forse basterebbe ad escluderli dalla "categoria di opere".
Poi, l'autore ha il diritto esclusivo di modificare l'opera (art. 18 LdA) s=
econdo quanto previsto nell'art. 4 (tra cui le opere derivate).
Il trasferimento di questo diritto esclusivo potrebbe forse violare l'art. =
120 LdA?
Inoltre, essendo i diritti esclusivi fra loro indipendenti, debbono essere =
trasferiti in maniera indipendente; in altre parole credo sia *necessario* =
che il contratto di trasferimento dei diritti esclusivi preveda esplicitame=
nte il trasferimento anche di questo.
Ecco perch=E8 FLA =E8 cos=EC "precisino". ;-)
Dove sta il problema: nella parola "future"?
=C8 anche remotamente possibile poter definire come "opere future" quelle d=
erivanti dall'esercizio delle attivit=E0 citate dal FLA?
Non credo proprio.
La parola "future" =E8 associata a "developments, corrections or faults and=
modifications", tutte attivit=E0 che sono comprese nel diritto esclusivo d=
i cui all'art. 18 LdA, che sono poi le attivit=E0 elencate nell'art. 4.
Mi sembra ovvio che tali attivit=E0 si svolgono solitamente in un periodo s=
uccessivo alla creazione dell'opera originale, quindi nel futuro; ci=F2 com=
unque non pregiudica la facolt=E0 dell'autore di trasferire ad altri questo=
suo diritto esclusivo: =E8 forse questa violazione dell'art.120 LdA?
> come vedi, siamo in un caso palese di riserva di diritti su opera
> futura.
Io proprio non riesco a vedere il "caso palese", anzi...
Per "tagliare la testa al *topo*", l'FLA dice:
"However, identifiable portions of such modifications, that are not
derived from the computer program and that have to be regarded as
independent and original software, shall not be encompassed by the scope
of the rights and licences granted under this Agreement."
Escludendo quindi dal trasferimento dei diritti esclusivi le porzioni
dell'opera che non sono derivate dal programma originale e possono
essere considerate come opere originali.
Su quelle porzioni l'autore manterrebbe la titolarit=E0 di tutti i diritti
di sfruttamento economico dell opera.
> Quindi l'art.120 l.d.a =E8 validamente invocabile.
Mah?
> E in ogni
> caso, anche a voler accettare le tue premesse, tu stesso concludi che
> l'articolo =E8 comunque applicabile, seppur parzialmente.
Qui dovrebbe rispondere Rossato, io non ho letto questo nel suo testo; a
meno che Monti non intenda un'opera derivata come "software originale ed
indipendente."
> =20
> >>mentre si applica, per le creazioni future, limitatamente agli
> >> sviluppi, correzioni e modificazioni dei programmi elencati, salvo
> >> esse non siano da considerarsi software originale ed indipendente.
[...]
=20
> >> Significa forse la norma che gli atti di
> >>cessione del software devono essere compiuti di fronte ad un
> >> notaio affinch=E8 l'acquirente degli stessi possa agire - in nome e
> >> conto propri - fatta salva la possibilit=E0 dell'autore di
> >> intervenire? Ovvio che no.
>=20
> Gli atti di cessione dei diritti d'autore sono sottoposti al requisito
> della forma scritta ad probationem tantum.
Quindi basta la forma scritta, art. 110 LdA
> Ma l'attribuzione della
> capacit=E0 di stare in giudizio segue le regole del codice di procedur=
a
> civile. E dunque, se il FLA intendesse esercitare giudizialmente dei
> diritti che spettano al programmatore dovrebbe, secondo la legge
> italiana, dotarsi di procura notarile. =C8 inoltre opportuno rilevare =
la
> scarsa tecnicit=E0 del FLA nella parte in cui afferma:
> > FSF Europe shall exercise the granted rights and licences in its
> > own name. Furthermore, FSF Europe shall be authorized to enjoin
> > third parties from using the software and forbid any unlawful or >
> > copyright infringing use of the Software, and shall be entitled to
> > enforce all its rights in its own name in and out of court.
>=20
> Si tratta di una clausola inutile in quanto il titolo di acquisto dei
> diritti d'autore la legittima attivamente a prescindere da qualsiasi
> altro atto.
L'ultima affermazione di Monti non =E8 forse in contraddizione con la
prima? Prima dice che =E8 necessrio l'atto notarile (per esercitare
giudizialmente i diritti) poi sostiene l'inutilit=E0 della clausola del
FLA perch=E8 il semplice "titolo di acquisto" dei diritti d'autore
legittima la FSFE ad agire attivamente (in and out of court).
Boh?
=20
> >>Relativamente all'affermazione secondo cui il =ABFLA contiene un
> >>meccanismo che rischia di ridurre significativamente l'ampiezza dei
> >>diritti dell'autore di un software regolamentato con la GPL=BB, si
> >>deve ricordare che l'art. 4 stabilisce che =ABl'uso dei diritti e
> >>delle licenze trasferiti avverr=E0 nel pieno rispetto delle regole
> >>poste dalle licenze libere, in particolar modo la GNU GPL e - nella
> >>misura necessaria al perseguimento degli scopi del software libero -
> >>la GNU LGPL=BB.
>=20
> Appunto, "nella misura necessaria al perseguimento degli scopi del
> software libero". Che non sono necessariamente quelli del
> programmatore. Il quale subisce una limitazione nell'esercizio dei
> propri diritti che non si verificherebbe se non avesse firmato il FLA.
Dir=F2 di pi=F9, l'autore non "subisce una limitazione", ma decide di
*trasferire* i diritti di utilizzazione economica alla FSFE.
[...]
> =20
> >>Ora, si comprende che se una corte ritenesse applicabili le regole
> >> della
> >>comunione ad esempio al kernel Linux e imponesse un liticonsorzio
> >>necessario per agire contro chi distribuisca versioni proprietarie
> >> dello stesso, ci=F2 starebbe a significare che la licenza del kernel
> >> non potrebbe essere azionata in giudizio. Il problema pu=F2 sembrare
> >> banale, ma nel caso di sviluppo distribuito del software in molte
> >> giurisdizioni ci=F2 potrebbe comportare la non validit=E0 giuridica de
> >> facto di licenze quali la GPL.
>=20
> Rimettiamo le cose a posto: quello di cui parli non =E0 un problema di
> validit=E0 (ne' tantomeno "de facto", categoria che all'interno del
> diritto civile non mi risulta essere stata ancora istituita).
> =20
> Semmai stiamo parlando di un profilo relativo alla concreta
> possibilit=E0 di tutelare le singole posizioni giuridiche soggettive.
> =20
> Il che =E8 un problema reale. Ma il fatto che tu non "gradisca" le
> conseguenze dell'applicazione della legge non significa cercare di
> sottrarsi al suo vigore.
> =20
> Come si dice, "non puoi fare la frittata senza rompere le uova", e
> quindi se vuoi usare il modello di sviluppo distribuito devi
> accettarne le conseguenze (tutte, anche quelle sgradite).
Non capisco proprio perch=E8 non farsi furbi e cercare di evitare anche
solo di dover pensare a fare una frittata quando ci si potrebbe occupare
di altro, lasciando che la FSFE tuteli gli autori in proprio nome e
conto.
Chiaro che ciascun autore pu=F2 poi decidere di non trasferire i propri
diritti e difendersi da solo, ma =E8 volere complicarsi la vita.
Avete mai seguito qualche vicenda di uso illegale di software rilasciato
decondo i termioni della GNU GPL a seguito della quale i programmatori
hanno deciso di interrompere lo sviluppo per "mancanza di risorse"? Io
si.
[...]
>=20
> Mi sembra, invece, che le tue considerazioni nulla tolgano alle tesi
> sostenute nel mio articolo.
> =20
> Riassumendo:
> 1. La FSF Europe si attribuisce tutti i proventi derivanti da
> eventuali transazioni,
In che modo?
> azioni giudiziali=20
vero, e sarebbe un'ottima cosa. I soldi verrebbero reinvestiti nello
sviluppo di nuovo Sofwtare Libero e/o nella tutela del software libero
esistente.
> o licenze di software sviluppato da terzi senza retrocedere un centesimo
La FSFE non pu=F2, per contratto, concedere il software a terzi con
licenze diverse da GPL o LGPL, quindi di che proventi parla?
> 2. Le controversie fra FSFE e programmatore sono decise ad Amburgo e
> applicando la legge tedesca
Irrilevante.
> 3. Il programmatore-licenziante accetta di esercitare i "diritti di
> ritorno" purch=E9 non limitino gli scopi del progetto GNU
Sacrosanto.
Tra i diritti di ritorno =E8 compreso quello di concedere il software a
terzi con un altra licenza.
> 4. Il FLA contiene ridondanze,
Repetita juvant ;-)
> clausole inutili (vedi quella sulla
> legittimazione attiva che non ha bisogno di essere accettata),
Boh? Ma =E8 importante?
> nulle (violazione art.120 L.d.a.),
No.
> oltre a probabili difetti di forma.
Probabili quanto? 20, 30 60% ? E poi quale forma?
> 5. Se un programmatore si limitasse a usare in proprio la GPL sarebbe
> indubitabilmente pi=F9 libero di quanto gli consente il FLA.
Concordo. Faccio notare comunque che l'unica libert=E0 in pi=F9 che avrebbe
sarebbe quella di doversi arrangiare da solo (o peggio doversi mettere
d'accordo con altri 20 coautori e poi arrangiarsi da solo) in caso di
violazione dei termini di licenza.
=20
> Alla prossima
> Andrea Monti
Ciao.
Giovanni.
--=20
=ABThe ultimate goal is to provide free software to do all of the jobs
computer users want to do--and thus make proprietary software obsolete.=BB
--------------------------------------------------------------------------
Associazione Culturale MiLUG | Xelera - servizi GNU/Linux=20
http://www.milug.org | http://xelera.it
mailto:giovanni.biscuolo@milug.org | mailto:g@xelera.it =
=20
--=-eVUjpCNH+43UclMxahXc
Content-Type: application/pgp-signature; name=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQA+mBMNihmrAnWLWXMRAtT7AJ9mn5/IxeDchqtbFRBJqoAfuDZd8ACffdNh
hONFJh1YnnlQO3+jahnEsXI=
=Mfq8
-----END PGP SIGNATURE-----
--=-eVUjpCNH+43UclMxahXc--