[Discussioni]debian weekly news

[Leonardo Boselli]

On 30 Apr 2003, at 12:54, Christian Surchi wrote:
> > è previsto anche dalla legge del diritto d'autore per le opere
> > letterarie, e fa parte dei "diritti inalienabili"
> Legge di quale stato? Ci sono situazioni profondamente diverse nel
> mondo, non stiamo parlando di una licenza per l'Italia.
la legge vigente in Italia . è senz'altro possibile che in altre parti del 
mondo sia diversa, ma facevo il caso particolare.
 
> > Su qui ci sarebbero da dire tre cose:
> > la prima che occorrerebbe distinguere tra la man-page del
> > programma e altri tipi di documentazione.
> > La Man page dovrebbe seguire la stessa licenza del sw, altra
> > documentazione invece le norme generali per la documentazione,
> > quindi se io faccio una man page [che non rimanda altrove] e delle
> > specifiche in linguaggio estremamente tecnico e criptico, e una
> > serie di pagine HTML o info che lo descrivono più a fondo, allora
> > queste ultime le gestisco come voglio, con la licenza che voglio e
> > se uso la FDGL  va bene lo stesso.
> il manuale di emacs dove lo mettiamo, visto che e' uno degli esempi
> concreti della discussione? :)
infatti il manuale di emacs non è una man page ma un file info ....
 
> > Circa alla obsolescenza se a qualcuno non va bene e vuole fare un
> > aggiornamento allora può benissimo o riscrivere tutto da capo,
> speriamo che gli sviluppatori di software libero non facciano il tuo
> stesso ragionamento allora :)
non era partito il discorsa proprio del distinguere SW e 
Documentazione ?
 
> > oppure affiancare il proprio commento (non necessariamente come
> > invariante).
> questo non e' banale, come dicevo, "pare" non sia neanche possibile
> indicare come obsoleta una parte invariante
e dove è scritto: al testo obsoleto faccio precedere "Nella versione 
originale viene detto" e dopo "Per la versione corrente invece ...".
E così mantieni pure la storia della documentazione.
D'altra perte per il SW è considerata cattiva regola "potare" il 
changelog ....
 
> > E riguardo i fork: se c'è un fork occorrerebbe specificare ache se
> > ci sono sezioni invarienti assolute  o invarienti nel capitolo. Nel
> > secondo caso se sostituisci integralmente il capitolo, allora puoi
> > togliere la invariante. Le invarianti "tecniche"quindi per essere
> > accettabile dovrebbero essere di questo tipo.
> non ti seguo... le invarianti sono invarianti punto e basta, non e'
> che puoi prendere i singoli capitoli e fare quello che ti pare.
Quello che suggerivo è di fare due livelli di invariuanti: quelle valide 
nell'insieme dell'opera e quelle il cui scope è limitato a una 
sezione, ossia che se togli tutta la sezione allora puoi togliere 
anche le relative invarianti.
 
> > La invariante in un certo senso garantisce che la documentazione non
> > si perda. Andando al limite: una documentazione tutta invariente è
> > blindata contro le modifiche, quindi resta per la eternità, una
> > documentazione senza invarienti potrebbe essere modicficata
> > completamente, e la opera originale (che magari si riferisce a una
> > vacchia versione che girerebbe bene su una certa macchina) non
> > riesci più a trovarla ....
> Mah... se la pensi cosi' allora potresti anche scrivere codice
> immutabile, per la paura che venga cambiato o vada perduto... :)
La licenza artistic, che è "ammessa" ha dei vincoli sul nome del 
programma derivato, e anche questo è un esempio di invariante ....

--
Leonardo Boselli
Nucleo Informatico e Telematico del Dipartimento Ingegneria Civile
Universita` di Firenze , V. S. Marta 3 - I-50139 Firenze
tel +39 0554796431 cell +39 3488605348 fax +39 055495333
http://www.dicea.unifi.it/~leo