Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual
* Matthew Garrett:
> Perhaps an easier way to do this would be to look at the DFSG and work
> out what changes need to be made. We have a set of freedoms that we
> believe software should provide - rather than providing an entirely
> different set of freedoms for documentation, we should try to justify
> any changes in those freedoms.
>
> Personally, I'm inclined to believe that free documentation should have
> all the freedoms that we think should be provided by free software. Do
> you believe it needs more freedoms? Fewer freedoms? A slightly different
> set of freedoms?
I'd prefer a slightly different set of freedoms, but this goal is
impractical. For instance, I believe that the GNU GPL is not a free
documentation license because it unnecessarily complicates the
distribution of printed copies, but it would be ridiculous to outlaw
all GPLed documentation for this reason.
IMHO, some questions should be answered before working on
documentation guidelines. My current list includes:
* If upstream includes a copy of an RFC (that is, documentation
which is non-free but redistributable), should we really stop
shipping pristine sources? I can understand that we don't want to
build RFCs into binary packages, but OTOH, the pristine sources
concept has a reason.
* Should source packages in main be allowed to build documentation
packages which go to non-free? This resolves a potential
synchronization problem, and would prevent some completely
unnecessary work.
* Shouldn't documentation include proper source code, including
source for most of its artwork? This means hi-res bitmap images,
vector graphics for technical drawings, FLAC instead of Ogg
Vorbis, etc. Of course, open formats with free editors are
required.
What about documentation indexes? Should it be possible to
regenerate them automatically after the documentation has been
modified?
* What about non-technical prose? Does it have a place in Debian at
all? Can we aford some invariant parts, such as license texts,
copyright statements and legal disclaimers, credits, mission
statements, provided that they are neither executable code nor
functional end-user documentation?
Reply to: