While looking around for license for the free dictionary I found this
http://i18n.kde.org/doc/doc-primer/licenses.html
It's a very nice license based on GFDL but still GPL compatible
avoiding both the various problems of GPL and GFDL.
It's used by kde for their docs and it's even accepted by the debian people;)
The reason I ask: It seems that it only addresses "Invariant Sections" issue - which is only one out of the three objections described in the Debian position statement:
http://people.debian.org/~srivasta/Position_Statement.html
If I get srivasta's interpretation of GFDL right, you still have:
* "Transparent and Opaque" issue - e.g.: any mirror serving a binary package containing a compiled form of your docs will be forced to keep serving the source package for at least one year *after* the binary package was *removed* from archive (and Debian do sometimes remove orphaned/deprecated packages from their archives)
* "DRM" Issue - e.g.: You can't save the doc on any DRM protected media (such as encrypted filesystem) - not even a private copy for personal usage, not even if you include the source on non-DRM media.
While I doubt that this interpretation is what the authors of GFDL really ment (certainly not with the DRM issue - where RMS said it would be clarified in future versions), with current version of the GFDL, it can be naturally understood this way (and that's more than enough for some people to sew, and for others to fear being sewed).
And to avoid being idly argumentative, let me suggest the following additional paragraphs:
----
Clarifications:
* The phrase "copies you make" in Section 2 of GFDL is understood to apply only to copies made for distribution, not to copies for personal use.
* For the sake of the third paragraph of GFDL Section 3, if you make the transparent copy available from the same site and with equivalent means as the opaque copy, and this fact is clearly stated in the opaque copy, the transparent copy is considered as "included along" with the opaque one, and the restrictions placed upon usage of the other option mentioned in the paragraph do not apply.
----
I believe with these added you might be safer DFSG-wise.
(note: the second clarification is a somewhat wild interpretation, and might be used as a loophole to render the whole "paragraph 3" void. This is related to the fact that I believe this paragraph might really place problematic restrictions)
