The Tech Help You Need

[Lex Spoon <lex@xxxxxxxxxxxxx>]

I like Martin's general idea of a blanket, wiki-wide license plus
exceptions for code that includes an explicit license notice.
Additionally, there is no particular restriction that the text and
code have to be under different licenses; we can very well say that it
is all under the same license if we want.

For the license choice, why not be as liberal as possible?  The
general idea is that, if someone is posting to a wiki, then generally
they are happy to have that content widely quoted, modified, and
reused.  If public domain does not make sense in our international
context, surely there is something close, e.g. "I release this content
for use for all purposes".  Runners up might be the MIT or Scala
licenses, which are close and are more commonly used.

While the GFDL is the FSF's recommended license for documentation,
significant problems with it have turned up.  For your consideration,
I'll append part of the statement put before Debian's members a while
ago.  In addition to the three problems this text identifies, note
that GFDL content is not even compatible with GPL content.

Draw your own conclusions about why the FSF, with all of its legal
resources, might release such a license with these surprising
properties.


-Lex





The full resolution is at http://www.debian.org/vote/2006/vote_001 .
My comments are in [...] brackets.


(2) How does it fail to meet Debian's standards for Free Software?

The GFDL conflicts with traditional requirements for free software in
a variety of ways, some of which are expanded upon below. As a
copyleft license, one of the consequences of this is that it is not
possible to include content from a document directly into free
software under the GFDL.

The major conflicts are:
(2.1) Invariant Sections

The most troublesome conflict concerns the class of invariant sections
that, once included, may not be modified or removed from the
documentation in future. Modifiability is, however, a fundamental
requirement of the DFSG, which states:

    3. Derived Works

    The license must allow modifications and derived works, and must
    allow them to be distributed under the same terms as the license
    of the original software.

Invariant sections create particular problems in reusing small
portions of the work (since any invariant section must be included
also, however large), and in making sure the documentation remains
accurate and relevant.  

[This is actually no big deal for the wiki; we could just say we have
 no invariant sections.]


(2.2) Transparent Copies

The second conflict is related to the GFDL's requirements for
transparent copies of documentation (that is, a copy of the
documentation in a form suitable for editing). In particular, Section
3 of the GFDL requires that a transparent copy of the documentation be
included with every opaque copy distributed, or that a transparent
copy is made available for a year after the opaque copies are no
longer being distributed.

For free software works, Debian expects that simply providing the
source (or transparent copy) alongside derivative works will be
sufficient, but this does not satisfy either clause of the GFDL's
requirements.

[I do not understand the subtleties here, but it sounds even more
complicated than GPL's requirements about distributing source code.
If we take our license choice seriously, then we would have to think
carefully about, e.g., enabling printing of the wiki, how to make a
stand-alone "transparent copy" for use when not net connected, how to
deal with changes in the wiki's format should we ever change wiki
software, and how to deal with stuff extracted from the wiki where we
might want to transition to a new format for the "transparent copy".
Would this be time well spent?]



(2.3) Digital Rights Management

The third conflict with the GFDL arises from the measures in Section 2
that attempt to overcome Digital Rights Management (DRM)
technologies. In particular, the GFDL states that You may not use
technical measures to obstruct or control the reading or further
copying of the copies you make or distribute. This inhibits freedom in
three ways: it limits use of the documentation as well as
distribution, by covering all copies made, as well as copies
distributed; it rules out distributing copies on DRM-protected media,
even if done in such a way as to give users full access to a
transparent copy of the work; and, as written, it also potentially
disallows encrypting the documentation, or even storing it on a
filesystem that supports permissions.

[This has terrible implications.  It seems to imply that if you send
an encrypted email to someone, then you may not include any GFDL
content.  Hmm, in fact, 'GFDL "encrypted filesystem"' gets a lot
of interesting Google hits.]