Subject:
Re: [discuss] Limits on doc licensing's significance
From:
Rick Moen ####@####.####
Date:
4 Oct 2008 02:01:18 +0100
Message-Id: <20081004010115.GF1041@linuxmafia.com>
Quoting David Lawyer ####@####.####
> Note: Rick Moen didn't write this directly to LDP. He sent it to LDP
> as a quote of what he wrote to another discussion group. So when I
> mention LDP in my comments, I don't mean to imply that Rick Moen
> neglected to consider the situation at LDP.
Not a problem. Thanks for taking care to make sure the context is
clear. (I'm going to try not to be grumpy. ;-> )
In your replies to the points I made to OSI (about fundamental
differences between software and non-software licensing that make
licensing a much less significant problem), you seem to be primarily
agreeing with me but also making additional comments. I'll try
to keep this in reasonable, real-world perspective -- perspective that,
in fact, was the specific point of my OSI post.
> > o Getting access to the preferred form really isn't very difficult for
> > a motivated re-user. (We're not talking about contrived DRM/Kindle
> > scenarios, but rather ordinary documentation -- but even those succumb
> > to screen snapshots and OCR.) At minimum, the full semantics of the
> > work are available to inspection, i.e., there's nothing like
> > software's trait of obscuring through compilation.
>
> Well, getting access to the source does present a problem since
> without source one would have to spend time adding all the needed
> LinuxDoc or DocBook tags, for example, in order to covert text into
> source.
You've quibbled here with wording but (slightly vexingly) ignored what I
actually meant: Yes, you can end up having to re-do markup in order to
re-gain (basically, rebuild) the preferred form -- and so, you're right
that, reading my words in a painfully literal, context-challenged sense,
the preferred form can be "unavailable" but must be rebuilt. The point
is, that's pretty trivial effort, and will always work in a fairly short
period of time. Remember, my point in the thread in question was to
contrast the at-worst nuisance situation for documentation with the
large, and sometimes insurmountable problem with software.
Let me give you a very specific example:
Back around 2000, Eric S. Raymond and I discovered to our surprise,
through chatting with each other, that we were both independently trying
to write the same essay, one on how to effectively seek help from
technical communities. We'd both noticed that newcomers to, in
particular, the open source community often committed self-defeating
mistakes in how they posed help questions, and so we wanted to write
something that communities of users might find useful as tips to
newcomers.
Even though we had slightly different emphases in mind (Eric kept
wanting to talk about help queries to "hackers"; I aimed a bit more
broadly), we kept exchanging passages we'd each written by e-mail.
Finally, with my blessing, Eric stitched a bunch of those passages
together as "How to Ask Questions the Smart Way", which he coded in
Docbook XML and then posted the resulting versioned HTML on his Web
site.
The earliest versions showed, with my blessing, just Eric as the
author/maintainer. However, after the first few times that someone
online quoted to me a passage *I* had written, claiming he was quoting
Eric, I asked Eric to please change the posted author credit (and
copyright statement) to show both our names, which he did.
We've continued to maintain the piece collaboratively, but it's always
been a bit awkward because I've never asked for a copy of Eric's XML
source: Instead, when I want to implement a change, I just grab the
HTML downstream copy and work on it, and then send Eric my changes in
some fashion or other.
To help that process and for various other reasons, a few years ago I
found it convenient to keep a local, HTML-only instance of the essay in
my own public Web space. In effect, I periodically fork Eric's HTML
downstream version (which he produces from his XML source), treating the
HTML as if it _were_ the source, and work on it locally. From time to
time, we at least partially re-synchronise our versions of the essay --
with the major ongoing exception being that Eric has some preferences
in grammar and spelling that I don't share, so our versions keep
diverging to that extent primarily.
If I _wanted_ to, I could sit down for 30 minutes and recreate (or at
least closely approximate) the XML markup of Eric's master version that
I've never bothered to request for him. Or I could ask him for a copy.
In either of those cases, further nuisances would probably follow, such
as either re-doing the XML markup following further refreshes from
Eric's HTML, or asking for Eric's revised XML periodically -- which
frankly is too much hassle for an essay whose HTML instantiation is the
only one that really matters in the first place.
So, there you have a real-world documentation example where, in a
strictly literal-minded way, sure, I don't have (easy, automatic) access
to the "preferred form" (XML), but (1) can recreate/regain that with
pretty trivial effort and (2) it doesn't matter, anyway.
The larger point is that I'm trying to discuss real-world realities
of documentation, as an _antidote_ to the usual harping on theoretical
concerns that actually don't matter. What's slightly vexing about your
comment is that you returned _immediately_ to those exact theoretical
concerns that don't matter.
> > o In part because of the above fact, there's very little barrier to
> > creation of a new, equivalent work if an existing one's terms of usage
> > become a problem.
>
> There is often a barrier and may take some work to overcome it.
Only in the trivial, "so-what?" sense that any creation always requires
work. Big deal. We knew that.
The point was that there is no artificial obstacle as there can be with
software. One can study the working parts -- the "code" (which is human
language) of an existing piece of documentation whose terms forbid the
desired reuse, to any desired degree of detail, with nothing standing in
your way.
> If the work is very outdated, then it isn't much more difficult to
> start from scratch and create a new document than it would be to
> modify the original. But in other cases perhaps only 10% - 20% of the
> doc needs modifying. Then it's going to present a barrier if you have
> to create an entire new document instead of just modifying a small
> part of the old document.
You seem to have decided to interpret my word "barrier" in some
extremely peculiar fashion, _especially_ since my actual phrase was
"barrier to CREATION OF A NEW, EQUIVALENT WORK" (emphasis added).
I mean, c'mon, David. There's nothing wrong with your disagreeing with
what I say -- that being what makes horse races, after all -- but is it
too much to ask for you to respond to what I _did_ say, as opposed to
other things that I didn't?
> For LDP docs, I think the majority of the ones that are
> not being maintained tend to fall into something like the first
> category where it would not require too much extra effort to rewrite
> them from scratch.
Excellent point. Also, many of them have been unmaintained for long
enough that it's not clear that re-use isn't more _work_ than rewriting
from scratch.
> > o The desire to create a new document as a derivative work borrowing part
> > of an existing document is relatively rarely felt. (The desire to
> > update an existing poorly maintained document occasionally does arise.)
>
> It's not felt much within LDP since most docs allow modification and
> also since we don't have enough volunteers.
I _did_ say "desire", not "capability".
> > o For various reasons of real-world perception, authors are often
> > concerned that modified variants of their work will make them appear to
> > have said something they didn't. Software people tend to assume that
> > this is no more of a problem than it is in software, and yet they are
> > not correct.
>
> These reasons are more than just perceptions, LDP has had cases of
> this situation where someone modifies a doc and wrecks it, making it
> look to some that the original author may have done it.
Yes, quite. I stressed this point to OSI because people forget that
one's reputation is exposed to risk from what you _appear_ to have
written much more readily in documentation than in software. This is in
part a cultural problem: The fact that a piece of work might be a
downstream fork and its problems don't necessarily reflect on the
upstream author is more widely understood by software users than by
readers of documentation and other writings (as a general observation).
This risk is a compelling reason why some writings (primarily
non-documentation) really should _not_ be under any form of classic
free licensing. For example, my personal FAQ/rants pages
(http://linuxmafia.com/~rick/faq/) originally had, after much
deliberation, a very clear proprietary licence: Readers were permitted
to mirror any page of that FAQ verbatim _only_.
Later, following an idea of Don Marti's (a friend and, at the time,
technical editor of _Linux Journal_), I appended an "or" clause to
give what Don calls a "bastard reverse copyleft" alternative: Readers
_also_ are permitted to "create derivative works of any sort for any
purpose, provided your versions contain no attribution to me, and that
you assert your own authorship (and not mine) in every practical medium."
> > It's often claimed that documentation's licensing must be compatible
> > with (if not the same as) that of the software it concerns, e.g., for
> > example code included in the docs -- but that's a pretty contrived
> > scenario, in my view.
>
> Well, as Stallman implies, if one can modify the software one needs to
> be able to modify the documentation to reflect the modifications to
> the software.
That is non-sequitur to my (preceding) observation.
A need to modify documentation to follow changes in software creates,
per se, _no_ need for the two to have compatible licensing. It just
doesn't. So, again, you seem to have ignored what I said.
> If something is copyrighted and doesn't allow modification, you can't
> just paraphrase each sentence since no derivative works are allowed.
That depends on what you mean by "_just_ paraphrase".
Copyright law says that the owner has a limited monopoly over certain
rights to the _creative expressive content_ of covered works -- as
distinct from purely functional and other non-creative elements. The
order and selection of sentences, basically the outline of the piece,
might get adjudicated to have sufficient "creative" and "expressive"
qualities to qualify for copyright protection, or might not.
A prudent author would, you're right, structure the work in an at least
slightly different way, to avoid the slender, not-bloody-likely
possibility of the prior author being able to credibly claim that
his/her "creative, expressive" outline format had been cruelly
misappropriated.
But, can we try to stick with real-world scenarios? Realistically,
it's staggeringly unlikely that such a legal attack would even be
feasible, not to mention likely, over even an unsubtle, undisguised,
acknowledged sentence-by-sentence rephrasing. Anyway, I don't remember
anyone proposing to write such a thing (i.e., a literal
sentence-by-sentence paraphrased do-over) -- and, I'd worry about anyone
so mentally dull as to not want to make _some_ improvements to the prior
author's selection and arrangement of points.
(I guess I should not be grumpy about this: You're trying to give some
practical suggestions for rewrites, and your point is valid -- albeit
being possibly a bit short on perspective, which I guess I'll try to
address below in a hapless effort to achieve a balanced view.)
> But facts can't be copyrighted. So it's some work creating a new doc.
> Once might first read it over and take notes. Then study other docs
> on the same topic and add to the notes (or even correct the original
> notes). Then organize all this into a new doc which should not follow
> the organization of the original doc (or at least not closely).
Well, sure, but I think for all practical purposes the notion of
someone's scheme of organisation within a HOWTO being adjudicated as a
copyrighted "creative, expressive" element is pretty laughable. I don't
think this is really, realisticaly something to lose sleep over.
> It should be a significant improvement over the original doc and
> present new information.
I can't see how this can fail to be the case, at least arguably so --
but don't think there's any legal-strategy obligation to make absolutely
certain of this. It's merely a good idea on its own merits.
> It should give credit to the sources of information
> used, including the original doc.
Well, that's just good manners. It's not a legal obligation (outside a
derivative-work scenario where an existing credit must be preserved).
> A problem arises if one wants to merge two docs with incompatible
> licenses. I don't think this happens very often.
Can you name even _one_ instance in LDP history of someone _really_,
seriously wanting and needing to do this?
After hearing for decades about how vital the need to do this with two
bits of documentation is -- always expressed by software people -- I
found myself asking "OK, when has this 'code reuse' scenario actually
happened in LDP history?"
I find, in short, that that capability is typically asserted, in
automatic fashion, to be absolutely vital, but then in practice never
used. Real-world borrowings either small enough to be fair use, or
are functional contents rather than expressive, or are specifically
authorised for your purposes by a friendly author -- or there are
other compelling advantages to just writing something new for the
purpose.
Never in the history of documentation can I find even one example of
someone seriously saying "I was going to create a magnum opus by
borrowing chapters from Alice and Bob's separate free-licensed
documents, but their licensing conflicts, and they both refuse
to grant licence exceptions [ / cannot be reached / etc.]."
> But still, it would be nice for everything on the wiki to use the same
> license.
It would be nice if all free / open-source software authors would use
the same licence, too -- but it ain't gonna happen. So, it's futile
spending time wishing that it were so. Similarly, unless LDP wishes to
jettison a bunch of its existing free-licensed documentation (not
limited to, but including, mine) that _should_ be on the wiki, and
wishes to alienate prospective authors who prefer some other
perfectly-OK licence, it should forget about the pipedream of
"everything having the same licence".
> And what I think a would be a good license for LDP hasn't been written
> yet.
I'm not saying that you're wrong -- but I'm struck with the irony of
your saying it'd be nice if everything (on the wiki) had the same
licence, and _then_ implying that yet another documentaiton licence
should be written. It's because people have had a series of different
views about what a licence should say, that we have diverse licences
already, a good handful of which are clearly OK for LDP's needs. And
that, in turn, is why everything under one licence gets less likely
every time someone tries out an idea -- including, perhaps, yours.
> For one, I think that a license should not allow people to distribute
> stale documentation unless it's labeled as such (or reached by a link
> named "archive" or the like).
I fully understand and sympathise with the appeal of such a requirement,
but I'm pretty sure that conventional definitions of "free" (such as
DFSG and OSD) tend to preclude mandatory elements (which was Debian
Project's problem with GFDL docs having invariant sections, in the
General Resolution that decided such things are non-free).
> Also, the adding of advertising to the doc shouldn't be
> allowed, including cases where it's presented in another frame or
> pop-up ad, etc.
Again, I understand the reason you say this, but restricting commercial
reuse is pretty much uniformly considered to render a licence non-free.
In both of the above cases, LDP might wish to consider allowing those
sorts of non-free licence provisions as being sufficiently compelling
despite their non-free results, but should be aware of the consequences
of so doing (e.g., exclusion from distros that are being picky about
non-free contents).
