Re: Licenses for non-software entities
[delayed due to DNS problem]
On Thu, Aug 13, 1998 at 12:43:35PM -0500, Manoj Srivastava wrote:
>
> Actually, I think we shoyuld not overload contrib with this;
> right now, contrib has a clear criteria, and we should retain
> that. What are the objections to a separate Verbatim area?
I don't have any philosophical objections. From a practical point of
view adding a new area is quite a bit of work, distributed among a lot of
people. Anyone getting updates over the net has to edit their upstream
source. The ftp maintainers have a bit of work to do. Partial mirrors have
to add verbatim to their config files. Maintainers of document packages
need to edit control. No one has a huge burden, but it's a large fraction
of everyone involved in debian and shouldn't be done lightly.
On the plus side, losing documents shouldn't break anyone's system.
> Remember, if we go with this, *all* verbatim documents should
> go in there. That cetainly means the FSSTND and the FHS, for
> starters. What about the GPL etc? By all rights the GPL itself should
> be in the verbatim section.
Aren't licenses and copyright notices a special case legally anyway?
I've heard they are not covered by copyright (you can take a license, make
minor changes, and use the new license for your own work). The modified
license would be invalid for the original work.
> Umm. Do you mean that we should not allow immutable documents
> because, in the future, there may be macro-virus-infested standards
> document? I would rather say that standards in macro-capable formats
> shoukld be mutable (rather than throwing out the baby with the bath
> water).
This means all postscript documents need to be mutable. I suspect there
are already immutable standards distributed in postscript. Consider the
utilities packaged with gs that are written in postscript (ps2epsi.ps). Not
all postscript files are documentation, so how do we distinguish them?
Someone who really wanted a program to be immutable but still part of Debian
could abuse the policy by writing the program in postscript. Insisting on
-DSAFER for postscript documents would be a start (no file output operations
allowed).
The macro-virus-infested-standard was just a twisted imagination. I'm
in favor of distributing immutable documents, but there are some
difficulties.
--
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
----- End forwarded message -----
--
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: