[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Licenses for non-software entities



  I agree with Manoj that it is important to put those standards that are
immutable in the hands of users and developers.  What if we widened the
definition of contrib/ to allow immutable documents?  There's no reason they
have to be packages in main/, contrib/ is just as good for the purposes
of our users.  We can still say "Document ABC-413b is on the Official CD". 
It's not modifiable by Debian, we haven't had the opportunity to edit it to
fit our needs, so perhaps we shouldn't claim it as part of Debian (in
main/).  It still belongs to the upstream authors, they have (contrib/)uted
it to us and allow us to distribute it any way we see fit.
   I'm not suggesting we allow immutable programs into contrib/.  That could
potentially affect our system security and robustness.
   Reformatting and typos aren't very important for non-code.  Translations
would be nice, but the translation is never going to be the standard, so one
route would be to make translations more of a general commentary on the
standard rather than a literal translation.  This avoids the entire
copyright issue, and in no way confuses the translation with the original
document.  I don't think we'll have many volunteers to translate standards
documents anyway.  Can you really think of anything more boring?  I think
most people would want to be well paid to do precise translations of
technical documents.
   What about data that isn't directly human readable, but also isn't code? 
I'm thinking about imagery, sound clips, schematics, etc.  I could see all
of these being classified as "documents" as well.
   And just to confuse matters: postscript is a programming language, but it
isn't very editable.  Any document policy that distinguishes between
"documents" and "code" needs to decide what postscript is.  Microsoft Word 6
format is also a programming language, but I don't think we need to worry
about it.
   The many macro-capable formats out there are probably a good argument
against having a separate document policy.  Hmm.  Imagine an immutable
macro-virus-infested standards document..

-- 
Dr. Drake Diedrich, Research Officer - Computing, (02)6279-8302
John Curtin School of Medical Research, Australian National University 0200
Replies to other than Drake.Diedrich@anu.edu.au will be routed off-planet


Reply to: