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

Re: documentation x executable code



On Wed, Jan 05, 2005 at 12:43:43AM -0800, Don Armstrong wrote:
> On Wed, 05 Jan 2005, Craig Sanders wrote:
> > whether you call it commentary or a patch, it's still a patch and is
> > explicitly allowed by the DFSG.
> 
> The section of the DFSG to which you are refering is the following:
> 
>      4. Integrity of The Author's Source Code
> 
>      The license may restrict source-code from being distributed in
>      modified form _only_ if the license allows the distribution of
>      "patch files" with the source code for the purpose of modifying
>      the program at build time. The license must explicitly permit
>      distribution of software built from modified source code.
> 
> The license must allow:
> 
>     1) the distribution of "patch files" for the purpose of modifying
>        the work at build time
> 
>     2) the modified form built from the patched work to be
>        distributed
> 
> These conditions are not satisfiable for GFDLed documentation with
> invariant sections.

i can take a GFDL document with an invariant section, add another section
which argues against, subverts, or just supplements the invariant section, AND
i can distribute the result as either a new source tarball with Makefile or
build-script etc or as a complete formatted manual (electronic or printed or
whatever).  i can also modify & redistribute non-invariant sections in any way
i please.

i can also distribute a "patch file" which contains that additional section.

both conditions are satisified.


> Furthermore, even if we were to ignore the requirement of DFSG 4 for
> the distribution of software built from modified source code, the

there's no need to ignore it.  the condition is satisified.

we discussed this at length while debating the DFSG years ago.  the reason why
this clause exists is because we decided (grudgingly) that when it comes to
free/non-free status, convenience is irrelevant.  all that matters is whether
we CAN modify something, not HOW that modification can be carried out.

> "patch file"[1] would include bits of the original source as context,

not necessarily.  some do, some don't.

> which is also not allowed for the invariant sections of a GFDLed
> work.[2]

as you say, fair-use considerations apply here.

> 1: Obviously alluding to a patch(1) (or similar) style patch file that
> can be applied in an automated fashion, as opposed to mere commentary.

more importantly: obviously not specifying that a patch must be in any
particular format or used by any particular program (or any program at all,
for that matter).

> 2: Fair use concerns enter in here, of course, but they are not
> sufficient remedy because many jurisdictions to not possess them.

which is why i think that one of the few minor tweaks that the GFDL needs is
an explicit listing of fair-use rights for jursidictions that don't have them,
and to *supplement* any that might exist in any given jurisdiction.


craig

-- 
craig sanders <cas@taz.net.au>           (part time cyborg)



Reply to: