L’antica questione “A chi appartiene Linux?” è ormai vicina alla conclusione

La lunga battaglia legale sulla proprietà di Linux è più vicina che mai alla conclusione, dopo che un collegio di tre giudici ha stabilito che la richiesta di risarcimento contro IBM e Red Hat non è valida e che i termini per ulteriori azioni legali sono scaduti.

La storia inizia nel 1998, quando IBM decise che il mondo aveva bisogno di un’unica versione di UNIX in grado di funzionare su diverse architetture di processori. Per realizzare questo obiettivo, Big Blue si alleò con una società chiamata Santa Cruz Operation (SCO), che aveva sviluppato una versione di UNIX per CPU x86. Anche Intel e Sequent aderirono al progetto multi-architettura, denominato “Project Monterey”.

L’alleanza non funzionò, principalmente perché Linux arrivò con un sistema *Nix in grado di funzionare su più processori (e introdusse un nuovo modo di sviluppare software).

IBM decise di integrare parte del codice sviluppato durante il Project Monterey in Linux, portando SCO e i suoi successori legali a rivendicare la proprietà di tale codice e, di conseguenza, un qualche diritto legale su Linux.

Si tratta di un potenziale premio considerevole, considerando che Linux è in esecuzione su miliardi di dispositivi. Per capire il perché, basti pensare che Huawei possiede brevetti che le fruttano 0,50 dollari per ogni dispositivo che utilizza il suo protocollo Wi-Fi 7. Se è possibile ottenere 50 centesimi solo per il Wi-Fi, le royalty derivanti da Linux potrebbero essere decisamente superiori.

Nel 2021, un erede di SCO ha raggiunto un accordo con IBM per 14,25 milioni di dollari, una somma che riflette il fatto che SCO per anni non era riuscita a produrre prove concrete a sostegno delle proprie affermazioni.

Un altro successore legale di SCO, Xinuos, ha presentato una nuova richiesta di risarcimento sostenendo che IBM avrebbe dovuto essere ritenuta responsabile perché Big Blue sapeva di non essere proprietaria del codice sorgente di Linux, ma di possedere invece una licenza non esclusiva per il suo utilizzo. Xinuos ha sostenuto che, con il contributo di IBM al codice del Project Monterey per Linux, IBM aveva violato tale licenza.

Xinuos ha infine portato la questione dinanzi alla Corte Distrettuale degli Stati Uniti per il Distretto Meridionale di New York, senza però riuscire a convincerla che IBM e Red Hat avessero un caso da risolvere. Xinuos ha presentato appello e il 10 agosto la Corte d’Appello degli Stati Uniti per il Secondo Circuito ha deciso di non riesaminare la sentenza della Corte Distrettuale, concordando sul fatto che, in base alla normativa originaria che regolava il Project Monterey, era ormai troppo tardi per riaprire la questione. La Corte d’Appello ha inoltre concordato sul fatto che Xinuos abbia tentato di presentare il caso come una questione di licenze, fallendo nel suo intento, e abbia invece sostenuto che la questione riguardasse in realtà la proprietà.

Ma non è tutto: Xinuos intende presentare una richiesta di riesame del caso da parte dell’intera Corte d’Appello.

Questo accade molto raramente, a meno che la Corte non riscontri errori significativi o importanti questioni legali che giustifichino un riesame. Lo studio legale Kaplan afferma che la Corte d’Appello del Secondo Circuito ha ammesso il riesame di meno dello 0,03% dei casi trattati. Quindi, forse, la questione è ormai vicina a una risoluzione definitiva.

Articolo originale su The Register

Recuperati i nastri di UNIX V4

Quasi due mesi fa è stato ritrovato un nastro contenente UNIX v4. È stato inviato al Computer History Museum, dove bitsavers.org si sarebbe occupato dell’ulteriore gestione del nastro, processo ora completato.

È possibile scaricare il contenuto del nastro da Archive.org, che purtroppo al momento è inattivo, mentre squoze.net ha un file readme con le istruzioni su come eseguire la copia di UNIX v4 recuperata dal nastro.

Brian Kernighan su Rust, Distribuzioni e NixOS

Durante una intervista rilasciata da Brian Kernighan, durante la quale ha affrontato vari argomenti relativi a Unix, la sua storia e la sua evoluzione, si è parlato in maniera simpatica e informale anche di alcuni argomenti che vanno per la maggiore ultimamente come ad esempio la tendenza a voler sostituire il C con Rust – per via della maggiore sicurezza nella gestione della memoria -, la relazione di Brian con le distribuzioni Linux e il crescente interesse per quelle immutabili come NixOS. Mettetevi comodi e godetevela!

MacOS 15 Sequoia è ufficialmente UNIX

Apple macOS 15 Sequoia è apparso a metà settembre ed è una versione ufficiale e conforme di UNIX™, ma potrebbe non significare esattamente ciò che pensate. Ad esempio, macOS non utilizza alcun codice sorgente AT&T: “Unix” ha smesso di significare questo nel lontano 1993, quando Novell ha acquistato UNIX da Bell Labs, come abbiamo discusso all’inizio dell’anno scorso quando abbiamo annunciato che Unix era morto.

Poco dopo l’uscita di Sequoia, sono emerse notizie riguardanti alcuni break del software di sicurezza seguiti dal primo aggiornamento, versione 15.0.1, all’inizio di questo mese. L’arrivo della versione 15.0.1 è stato seguito da un paio di altri eventi. Uno non è affatto molto significativo. Un giorno o giù di lì dopo, il MacBook Air del Reg FOSS desk ha iniziato a offrire l’aggiornamento.

L’altro è un po’ più significativo per il mondo in generale, anche se solo leggermente. Sequoia è apparso come la voce più recente nel registro dei prodotti certificati UNIX® dell’Open Group. In effetti, ha sia il primo che il secondo posto perché ci sono voci separate per la versione Apple Silicon e la versione x86-64. Non c’è un significato particolare nell’ordine, ma se Apple continua a pagare per la certificazione, a un certo punto la versione x86-64 uscirà dall’elenco quando Apple smetterà di supportare il suo kit basato su Intel.

Unix è solo un nome nuovo per POSIX

Non è una questione di codice. Non lo è da più di 30 anni, da quando Novell ha acquistato l’Unix originale da AT&T. In realtà, ciò che la certificazione UNIX™ significa ora è ciò che una volta veniva chiamato “compatibile con POSIX”, un’abbreviazione coniata da Richard Stallman, guarda caso.

POSIX è essenzialmente un set di specifiche e test di compatibilità, tra cui avere gli strumenti giusti presenti nelle posizioni giuste. Finché ci sono, un sistema operativo può superare il test, ed è così che sistemi come il sistema operativo mainframe z/OS di IBM sono nell’elenco. z/OS è un lontano discendente dell’MVS a 24 bit di IBM per il mainframe System/370 del 1974, che in fondo non è molto più simile a Unix di un Apple II che esegue ProDOS.

Lo standard POSIX si è evoluto nel corso degli anni e, cosa abbastanza interessante, Apple rivendica UNIX 03 solo dal 2002. Un singolo prodotto, IBM AIX 7, vanta la compatibilità con la versione 4 dello standard, denominata UNIX® V7, ovvero POSIX.1-2008.

Da allora, lo standard ha continuato a evolversi. La specifica della versione 4 è stata rivista l’ultima volta nel 2018 e c’è anche una versione del 2024. Nessuno sembra più farci caso, il che è abbastanza giusto. Il mondo si è allontanato da Unix proprietario e ora che tutti i sistemi operativi Unix-like significativi sono FOSS o freeware, puoi aggiungere qualsiasi bit mancante senza pagare.

Ad esempio, POSIX ha risolto le differenze tra vari strumenti di archiviazione aggiungendo un nuovo comando, chiamato pax, in grado di gestire tutti i formati principali. È un ibrido di tar e cpio e la maggior parte delle distribuzioni Linux non lo include perché gli strumenti esistenti possono gestire i file. L’assenza del comando pax significa che un sistema operativo non è conforme a POSIX-1.2001 o versione successiva, ma ormai a nessuno importa più.

Quindi cosa rende un sistema operativo simile a Unix?

Se non avete bisogno di usare nessuno dei codici sorgente originali AT&T e persino la manciata di aziende che continuano a pagare per la certificazione ufficiale Unix non si preoccupa di puntare alla conformità con le ultime versioni di POSIX, allora cosa rende un sistema operativo simile a Unix?

Da una prospettiva molto più ampia, ciò che costituisce un Unix è che sembra Unix, si comporta come Unix e puoi trasferire programmi scritti per Unix su di esso senza modifiche sostanziali.

Il nucleo di macOS è abbastanza simile da qualificarsi. Utilizza un kernel chiamato XNU (che, ironicamente, sta per “XNU is Not Unix”) e un user-land derivato principalmente dal codice BSD. XNU è basato sul kernel Mach [PDF]. In particolare, dopo che Apple ha acquistato NeXT, ha aggiornato i componenti Mach del kernel NeXTstep con la versione migliorata di DEC OSF/1 (in seguito commercializzata come Compaq Tru64). Dispone inoltre di un grande “server Unix” nel kernel derivato dal codice BSD, il che significa che il sistema operativo microkernel più famoso e di successo del settore non è affatto un vero microkernel.

Oltre a ciò, la “user-land” (la roba in modalità testo sotto la GUI, i vari comandi, le shell e così via) è per lo più open source e gran parte di essa proviene da BSD. Ad esempio, il kernel XNU è su GitHub, così come grandi porzioni di macOS e iOS. Sono i livelli della GUI, le parti visibili che la rendono carina, che sono proprietari; sono i bit scritti per lo più in Objective-C e più di recente in Swift.

Apple era solita rendere disponibile una versione per lo più autonoma di questi livelli inferiori del sistema operativo come progetto chiamato Darwin e c’erano diverse distribuzioni che cercavano di completarla usando bit di altri sistemi operativi FOSS, come OpenDarwin e PureDarwin. Per noi, uno dei progetti più interessanti è stato NextBSD, che ha fatto l’opposto. Ha mantenuto il kernel FreeBSD, ma lo ha modificato in modo da poter usare parte del codice di livello superiore di Apple, come launchd, il sistema init di nuova generazione di Apple. In altre parole, l’equivalente di Cupertino di systemd.

Apple annunciò che avrebbe acquisito NeXT Computer alla fine del 1996 e nell’ottobre 1997 pubblicò un’anteprima del suo sistema operativo di nuova generazione chiamato Rhapsody. Rhapsody era effettivamente NeXTstep 5. Nel 1999, divenne Mac OS X Server 1.0, ancora visibilmente simile a NeXTstep. Che si evolse in Mac OS X 1.0 nel 2000.

NeXTstep (la capitalizzazione cambiò un paio di volte) divenne OPENSTEP, che divenne Rhapsody, poi Mac OS X Server, Mac OS X e poi solo OS X con 10.8 Mountain Lion e, a partire da 10.12 Sierra, era semplicemente macOS. Ma è riconoscibilmente lo stesso sistema operativo di NeXTstep 0.8, come dimostrato da un giovane Steve Jobs nel 1988.

Bootnote: Quindi, tutto in C?

No, non deve nemmeno essere implementato in C. Serenity OS è implementato in C++ e Redox OS è scritto in Rust, ed entrambi sono molto simili a Unix. Per andare agli estremi, sia C++ che Rust sono linguaggi di parentesi graffe nella più ampia famiglia C, ma TUNIS, il Toronto University System, era un sistema operativo compatibile con Unix Seventh Edition implementato in Concurrent Euclid, una variante di Pascal.

 

Articolo originale su The Register

1 2 3 … 7