Linux&Co n. 36 di Andrea Monti
RedHat ha da poco annunciato una nuova strategia commerciale che – in sintesi – consiste nel tenere per sè lo sviluppo delle piattaforme dedicate al mondo business (RedHat Enterprise Linux – RHEL), lasciando alla comunità la gestione di un sistema operativo open source e “general purpose” chiamato “Progetto Fedora”[1].
Red Hat afferma esplicitamente che l’intero sistema RHEL rimane open source, tanto che i sorgenti continueranno a essere liberamente disponibili[2]. Ma dice pure che i relativi file binari non saranno liberamente accessibili. Questi ultimi, infatti, insieme all’abbonamento annuale al Red Hat Network, al diritto di ottenere gli upgrade e di accedere a particolari servizi di supporto costituiscono l’insieme di RHEL[3]. Che dovrà essere acquistato per ogni macchina sulla quale viene installato[4].
Messa in questi termini, la cosa non sembrerebbe particolarmente deviante o eretica. Anzi, la strategia di Red Hat risulterebbe perfettamente inserita nel modello economico dell’open source: guadagnare sui servizi invece che sul software.
Le strategie di marketing e le condizioni di servizio lasciano qualche dubbio che avrei preferito chiarire con qualche responsabile dell’azienda. Ma non è stato possibile ottenere un contatto chiarificatore[5] e dunque l’analisi che segue sarà basata soltanto sul materiale reso disponibile sui siti ufficiali.
Cominciamo studiando le strategie commerciali adottate per convincere gli utenti a cambiare piattaforma.
Il primo argomento utilizzato da Red Hat è evidenziare la differenziazione fra RHEL e Fedora[6]. La piattaforma commerciale, manutenuta dal team di Red Hat, sarebbe stabile, affidabile, ampiamente supportata, facile da installare e gestire, dotata di molte applicazioni certificate, con un alto grado di performance e scalabilità da server a desktop. Mentre Fedora – gestita dalla comunità open source pur supportata da Red Hat – sarebbe caratterizzata dal modello “release early, release often”, priva di certificazioni e di date certe sul rilascio di upgrade. Per di più, mentre il ciclo di vita degli update di RHEL sarebbe di cinque anni, quello di Fedora sarebbe appena di qualche mese. In sintesi: usare RHEL è facile e sicuro mentre chi usa Fedora lo fa “a proprio rischio e pericolo”[7].
Sempre dal punto di vista delle pure scelte commerciali, mentre le versioni RHEL Enterprise Server (ES) e Advanced Server (AS) avrebbero le stesse identiche funzionalità, vengono differenziate in base al numero di CPU e alla quantità di memoria presenti sulla macchina. E’, poi, richiesto l’acquisto di un pacchetto RHEL e dei relativi servizi per ciascun computer sul quale gira l’applicazione. Infine, per effettuare la migrazione è necessario reinstallare l’intero sistema[8].
Confrontiamo ora le dichiarazioni di marketing con il contenuto della licenza[9].
Diversamente dalle dichiarazioni promozionali sulle caratteristiche tecniche di RHEL, l’art. 6 del contratto di somministrazione di beni e servizi afferma che
il software, i servizi e ciascun programma software fornito attraverso RHN, ciascun Server Proxy, Satellite, o il Codice RHN (ciascuno come da definizione qui riportata) sono forniti e ceduti in licenza “nello stato in cui si trovano” senza alcuna garanzia, espressa o implicita, comprese le garanzie implicite relative alla vendibilità, alla non violazione di diritti di terzi ed all’adeguatezza ad un determinato scopo. Red hat non garantisce che l’uso del software, i servizi, o il server proxy, il satellite, o il codice rhn (ciascuno come da definizione qui riportata) non saranno interrotti o che la loro fruizione sara’ completamente immune da errori.
Clausola riportata, nei suoi contenuti sostanziali, anche nell’art.3 dell’ Appendice 1[10].
Sulla base di questa struttura commerciale e contrattuale Red Hat – analogamente a quanto possono fare le aziende che hanno scelto il modello proprietario – potrebbe:
– denunciare per duplicazione abusiva ai sensi dell’art.171 bis L.633/41 chiunque, su un numero di macchine superiore alle licenze acquistate installa più copie di RHEL (gli eseguibili sono, infatti, ceduti in licenza per una singola macchina) oppure riutilizza patch e upgrade resi disponibili dall’azienda in solo formato eseguibile,
– “chiamarsi fuori” da ogni garanzia rispetto alla rispondenza del software a uno scopo particolare,
– declinare le responsabilità per malfunzionamenti delle applicazioni.
E dunque gli utenti potrebbero andare incontro, magari inconsapevolmente, a spiacevoli imprevisti.
Quanto al primo punto (applicabilità delle sanzioni penali in materia di duplicazione abusiva) è pur vero che siccome RHEL è in gran parte governato dalla GPL, Red Hat è obbligata a rendere disponibili anche i sorgenti delle patch e degli upgrade. Ma questo discorso, innanzi tutto, non vale per quelle parti di RHEL che hanno una licenza diversa dalla GPL. Inoltre c’è da considerare che la GPL si occupa solo dei sorgenti e non dice quando il materiale in questione deve essere reso disponibile.
In altri termini: formalmente RedHat non viola la GPL perchè incorporerà (o dovrebbe incorporare) tutte le modifiche con il rilascio dei sorgenti delle versioni successive. Che, però, vedranno la luce solo dopo 12/18 mesi[11].
Fino a quel momento riutilizzare gli eseguibili degli aggiornamenti intermedi (che sono fuori dalla GPL) significa effettuare una duplicazione abusiva punita dalla legge.
Anche gli altri aspetti (limitazioni di garanzia e responsabilità) danno più di uno spunto per riflettere.
Se un soggetto si convince ad acquistare un software perchè gli viene presentato come robusto, affidabile, certificato, scalabile e via discorrendo, è chiaro che il produttore non può eliminare o attenuare le conseguenze giuridiche di queste affermazioni. E dunque una clausola contrattuale che contrasta con gli elementi che inducono all’acquisto della licenza (tipicamente quella del software ceduto “as is” [12]) o non è valida, o va interpretata in modo da essere coerente con gli elementi in questione. Ne consegue che – se questo ragionamento è corretto – le limitazioni di garanzia e responsabilità contenute nel contratto RHEL non varrebbero per quelle caratteristiche evidenziate come punto di forza per promuovere commercialmente il prodotto/servizio. Se, infatti, chi “assembla” una distribuzione gratuita può ricorrere alla clausola “as is” senza troppi problemi questo non vale automaticamente per le realtà commerciali. E, dunque, quando affermazioni promozionali sulla qualità del pacchetto vantano apertamente “plus” come la certificazione dei software e via discorrendo, chi gestisce la distribuzione si assume la responsabilità di avere controllato ciò che veicola oltre al software che realizza in proprio. Poco importerebbe che RHEL sia costituito, come tutti i sistemi basati su Linux, sia da software sviluppati da terze parti, sia da chi gestisce la distribuzione.
Chi intende offrire servizi basati su RHEL, poi, dovrebbe riflettere sulle conseguenze pratiche di questo scenario, che sembra offrire due solo due opzioni:
– diventare essenzialmente un “box mover”, un “muoviscatole a capacità limitata”, visto che la sua attività sarà limitata ai servizi di installazione, configurazione e formazione (nè più, nè meno di quanto accade con altri sistemi operativi non liberi)[13];
– assumersi l’onere e il rischio di scaricare i sorgenti di RHEL, personalizzarli e installarli senza poter contare sugli aggiornamenti (disponibili solo a pagamento) e sulle nuove release (rilasciate ogni 12/18 mesi).
A questo punto è evidente come la svolta di Red Hat non sia solamente commerciale ma anche, con buona probabilità, culturale e filosofica. Al di là dei tecnicismi, il dato ragionevomente certo è la presenza, nelle scelte aziendali, di una forte componente proprietaria.
Il che non è certo condannabile in sè. Nonostante, infatti, queste pratiche lascino alquanto perplessi, è pieno diritto di Red Hat proteggere come meglio ritiene opportuno il proprio capitale di proprietà intellettuale[14] ed evidenziare la maggiore qualità del servizio come elemento di distinzione rispetto ad altra piattaforme presenti sul mercato.
Ma è quantomeno discutibile la scelta di raggiungere questo risultato con un’interpretazione giuridicamente (forse)[15] sostenibile della GPL che, nei fatti, crea ostacoli alla libera circolazione del software e alla possibilità di fornire servizi indipendentemente dallo sviluppatore della piattaforma.
Nella forma, tutto questo sarà anche corretto. Nella sostanza, è culturalmente inaccettabile.
[1] http://fedora.redhat.com/
[2] Con l’eccezione delle licenze di alcuni componenti, tipo Java, che hanno la propria regolamentazione contrattuale.
[3] Si legge nella FAQ n.6 predisposta da Red Hat: “Except for a few components provided by third parties (for example, Java) all the code in Red Hat products is open source and licensed under the GPL (or a similar license, such as the LGPL). So you always have free access to the source code. In fact you can download it from our FTP servers at any time. However, Red Hat does not provide free access to the binaries of Red Hat Enterprise Linux, and these, combined with an annual subscription to Red Hat Network, access to upgrades, and a selected support services, are the components that Red Hat bundles into each Red Hat Enterprise Linux solution. Since every Red Hat Enterprise Linux product includes support for the system on which it is installed, Red Hat supplies the products with a per-system usage/support subscription. This simple model ensures that systems which useRed Hat Enterprise Linux are able to access the maintenance, services and product upgrades to which they are entitled. Of course, as mentioned before, this has no impact on your access to the Red Hat Enterprise Linux source code.”. Http://www.redhat.com/software/rhel/faq/#six v. 09/11/03
[4] http://www.redhat.com/software/rhel/faq/#five v. 09/11/03
[5] Purtroppo, nessuno di Red Hat ha risposto alla mail con la quale chiedevo un contatto e dunque non è possibile dare conto delle eventuali risposte dell’azienda.
[6] http://www.redhat.com/software/rhelorfedora/ v. 09/11/03
[7] Queste considerazioni, esplicitamente formulate nei confronti di Fedora, possono essere tuttavia utilizzate anche nei confronti di altre distribuzioni non basate sul modello di business di Red Hat. Il che si traduce in una ingiusta penalizzazione di attività che nulla hanno a che vedere con le scelte commerciali di questa azienda.
[8] Migrating to Red Hat Enterprise Linux – Benefits and Guidelines, p.8
Click to access Migrate_RHEL.pdf
“So, because it is important to ensure that Red Hat Enterprise Linux deployments start from a fresh, known state, Red Hat does not provide an upgrade capability from the consumer releases. This means that a migration to any Red Hat Enterprise Linux product requires a fresh installation (except where noted below).
Fortunately, the heritage of Red Hat Enterprise Linux products, which were originally based on the consumer products, makes fresh installation a straightforward exercise. Externally visible components, for example, are the same across the systems…”.
[10] Contratto di licenza e garanzia limitata del prodotto red hat® enterprise linux® e red hat® applications. L’articolo 3 si intitola Garanzia Limitata e recita testualmente: Fatta eccezione per quanto specificatamente affermato nel presente contratto o nella licenza per un particolare componente, nei termini massimi concessi dalla legge applicabile, il Software e i suoi componenti vengono forniti e ceduti in licenza “nello stato in cui si trovano” senza alcuna garanzia, espressa o implicita, comprese le garanzie implicite relative alla vendibilità, alla non violazione di diritti di terzi ed all’adeguatezza ad un determinato scopo. Red Hat garantisce che il supporto su cui il software è fornito sarà privo di difetti nel materiale e di fabbricazione durante il normale utilizzo per un periodo di 30 giorni dalla data di consegna al Cliente. Red Hat non garantisce che le funzioni contenute nel Software siano idonee a soddisfare le esigenze del Cliente, nè garantisce una sua fruizione completamente immune da errori o che esso apparirà esattamente come descritto nel materiale di accompagnamento. La presente garanzia si applica esclusivamente alla parte acquirente il Software direttamente da Red Hat o a un distributore Red Hat autorizzato.
[11] Un modo per neutralizzare queste conseguenza sarebbe quello di integrare la GPL nel senso di chiarire in modo esplicito e non contraddittorio che i sorgenti delle modifiche devono essere rilasciati non appena raggiunta la stabilità. E’ pur vero che la ratio della GPL(cioè l’obiettivo che intende raggiungere) è quello della effettiva disponibilità del codice. Il che implicherebbe, da un lato, la necessarietò del doverlo rendere disponibile non appena realizzato. Dall’altro, che non comportarsi in questo modo significherebbe violare la GPL. Purtroppo la situazione non è così semplice. Questo discorso, per quanto condivisibile, è solo una interpretazione personale e dunque, a meno di non raggiungere un accordo fra FSF e Red Hat l’unico a poter dirimere la questione è un giudice. Ma chi mai promuoverà l’azione legale?
[12] Cioè usare il software a proprio rischio e pericolo.
[13] E’ vero che i sorgenti sono comunque disponibili e che quindi è sempre possibile modificarli. Ma bisognerebbe capire in che modo queste eventuali modifiche effettuate dall’utente incidono sul contratto di supporto e sulla garanzia.
[14] Il contratto RHEL contiene una specie di easter-egg che renderebbe praticamente impossibile ridistribuire liberamente i sorgenti di questa applicazione. Red Hat scrive esplicitamente che il nome redhat e il relativo marchio possono essere usati solo previa specifica autorizzazione (art.2 contratto di licenza). Nello stesso articolo si dice che la eventuale ridistribuzione dei sorgenti è condizionata all’eliminazione di tutte le immagini contenenti i logo “Red Hat” o “Shadowman” dai file redhat-logos e anaconda-images. E che la semplice cancellazione di questi file potrebbe guastare il software.
Vediamo ora Le regole per l’utlizzo dei marchi Red Hat http://www.redhat.com/about/corporate/trademark/guidelines/page4.html alla lettera C. "Plays On Words" And Other Actions That May Cause Confusion Are Also Prohibited prevedono che: There is no connection between the words "Red Hat" and Linux-based computer software, products and services other than the association created by the Red Hat® brand of Linux-based products and services. Red Hat, Inc. has created this association by spending time and money to establish goodwill in its products, services and trademarks. As a result, you may not use the words "Red Hat" (together or individually), words with similar connotations or pronunciations, translations of those words, or other words that may cause confusion in the market as a trademark for your products. Some examples of prohibited uses include, but are not limited to, "Red Cap" Linux, "Sombrero Rojo" ("Red Hat" translated into Spanish) Linux, "Redd Hatte" Linux, "RH" Linux, and "Green Hat" Linux.”.
Dunque, secondo il contratto di licenza per ridistribuire sorgenti Red Hat devo eliminare i logo, e per le regole sull’uso dei marchi non posso usare le parole Red Hat in ogni forma e associazione. Ciò significa che una distribution non ufficiale non può nemmeno usare la parola Red Hat per identificare dei file. E che, dunque, dovrà cancellare i file redhat-logos. La cui eliminazione può provocare il malfunzionamento del software.
[15] Vedi nota n.11.
Possibly Related Posts:
- Chi ci protegge dal dossieraggio tecnologico?
- Webscraping e Dataset AI: se il fine è di interesse pubblico non c’è violazione di copyright
- Perché Apple ha ritirato la causa contro la società israeliana dietro lo spyware Pegasus?
- Le sanzioni UE ad Apple e Google aprono un altro fronte nella guerra contro Big Tech (e incrinano quello interno)
- La rottura tra Stati e big tech non è mai stata così forte