Più in generale, “Array” richiama un’idea di ordine non fondato su una struttura gerarchica, ma su regole e organizzazione.
Array riunisce una serie (un “array”, appunto) di IT lawyer indipendenti che offrono supporto specialistico ad aziende, programmatori e studi legali nei casi in cui sia richiesta una competenza legale molto focalizzata su IT e TLC, unita a una profonda comprensione delle questioni tecniche che stanno alla base dei problemi giuridici. Si tratta di competenze raramente si trovano negli studi legali tradizionali, anche quando specializzati in proprietà intellettuale, ma che sono indispensabili per fornire una consulenza davvero efficace agli operatori del settore.
Infine, i membri di Array, oltre a fornire assistenza e consulenza nelle aree tradizionali dell’IT/TLC law, sono particolarmente focalizzati sul mondo del free software (anche detto open source software), dell’open content e dell’open data, e possono offrire in questo ambito competenze difficili da reperire anche in studi legali specializzati in IT/TLC law. Una parte significativa della nostra attività consiste proprio nel collaborare con studi internazionali di medie e grandi dimensioni (incluso EuroITcounsel).
IT Lawyers
Non è sufficiente avere estese competenze in “intellectual property” o in contrattualistica internazionale per potersi definire davvero un”IT lawyer”. In primo luogo, un buon IT lawyer deve conoscere gli elementi di base della programmazione software, le differenze tra i principali linguaggi di programmazione, il funzionamento delle reti informatiche, le tecniche di hacking e così via: in altre parole, è fondamentale una solida conoscenza tecnica che in altri settori, di norma, non viene richiesta all’avvocato.
Ad esempio, per fornire un parere corretto sulla protezione legale dei protocolli di comunicazione è necessario essere in grado di comprendere, a livello tecnico, la differenza che intercorre tra il protocollo in sé, l’implementazione software del protocollo e la documentazione tecnica che descrive il protocollo medesimo, altrimenti si rischia di dare al cliente indicazioni fuorvianti o addirittura errate sull’applicabilità dei diritti di privativa industriale in tale ambito.
Per fare un altro esempio, se si devono affrontare le questioni legali relative alla combinazione di software proprietario e free/open source software è indispensabile comprendere le modalità tecniche con le quali tale combinazione può avvenire (linking, shims, ecc.), altrimenti si rischia di “spaventare” il cliente in merito ad inesistenti rischi legati all’utilizzo di free software nei propri prodotti oppure, al contrario, di non informare correttamente il cliente sui propri diritti e obblighi in materia.
In secondo luogo, un buon IT lawyer deve conoscere le problematiche legali specifiche legate alla produzione, vendita e distribuzione di hardware e software, nonché le dinamiche di mercato del settore IT/TLC.
Ad esempio, per redigere un buon contratto di distribuzione di prodotti e servizi informatici è necessario avere dimestichezza con la normativa e le convenzioni internazionali che pongono determinati obblighi o restrizioni rispetto a certe tipologie di prodotti informatici (come ad esempio il Wassenaar Arrangement); con le limitazioni di garanzia e gli obblighi imposti da licenze (copyleft o proprietarie) di software di terze parti incluso nel prodotto realizzato dal cliente; con le normative in merito di data retention e sicurezza informatica; con gli strumenti tecnici, contrattuali e legali necessari per garantire il cliente – per quanto possibile – contro la violazione dei propri diritti di privativa industriale (o viceversa contro l’involontaria violazione di quelli altrui); con le standard policy del settore in merito a garanzia, assistenza e manutenzione; e così via.
In terzo luogo, un buon IT lawyer deve avere dimestichezza con le dinamiche aziendali e con le prassi del settore, per essere in grado di seguire e validare passo passo un progetto hardware/software, evitando di porre inutili ostacoli e interfacciandosi in maniera corretta ed efficace con i tecnici e i responsabili interni, ma allo stesso tempo segnalando per tempo possibili criticità legali, così da evitare che emergano solo quando si entra in produzione o – peggio ancora – quando l’azienda si ritrova a subire azioni legali da terze parti.
Ad esempio a chi è pratico del settore è noto che alcuni filesystem sono coperti da brevetti che ne rendono altamente sconsigliabile l’utilizzo con determinati sistemi operativi per dispositivi embedded. Se un legale non è in grado di interagire correttamente con un reparto di R&D e di rilevare questa problematica già in fase di progettazione, suggerendo delle soluzioni alternative sulla base delle prassi del settore, l’azienda potrebbe patire delle gravi conseguenze economiche per rimediare al problema quando il prodotto è già stato commercializzato.