Alcune settimane fa, in concomitanza con l’End of Life di Windows 7, la Free Software Foundation aveva indetto una petizione per chiedere a Microsoft il rilascio sotto licenza open di Windows 7.
L’obbiettivo era quello di raggiungere le 7.777 firme (numero azzeccato per il tipo di petizione!) e la campagna si è chiusa con un numero quasi doppio: oltre 13.000 firme a supporto dell’iniziativa di FSF.
Dopo il riscontro positivo da parte della comunità, FSF continua con il suo progetto di upcycle e lo fa con una provocazione: inviare ai vertici Microsoft un hard disk praticamente vuoto, con l’elenco delle firme, su cui la software house di Redmond potrà salvare il codice di Windows 7 e restituirlo comodamente alla Foundation.
We want them to show exactly how much love they have for the “open source” software they mention in their advertising. If they really do love free software — and we’re willing to give them the benefit of the doubt — they have the opportunity to show it to the world.
Vogliamo che dimostrino esattamente quanto tengono al software “open source” che citano nelle loro campagne pubblicitarie. Se hanno veramente a cuore il software libero — e gli daremo il beneficio del dubbio — ora hanno l’opportunità di dimostrarlo al mondo.
Inutile dire che tutta questa questione è cosa destinata a finire in una bolla di sapone perché è ben noto che parte del codice di Windows 7 è stato incluso in Windows 8.1 e Windows 10 dunque ancora sotto brevetto.
Magari per vedere un OS open source da Microsoft dovremmo solo aspettare un Microsoft Linux! Forse…
Nonostante la ricerca su Google porti a tutt’altro risultato, il nostro Simon Peter è il creatore del progetto AppImage, di cui abbiamo accennato qualcosina diversi articoli fa, il formato di distribuzione di software portatile per Linux.
It’s FOSS ha di recente intervistato lo sviluppatore per tastare il polso al progetto, ormai pienamente maturo.
Di sicuro vi sarà capitato di incappare in file *.appimage mentre cercavate l’ultima release del vostro software preferito. Si, siamo d’accordo, i Software Center sono comodi, integrati nel sistema operativo e lì per un motivo. Ma le applicazioni portatili sono un’altra cosa:
AppImage is all about single-file application bundles that can be “managed” by nothing else than a web browser and a file manager. It’s meant for “mere mortals”, end users, not system administrators. It needs no package manager, it needs no root rights, it needs nothing to be installed on the system. It gives complete freedom to application developers and users.
AppImage altro non è che è un’ applicazione composta di un singolo file, gestibile da un browser web e un file manager. Non è per gli amministratori di sistema, è per i “semplici mortali”, gli utenti finali. Non necessità di package manager, di diritti di root, nulla di già installato sul sistema. Dà completa libertà agli sviluppatori e agli utenti.
Già, perché di questo si tratta: libertà. Nessun vincolo, infrastrutturale o di marketing. Diversamente da Flatpack e Snap (rispettivamente Fedora e Canonical), AppImage è un sistema di distribuzione pacchetti universale, nessuna dipendenza, nessuna libreria aggiuntiva (e nessun conflitto per due versioni differenti contemporaneamente presenti sul sistema), niente di niente: è questa la sua carta vincente, ciò che convince gli utenti.
Questo è il punto fermo per Simon, il paradigma “one app = one file”. Quindici anni fa, quando AppImage si chiamava ancor klik, il suo creatore era alla ricerca di una soluzione su Linux che gli ricordasse l’esperienza avuta sul suo primo computer (un Mac, nel 1986): poter copiare un’applicazione da una parte all’altra del del proprio hard disk e poterla eseguire, solo con un click.
E nonostante un iniziale scetticismo da parte della comunità, che ha quasi causato la chiusura del progetto, lo stesso Torvalds ha definito AppImage “very cool”. L’endorsement sembra aver avuto un effetto benefico, e il progetto è in costante crescita da allora, come indicato dal numero di preferenze al repository GitHub.
L’ impegno di Simon sembra non essersi ancora esaurito, anzi, ci sono tutti i presupposti per continuare lo sviluppo e aumentare l’usabilità di questa soluzione, che è a tutti gli effetti, geniale nella sua semplicità.
Le elezioni negli Stati Uniti sono da sempre diverse dalle nostre, specialmente perché ogni Stato ha la libertà di selezionare i metodi che più lo aggrada. Per esempio, spesso, è permesso votare via posta, anche con settimane di anticipo.
Nel tempo, per rendere più facili le votazioni ai cittadini e immediati i conteggi, sono stati proposti (e talvolta adottati) vari metodi, anche stravaganti: dalle schede da perforare, alle macchine con le leve, ai tablet. Ovvia evoluzione, quindi, l’usi di una app sul proprio telefono.
Negli ultimi anni, in alcune elezioni sia locali che nazionali, comprese quelle di medio termine del 2018 (uno degli appuntamenti più importanti negli USA), una startup è riuscita a lanciare la propria app omonima, Voatz, e a farla utilizzare in alcuni progetti pilota. In totale gli elettori coinvolti sono stati meno di 600, ma il solo fatto di essere stato uno strumento ufficiale è degna di attenzione. Tanta attenzione che alcuni ricercatori del MIT hanno deciso di indagare sulla sicurezza di questa app, e pubblicato un’analisi tecnica approfondita.
Le conclusioni? Lasciate perdere l’app. Secondo i ricercatori il voto può essere non solo conosciuto da un eventuale attaccante, ma anche cancellato o modificato. E la prima colpa? L’uso di varie componenti di terze parti closed-source, che hanno dei buchi, ma non potendo conoscere il codice non è possibile porre rimedio.
Ovviamente la startup ha subito replicato queste conclusioni, criticando principalmente il metodo usato – e dichiarato. Per esempio, l’app è stata solo analizzata in sé, offline, senza prendere in considerazione i backend per l’uso reale, con i loro strati di sicurezza. Forse, per questo punto, un precedente che ha portato nel 2018 alla denuncia di alcuni ricercatori del Michigan proprio per aver testato l’infrastruttura ha fatto un po’ da deterrente… Possibile, no?
Rimane il fatto che l’applicazione viene confezionata e la sicurezza garantita sulla fiducia, in quanto tutto il sistema è chiuso e non si può fare altro che fidarsi di chi l’ha realizzato. Noi crediamo da sempre che la sicurezza è più efficace se aperta, se viene mostrato come la si garantisce, con codice open-source. Cosicché, in caso di qualche errore o sbavatura, chiunque possa proporre il rimedio.
La storia di John Graham-Cumming è una di quelle che vale la pena raccontare. Per quanto non sia focalizzata ed incentrata su alcuno dei temi che trattiamo solitamente su MiaMammaUsaLinux, parla di informatica ed in un certo senso di uno dei pionieri della nostra scienza: Alan Turing.
Il matematico inglese, padre della cripto analisi e della scienza dei computer, capace di decrittare il codice nazista enigma nel corso della seconda guerra mondiale e di contribuire in maniera determinante alla vittoria degli alleati, fu in realtà poco celebrato dai contemporanei. E sì, sto usando un eufemismo, poiché non potendo convivere con le accuse di indecenza mosse dal governo britannico a causa della sua dichiarata omosessualità, si tolse la vita a soli 41 anni.
La triste storia del padre della macchina di Turing che tutti conosciamo aveva sempre colpito Graham-Cumming il quale, da britannico, ha cercato di tramutare il proprio sdegno in azioni concrete che potessero pensare di rimediare, almeno parzialmente, a quanto accaduto ad uno dei pionieri dell’informatica moderna.
Iniziando con un post sul suo blog personale mediante uno dei commenti ricevuti scoprì di poter avviare una petizione affinché il governo britannico chiedesse scusa a Turing”. Passato un mese per l’accettazione, la campagna raccolse quasi subito 500 firme, per poi fermarsi. Accortosi però che qualcuno dei firmatari era un nome rilevante nel panorama britannico, Graham-Cumming creò quello che lui definisce un brutto script Perl che, sulla base dei nomi firmatari della petizione, cercava su Wikipedia se, nella sostanza, queste persone fossero famose.
Partendo dallo scrittore Ian McEwan cominciò a contattare personalmente i firmatari chiedendo di poterli citare in modo che la questione assumesse sempre più i toni di una faccenda realmente importante. Poco tempo dopo, Graham-Cumming pensò di scrivere a Zoe Kleinman, una giornalista della BBC che aveva conosciuto poco tempo prima, per parlarle di questa storia.
“Scriverò qualcosa e lo invierò al mio editor prima delle vacanze”, disse lei, non assicurando niente. Graham-Cumming non vide alcuna pubblicazione in merito, ma la sorpresa non tardò ad arrivare: diventata una news sul sito della BBC la campagna prese letteralmente il volo raggiungendo la cifra di trentamila firmatari e Graham-Cumming si trovò catapultato in prima serata a parlare della vicenda.
Di lì a poco l’intera Gran Bretagna aveva preso sul serio la questione ed il naturale corso delle cose portò Graham-Cumming a parlare nientemeno con il primo ministro britannico, che al tempo era Gordon Brown, il quale gli confermò la volontà di voler avviare il processo di scuse ufficiali nei confronti di Turing, come poi infatti avvenne.
La storia intera la trovate raccontata, per bocca del suo protagonista, a questo indirizzo.
Un brutto script Perl ha portato le doverose scuse ad uno dei padri dell’informatica moderna. C’è davvero un profondo senso di giustizia in tutto questo.
Ancora nuovo fiammante, il Kernel 5.5 ha già ricevuto due point release. Ma a breve riceverà anche la terza. Tanto a breve che, mentre leggete questo articolo, potrebbe già essere uscita.
L’allarme è stato dato da Chris Wilson, uno sviluppatore di driver grafici per Intel di lunga data, con qualcosa che sembra tanto un titolo clickbait:
v5.5 is missing multiple urgent patches from dinf
Alla versione 5.5 [del Kernel] mancano molte patch urgenti da dinf (DRM Intel Next Fixes – prossime fix per DRM di Intel, N.d.T.)
Pur essendo stato già approvato e rilasciato, per una svista mancherebbero all’appello delle patch definite urgenti e che riguardano i driver video usati dalle schede Intel, e in particolare quelle integrate ormai da vent’anni in tutte le CPU, con un numero di potenziali utenti impattati molto elevato.
At least two patches are missing and can lead the Linux 5.5 stable to running into irrecoverable system hangs / hangs without the ability for the Intel graphics to recover or reset.
Mancano almeno due patch [che evitano che] un [Kernel] Linux 5.5 stabile si trovi in un blocco di sistema non recuperabile, senza l’abilità per la scheda video Intel di recuperare o resettarsi.
Insomma: possibile blocco del sistema, con unica soluzione un riavvio forzato. Molto spiacevole.
Paura, quindi? Solo se siete tanto temerari da star utilizzando già il nuovo Kernel, cosa che accade solo se usate una distribuzione rolling release, come openSuse Tumbleweed, Gentoo o Arch Linux (il caso del sottoscritto). Noi dovremo solo stare attenti agli update: come già detto, probabilmente vi è già possibile aggiornare il pacchetto. Per gli altri il Kernel è semplicemente troppo nuovo, e probabilmente quando sarà disponibile (cosa per altro non certa, visto che non è una LTS, ovvero con supporto a lungo termine) probabilmente conterrà già la patch.
Ma il consiglio rimane sempre lo stesso: aggiornare, aggiornare, aggiornare!
L’onda lunga del Corona Virus si sta abbattendo sulla nostra quotidianità. Guardandosi intorno, è inutile negarlo, i segnali che balzano all’occhio in questi giorni sono molteplici, il Mobile World Congress che doveva svolgersi a Barcellona è stato annullato, la produzione di Helios64, il NAS open-source dalle enormi speranze, subirà imprevedibili rallentamenti, poi Tesla, Apple ed altre compagnie IT stanno tutte cercando di predisporsi all’impatto che quest’infezione sta portando alle varie supply-chain.
L’imprevedibilità del momento non consente al momento di fare previsioni di sorta in merito a quando tutto tornerà alla normalità pertanto, per quanto sia una frase fatta, conviene ricordare che le situazioni di crisi sono anche delle grosse opportunità per evolversi.
In questo senso l’open-source ed il cloud compting sono dall’inizio strumenti mediante i quali i ricercatori di tutto il mondo stanno combattendo questa importante battaglia. Lo racconta molto bene Kate Wang in questo articolo.
Ci sono aziende come Bluedot che sono riuscite, mediante l’utilizzo dei big data in ambito medico, a predire cosa stava accadendo già il 5 di gennaio.
Il Center for Systems Science and Engineering (CSSE) ospita una mappa realtime che mostra quante persone sono state infettate, quante sono morte e quante ristabilite. Questo il dato di poco fa:
Poi ci sono i ricercatori della Deargen and Dankook University che hanno elaborato un modello predittivo di intelligenza artificiale volto a suggerire quali potrebbero essere i migliori farmaci per il trattamento della malattia.
E non è finita qui. Immunity Bio, un’azienda che effettua test molecolari, avendo chiaramente necessità di processare un’enorme quantità di dati utilizza Ceph per le elaborazioni dei test genetici, dove è all’ordine del giorno la gestione di milioni di file da analizzare, confrontare e registrare. Tanto per intenderci, Ceph è stata anche la scelta del Cern, sede dell’acceleratore di particelle più famoso nel mondo.
Concludendo, nessuno sa quando questa fase della storia dell’umanità finirà, ma una cosa è certa: le forze (informatiche) messe in campo per sconfiggere il Corona Virus stanno combattendo valorosamente.
Torniamo a parlare di Btrfs, il filesystem carico di promesse alla nascita e concorrente di ZFS, il Santo Graal del momento anche su Linux. Ma per prima cosa dobbiamo spiegare, per chi non lo sapesse, cosa vuol dire RAID.
Con RAID (Redundant Array of Independent Disks – insieme ridondante di dischi indipendenti), i dati sono divisi in pezzetti (chiamati chunk) che vengono distribuiti sui vari dischi. Le diverse implementazioni, chiamate livelli, permettono di avere più o meno resilienza dei dati, ovvero poter lavorare in sicurezza con la perdita di uno o più dischi. Il tutto grazie alla ridondanza, ovvero scrivere i dati più volte, al costo di prestazioni e spazio utilizzabile.
RAID-0 I dischi sono usati in parallelo e i dati distribuiti. Permette le migliori prestazioni (si sommano quelle dei singoli dischi), ma – a dispetto dell’acronimo – nessuna ridondanza: alla perdita di un disco, tutto il pool risulta inaccessibile.
RAID-1 I dischi sono usati in parallelo e i dati copiati su tutti i dischi. La velocità di scrittura e la capienza sono pari a quella di un singolo disco, mentre la velocità di lettura è la somma – come nel RAID-0. Dato che tutti i dischi contengono gli stessi dati, la resilienza è la più alta: permette la perdita di tutti i dischi meno uno.
RAID-5 Per questa configurazione servono almeno 3 dischi. I dati sono distribuiti tra tutti i dischi tranne uno, che invece conterrà un chunk speciale, quello di parità. Sopporta la perdita di un disco, ma le prestazioni sono una via di mezzo tra RAID-0 e RAID-1.
RAID-6 Per questa configurazione servono almeno 4 dischi. Come RAID-5, ma i chunk di parità sono due, quindi sopporta la perdita di due dischi.
Per usare RAID ci si deve affidare ad un software apposito (MD – Multi Disk, in Linux), oppure ad un controller hardware apposito, che garantisce prestazioni superiori.
Una delle funzionalità più apprezzate di ZFS è la possibilità di designare più dispositivi (dischi) a formare un unico dispositivo, chiamato zpool, la cui implementazione ricalca quanto avviene con RAID, ma senza la necessità di hardware o software dedicati, cosa che ne semplifica la gestione. ZFS implementa per i propri zpool tre livelli di resilienza:
RAIDZ-1 Costituito da almeno 3 dischi, permette di perderne uno. Paragonabile a RAID-5.
RAIDZ-2 Costituito da almeno 4 dischi, permette di perderne due. Paragonabile a RAID-6.
RAIDZ-3 Costituito da almeno 5 dischi, permette di perderne tre.
Anche Btrfs, da buon antagonista, prevede fin dall’origine la stessa possibilità, implementando direttamente al suo interno i vari livelli RAID sopra esposti, ma una delle critiche più forti fatte finora è la non affidabilità dell’implementazione attuale dei livelli RAID-5 e RAID-6. C’è comunque da fare una precisazione per l’implementazione di RAID-1: la distribuzione dei dati non avviene su tutti i dischi, ma viene scritto lo stesso chunk su due dischi diversi. Questo permette di lavorare con dischi di dimensione diversa, ma al costo di poter perdere solo un disco. In questo senso quindi si può parlare di RAID1C2: RAID-1 con Copia su 2 dischi.
Solo un paio di anni fa è stato risolto un bug per il RAID di Btrfs che aveva il potenziale di far perdere tutti i dati: esattamente quanto non deve accadere con un filesystem. Ma proprio basandosi sull’affidabilità raggiunta, lo sviluppatore David Sterba si è dedicato all’implementazione di due nuove modalità: RAID1C3 e RAID1C4. In queste modalità i dati sono duplicati rispettivamente 2 e 3 volte, permettendo la perdita rispettivamente di 2 o 3 dischi. Proprio come i RAIDZ di ZFS. A detta dello sviluppatore, per avere ulteriore ridondanza (un RAID1C5, per esempio) il codice andrebbe complicato troppo: meglio trovare un altro sistema. Inoltre, non vede nessuno interessato.
Questa nuova caratteristica interessa sicuramente gli utilizzatori più grandi, tipo Facebook, che possano decidere di investire in più dischi per avere migliori prestazioni (lettura parallela dei dati) e resilienza, al costo dello spazio disco usabile. Ricordiamo infatti che creando un RAID1C4 con 4 dischi da 1 TB l’uno, avremo impegnato 4 TB ma disponibile solo 1 TB: il 25%.
L’uscita dell’ultimo Kernel, il 5.5, ha visto l’accettazione anche di queste modifiche a Btrfs, permettendone l’uso. E Sterba ha pubblicato un mini-manuale d’uso che mostra i comandi per poter creare un filesystem con le nuove funzionalità. E si annunciano già dei miglioramenti per il Kernel 5.7. Se ci aggiungiamo poi che GRUB, oltre a quanto implementato l’anno scorso, è già compatibile, possiamo dire che chiunque sia interessato ad usare questa possibilità non ha scuse per non farlo.
Non crediamo che questa caratteristica sia l’arma finale per vincere la battaglia del miglior filesystem, per quanto sia una conferma per chi crede ancora in Btrfs. E voi cosa preferite? ZFS, altro?
Sul sito IndieGoGo, il servizio che automatizza le raccolte fondi per svariati progetti, da qualche tempo c’è una campagna creata dai produttori di ElementaryOS, chiamata AppCenter for Everyone.
L’obiettivo è quello di evolvere nuovamente l’AppCenter sviluppato da ElementaryOS (che a sua volta era stato creato attraverso una campagna di raccolta fondi che aveva totalizzato più di 9.300 euro) in modo che diventi un centro per le applicazioni agnostico nei confronti della distribuzione.
Gli obiettivi dichiarati sono essenzialmente quattro:
incrementare la sicurezza, la stabilità ed il livello di privacy;
fare in modo che gli sviluppatori abbiano a disposizione tutte le ultime tecnologie per distribuire le proprie applicazioni;
semplificare il processo di pagamento per le applicazioni acquistabili;
espandere il mercato dell’AppCenter in modo che le applicazioni possano essere disponibili su altri sistemi Linux;
E proprio quest’ultimo punto fa di questa proposta qualcosa di realmente appetibile al pubblico Linux. Non che di AppStore ci sia un gran bisogno, tra applicazioni Snap, Flatpak e AppImage, e forse il senso è tutto lì. Cercare di standardizzare il marasma che c’è oggi sul tema non sembra affatto una cattiva idea.
Tra l’altro anche il mercato stesso non sembra disprezzare, la nuova campagna ha raccolto più di 8.100 euro, e considerato che scadrà ad Aprile c’è da sperare che il risultato verrà raggiunto.
I soldi raccolti verranno utilizzati come illustrato da questa immagine:
Vedremo se questo AppCenter for everyone, che per inciso è basato su Flatpak, sarà in grado di portare quell’ordine nella confusione che da sempre è croce e delizia del movimento open-source.
I presupposti ci sono tutti ed i fondi stanno per arrivare, non sembra davvero mancare altro.
Chi ha avuto modo di mettere le mai sui container nelle loro prime (o quasi) incarnazioni dell’ultimo decennio. molto probabilmente è incappato in CoreOS. Nato come sistema Linux minimale ed ottimizzato per il deployment e l’update su larga scala, la sua natura intrinsecamente basata su container lo rendeva un’ottima soluzione per chi necessitasse di deployare orchestrator online.
Nato con il solo supporto a Docker, nel Dicembre 2014 ha iniziato a supportare rkt, un container runtime alternativo al più famoso, ed ha continuato a farlo evolvere sia standardizzando la definizione delle immagini che integrando un protocollo standard per la discover ed il download delle stesse. Tutto questo ha portato allo sviluppo delle specifiche appc (app container) come descrittori delle Application Container Image, o ACI. Successivamente ha lavorato per l’integrazione delle stesse nella Open Container Initiative, al fine di renderle standard e riutilizzabili.
Tutto questo prima del 2018 quando, inaspettatamente, l‘azienda che pubblicava CoreOS è stata acquistata da Red Hat e colata nel progetto OpenShift. Un sistema così facilmente scalabile ed automatizzabile rientrava nella visione che l’azienda dal cappello rosso, soprattutto per integrare alcune delle idee in quello che ai tempi era il progetto Atomic Host, versioni minimali ed ottimizzate all’uso per container di Fedora, CentOS ed ovviamente Red Hat.
Seppur Red Hat abbia beneficiato parecchio di quanto acquisito, mantenere una distribuzione in più è un gran lavoro, ed è quindi giunta la fine di CoreOS: già perchè dal 26 Maggio di quest’anno la distribuzione raggiungerà la End Of Life e non riceverà più update.
L’idea, dopo aver già rimosso CoreOS Container Linux dal marketplace di AWS, è quella di rimuovere totalmente tutte le immagini di CoreOS per il primo Settembre di quest’anno.
We’d like to extend our gratitude to our users, contributors, partners, and advocates who contributed to the success of CoreOS and Container Linux over the years
Vogliamo estendere la nostra gratitudine agli utenti, i contributori, i partner ed i promotori che hanno contribuito al successo di CoreOS e Container Linux durante gli anni
Ovviamente il lavoro fatto su di esso non andrà perduto. Già dall’acquisizione, come dicevamo, Red Hat ha fatto buon uso del codice di CoreOS, che ha portato all’integrazione in OpenShift 4.1 di RHCOS, Red Hat Enterprise Linux CoreOS e, di fatto, è l’unico sistema operativo supportato per gli host Control Plane (i master, per intenderci) della soluzione di orchestration di Red Hat.
Dovrete mettervi il cuore in pace, quindi, se siete utenti di CoreOS. Bisogna migrare a qualcos’altro, fortunatamente questo annuncio è arrivato poco dopo la presentazione di Fedora CoreOS che però:
Non fornisce supporto nativo per Azure, Digital Ocean, GCE, Vagrant ed in generale per dove veniva supportato CoreOS Container Linux;
Non è più presente il container runtime rkt;
Quindi, a meno di accontentarsi e seguire le note di migrazione da CoreOS a Fedora CoreOS, l’unica è appoggiarsi ad alternative come Flatcar Linux che nascono come fork di CoreOS ma che, proprio per la loro natura, forse non sono i più indicati in un ambiente di produzione.
Le affermazioni, che vanno a compendio di quanto affermato in fase di dimissioni, sono molto chiare e semplici. Perens spinge per un open-source coerente, che preveda nella sostanza solamente tre licenze (per la verità due e mezzo, tanto per semplificare le cose): Affero GPL 3, LGPL3 e Apache 2.
Questo il centro del discorso:
All three licenses address the problem of software patents in some way. There is much text shared between AGPL3 and LGPL3, so the effect is sort of like having to learn 2.5 licenses rather than 3. And of course AGPL3 addresses the SaaS problem by requiring SaaS providers to share their modifications, just as the GPL required people to share modifications before SaaS.
Tutte e tre le licenze indirizzano in qualche modo il problema dei brevetti software. Parecchie parti di AGPL3 e LGPL3 sono condivise, quindi l’effetto è quello di dover nella sostanza imparare due licenze e mezzo, anziché tre. Chiaramente AGPL3 indirizza il problema SaaS (Software As A Service, ndr) obbligando i provider che offrono servizi SaaS a condividere le loro modifiche, così come la GPL ha sempre richiesto, prima dell’era SaaS, di condividere le proprie modifiche alla stessa maniera.
Destinatari del messaggio, chiaramente, le grandi compagnie che fanno dell’open-source la base del proprio business:
We should be asking more of companies like Google and Amazon today, since they get so much value from us. But without deviating from the ideals of Free Software / Open Source as some license proposals do.
Oggi dovremmo chiedere di più da aziende come Google e Amazon visto che queste ricavano molto guadagno dal nostro lavoro. Ma senza deviare dagli ideali del Free Software / Open Source come alcune proposte di licenza fanno.
Nell’intervista le domande sono molteplici, dai motivi dell’abbandono alla OSI per arrivare alla recente causa vinta dallo stesso Perens contro Open Source Security Inc. per arrivare a parlare di uno degli hobby del pioniere dell’open-source: la creazione di una rete di satelliti open-source basati su open-hardware nata con l’intento di raccogliere proattivamente informazioni nei periodi tranquilli per far sì che durante le emergenze ci sia tutto l’equipaggiamento necessario ad agire prontamente.
Insomma, c’è poco da fare, un pioniere sarà sempre un pioniere, anche e soprattutto a sessantanni. Seguiremo da vicino gli sviluppi di queste prese di posizione, che ci sembrano coerenti e ben argomentate, non dimenticando che nel frattempo è in corso il processo d’appello della causa sopra menzionata.
Niente paura quindi, c’è da scommettere come il nome di Perens apparirà ancora su queste pagine virtuali.
