On Thu, Aug 14, 2008 at 7:57 PM, robert_horning(a)netzero.net
<robert_horning(a)netzero.net> wrote:
One thing that I think is reasonable to ask for is
that the GFDL is one of the licenses that must be included. I don't think there is
any dispute here.
Nope, none whatsoever.
The problem comes from those editors who decide to
contribute to a wikibook, but for some reason or other explicitly don't want the
"dual licensing" to continue. A great deal of this can and IMHO should be in
some sort of policy guideline for the project.
Yes, but I think this is just a small aspect of the larger problem.
It's not just users who explicitly want GFDL-only, but also people who
are lead to believe that Wikibooks is GFDL-only and edit a
dual-licensed book without knowledge of it. The last thing that we
need right now is to insist that all new editors familiarize
themselves with the licensing intricacies of every single book before
attempting an edit. Our barrier to entry is already high enough
without demanding our editors navigate an uneven and haphazard legal
landscape.
There are obviously some steps we could take to mediate this problem.
If we altered the copyright notice at the bottom of the edit page, we
could inform users that some books use more complicated licensing
schemes then the default GFDL-only. However, even with warning there
are people who aren't going to read that notice or understand it.
There are some book projects that there are some very
legitimate reasons for wanting to continue the dual-license. We've gone over before
some of those book projects that want to be dual-licensed GPL/GFDL in order to ultimately
include some GPL'd software into the book in some sort of final distro. I've also
seen some books that were to be distributed with other items that were of some other
free-type license (such as CC-by-SA or some other similar license). In these cases,
maintaining the dual-licensing can be incredibly useful as we get the benefit of having
the free content on Wikibooks, but the "end users" can also use the content in a
completely different context.
In the cases you mentioned, an aggregate could contain portions of
content that are licensed separately. Think about how fair use
excerpts are included in GFDL articles at Wikipedia. Or, think about
how CC-BY-SA images are included in our books. Code snippets can be
licensed separately, and we should find a way (special templates?) to
support that more transparently.
I would hope that dual-licensing aren't completely
dismissed from Wikibooks, and I especially would be abhorred by some
"administrator" or other user randomly going through all of the current
wikibooks and removing all mention of any dual-licensing content that currently exists.
Such actions are IMHO contrary to a wiki spirit and this is something that should receive
further debate... especially if such drastic actions are taking place.
This isn't something that is restricted to admins, any ordinary user
could do it, and in a legally convincing manner. A dual license is an
either-or affair: A reuser can choose one license or the other as
their preference allows. All a user would need to do on a
dual-licensed book is to make an edit that is GFDL-only, thus negating
the second license.
Further, consider the potential pitfalls if a user decided to make a
CC-BY-SA edit instead, thus negating the GFDL component of the
dual-license. In a dual license, it's perfectly within the rights of
the editor to select the second of the two licenses for their
derivative. What a pickle we would be in if our books were all
incompatible with each other.
All this said, the dual-licensing is something that
should be decided when the book is established and is nearly impossible to change once
multiple authors have contributed (in a significant manner) to its contents.
I'll reiterate my points: We risk creating an uneven landscape that is
difficult to navigate. We risk raising the already formidable barrier
to entry, asking new users to know and understand a myriad of licenses
and license combinations.We run the risk of creating books that become
legally incompatible with each other. +
As many opportunities and benefits as there are for flexible licensing
schemes, I think we are far better served with a consistent and simple
licensing scheme for now. The best I think we can do is to allow
particular revisions to be flagged as dual-licensed, if all
contributions previous to that revision are likewise licensed. This,
of course, raises a certain amount of confusion in and of itself, and
might be untenable for long-term ubiquitous use.
I just don't see how the additional flexibility we gain from this
offsets all the other potential problems inherent in it.
--Andrew Whitworth