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

Re: Inconsistencies in our approach



On Thu, Aug 07, 2003 at 04:33:05PM -0500, John Goerzen wrote:
> > I continue to suspect that people are indulging an Aristotelian
> > categorization fetish solely as a means to an end, that end being to
> > compel the Debian Project to ship their favorite w4r3z in main, heedless
> > of the negative consequences to the freedoms that our users currently
> > enjoy.
> 
> Actually, my goals are the opposite.  I see it as intellectually and
> logically dishonest to claim certain requirements for some types of
> non-program data in Debian, other requirements for other data, and do it all
> under the guise that "everything binary is software."

What requirements, exactly, do you think are being made of some things
and not of others?

> > After all, what utility would this distinction serve beyond providing
> > one a means of routing around the DFSG's inconvenient restrictions?
> 
> The DFSG's restrictions prove inconvenient to those on your side of the
> fence, too.  After all, if you claim that all documentation is software,
> than you are ignoring the restriction in DFSG #2, which states:
> 
>    2. Source Code 
>   
>    The program must include source code, and must allow distribution in
>    source code as well as compiled form.
> 
> There is neither source code nor compiled code for my King James Bible in
> free-form ASCII text.

This is an example of why they are guidelines, not rules. It is simple
for an intelligent person to interpret this in a sensible manner for
documentation.

> The point is that this is not an exercise on my part to let less-than-free
> bits into Debian.  It is rather an attempt to call a horse a horse, rather
> than engage in this business of calling everything software.  I think we
> have a clear weakness in the DFSG and a clear need for some guidelines for
> non-Software components, and I advocate that.

So, now we come to the crux of your argument.

What weaknesses, exactly? What actual problems does it cause us?

We have not, to date, had any difficulty in interpreting the DFSG as
applied to documentation, excluding the lunatic fringe who appear,
stick their oar in, and cease to send mail when somebody points out
why their argument is flawed (in every discussion, not just licensing
ones).

In all the FDL debates, there has not once been a solid argument that
it is actually acceptable, which was not immediately rebutted. If
anybody thinks otherwise, they are invited to present their argument
*and then defend it in the face of skilled opposition*.

> Why is it OK to include the GPL in our system but not other bits of
> documentation?

This is virtually a FAQ.

Firstly, even if that statement was not present, the license would
still be unmodifiable and non-removable; that is the nature of
copyright.

Secondly, there is no convincing reason to believe that this statement
is binding in law, because nobody has presented any evidence that
copyright subsists in a license _at all_. Remember, copyright is not a
natural thing, it was invented in the past few decades in order to
improve the profit margins of corporations.

Thirdly, we are distributing software, not licenses. We wouldn't
include them at all if we didn't have to; we only accept them because
forces beyond our control require us to.

Any one of these would be enough on its own. There's probably some
more that I've forgotten.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: pgpl6gmXLrube.pgp
Description: PGP signature


Reply to: