[Formati] Definizione e obiettivi

[Mirko Maischberger]

Simo Sorce wrote:
> On Fri, 2005-01-28 at 18:10 +0100, Mirko Maischberger wrote:
> 
>>Per definizione pragmatica intendevo una definizione che parte 
>>dall'esistente (elenco di quelli che riteniamo essere formati liberi) e 
>>prova a darne una definizione per sintesi.
> 
> 
> SI, l'avevo intuito, e la ritengo una posizione perdente e soprattutto
> una posizione che pone il fianco ad inconsistenze a breve termine e a
> lungo termine.

Sì, concordo. E' un terreno scivolosissimo. Il mio dubbio si basava solo 
sul fatto che non siamo nel 1984, che oggi il software libero esiste ed 
usa molti formati: quindi una definizione di principio scorretta 
potrebbe porre molti più vincoli e problemi di quelli necessari.

Inoltre secondo me partire da definizioni di principio, correggendo il 
tiro sull'esistente solo a posteriori è ancora più rischioso che tentare 
una sintesi.

In più le obiezioni ed il lavoro che ho visto fare su questa lista sono 
sempre state molto aderenti ai fatti (embrace&extend, pdf sì/pdf no, etc.)


> Secondo me stai confondendo formato standard con formato libero (anche
> perché l'ultimo non è neanche ancora definitivamente definito :-)

Hai una definizione ufficiale e mondialmente riconosciuta di "formato 
standard" da passarmi? Credo che sarebbe un bel punto fermo dal quale 
iniziare :-)


> Non importa il nome che dai al formato.

Il senso era: immagina un mondo senza ECMA... il software libero non 
avrebbe ad oggi un formato per i caratteri... orrore ti sto scrivendo 
questa mail in un formato proprietario... È un'esagerazione? Sicuro?

Comunque anche sulla storia dell'importanza del nome non sono sicuro. 
L'importante è capirsi, vero, ma il nome del formato _libero_ è uno: se 
poi ne esistono altre varianti non libere vanno chiaramente indicate 
come tali, specialmente da un documento di principio. Sono specifiche 
equivalenti, ma immagino anche che non siano identiche.

Metti che si scopra un'incompatibilità tra ECMA-6 ed 
ANSI-Xvattelappesca.x, magari a causa di un errore tipografico. Come lo 
dici al resto del mondo che stanno sbagliando loro e non tu che usi 
ECMA-6... Ti assicuro che nelle specifiche ECMA-6 "ASCII" non c'è 
scritto mai...


> Se leggi il documento postato vedrai che il fatto che le specifiche
> siano distribuite a pagamento non è una pregiudiziale per la libertà del
> formato.

Dal documento che ho letto:
"""... condizione necessaria affinché il
Formato possa essere definito libero è che la documentazione che lo
descrive sia distribuita insieme all'applicativo che ne fa uso _senza_
_costi_ _aggiuntivi_ o che sia liberamente accessibile a chiunque 
_senza_ _restrizioni_ attraverso un comune mezzo di comunicazione 
telematica...
"""

Io il "senza restrizioni" l'avevo inteso come "eppure gratis".
E l'idea del bundle con il programma è forse efficace, ma estremamente 
pragmatica. E sinceramente mi pare un po' una forzatura.


> Non importa, quando fu definito il "software libero" pensi ce ne fosse
> veramente molto in giro? e quando fu definito il copyleft? :)

Sì, ci avevo pensato, ma ho imparato su queste liste che il software è 
peculiare. Mentre non sono sicuro che i formati lo siano, in particolare 
non allo stesso modo del software.


>>Personalmente mi andrebbe anche bene, non fraintendermi, ma forse non 
>>sarebbe la mossa politicamente più azzeccata per aumentare la diffusione 
>>del software libero.
> 
> Le dichiarazioni di principio non vengono a patti con il contingente,
> altrimenti non si possono chiamare "di principio".

Questo è vero, ma è anche una tautologia.


>>Il programmatore ha sempre accettato l'onere di dover comprare 
>>documentazione, anche Linus credo abbia pagato le specifiche POSIX, ciò 
>>  rende il kernel meno libero? La verità è che la risposta non la so.
> 
> Ripeto che la gratuità o meno delle specifiche non è (entro certi
> limiti) pregiudiziale di per se stessa alla libertà del formato.

Sì, ma non era quello il punto sollevato. La distinzione era tra 
specifiche non libere gratuite e specifiche non libere a pagamento.

Le specifiche POSIX non sono solo a pagamento, immagino siano anche 
coperte da copyright e che non sia possibile classificarle come 
documentazione libera, indipendentemente dal prezzo. Sbaglio? (in 
effetti non credo di averne mai letto la licenza di copyright)

Poi lo ammetto: sto provando a vedere se riusciamo a tenere dentro la 
definizione di "libero" almeno l'ascii...


>>>Io mi atterrei alle caratteristiche del formato, più che al fatto che
>>>esistano software o validatori. Altrimenti un formato non sarà mai
>>>libero finchè non viene implementato (e si rischia che non venga
>>>implementato perchè non è libero :-)
>>
>>In realtà, anche se sinteticamente, stavo provando ad esporre un punto 
>>di vista piuttosto complesso che non credo possa essere liquidato così 
>>facilmente :).
> 
> 
> Stavi definendo delle linee pragmatiche, un po' come cercare di scrivere
> la GPL prima di definire cos'è il software libero, secondo me non è il
> punto di partenza giusto.

Sono d'accordo in parte.

Io non sono dell'idea di appiattire "formato" su "documentazione del 
formato". Non m'interessa definire "formato con documentazione libera", 
ma "formato libero". Vedo la documentazione come un aspetto importante, 
molto importante, ma non fondante. E' un errore secondo me inchiodarsi 
sulla documentazione per definire "libero".

Dire: "un formato è libero se è trattabile in modo corretto e completo 
da software libero" è una pura affermazione di principio, affatto 
pragmatica. Solo che secondo me non era sufficiente ed ho voluto 
aggiungerci la documentazione e la validazione (uscendo un po' dal puro 
principio).

L'aggiunta della richiesta del validatore libero IMO è tanto pragmatica 
quanto lo è la richiesta di documentazione libera. Coprono aspetti 
diversi, ma ugualmente importanti. La staticità del formato e la sua 
conoscibilità.


>>Il problema che poni per me non è corretto: anche un software libero non 
>>è libero finché qualcuno non lo implementa.
> 
> Finché qualcuno non lo implementa non è software, quindi non ha senso
> parlare di libertà o meno di qualcosa che non esiste. Mentre un formato
> esiste dal momento in cui ne fai una descrizione, se a questo per farlo
> diventare libero aggiungi altri obblighi (avere del sw o dei validatori)
> stai sviando dal descrivere quali caratteristiche devono avere le
> descrizioni e ciò che le regola.

Un formato dati, a mio avviso, esiste nel momento in cui c'è un software 
che lo tratta. Un formato dati libero quindi "appare" se "appare" il 
relativo software libero. E' una definizione in subordine al software 
libero, così come il formato dati è in subordine al software (sembra 
un'affermazione a dispetto del famoso libro di Wirth, ma quando parla di 
strutture dati parla più in generale, a noi interessano solo quelle che 
"escono" ed "entrano" in uno o più software).

Qui mi viene da pensare: se "algoritmi+strutture dati=programmi" allora 
se un programma è libero lo sono per forza di cose anche i formati relativi!

Come avrai capito non ho ancora le idee del tutto chiare, per fortuna.

>> Aggiungi poi che parlare di 
>>libertà del formato è come parlare di libertà delle idee... credo che 
>>sia per questo che la definizione è sfuggente.
> 
> 
> In parte si, m un formato è qualcosa di ben più concreto di un'idea.
> Prova a prendere le specifiche del TCP/IP e vedrai che ci sono notevoli
> differenze tra semplici idee e un formato consolidato e completamente
> descritto.

Non sono affatto convinto. Cosa sono le specifiche TCP/IP secondo te? 
un'invenzione? un'idea astratta? un'idea particolareggiata? 
un'implementazione in pseudo-codice? Un'idea di base completata da una 
serie di convenzioni? o cos'altro?

IMO, un'idea dettagliata rimane un'idea. E una convenzione non è niente 
di più di un'idea condivisa. E' solo un'idea realizzata che può meritare 
un altro status.

Certo che le specifiche TCP/IP sono delle idee esposte in modo talmente 
chiaro da essere abbastanza vicine ad una realizzazione. Ma sempre 
parole sono. Non posso copiarle, ma posso capirle e implementarle 
liberamente. Posso anche scriverne una versione modificata, senza 
bisogno che nessun documento me lo conceda. Se non voglio riscrivere 
tutto dall'inizio, a partire da una specifica libera, posso scrivere un 
documento che descriva le sole modifiche. Con i rischi del caso, ma ben 
minori del richiedere documentazione libera...

>> Da questo punto di vista, 
>>se non ci sono brevetti pendenti, un formato è "libero" anche se non 
>>documentato.
> 
> 
> I brevetti possono essere un problema ma non lo sono per forza, dipende
> tanto da quali obblighi pongono a chi deve implementarlo/usarlo il
> formato.
> Un formato segreto è altrettanto non-libero.

Sì, ma è sempre un punto di vista... Secondo me molti qui sarebbero 
portati a dire che XCF (gimp binario) o .blend (Belnder) sono formati 
liberi, ma questi formati non sono documentati (non al dettaglio di 
TCP/IP, almeno stando a quello che ho trovato in rete).

Ad oggi poi non conosco un singolo formato che goda di documentazione 
libera (del livello di quella del TCP/IP che citavi). O nella 
documentazione di un formato ci fai rientrare anche il codice sorgente?



>> Perché un formato invece sia facilmente "portabile" a 
>>software e a piattaforme diverse possono essere necessarie molte altre 
>>caratteristiche accessorie.
> 
> 
> La difficoltà tecnica non è un parametro di cui mi preoccuperei nella
> stesura dei principi, quello che conta è la "difficoltà legale".

È sensato... ma sono dubbi che sto ponendo dopo aver letto gli archivi 
di questa lista, su temi che non sono stati abbastanza approfonditi. Si 
potrebbe dire che non sono dubbi miei. Io, alla fine di questa 
discussione cercherò di fare un lavoro che sia anche di sintesi, ma per 
questo ho bisogno di più pareri.


>>Il validatore è sicuramente un "accessorio" importante, infatti mentre 
>>per il software la maggior libertà è quella di poterlo cambiare, per un 
>>formato la miglior garanzia è che non cambi troppo spesso.
> 
> 
> Qui tocchi un nervo scoperto. Un formato, _secondo me_, quando è libero
> deve anche permettere derivazioni a patto che sia chiaro ed evidente a
> tutti che ciò che si è derivato è un'altra cosa.

Ok, nessun problema: per derivarlo, se vuoi che sia libero, bisogna che 
tu ti faccia un nuovo validatore... mica voglio impedirlo. Se poi lo 
chiami pure con un altro nome...

Ma il "permettere derivazioni", secondo me, va ben al di là dello scopo 
del documento sui formati liberi. Se un formato è libero, la derivazione 
deve essere (IMO) solo un effetto collaterale.


>> Almeno 
>>fintanto che, in Europa, la possibilità di modificare un formato sarà 
>>garantita a tutti e indipendentemente dalla volontà di chi lo ha creato 
>>(sempre salvo brevetti). Pensa poi al valore che ha avuto il validatore 
>>per la rinascita di HTML e il freno che ha messo alle tendenze ad 
>>"estenderlo" autonomamente di Netscape prima e di Microsoft poi.
> 
> 
> Il validatore è uno strumento per capire se un particolare file aderisce
> ad una specifica di formato, non definisce il formato in se.

Anche la definizione del formato non è il formato.

Neanche l'implementazione definisce il formato, ma io vorrei spostare 
l'attenzione dalla libertà della documentazione del formato alla libertà 
del formato stesso. Ti sembra corretto?


>>Un esempio calzante a questo proposito è RTF: inutile dire "se è 
>>documentato è libero", se poi non esiste un modo per verificare che il 
>>software proprietario che lo implementa, che è di fatto 
>>l'"implementazione di riferimento", lo faccia correttamente. RTF, per 
>>come è implementato, è libero poco più del .DOC.
> 
> 
> Invece avrebbe senso, quello che bisognerebbe poter fare è costringere
> chi ne fa derivati non conformi E non liberi a cambiare nome, a non
> poter dichiarare di generare documenti .rtf, in quesot caso il
> validatore è uno strumento utile a capire se c'è o meno violazione ma è
> solo uno strumento accessorio, non deve rientare nella definizione di
> principio, ma in una successiva serie di best-practice o cose del genere
> IMHO.

Beh, ma "costringere" non si può... al limite si può "sbugiardare" e lo 
strumento più efficace per farlo è un validatore. Certo che essendo un 
"accessorio" potrebbe restare fuori dalla definizione ed essere solo una 
raccomandazione.


> No, mi riferisco al fatto che OOo, ha "adottato" .doc, .xls, .ppt, ma
> non per questo i formati suddetti sono più liberi. Sarebbe lo stesso se
> fossero documentati bene ma coperti da brevetti con licenza non-RF.

Già e qui c'è un altro problema: il formatto .doc salvato da OOo è 
implementato come software libero. Se gli avessero scritto pure della 
documentazione libera potrebbe venir fuori che .doc è libero... E non 
sarebbe un male... beh, non in presenza di un validatore :)


>>Non l'avevo notato, forse lo dovrei rileggere meglio. È la stessa 
>>versione che c'è su cvs?
> 
> Credo di si, ma controllerei.

Dopo una breve ricerca mi pare di sì, anche se su cvs mancano le ultime 
correzioni di Potortì. La divisione di cui si parlava (tra formati 
liberi e formati accettabili) però non mi pare sia nemmeno accennata, 
forse era stata solo pensata.


-- 
Mirko Maischberger - jabber: mirko at jabber.linux.it - GPGKey: 5B35D286
Mail HTML o con allegati potrebbero non ricevere attenzione immediata