Re: GNU FDL 1.2 draft comment summary posted, and RFD (fwd)
On Wed, Jun 12, 2002 at 11:40:44PM -0400, Anthony DeRobertis wrote:
> > No, it's because it's possible to make subtle changes to a document that
> > will *completely* alter its function, which is much harder (usually),
> > with software.
>
> It is much easier for me to --- for example --- hide an exploitable
> buffer overflow in Apache than it is to hide something in a document.
It's clear to anyone who bothers to examine the source code that the elements
you are talking about are insertions and perform functions other than that
for which the whole thing was intended. It's not likely to be nearly as
clear (if I selectively edit a document) that I have completely perverted
the author's intentions.
> Remember, the GPL already requires me to make public what I changed. If
> I secretly alter your document, and then redistribute that, I am
> violating the GPL.
It doesn't require you to state exactly which bits you have changed (which
might after all be impossible). It only requires you to state that you have
made changes. It would usually be assumed that your changes were enhancements,
or that you were using the original program (or part of it) as a building
block in a greater edifice.
The point is that you don't need to secretly edit a document; even if it can
clearly be seen that you have edited it, you can still subtly twist the
message without the fact that your edits have had that effect being obvious.
> > It would for example be easy to take a Microsoft press release and make
> > subtle changes which result in something which completely satirises MS.
>
> Right. And once I put the GPL-required notice that I changed it on it,
> so what?
OK, let's take a more likely scenario. Alice writes a manifesto for Free
Software. Bob subtly edits it to become a manifesto for Open Source. If Bob
says "Document edited by Bob, based on an original by Alice. (c) Alice 1999,
(c) Bob 2002", then it is likely that most readers would believe Alice's
position to be insignificantly different to Bob's.
An appropriate license needs to require Bob to make clear that that is
likely not the case.
> > It would usually be much harder to make subtle changes to a program's
> > source code in such a way as to cause it to behave in a manner diametrically
> > opposed to the original author's intent.
>
> No. Much easier, as I pointed out with Apache above. Security holes are
> one very well known example, though they are usually mistakes. Ken
> Thompson has a paper about trojaning the compiler ;-) See:
> http://www.acm.org/classics/sep95/
Zzzzz... anyone who reads and understands the source will notice any added
backdoors, even without seeing the original. Not true with a document, as
documents' original purposes or results are less likely to be well-known or
even well-defined. If I write a document as a fair evaluation of two pieces
of software, *I* intend the readers to come to a valid conclusion about
whether or not to use the software. If someone edits and adds to it to make
the reader more likely to pick one particular product, then that is not
likely to be at all obvious. If they then try the product and find that they
have wasted their time and effort, then they are just as likely to think
badly of me as of the later editor, unless the later editor is required
to make clear that the final document is likely not a fair representation
of my thoughts, experiences and conclusions.
Cheers,
Nick
--
Nick Phillips -- nwp@lemon-computing.com
Perfect day for scrubbing the floor and other exciting things.
--
To UNSUBSCRIBE, email to debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: