discuss: Thread: Limits on doc licensing's significance

Here are a couple of messages I sent to OSI's licence-discussion mailing
list last month, when documentation licensing came up.  The point is to
put in perspective the degree to which documentation licensing matters
-- which is much less than many people think.  (Having docs under any 
forkable licence is useful, but even its absence is less significant
than is the case with software.)




 Date: Mon, 4 Aug 2008 20:47:28 -0700
 From: Rick Moen ####@####.####
 To: ####@####.####
 Subject: Re: Creative Commons

Quoting Raj Mathur ####@####.####

[snip]
> However, I don't see how you can go wrong using one of the CC licences, 
> which are the de-facto standard for open document publishing and 
> implicitly approved by the OSI by use.  Any OSI board member (I used to 
> be one) would probably advise you to choose the CC licence that meets 
> your needs and go ahead with it.

It should be bourne in mind that most of the CC licences are (by design)
proprietary.  That is, some of them intentionally do not grant the right
to create or distribute derivative works, and some of them intentionally
grant that right only for non-commercial re-use.

Applying the OSD as criterion, the current 3.0 licence revisions divide
like this, in my opinion:

Proprietary
-----------
Attribution-NoDerivs
Attribution-NonCommercial-NoDerivs
Attribution-NonCommercial
Attribution-NonCommercial-ShareAlike

Open source
-----------
Attribution
Attribution-ShareAlike



 Date: Mon, 4 Aug 2008 23:07:00 -0700
 From: Rick Moen ####@####.####
 To: ####@####.####
 Subject: Re: Creative Commons

Quoting Raj Mathur ####@####.####

> OK, I stand corrected -- thanks for the insight, Rick.  On the other 
> hand, I don't know how far we can go applying criteria for software to 
> documents -- what you propose appears reasonable and intuitive, but I'd 
> still advise caution when applying the OSD directly to document 
> licences.

Very good point (and the original answer still pertains, that OSI simply 
doesn't have non-software licensing within its bailiwick in the first
place).  

Opinions on documentation licensing tend to be surprisingly contentious
(and I wasn't even particularly thinking of the Debian vs. GFDL affair); 
many commentators seem to forget about ways in which documentation tends
to differ fundamentally from software:

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.
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.
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.)
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.

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.

But, to stress again, all of this is outside OSI's ambit.

On Tue, Sep 30, 2008 at 03:51:50PM -0700, Rick Moen wrote:

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.

> 
> Opinions on documentation licensing tend to be surprisingly contentious
> (and I wasn't even particularly thinking of the Debian vs. GFDL affair); 
> many commentators seem to forget about ways in which documentation tends
> to differ fundamentally from software:

I've thought about this topic too but never got around to putting it
in writing.
> 
> 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.

But the main point is that for software, one can't read the source and
thus can't gain an understanding of how it works.  For documentation,
it must have a readable form (otherwise it isn't documentation) and by
reading it one may understand what it says and at least take notes.
So proprietary documentation that can't be copied or modified is not
the disaster that proprietary software is.  One can learn a lot by
reading proprietary documentation but proprietary software can't be
read at all.  Rick's last sentence says the same thing using the word
"semantics".

> 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.  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.  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.

> 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.  But in general, it's much
better if a doc allows modification, which in a special case could
mean that the original author must approve of the modification or that
if the original author can't be located (or has no time to review a
proposed modification), then one can go ahead and make the
modifications (and distribute the modified doc).  Too bad that there
are no licenses like this.

> 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.
> 
> 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.

If something is copyrighted and doesn't allow modification, you can't
just paraphrase each sentence since no derivative works are allowed.
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).  It
should be a significant improvement over the original doc and present
new information.  It should give credit to the sources of information
used, including the original doc.

A  problem arises if one wants to merge two docs with incompatible
licenses.  I don't think this happens very often.  But still, it would
be nice for everything on the wiki to use the same license.  And what
I think a would be a good license for LDP hasn't been written yet.  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).  Many out-of-date versions of HOWTOs are
found on the Internet.  (I mean out-of-date where a newer version
exists.)  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.  Since the mirror sites don't have ads, there is no
problem with having fewer sites that carry LDP docs if the ones with
ads are banned via the licenses.

			David Lawyer

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).

Rick Moen a écrit :

> You've quibbled here with wording but (slightly vexingly) ignored what I
> actually meant:

please, Rick, your participation *is* invaluable, but you feel often
very easily offended. Don't.

We are, here, on good company, good fellows, all aimed to the same goal.

Of course, we have all a past with some ideas, may be preconceived,
sometime wrong, but I think we are always of good faith.

the problem we are debatting now are *very difficult* and you make a
very good work making it clear, but the light come slowly. I
understand very well how it can be disapointing to have to explain and
explain again (I'm a former teacher :-), but it's usefull.

At least for me, this discussion is very usefull.

> 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."

very good phrasing

> That depends on what you mean by "_just_ paraphrase".

If I understand well you mean (and it's pretty obvious, just thinking
about it) that fact being not possible to copyright, sentences
describing simply the fact can't be neither. In (very) short, only the
"humor" of the text, his "style" can't be copied

>> 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).

US writers tend to be quite picky on this matter, much less is some
other countries

> 
>> 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?

just a present exemple. Two HOWTOs aiming to howto edit documents have
been written, one with explicit licence (mine), the other without any
(randy's). Strictly speaking it's impossible to merge them, however I
proposed to merge and Randy agreed, it was simply obvious that they
where made in this goal. In most case this is not a problem.

In fact, the main  problem I fear is somebody going to Slashdot and
claiming the LDP have stolen his doc. Even if the claim is biased,
even untrue such thing could be very destructive. I have no link on
such things, but suffered from similar problems that nearly killed my
LUG three years ago.

So we need to have a "absolutely clean" LDP.

So better not modify a document with dubtfull licence than risk some
clash (no document should be so important as to risk our reputation).

It's probably better to stay like this now and report here only with
real (LDP) case.

thanks
jdd




-- 
http://www.dodin.net
http://valerie.dodin.org
http://www.youtube.com/watch?v=t-eic8MSSfM

On Saturday 04 October 2008 03:54 am, jdd wrote:
> just a present exemple. Two HOWTOs aiming to howto edit documents have
> been written, one with explicit licence (mine), the other without any
> (randy's). Strictly speaking it's impossible to merge them, however I
> proposed to merge and Randy agreed, it was simply obvious that they
> where made in this goal. In most case this is not a problem.

I know this wasn't the main point of your post, but just for the record:

   * I didn't even think about the need for a license, my intent was to 
"contribute" what I wrote under the default license of the TLDP 
(whatever that turns out to be)

   * Yes, absolutely they can be merged--I wasn't really trying to write 
a "new" HOWTO, but I had trouble seeing how to comment on what you 
wrote, so I thought a new attempt, trying to say some of the same 
things you were saying might be useful (or not)

Anyway, feel free to merge it however it makes sense (or not)--I'm sure 
other will have comments as well as it gets closer to agreement.

Randy Kramer


-- 
I didn't have time to write a short letter, so I created a video 
instead.--with apologies to Cicero, et.al.

Quoting Jean-Daniel Dodin ####@####.####

> Rick Moen a écrit :
> 
> > You've quibbled here with wording but (slightly vexingly) ignored
> > what I actually meant:
> 
> please, Rick, your participation *is* invaluable, but you feel often
> very easily offended. Don't.  We are, here, on good company, good
> fellows, all aimed to the same goal.

We are, but (1) you're rather melodramatically exaggerating your reading
of the phrase "slightly vexingly".  Since English isn't your native
tongue, this is probably accidental, but you should be aware that
"vex/vexed" is an extremely mild verb, connoting a very polite,
drawing-room level of reproach over some perceived form of avoidable
harrassment.  (2) All I've really said, in effect, is that I didn't
appreciate David carelessly muddying the perspective that I had
carefully and concisely constructed in my brief summary.

However, that having been said, I _do_ get really weary of computerists
ignoring reasonable real-world perspective, obsessing on irrelevant
points of abstract theory and/or improbable edge cases that don't
matter, and attempting to treat the legal system like a Turing machine
-- especially when I've _immediately before that_ been at some pains to
point out why those approaches aren't fruitful.


> > That depends on what you mean by "_just_ paraphrase".
> 
> If I understand well you mean (and it's pretty obvious, just thinking
> about it) that fact being not possible to copyright, sentences
> describing simply the fact can't be neither. In (very) short, only the
> "humor" of the text, his "style" can't be copied

Above and beyond that, David was actually pointing out a significant
point of law, that should be heeded (and which I do thank him for
reminding us about):  In legal theory, a HOWTO's (or similar work's)
overall structure that is inherent in the ordering of the sentences --
its larger-scale composition structure -- _could_ itself include
copyright-eligible elements, which thus could not be lawfully copied to
a new work without permission.

This is a relevant concern -- at least in theory -- if an LDP author 
decided to remedy the proprietary licence status of an existing,
unmaintained HOWTO by merely paraphrasing each sentence of the existing
HOWTO in his own words.  David's point was that so doing is not legally
sufficient to avoid copyright infringement.

That point is well taken (though there are real-world reasons why I
think it's not going to arise).  And there is a profound lesson for
computerists, hiding in that scenario, about copyright:  A new work
might be written with literally not a single word in common with an
earlier one, and yet nonetheless be ruled to infringe its copyright.

This is a useful lesson for computerists because, almost always, they
imagine that judges in copyright suits would simply do word matching,
and no matches above some level of granularity would mean no
infringement.  No, that's not how it works at all:  The law has a
concept of "expressive elements" (as opposed to functional or strictly
factual ones) of a creative work's tangible form being entitled to
copyright monopoly.  (_Ideas_ are not copyrightable, however.)

Further explanations of "expressive elements" in copyright context:
http://www.ivanhoffman.com/infringement.html
http://www.unc.edu/courses/2006spring/law/357c/001/projects/dougf/node5.html
http://www.innovationlaw.org/projects/dcr/copyright.htm

The reasons I don't think the legal risk in question is likely to ever
be much of a real-world concern for LDP are:  (1) There's not a lot of
creativity and expressive, artistic effort in the large-scale
organisation of your typical LDP HOWTO, and an author attempting to
assert otherwise in court is going to look pretty dumb to the judge.
(2) It'd be really rare for a new author to go to all the trouble of
paraphrasing an entire HOWTO and not also want to make _some_
improvements or changes to its large-scale structure.

And, now, look back at the above seven-paragraph digression that I've
had to indulge in, to understand where I'm coming from about getting 
"slightly vexed":  I'd made, upthread, an ultra-concise, carefully worded,
list of ways in which software people tend to horribly exaggerate the
severity of documentation licensing, tending to destroy any reasonable
perspective on the problem.  And what does David come along and do?  He
seizes on something tangential to what I saying, and (in my view) blows
perspective out of the water.  Oh well.  I hope this has been useful in
some way.


> > Can you name even _one_ instance in LDP history of someone _really_,
> > seriously wanting and needing to do this?
> 
> just a present exemple. Two HOWTOs aiming to howto edit documents have
> been written, one with explicit licence (mine), the other without any
> (randy's). Strictly speaking it's impossible to merge them, however I
> proposed to merge and Randy agreed, it was simply obvious that they
> where made in this goal. In most case this is not a problem.

Sorry, but that is not (even) an example of a licence conflict, let alone 
of the scenario I was asking about, but rather is an example of one
author not bothering to be clear about his licensing at all -- which is
a separate and potentially fairly severe LDP problem.  It's a reason to
hurry up and make the wiki's submission mechanism guide people properly,
to not accept documents without clear licensing, and to make sure we
have useful identification of contributors (sufficient to re-find and
contact them) and not just handles.  In other words, avoiding falling
into typical "wiki disease" (word soup without clear licensing and with
nothing but pseudonymous handles to identify authors) by default.

And, I should point out, I was very clear in what my phrase "needing to
do that" referred to:  I was saying that it has _always_ been the case
that either the borrowing was "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."

What you cite is, in fact, a quite typical, everyday example of
"specifically authorised for your purposes by a friendly author" --
combined with that author dealing with having failed to be clear about
licensing in the first place.


> In fact, the main  problem I fear is somebody going to Slashdot and
> claiming the LDP have stolen his doc.

LDP has always been exposed to that risk, always will be, and always
would be, no matter what it does and doesn't do.  Thus, the real
question is:  How does it make that charge non-credible?  It does so by
having clear, documented, actually applied policies about identification
of contributors and securing licensing permission from them.

(As mentioned previously, LDP has always had in its manifesto, for
example, a policy of requiring free licensing, but has accumulated a
certain number of problem docs under proprietary licensing because
it didn't _enforce_ that policy.)



> So better not modify a document with dubtfull licence than risk some
> clash (no document should be so important as to risk our reputation).

Oh, I agree.  I'm just trying to help LDP clarify its policy about
insisting that wiki-mediated submissions have explicit, documented
licences that are actually _granted_ by their authors (as opposed to
just being indicated on a generic wiki page elsewhere such that LDP 
has little ability to show assent) and take measures to ensure that we 
also collect and maintain meaningful contact information for HOWTO
maintainers.  So far, we're not doing that.

I wrote:

> And there is a profound lesson for computerists, hiding in that
> scenario, about copyright:  A new work might be written with literally
> not a single word in common with an earlier one, and yet nonetheless
> be ruled to infringe its copyright.

There was a famous court case in 2001-2 that illustrates this point: 
Someone named Alice Randall wrote a parody called _The Wind Done Gone_, 
telling a plantation slave's view of the events in Margaret Mitchell's
rather awful but remunerative 1936 melodrama, _Gone with the Wind_.
Randall carefully avoided reusing not only the entire text of Mitchell's
opus, but even found ways to skirt around the names of Mitchell's
characters, the names of the two plantations, and so on.  Mitchell's
estate nonetheless sued for copyright infringement.

The case got as far as an injunction against Randall's publisher, which
then was vacated by a higher court pending trial, but the case was never
heard to a conclusion, because it was settled (and thus dropped) on
terms where Randall's publisher agreed to pay an undisclosed gift to
Morehouse College in Atlanta, a school historically founded for blacks, 
and Mitchell's estate ceased opposing publishing of Randall's book.

The interesting thing was that everyone seemed to agree that Randall
_had_ copied copyrightable "elements" from Mitchell's potboiler -- even
though they had zero text in common -- and debate centered on whether
Randall's work should enjoy immunity from copyright litigation _anyway_
on grounds of being a (legally protected) parody.  (Fair-use parodies
are permitted to borrow otherwise copyright-guarded elements, but only
enough to "recall or conjure up the original", and must be
"transformative" in the way those elements are used.)

Mitchell's estate alleged that (among other things) Mitchell's
"core characters, character traits, and relationships", "famous scenes
and other elements of the plot", and "verbatim dialogues and
descriptions " were copyrightable in the creative mix of characteristics
that Mitchell designed into them, and that Randall was wrongfully
copying those elements even if she avoided voicing their names.  Had the
case proceeded, they apparently _would_ have won that point, leaving the
major legal question whether Randall's fair-use parody defence was
sufficient.  

A legal analysis:  http://www.ivanhoffman.com/seinfeld.html