[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Amendment: GFDL is compatible with DFSG



On Mon, 2006-01-23 at 17:39 -0600, Peter Samuelson wrote:
> I think everyone is forgetting this one (IMHO pretty reasonable)
> option:
> 
> - Works licensed under the terms of the GNU FDL but with no
>   invariant-foo comply (or may comply) with the DFSG, but we still
>   refuse to distribute them, because of the significant practical
>   problems that this would cause both for us and for our users.

A valid point, but at least the three problems you list don't seem
sufficiently problematic.

> The notable practical problems I'm alluding to would include:
> 
> - All Debian mirrors must retain source packages one year after the
>   corresponding binary packages are deleted

This is hardly impossible, or even difficult. We still retain sources
for Woody, released in 2002. The arrangement to no longer serve the
binaries is trivial. That said, this is of course a decision for
individuals working on the archive and mirrors. (Also, I suspect having
the source available in one location would satisfy GNU FDL, section 3,
paragraph 3, which is where this claim seems to come from.)

> - Debian CD vendors must either ship source CDs to all customers
>   regardless of whether a customer wants them, or maintain their own
>   download mirrors.

I don't see how GNU FDL, section 3, paragraph 3, amounts to CD vendors
having to maintain their own mirrors. If Debian already retains source
for a year, then "reasonably prudent steps" on their part would be to
point the customer to the Debian mirror network and cease distribution
when Debian does so.

Of course, they may choose to distribute for a longer time than Debian,
but that would mean they have to make the arrangements anyway.

> - Neither Debian, nor the mirror network, nor the users, can use
>   rsync-over-ssh to update their CD images or individual packages.

Do you think section 2 of the GNU FDL leads to this? That's where the
so-called DRM clause is located, which states:

        You may not use technical measures to obstruct or control the
        reading or further copying of the copies you make or distribute.

I really have a hard time answering the following questions now:

How does rsync-over-ssh obstruct or control the reading of a document?
Are you suggesting it has to be readable in transit?

How does rsync-over-ssh obstruct or control the further copying of a
document? Unless I'm mistaken, the copy will be identical to the
original, and rsync-over-ssh cannot alter the document so that it is
impossible to copy again.

In fact, consider this part of section 3, paragraph 3:

        ... you must either include a machine-readable Transparent copy
        along with each Opaque copy, or state in or with each Opaque
        copy a computer-network location from which the general
        network-using public has access to download using
        public-standard network protocols a complete Transparent copy of
        the Document, free of added material.

Since rsync-over-ssh is a "public-standard network protocol", and since
rsync-over-ssh URLs are "computer-network locations from which the
general network-using public has access to download" given you tell the
user the password or use no authentication, the requirement for
distributing opaque copies ("source") could be fulfilled by providing
rsync-over-ssh access to anyone that the distributor is obliged to
provide opaque copies to.

> I think any one of these points is serious enough to reject GNU FDL
> works regardless of whether they can pass a strict reading of the DFSG.
> In other words, the DFSG is a *necessary* but not necessarily
> *sufficient* hurdle.

I would suggest supporting the GR on this issue, by seconding my
proposal and/or making an amendment.

-- 
Fabian Fagerholm <fabbe@paniq.net>

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: