Re: documentation x executable code

[Craig Sanders]

On Wed, Jan 05, 2005 at 04:13:25PM +1100, Matthew Palmer wrote:
> On Wed, Jan 05, 2005 at 04:02:38PM +1100, Craig Sanders wrote:
> > sorry, but that argument is bogus.  convenience is NOT the same as freedom.
> > more to the point, freedom does not require convenience.
> 
> Convenience and freedom are not the same, but they are related.  You have
> the freedom to write a program which operates in a manner exactly the same
> as acroreader, but without some irritating bug (choose whichever one you
> like).  It would be far more convenient if you had the source to acroread to
> make simply the bugfix you require, but freedom does not require
> convenience.  So acroread is Free.  Cool.

no, acroread is DFSG non-free for other reasons that have nothing to do with
convenience.  most notably, the complete absence of source-code, and the right
to modify and redistribute the source.


> > in short, it doesn't make any practical *OR* ethical difference so it 
> > doesn't
> > matter in the slightest.
> 
> I don't see much of a case at all for "no practical difference" in what you
> wrote above.  The only form of "amendment" that can be made is to reissue a
> newly written RFC saying "this previous one is wrong", 

irrelevant.  it doesn't matter that the process is inconvenient.

> but your new RFC cannot be a derived work of the superceded one.
> That's a real practical difference to me.

in theory, you may be right.  in practice, nobody would give a damn - and
nobody HAS given a damn when people have done exactly that.

the format for an RFC is pretty much prescribed by convention if not by
explict written rule, and the data is implicit in what you're writing.  given
those two conditions, any "clean room" re-implementation of an RFC is likely
to be nearly identical to a copy anyway.

as long as you're not plagiarising someone else's work (i.e. claiming it as
your own or failing to give due credit), you can basically do what you want.


> > ps: the GPL itself is non-free.  you're not allowed to modify it, so it is
> > non-free.  it must therefore be discarded from debian (or moved to 
> > non-free).
> > furthermore, since GPL-licensed software requires that the license be
> > distributed with the software, and we are unable to meet that requirement, 
> > all
> > GPL-licensed software must likewise be discarded from debian.
> > 
> > please explain why we should be willing to make an exception for the GPL 
> > text,
> > but not for other texts.
> 
> Ghods, not this one again.  The GPL, as a text of it's own, would most
> certainly fail the DFSG.  We only include the GPL as a description of the
> terms under which much of the software in Debian is distributed, which is
> very, very inviolable -- the moment you start trying to modify the licence
> terms of a piece of software without the permission of the copyright holder,
> you're deep in "do not pass go, do not collect $200" territory.

it doesn't matter what reason we might have for distributing it.  what matters
is that doing so is clearly against the DFSG and the SC.

you haven't explained why we *should* make an exception for the GPL but not
for other texts (note: mere convenience is not a valid reason, any more than
it would be a valid reason for including acroread in main).

by your own admission, the GPL is a non-free document.  why, then, is it OK to
distribute it within debian, and why is it OK to distribute other works which
depend upon it (at best, they should go in contrib)?

i see no reason why it's OK to be pedantic about the licensing of one document
(or set of documents, such as those licensed under the GFDL) but fail to be
equally pedantic about another document (e.g. the GNU GPL text).



since you can't or won't explain it, i'll make an attempt for you:

perhaps, just perhaps, the reason is that there is an implicit acknowledgement
of the fact that documents don't need to be held to the exact same standard of
freedom as software, hence it doesn't actually qualify as "non-free" (even
though it would if it were software).

alternatively, maybe nobody thought about it before and everyone just assumed
that it wasn't a problem.  well, we know better now.

or, it may just be a copout.  the ramifications of holding the GPL text to the
same standard as software are both disastrous and enormous, so we just ignore
the problem and hope it will go away.  

craig

-- 
craig sanders <[EMAIL PROTECTED]>   (part time cyborg)

Re: documentation x executable code

[Glenn Maynard]

On Wed, Jan 05, 2005 at 04:13:25PM +1100, Matthew Palmer wrote:
> Ghods, not this one again.  The GPL, as a text of it's own, would most
> certainly fail the DFSG.  We only include the GPL as a description of the
> terms under which much of the software in Debian is distributed, which is
> very, very inviolable -- the moment you start trying to modify the licence
> terms of a piece of software without the permission of the copyright holder,
> you're deep in "do not pass go, do not collect $200" territory.

His argument is old and broken, of course, but I partially disagree with
this logic.

License texts--as texts--do not have to be inviolate.  The only thing
that must be inviolate is the represented terms of a program.  This means
"you can change this license, but if you do so, don't claim that my program
is under the modified license" is (roughly) enough to allow modification
and reuse of the license.  The GPL does, in fact (with some restrictions
for misrepresentation and the preamble) allow modifications, though those
terms are not quite DFSG-free.

License texts are allowed to be invariant because there's no choice.  Debian
could try to lobby for modifiable licenses, but it can't use the "punt it to
non-free" lever that it has available with everything else.

(The fact that most people with any licensing experience want to minimize
license proliferation is probably one reason there's not much effort to fix
this.  Given their stonewalling with the GFDL, there'd be no hope of the
FSF changing this with the GPL, either.)

-- 
Glenn Maynard

Re: documentation x executable code

[Matthew Palmer]

On Wed, Jan 05, 2005 at 05:03:09PM +1100, Craig Sanders wrote:
> On Wed, Jan 05, 2005 at 04:13:25PM +1100, Matthew Palmer wrote:
> > On Wed, Jan 05, 2005 at 04:02:38PM +1100, Craig Sanders wrote:
> > > sorry, but that argument is bogus.  convenience is NOT the same as 
> > > freedom.
> > > more to the point, freedom does not require convenience.
> > 
> > Convenience and freedom are not the same, but they are related.  You have
> > the freedom to write a program which operates in a manner exactly the same
> > as acroreader, but without some irritating bug (choose whichever one you
> > like).  It would be far more convenient if you had the source to acroread to
> > make simply the bugfix you require, but freedom does not require
> > convenience.  So acroread is Free.  Cool.
> 
> no, acroread is DFSG non-free for other reasons that have nothing to do with
> convenience.  most notably, the complete absence of source-code, and the right
> to modify and redistribute the source.

Irrelevant.  It doesn't matter that the process is inconvenient.

Lack of source code and no permission to modify the existing article are
just convenience.  Nobody's denying you the freedom to rewrite a functional
equivalent of acroread, or to write a program that invokes acroread as
required.

> > > in short, it doesn't make any practical *OR* ethical difference so it 
> > > doesn't
> > > matter in the slightest.
> > 
> > I don't see much of a case at all for "no practical difference" in what you
> > wrote above.  The only form of "amendment" that can be made is to reissue a
> > newly written RFC saying "this previous one is wrong", 
> 
> irrelevant.  it doesn't matter that the process is inconvenient.
> 
> > but your new RFC cannot be a derived work of the superceded one.
> > That's a real practical difference to me.
> 
> in theory, you may be right.  in practice, nobody would give a damn - and
> nobody HAS given a damn when people have done exactly that.

So you're advocating the deliberate and knowing breach of copyright?

> the format for an RFC is pretty much prescribed by convention if not by
> explict written rule, and the data is implicit in what you're writing.  given
> those two conditions, any "clean room" re-implementation of an RFC is likely
> to be nearly identical to a copy anyway.

An RFC has sufficient creative input to merit copyright protection?  An
interesting claim, not one that I think I've seen before.

> as long as you're not plagiarising someone else's work (i.e. claiming it as
> your own or failing to give due credit), you can basically do what you want.

That is not what the licence of the text says.

> by your own admission, the GPL is a non-free document.  why, then, is it OK to
> distribute it within debian, and why is it OK to distribute other works which
> depend upon it (at best, they should go in contrib)?

We're not distributing the GPL as a document, we're distributing it as an
exact description of the terms under which some things in Debian are allowed
to be copied.  We can't have a distribution without it.  No such equivalent
exists for any of the other non-DFSG-free crud you want to burden us with.

> since you can't or won't explain it, i'll make an attempt for you:

Ho, ho, ho.  Can and have.  As have others.

> perhaps, just perhaps, the reason is that there is an implicit acknowledgement
> of the fact that documents don't need to be held to the exact same standard of
> freedom as software, hence it doesn't actually qualify as "non-free" (even
> though it would if it were software).

It's a really poor attempt, and doesn't represent my beliefs at all.  

- Matt


signature.asc
Description: Digital signature

Re: documentation x executable code

[Glenn Maynard]

On Wed, Jan 05, 2005 at 05:10:18PM +1100, Matthew Palmer wrote:
> > the format for an RFC is pretty much prescribed by convention if not by
> > explict written rule, and the data is implicit in what you're writing.  
> > given
> > those two conditions, any "clean room" re-implementation of an RFC is likely
> > to be nearly identical to a copy anyway.
> 
> An RFC has sufficient creative input to merit copyright protection?  An
> interesting claim, not one that I think I've seen before.

ITYM s/sufficient/insufficient/

> > perhaps, just perhaps, the reason is that there is an implicit 
> > acknowledgement
> > of the fact that documents don't need to be held to the exact same standard 
> > of
> > freedom as software, hence it doesn't actually qualify as "non-free" (even
> > though it would if it were software).
> 
> It's a really poor attempt, and doesn't represent my beliefs at all.  

Or anyone else, as far as I know.  (I doubt Craig actually believes this
himself.)

-- 
Glenn Maynard

Re: documentation x executable code

[Don Armstrong]

On Wed, 05 Jan 2005, Craig Sanders wrote:
> On Wed, Jan 05, 2005 at 04:13:25PM +1100, Matthew Palmer wrote:
> > Ghods, not this one again.  The GPL, as a text of it's own, would
> > most certainly fail the DFSG.
> 
> it doesn't matter what reason we might have for distributing it.
> what matters is that doing so is clearly against the DFSG and the
> SC.



> alternatively, maybe nobody thought about it before and everyone
> just assumed that it wasn't a problem.  well, we know better now.

This was brought up in the context of the most recent DFSG/SC vote as
an implied exception, nearly a year ago.[1]

If a significant number of people feel that this is an exception that
was not implied, there is nothing stopping them from putting together
an amendment to make the exception explicit.

Copyright statements and the licenses that they include are
necessarily non-modifiable, and thus fail the DFSG because of it.

The GNU GPL, were it to be included for its own sake, would not
satisfy the terms of the DFSG, and thus could not be included in main
or contrib. However, because it is included by reference in the
copyright statement, the legally relevant part of it must be included,
and cannot be modified.

Like it or not, this is part of the legal game that must be played in
order to have any free software at all.


Don Armstrong

1: http://people.debian.org/~terpstra/message/20040129.031954.8111224d.en.html
-- 
"...Yet terrible as UNIX addiction is, there are worse fates. If UNIX
is the heroin of operating systems, then VMS is barbiturate addiction, the
Mac is MDMA, and MS-DOS is sniffing glue. (Windows is filling your sinuses
with lucite and letting it set.) You owe the Oracle a twelve-step program."
 --The Usenet Oracle

http://www.donarmstrong.com  http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: documentation x executable code

[Matthew Palmer]

On Wed, Jan 05, 2005 at 01:15:13AM -0500, Glenn Maynard wrote:
> On Wed, Jan 05, 2005 at 05:10:18PM +1100, Matthew Palmer wrote:
> > > the format for an RFC is pretty much prescribed by convention if not by
> > > explict written rule, and the data is implicit in what you're writing.  
> > > given
> > > those two conditions, any "clean room" re-implementation of an RFC is 
> > > likely
> > > to be nearly identical to a copy anyway.
> > 
> > An RFC has sufficient creative input to merit copyright protection?  An
> > interesting claim, not one that I think I've seen before.
> 
> ITYM s/sufficient/insufficient/

Indeed.  Thanks.

- Matt


signature.asc
Description: Digital signature

Re: documentation x executable code

[Craig Sanders]

On Wed, Jan 05, 2005 at 12:56:29AM -0500, Glenn Maynard wrote:
> On Wed, Jan 05, 2005 at 04:02:38PM +1100, Craig Sanders wrote:
> > sorry, but that argument is bogus.  convenience is NOT the same as freedom.
> > more to the point, freedom does not require convenience.
> 
> This isn't a matter of convenience.  A "standard" which is explained as
> a set of changes to a previous standard, which itself is a set of changes
> to another, going down a chain of several old documents, is not inconvenient;
> it's completely useless.  

that's still just convenience - in this case, the convenience of not having
to read several prior documents.

btw, usefulness isn't one of the criterion for freedom, either.

> > is more than sufficient reason to be a bit more tolerant about freedom
> > criteria for documents.
> 
> I disagree strongly.  b) is unsufficient, as I've already explained.  a)
> is very weak; the utility of Netscape, back when it was important, was
> very high for a massive number of users, and it was just as weak then.
> c) is very weak; very few people will want to modify anything at all


you're partly right.  both a) and c) are weak, but b) is sufficient (both
convenience and usefulness are not relevant when deciding whether something is
free or not, remember).

a) and c) are definitely too weak for software, but may be good enough for
documentation.

IMO all three together are, as i said, sufficient reason to be a bit more
tolerant about licensing for documentation.




> > ps: the GPL itself is non-free.  you're not allowed to modify it, so it is
> 
> Actually, this is incorrect.  You can modify the GPL, but you have to remove
> the preamble, and rename it to something other than the "GPL"[1].  However,
> the preamble itself is an invariant text, so the question does apply (even
> though it's been asked and answered many times before--as I suspect you're
> aware).

yes, i was assuming that the reader knew all that.

(similarly, you CAN modify an invariant section - but you can only do so by
adding a new section that subverts or refutes or simply adds to the invariant
section.  i.e. you can make whatever comments you like about it, but you can't
censor the original words.  in other words, modification only by patch - which
is explicitly allowed by the DFSG)
 

> > non-free.  it must therefore be discarded from debian (or moved to 
> > non-free).
> > furthermore, since GPL-licensed software requires that the license be
> > distributed with the software, and we are unable to meet that requirement, 
> > all
> > GPL-licensed software must likewise be discarded from debian.
> > 
> > please explain why we should be willing to make an exception for the GPL 
> > text,
> > but not for other texts.
> 
> We shouldn't be.  However, there is absolutely no choice but to include the
> text of the GPL; it'd leave us with no operating system.  License texts
> (when detached from an actual work) don't need to be invariant, but as
> many important ones (unfortunately) are, we have no choice.

we do have a choice, even if it's one we don't like or one that doesn't leave
us with a very useful system.  we don't have to distribute GPL licensed
software, there are many other free software licenses to choose from.


> I'm not aware of any other non-free bits of data in Debian with the
> status of "we have absolutely no choice", other than license texts, so
> nothing else

i don't believe that we do have "absolutely no choice".  it might be an
extremely unpalatable choice, but it's still a choice.

> puts Debian in this position. Attempting to use license texts as a
> lever to shove other non-free stuff into Debian is not going to work
> (that's been tried many times already).

that's not what i'm trying to do.  i don't want non-free stuff in debian.

i just want people to stop being hypocritically pedantic about the GFDL, and i
want people to stop manipulating debian into blackmailing the FSF over this
stupid issue.

GFDL docs *are* free, except in the minds of wannabe-Holier-Than-Stallman
zealots, and even they can't come up with any *credible* arguments why it
should be considered non-free.  the best they can do is come up with ludicrous
hypotheticals that "prove" that it is possible to misuse/misapply the GFDL (or
any license) in such a way that it invalidates the license, making that one
particular work both non-free and non-distributable.

> With everything else, Debian has a choice--and GR 2004-003 shows that Debian
> has, in fact, made that choice: to not include non-free standards documents.

that's not relevant.  nobody has yet proven that GFDL licensed texts are
non-free, and debian has not yet voted on the issue.  claiming that the GFDL
is non-free is not a statement of fact, it is merely a statement of opinion.

craig

-- 
craig sanders <[EMAIL PROTECTED]>   (part time cyborg)

Re: documentation x executable code

[Matthew Palmer]

On Wed, Jan 05, 2005 at 05:38:31PM +1100, Craig Sanders wrote:
> (similarly, you CAN modify an invariant section - but you can only do so by
> adding a new section that subverts or refutes or simply adds to the invariant
> section.  i.e. you can make whatever comments you like about it, but you can't
> censor the original words.  in other words, modification only by patch - which
> is explicitly allowed by the DFSG)

What you describe isn't modification by patch, it's modification by
commentary, and you can do that even without any permissions granted at all
by the copyright holder.

> we do have a choice, even if it's one we don't like or one that doesn't leave
> us with a very useful system.  we don't have to distribute GPL licensed
> software, there are many other free software licenses to choose from.

I'm not aware of any licence texts which provide explicit permission to
modify the licence text itself.  Can you give some examples?

> GFDL docs *are* free, except in the minds of wannabe-Holier-Than-Stallman
> zealots, and even they can't come up with any *credible* arguments why it
> should be considered non-free.  the best they can do is come up with

Can you give a reasoned rebuttal of Manoj's GFDL position statement? 
Preferably without use of the words "wannabe" and "zealot".

> non-free, and debian has not yet voted on the issue.  claiming that the GFDL
> is non-free is not a statement of fact, it is merely a statement of opinion.

An opinon which you're working very hard not to actually argue against, but
merely shout into the ground.

- Matt


signature.asc
Description: Digital signature

Re: documentation x executable code

[Glenn Maynard]

On Wed, Jan 05, 2005 at 05:38:31PM +1100, Craig Sanders wrote:
> IMO all three together are, as i said, sufficient reason to be a bit more
> tolerant about licensing for documentation.

I disagree, and I also think it's insane to claim that "a bit more tolerant"
includes "allow the license to prohibit changing it entirely".  (We're not
going anywhere, so let's conclude that we disagree on this.)

> > I'm not aware of any other non-free bits of data in Debian with the
> > status of "we have absolutely no choice", other than license texts, so
> > nothing else
> 
> i don't believe that we do have "absolutely no choice".  it might be an
> extremely unpalatable choice, but it's still a choice.

There is no comparison between the choices available for licenses ("useless
system" vs "make an exception") and standards documents ("a useful system
that just doesn't happen to mirror standards documents that you can get
anywhere" vs "make an exception").  The two topics are irrelevant to
each other.

> i just want people to stop being hypocritically pedantic about the GFDL, and i
> want people to stop manipulating debian into blackmailing the FSF over this
> stupid issue.
> 
> GFDL docs *are* free, except in the minds of wannabe-Holier-Than-Stallman
> zealots, and even they can't come up with any *credible* arguments why it
> should be considered non-free.  the best they can do is come up with ludicrous
> hypotheticals that "prove" that it is possible to misuse/misapply the GFDL (or
> any license) in such a way that it invalidates the license, making that one
> particular work both non-free and non-distributable.

If your best rebuttal to [1] is "wannabe-Holier-Than-Stallman zealots",
then I don't think any further response is necessary.

[1] http://people.debian.org/~srivasta/Position_Statement.xhtml#annotated

> > With everything else, Debian has a choice--and GR 2004-003 shows that Debian
> > has, in fact, made that choice: to not include non-free standards documents.
> 
> that's not relevant.  nobody has yet proven that GFDL licensed texts are
> non-free, and debian has not yet voted on the issue.  claiming that the GFDL
> is non-free is not a statement of fact, it is merely a statement of opinion.

Invariant sections can not be modified.  The DFSG requires that modification
be allowed.  QED.

(tip: if the strongest response you have is to point at license texts, don't
bother)

-- 
Glenn Maynard

Re: documentation x executable code

[Craig Sanders]

On Wed, Jan 05, 2005 at 05:10:18PM +1100, Matthew Palmer wrote:
> On Wed, Jan 05, 2005 at 05:03:09PM +1100, Craig Sanders wrote:
> > no, acroread is DFSG non-free for other reasons that have nothing
> > to do with convenience. most notably, the complete absence of
> > source-code, and the right to modify and redistribute the source.
>
> Irrelevant. It doesn't matter that the process is inconvenient.
>
> Lack of source code and no permission to modify the existing article
> are just convenience.

no, they're not "just convenience". they are non-negotiable requirements
of the DFSG.

convenience, however, is NOT a requirement.


> > > but your new RFC cannot be a derived work of the superceded on  e.
> > > That's a real practical difference to m e.
> >
> > in theory, you may be right. in practice, nobody would give a damn -
> > and nobody HAS given a damn when people have done exactly that.
>
> So you're advocating the deliberate and knowing breach of copyright?

when did i advocate that?

i just pointed out the historical reality.
 


> > by your own admission, the GPL is a non-free document. why, then, is
> > it OK to distribute it within debian, and why is it OK to distribute
> > other works which depend upon it (at best, they should go in
> > contrib)?
>
> We're not distributing the GPL as a document,

that makes no sense at all. of course, we're "distributing the GPL as a
document". it's a document. we're distributing it.

> we're distributing it as an exact description of the terms under which
> some things in Debian are allowed to be copied.

but we've already voted that debian will be entirely free. and we've
voted to disambiguate that phrase so that it means *everything* must be
free, not just "software". accordingly, if the GPL itself isn't free, we
can't distribute it in debian.


> We can't have a distribution without it.

yes, that is the obvious and inevitable consequence of moronic pedantry.

as the GPL says:

  7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License.  If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all.  For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.


the solution to this problem is not to be selectively pedantic, but to
be consistent and eliminate pedantry.


> No such equivalent exists for any of the other non-DFSG-free crud you
> want to burden us with.

please take your ad-hominem bullshit and shove it somewhere painful. i
don't want to burden debian with *ANY* "non-DFSG-free crud".

craig

-- 
craig sanders <[EMAIL PROTECTED]>   (part time cyborg)

Re: documentation x executable code

[Matthew Palmer]

On Wed, Jan 05, 2005 at 06:01:41PM +1100, Craig Sanders wrote:
> On Wed, Jan 05, 2005 at 05:10:18PM +1100, Matthew Palmer wrote:
> > On Wed, Jan 05, 2005 at 05:03:09PM +1100, Craig Sanders wrote:
> > > no, acroread is DFSG non-free for other reasons that have nothing
> > > to do with convenience. most notably, the complete absence of
> > > source-code, and the right to modify and redistribute the source.
> >
> > Irrelevant. It doesn't matter that the process is inconvenient.
> >
> > Lack of source code and no permission to modify the existing article
> > are just convenience.
> 
> no, they're not "just convenience". they are non-negotiable requirements
> of the DFSG.

So you agree that non-modifiability is a requirement of the DFSG?  So why do
you continue to claim that the GFDL, prohibiting, as it does, the
modification of the document, is DFSG-free?

- Matt


signature.asc
Description: Digital signature

Re: documentation x executable code

[Daniel Burrows]

On Tuesday 04 January 2005 10:07 pm, Glenn Maynard wrote:
> License texts are allowed to be invariant because there's no choice.
>  Debian could try to lobby for modifiable licenses, but it can't use the
> "punt it to non-free" lever that it has available with everything else.

  Also, the fact that we have a long-standing exception for one non-free thing 
doesn't mean we have to create exceptions for other random non-free things 
that people want to include.

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
|   The perfect is the enemy of the good.   |
|   The good is the enemy of the perfect.   |
\- A duck! -- http://www.python.org /


pgpX8n2n9hNha.pgp
Description: PGP signature

Re: documentation x executable code

[Craig Sanders]

On Wed, Jan 05, 2005 at 05:46:56PM +1100, Matthew Palmer wrote:
> On Wed, Jan 05, 2005 at 05:38:31PM +1100, Craig Sanders wrote:
> > (similarly, you CAN modify an invariant section - but you can only
> > do so by adding a new section that subverts or refutes or simply
> > adds to the invariant section. i.e. you can make whatever comments
> > you like about it, but you can't censor the original words. in other
> > words, modification only by patch - which is explicitly allowed by
> > the DFSG)
>
> What you describe isn't modification by patch, it's modification by
> commentary, and you can do that even without any permissions granted
> at all by the copyright holder.

i'm sorry, i thought i was conversing with a reasonably intelligent adult and
not with a child who needs every term precisely defined so as to remove all
possibility of ambiguity.  if i was wrong, please let me know and i'll adjust
my writing accordingly.  maybe i should footnote every word to let you know
exactly which dictionary defintion i'm using in any given context.

the word "patch" isn't restricted to the output of diff(1), or the controlling
input to patch(1).

whether you call it commentary or a patch, it's still a patch and is
explicitly allowed by the DFSG.


(there are other definitions of patch that apply, but the most obvious is "v:
repair by adding pieces".  see "dict patch" for others)

> > we do have a choice, even if it's one we don't like or one that
> > doesn't leave us with a very useful system. we don't have to
> > distribute GPL licensed software, there are many other free software
> > licenses to choose from.
>
> I'm not aware of any licence texts which provide explicit permission
> to modify the licence text itself. Can you give some examples?

you're missing the point.

it doesn't matter whether any others allow it or not.  the point is that the
GPL doesn't.  if others don't then they fail the DFSG too, and have to be
removed (according to the moronic zealot path to Holier-Than-Stallmanness,
that is).

if we make an exception for the GPL (and other license texts) then why not for
other non-license texts?  if we do make an exception, then when and where was
this discussed and decided (or voted) upon?  and when & where was it decided
that the exception was exclusively for licenses?  what are the exact limits of
the exception?

(a brief mention in passing in some vaguely related thread doesn't count as a
decision)

> > GFDL docs *are* free, except in the minds of
> > wannabe-Holier-Than-Stallman zealots, and even they can't come up
> > with any *credible* arguments why it should be considered non-free.
> > the best they can do is come up with
>
> Can you give a reasoned rebuttal of Manoj's GFDL position statement?

again?

> Preferably without use of the words "wannabe" and "zealot".

why?  they're very appropriate words to use in this discussion.

> > non-free, and debian has not yet voted on the issue. claiming that
> > the GFDL is non-free is not a statement of fact, it is merely a
> > statement of opinion.
>
> An opinon which you're working very hard not to actually argue
> against, but merely shout into the ground.

bullshit.  i've argued against it consistently.  nobody has yet come up with
anything that refutes what i have argued.  the most i've got in response is
lame re-iterations of the same absurd hypothetical scenarios - as if they're
some kind of compelling proof.

it's you zealots who claim that GFDL is non-free, therefore the onus is on you
to prove your claim.

craig

-- 
craig sanders <[EMAIL PROTECTED]>   (part time cyborg)

Re: documentation x executable code

[Craig Sanders]

On Wed, Jan 05, 2005 at 02:01:31AM -0500, Glenn Maynard wrote:
> > > I'm not aware of any other non-free bits of data in Debian with the
> > > status of "we have absolutely no choice", other than license texts, so
> > > nothing else
> > 
> > i don't believe that we do have "absolutely no choice".  it might be an
> > extremely unpalatable choice, but it's still a choice.
> 
> There is no comparison between the choices available for licenses ("useless
> system" vs "make an exception") and standards documents ("a useful system
> that just doesn't happen to mirror standards documents that you can get
> anywhere" vs "make an exception").  The two topics are irrelevant to
> each other.

according to your particular degree of zealotry...but your zealotry is more
intense than what was common when we wrote the DFSG, so it's entirely possible
that even crazier lunatics will arrive in the future (encouraged, no doubt, by
the "successes" of the current crop of loonies).
  
the point here is "what makes your version of zealotry any more correct than
those of someone even more extreme?".  you're just making arbitrary
exceptions, and selective application of the rules.  if you want an exception,
then define it - don't just leave it up to common-sense because that doesn't
work in debian (or pretty nearly anywhere else for that matter).  some
pedantic turd will inevitably come along and twist your common-sense words so
that they mean something you didn't mean at all.


> > i just want people to stop being hypocritically pedantic about the GFDL, 
> > and i
> > want people to stop manipulating debian into blackmailing the FSF over this
> > stupid issue.
> > 
> > GFDL docs *are* free, except in the minds of wannabe-Holier-Than-Stallman
> > zealots, and even they can't come up with any *credible* arguments why it
> > should be considered non-free.  the best they can do is come up with 
> > ludicrous
> > hypotheticals that "prove" that it is possible to misuse/misapply the GFDL 
> > (or
> > any license) in such a way that it invalidates the license, making that one
> > particular work both non-free and non-distributable.
> 
> If your best rebuttal to [1] is "wannabe-Holier-Than-Stallman zealots",
> then I don't think any further response is necessary.

"wannabe-Holier-Than-Stallman zealots" is not a rebuttal, it's merely a
succinct description of the anti-GFDL crowd.



> > > With everything else, Debian has a choice--and GR 2004-003 shows that 
> > > Debian
> > > has, in fact, made that choice: to not include non-free standards 
> > > documents.
> > 
> > that's not relevant.  nobody has yet proven that GFDL licensed texts are
> > non-free, and debian has not yet voted on the issue.  claiming that the GFDL
> > is non-free is not a statement of fact, it is merely a statement of opinion.
> 
> Invariant sections can not be modified.  The DFSG requires that modification
> be allowed.  QED.

invariant sections can be modified by patch.  the DFSG allows that
restriction.  QED.

craig

-- 
craig sanders <[EMAIL PROTECTED]>   (part time cyborg)

Re: documentation x executable code

[Craig Sanders]

On Wed, Jan 05, 2005 at 06:04:08PM +1100, Matthew Palmer wrote:
> On Wed, Jan 05, 2005 at 06:01:41PM +1100, Craig Sanders wrote:
> > On Wed, Jan 05, 2005 at 05:10:18PM +1100, Matthew Palmer wrote:
> > > Lack of source code and no permission to modify the existing article
> > > are just convenience.
> > 
> > no, they're not "just convenience". they are non-negotiable requirements
> > of the DFSG.
> 
> So you agree that non-modifiability is a requirement of the DFSG? So
> why do you continue to claim that the GFDL, prohibiting, as it does,
> the modification of the document, is DFSG-free?

how many times does it have to be said?

because the DFSG explicitly allows a license to restrict modification so that
it is only permitted by patch.

and, as you pointed out yourself, this freedom (to patch) exists even when it
is not explicitly granted by the license.

craig

-- 
craig sanders <[EMAIL PROTECTED]>   (part time cyborg)

Re: documentation x executable code

[Don Armstrong]

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.

Furthermore, even if we were to ignore the requirement of DFSG 4 for
the distribution of software built from modified source code, the
"patch file"[1] would include bits of the original source as context,
which is also not allowed for the invariant sections of a GFDLed
work.[2]


Don Armstrong

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.

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

-- 
I don't care how poor and inefficient a little country is; they like
to run their own business.  I know men that would make my wife a
better husband than I am; but, darn it, I'm not going to give her to
'em.
 -- The Best of Will Rogers

http://www.donarmstrong.com  http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: documentation x executable code

[David Weinehall]

On Wed, Jan 05, 2005 at 07:36:02PM +1100, Craig Sanders wrote:
[snip]

> "wannabe-Holier-Than-Stallman zealots" is not a rebuttal, it's merely a
> succinct description of the anti-GFDL crowd.

Not agreeing with you does not necessarily make people zealots.  Have
you ever considered that you're a zealot too?  a GFDL zealot...

> invariant sections can be modified by patch.  the DFSG allows that
> restriction.  QED.

So for instance, you'd have nothing against a license that only allowed
"fixing" typos in a program along these lines:

--- helloworld.c.old2005-01-05 10:44:53 +0200
+++ helloworld.c2005-01-05 10:45:14 +0200
@@ -3,6 +3,7 @@
 int main(void)
 {
printf("Hello Wolrd\n");
+   printf("Hello World\n");

return 0;
 }

Because that's the only kind of "modification by patch" that the GFDL
allows for.


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/

Re: documentation x executable code

[Jacobo Tarrio]

O Mércores,  5 de Xaneiro de 2005 ás 19:42:46 +1100, Craig Sanders escribía:

> because the DFSG explicitly allows a license to restrict modification so that
> it is only permitted by patch.

 As long as we can distribute a modified binary.

 There's no way we can distribute a GFDL-licensed document with a
patched-modified invariant section, no matter how many "compiling" or
"processing" passes we give to it.

-- 
   Jacobo Tarrío | http://jacobo.tarrio.org/

Re: documentation x executable code

[Craig Sanders]

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 <[EMAIL PROTECTED]>   (part time cyborg)

Re: documentation x executable code

[Craig Sanders]

On Wed, Jan 05, 2005 at 09:54:38AM +0100, David Weinehall wrote:
> On Wed, Jan 05, 2005 at 07:36:02PM +1100, Craig Sanders wrote:
> [snip]
> 
> > "wannabe-Holier-Than-Stallman zealots" is not a rebuttal, it's merely a
> > succinct description of the anti-GFDL crowd.
> 
> Not agreeing with you does not necessarily make people zealots.  

i never said it did.

being insanely pedantic & obsessive about licensing trivialities does,
however, make one a zealot.


> Because that's the only kind of "modification by patch" that the GFDL
> allows for.

"patch" is not restricted to the controlling input to patch(1) - or
to any particular program or method.

craig

-- 
craig sanders <[EMAIL PROTECTED]>   (part time cyborg)

Re: documentation x executable code

[Craig Sanders]

On Wed, Jan 05, 2005 at 09:56:09AM +0100, Jacobo Tarrio wrote:
> O M?rcores,  5 de Xaneiro de 2005 ?s 19:42:46 +1100, Craig Sanders escrib?a:
> 
> > because the DFSG explicitly allows a license to restrict modification so 
> > that
> > it is only permitted by patch.
> 
>  As long as we can distribute a modified binary.
> 
>  There's no way we can distribute a GFDL-licensed document with a
> patched-modified invariant section, no matter how many "compiling" or
> "processing" passes we give to it.

wrong.

i couldn't be bothered rewriting the same argument, so i'll just cut and
paste:

  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.


craig

-- 
craig sanders <[EMAIL PROTECTED]>   (part time cyborg)

Re: documentation x executable code

[Don Armstrong]

On Wed, 05 Jan 2005, Craig Sanders wrote:
> On Wed, Jan 05, 2005 at 12:43:43AM -0800, Don Armstrong wrote:
> > 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).

The GFDL allows one to make additions to the work, but not to make
subtractions or modifications to the section that is invariant
itself.

Perhaps my understanding of modification is fundamentally different
from the one you are advancing, but if a work allows modification, I
expect to be able to modify it in any way that I please.[1] If it were
sufficent for the work to allow mere addition, I would expect this
clause to substitute addition for modification throughout.

Hopefully now my position is clear, even if others still disagree with
it.


Don Armstrong


1: With the exception of copyright and license statements.
-- 
I'd never hurt another living thing.
But if I did...
It would be you.
 -- Chris Bishop  http://www.chrisbishop.com/her/archives/her69.html

http://www.donarmstrong.com  http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: documentation x executable code

[David Weinehall]

On Wed, Jan 05, 2005 at 08:05:57PM +1100, Craig Sanders wrote:
> On Wed, Jan 05, 2005 at 09:54:38AM +0100, David Weinehall wrote:
> > On Wed, Jan 05, 2005 at 07:36:02PM +1100, Craig Sanders wrote:
> > [snip]
> > 
> > > "wannabe-Holier-Than-Stallman zealots" is not a rebuttal, it's merely a
> > > succinct description of the anti-GFDL crowd.
> > 
> > Not agreeing with you does not necessarily make people zealots.  
> 
> i never said it did.
> 
> being insanely pedantic & obsessive about licensing trivialities does,
> however, make one a zealot.

Indeed.  But not everyone agrees with your opinion that invariant sections 
are trivialities.

> > Because that's the only kind of "modification by patch" that the GFDL
> > allows for.
> 
> "patch" is not restricted to the controlling input to patch(1) - or
> to any particular program or method.

Nor did I say so, I was using a simple comparision.  But you artfully
dodged the real question, so I'll repeat it in rephrased form, without
mentioning of the word patch:

"Would you accept a license that only allowed fixing typos (for instance)
 in a program by *also* outputting the fixed line of text?"

Because this is *exactly* the situation you get with invariant sections.
Sure, you can add another invariant section that fixes all the "bugs" in
the original version, but that still leaves the buggy version in the
document.


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/

Re: documentation x executable code

[Jacobo Tarrio]

O Mércores,  5 de Xaneiro de 2005 ás 20:09:01 +1100, Craig Sanders escribía:

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

 Yes, but that's not modification. That's adding new information.

-- 
   Jacobo Tarrío | http://jacobo.tarrio.org/

Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual

[Florian Weimer]

* Matthew Garrett:

> Perhaps an easier way to do this would be to look at the DFSG and work
> out what changes need to be made. We have a set of freedoms that we
> believe software should provide - rather than providing an entirely
> different set of freedoms for documentation, we should try to justify
> any changes in those freedoms.
>
> Personally, I'm inclined to believe that free documentation should have
> all the freedoms that we think should be provided by free software. Do
> you believe it needs more freedoms? Fewer freedoms? A slightly different
> set of freedoms?

I'd prefer a slightly different set of freedoms, but this goal is
impractical.  For instance, I believe that the GNU GPL is not a free
documentation license because it unnecessarily complicates the
distribution of printed copies, but it would be ridiculous to outlaw
all GPLed documentation for this reason.

IMHO, some questions should be answered before working on
documentation guidelines.  My current list includes:

  * If upstream includes a copy of an RFC (that is, documentation
which is non-free but redistributable), should we really stop
shipping pristine sources?  I can understand that we don't want to
build RFCs into binary packages, but OTOH, the pristine sources
concept has a reason.

  * Should source packages in main be allowed to build documentation
packages which go to non-free?  This resolves a potential
synchronization problem, and would prevent some completely
unnecessary work.

  * Shouldn't documentation include proper source code, including
source for most of its artwork?  This means hi-res bitmap images,
vector graphics for technical drawings, FLAC instead of Ogg
Vorbis, etc.  Of course, open formats with free editors are
required.

What about documentation indexes?  Should it be possible to
regenerate them automatically after the documentation has been
modified?

  * What about non-technical prose?  Does it have a place in Debian at
all?  Can we aford some invariant parts, such as license texts,
copyright statements and legal disclaimers, credits, mission
statements, provided that they are neither executable code nor
functional end-user documentation?

Re: documentation x executable code

[Florian Weimer]

* Craig Sanders:

> and, as you pointed out yourself, this freedom (to patch) exists
> even when it is not explicitly granted by the license.

Without permission from the author, you may not redistribute patches
in many jurisdictions.  (DJB's analysis clearly does not apply to the
situation in Germany, just to name one example.)

Re: Debian Free Documentation Guidelines was: License of old GNU Emacs manual

[Andrew Suffield]

On Wed, Jan 05, 2005 at 02:21:00PM +0100, Florian Weimer wrote:
> * Matthew Garrett:
> 
> > Perhaps an easier way to do this would be to look at the DFSG and work
> > out what changes need to be made. We have a set of freedoms that we
> > believe software should provide - rather than providing an entirely
> > different set of freedoms for documentation, we should try to justify
> > any changes in those freedoms.
> >
> > Personally, I'm inclined to believe that free documentation should have
> > all the freedoms that we think should be provided by free software. Do
> > you believe it needs more freedoms? Fewer freedoms? A slightly different
> > set of freedoms?
> 
> I'd prefer a slightly different set of freedoms, but this goal is
> impractical.  For instance, I believe that the GNU GPL is not a free
> documentation license because it unnecessarily complicates the
> distribution of printed copies,

Complicates, sure. Unnecessarily? That's just you objecting to the
principle of copyleft licenses; it is *necessary* to introduce this
complication in order to have a copyleft. To the point of not being
free? No.

>   * If upstream includes a copy of an RFC (that is, documentation
> which is non-free but redistributable), should we really stop
> shipping pristine sources?  I can understand that we don't want to
> build RFCs into binary packages, but OTOH, the pristine sources
> concept has a reason.

Pristine source is a very minor benefit. Free source is a very major
one. Pristine source is just a 'nice to have': do it whenever you can,
but don't worry about it when you can't.

>   * Shouldn't documentation include proper source code, including
> source for most of its artwork?

Yes, of course. Free software needs free documentation. It's not free
unless I can modify it to match the changes I made to the
software. Anything obstructing that cannot possibly be free.

> What about documentation indexes?  Should it be possible to
> regenerate them automatically after the documentation has been
> modified?

Too vague. Sometimes.

>   * What about non-technical prose?  Does it have a place in Debian at
> all?

Not really, but if it concidentally happens to be free then it doesn't
matter if it goes in.

> Can we aford some invariant parts, such as license texts,
> copyright statements and legal disclaimers, credits, mission
> statements, provided that they are neither executable code nor
> functional end-user documentation?

No. The exception is the bits which are required by law, not license
holder (and then only grudgingly, but we don't really have time to sit
and wait for legislators to get a clue).

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


signature.asc
Description: Digital signature

Re: Re: wrong meaning of "GNU/Linux" on Debian Project mainpage

[Johannes Rohr]

Am Wed, 05 Jan 2005 02:30:12 +0100 schrieb Brian Masinick:


> 
> I agree with you.  What is there currently is quite clear, and I don't
> think that it is misleading, either.  Just as Richard Stallman states,
> the system comes with GNU utilities, and in our case, GNU utilities,
> various other unencumbered utilities, and a choice of kernels.

The disagreement is about who produces the actual OS:

Stallman says: GNU/Linux is an OS, using the Linux kernel, being packaged
and distributed by distributors such as Debian

Debian says: Debian is an OS, using the GNU tools and the Linux kernel
(and prospectively other kernels, too)

Linus says: Linux is an OS, using the GNU tools and being packaged by
distributors.

So every party claims: I am the major player, the others are - however
important - merely contributors.

Probably the fairest compromise would be to say that "we", i.e. the GNU
project, Linux developers and Debian (and of course other
distributors) together produce an OS. None of the parties would get very
far without the others (unless GNU's own kernel replacement would one day
be ready, which is far from likely)

Thanks,

Johannes

Re: Debian Free Documentation Guidelines was: License of old GNU Emacsmanual

[Florian Weimer]

* Gunnar Wolf:

> Well... Remember the GPL does not require you to provide the sources
> _together_ with the binary/printout/whatever - It requires you to
> provide means to get the sources. So if you print a book that [...]
> has the URL for the place you can refer to in order to get the
> source, it will be enough. That does not sound like 'unnecessarily
> complicated'.

This is an unusual GPL interpretation.  Most commentators assume that
providing a *separate* URL is *not* enough.

Re: Debian Free Documentation Guidelines was: License of old GNUEmacsmanual

[Florian Weimer]

* Gunnar Wolf:

> Florian Weimer dijo [Wed, Jan 05, 2005 at 07:14:55PM +0100]:
>> > Well... Remember the GPL does not require you to provide the sources
>> > _together_ with the binary/printout/whatever - It requires you to
>> > provide means to get the sources. So if you print a book that [...]
>> > has the URL for the place you can refer to in order to get the
>> > source, it will be enough. That does not sound like 'unnecessarily
>> > complicated'.
>> 
>> This is an unusual GPL interpretation.  Most commentators assume that
>> providing a *separate* URL is *not* enough.
>
> That's exactly what Debian does, isn't it?

No, Debian distributes source and binaries on the same (virtual)
medium.  This is different from handing over a physical object with
the "binary" and providing a URL for some resource on the Internet.

Re: Debian Free Documentation Guidelines was: License of old GNU Emacsmanual

[Gunnar Wolf]

Florian Weimer dijo [Wed, Jan 05, 2005 at 02:21:00PM +0100]:
> I'd prefer a slightly different set of freedoms, but this goal is
> impractical.  For instance, I believe that the GNU GPL is not a free
> documentation license because it unnecessarily complicates the
> distribution of printed copies, but it would be ridiculous to outlaw
> all GPLed documentation for this reason.

Well... Remember the GPL does not require you to provide the sources
_together_ with the binary/printout/whatever - It requires you to
provide means to get the sources. So if you print a book that -on an
obvious place, not hidden in the middle of the text... And even there
it would be legal, although it went against the GPL spirit- has the
URL for the place you can refer to in order to get the source, it will
be enough. That does not sound like 'unnecessarily complicated'.

>   * What about non-technical prose?  Does it have a place in Debian at
> all?  Can we aford some invariant parts, such as license texts,
> copyright statements and legal disclaimers, credits, mission
> statements, provided that they are neither executable code nor
> functional end-user documentation?

U... Strictly speaking, Debian is not into the business of
providing content just for the sake of it. Now, for example, you have
many tools that can use bible-kjv-text as their data source, and that
makes bible-kjv-text a valid and useful (for some) package.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: Debian Free Documentation Guidelines was: License of old GNUEmacsmanual

[Gunnar Wolf]

Florian Weimer dijo [Wed, Jan 05, 2005 at 07:14:55PM +0100]:
> > Well... Remember the GPL does not require you to provide the sources
> > _together_ with the binary/printout/whatever - It requires you to
> > provide means to get the sources. So if you print a book that [...]
> > has the URL for the place you can refer to in order to get the
> > source, it will be enough. That does not sound like 'unnecessarily
> > complicated'.
> 
> This is an unusual GPL interpretation.  Most commentators assume that
> providing a *separate* URL is *not* enough.

That's exactly what Debian does, isn't it? I know that if I want to
get the sources of a Debian package, I have to ask apt-get for
it. What apt-get does is to look for the URL for the source package in
/var/lib/apt/lists and fetch it. Of course, I can do that by myself as
well - And, as it is very hard to include an application that can do
precisely that in a printed book, the closest you can get is to say
"you can get the sources for this boot at http://whatever/ or by
writing to my snail-mail address, which is this and that".

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: Re: wrong meaning of "GNU/Linux" on Debian Project mainpage

[Michael Banck]

On Tue, Jan 04, 2005 at 08:04:24PM -0500, Brian Masinick wrote:
> Think about it, just as there is "Debian GNU/HURD" 

It's the Hurd, not the HURD.


cheers,

Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html

HELP FINDING DISTRO

[Rybon, John P.]

Greetings and Happy New 
Year!
 
I recieved a Dell 5160 
laptop as a holiday gift and require assistance finding a distro that supports 
the included components.  I have tried several live disks (knoppix, 
linspire, mandrake) but wireless networking and video components continue 
to be problematic.  Can you make a recommendation or direct me to a forum 
where I might find users with similar experience?
 
Best Regards, 
John
 
<=>-<=>-<=>-<=>-<=>-<=>-<=>-<=>-<=>
John Rybon, M.E.
Stolle Machinery Company 
L.L.C.
303-708-5058
 

Re: documentation x executable code

[Glenn Maynard]

On Wed, Jan 05, 2005 at 07:36:02PM +1100, Craig Sanders wrote:
> according to your particular degree of zealotry...but your zealotry is more
> intense than what was common when we wrote the DFSG, so it's entirely possible
> that even crazier lunatics will arrive in the future (encouraged, no doubt, by
> the "successes" of the current crop of loonies).

Okay, since you refuse to converse civilly, without constantly throwing around
"zealot", "lunatic" and "loonies", I'm not going to converse with you.  (I
don't really have to, since your flaming rants aren't convincing anyone, and
I've never expected to convince you directly.)  Once you understand that
people can, in fact, rationally disagree with you, you might have more success
in debate.

-- 
Glenn Maynard

Re: Debian Free Documentation Guidelines was: License of oldGNUEmacsmanual

[Florian Weimer]

* Gunnar Wolf:

>> No, Debian distributes source and binaries on the same (virtual)
>> medium.  This is different from handing over a physical object with
>> the "binary" and providing a URL for some resource on the Internet.
>
> So... If I hand over a Debian CD to someone, will I be breaching the
> law as I am giving him only the binaries, even if they have a very
> easy way of getting the sources?

It's generally believed that it's sufficient to offer a source code CD
at the same time you give away the CD with binaries, as long as you
are prepared to fulfill this offer.

> Or, if we talk about other distributions (which _are_ usually
> distributed via CDs), do they breach the GPL?

All distributions I bought so far had source code on the same CD, or
came with separate source code CDs.

Re: Debian Free Documentation Guidelines was: License of oldGNUEmacsmanual

[Gunnar Wolf]

Florian Weimer dijo [Wed, Jan 05, 2005 at 07:22:45PM +0100]:
> >> This is an unusual GPL interpretation.  Most commentators assume that
> >> providing a *separate* URL is *not* enough.
> >
> > That's exactly what Debian does, isn't it?
> 
> No, Debian distributes source and binaries on the same (virtual)
> medium.  This is different from handing over a physical object with
> the "binary" and providing a URL for some resource on the Internet.

So... If I hand over a Debian CD to someone, will I be breaching the
law as I am giving him only the binaries, even if they have a very
easy way of getting the sources? Or, if we talk about other
distributions (which _are_ usually distributed via CDs), do they
breach the GPL?

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: Joerg Jaspert, an additional DAM

[dann frazier]

On Mon, Jan 03, 2005 at 04:06:51PM +0100, Geert Stappers wrote:
> -public_html on gluck and refered to by
> +~/public_html on gluck and refered to by

s/refered/referred/

http://www.m-w.com/cgi-bin/dictionary?va=referred
http://www.m-w.com/cgi-bin/dictionary?va=refered

Re: documentation x executable code

[Craig Sanders]

On Wed, Jan 05, 2005 at 12:03:49PM +0100, David Weinehall wrote:
> On Wed, Jan 05, 2005 at 08:05:57PM +1100, Craig Sanders wrote:
> > On Wed, Jan 05, 2005 at 09:54:38AM +0100, David Weinehall wrote:
> > > On Wed, Jan 05, 2005 at 07:36:02PM +1100, Craig Sanders wrote:
> > > [snip]
> > > 
> > > > "wannabe-Holier-Than-Stallman zealots" is not a rebuttal, it's merely a
> > > > succinct description of the anti-GFDL crowd.
> > > 
> > > Not agreeing with you does not necessarily make people zealots.  
> > 
> > i never said it did.
> > 
> > being insanely pedantic & obsessive about licensing trivialities does,
> > however, make one a zealot.
> 
> Indeed.  But not everyone agrees with your opinion that invariant sections 
> are trivialities.

well, that just makes them wrong.  and if they're obsessive about it, zealots.


> > > Because that's the only kind of "modification by patch" that the GFDL
> > > allows for.
> > 
> > "patch" is not restricted to the controlling input to patch(1) - or
> > to any particular program or method.
> 
> Nor did I say so, I was using a simple comparision.  But you artfully
> dodged the real question, so I'll repeat it in rephrased form, without
> mentioning of the word patch:

i thought it was a stupid question that missed the point entirely.

but, since you insist on having your stupid question answered:

> "Would you accept a license that only allowed fixing typos (for instance)
>  in a program by *also* outputting the fixed line of text?"

for software, no.

for the primary content of a document, no.


> Because this is *exactly* the situation you get with invariant sections.
> Sure, you can add another invariant section that fixes all the "bugs" in
> the original version, but that still leaves the buggy version in the
> document.

for invariant sections (as defined in the GFDL) in a document, that's good
enough.

for a document, one person's "bugfix" is another person's "censorship".

the point of invariant sections is that nobody can come along later and censor
the original author's words or put words in their mouths.  whether you agree
with them or not, you do not have the right to change or delete what they
said, you only have the right to comment upon it.

this is perfectly OK for documentation because only secondary sections may be
invariant.   the primary content (i.e. the subject matter) can never be
invariant and may be changed at will, e.g. to reflect changes in the
associated software.  THIS is the important freedom for documentation.

the following extract from the GFDL is why Invariant Sections are a licensing
triviality:

 A "Secondary Section" is a named appendix or a front-matter
 section of the Document that deals exclusively with the
 relationship of the publishers or authors of the Document to the
 Document's overall subject (or to related matters) and contains
 nothing that could fall directly within that overall subject.
 (For example, if the Document is in part a textbook of
 mathematics, a Secondary Section may not explain any mathematics.)
 The relationship could be a matter of historical connection with
 the subject or with related matters, or of legal, commercial,
 philosophical, ethical or political position regarding them.

 The "Invariant Sections" are certain Secondary Sections whose
 titles are designated, as being those of Invariant Sections, in
 the notice that says that the Document is released under this
 License.

"a named appendix or a front-matter section of the Document that deals
*exclusively* with the *relationship* of the publishers or authors of the
Document to the Document's overall subject" (emphasis mine) -- it does not
matter in the slightest if these things can not be changed by anyone but the
original authors.  they are not in the least bit important for the task of
accurately documenting software.

the purpose of an Invariant section is to ensure that the author is correctly
attributed in the manner that they choose, and that *their work* is presented
in the philosophical context that they choose.

e.g. it is to stop people from changing text like "Professor Fred Bloggs has
worked in the field of blahblahblah for 50 years" to "Fred Bloggs is a
fuckwit", and to stop people from deleting a rant on the ethical superiority
of free software and replacing it with a diatribe.  or vice-versa.
 
these are perfectly legitimate things for an author to want to remain
invariant.  if someone disagrees with them then they can add a comment
detailing their disagreement, but they do not have the right to censor the
author's words or to change what they said.

if you don't like their political or ethical stance and want to delete it
entirely (or worse, change it), then tough luck - write your OWN damn document
and then you can do whatever you want with it.

these are fundamental ethical principles - censorship is evil, and you do not
put words in people's mouths.  these thing are just plain wron

Re: documentation x executable code

[Craig Sanders]

On Wed, Jan 05, 2005 at 01:13:51AM -0800, Don Armstrong wrote:
> On Wed, 05 Jan 2005, Craig Sanders wrote:
> > On Wed, Jan 05, 2005 at 12:43:43AM -0800, Don Armstrong wrote:
> > > 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).
> 
> The GFDL allows one to make additions to the work, but not to make
> subtractions or modifications to the section that is invariant
> itself.

for software (and for the primary subject matter of a document), that would
NOT be good enough - because it affects the functioning of the software.

(and in any case, code can't be "invariant" because it can not be "secondary",
it is inherently the subject matter of the licensed work).

for secondary material describing the relationship or ethical stance of the
authors to the subject matter of the documentation[1], it is good enough.  you
can agree or disagree with the authors, you can write a counter-rant or a
supporting rant, or add whatever you want but you can not censor or change
what they said.


[1] i.e. the *ONLY* things that are allowed to be invariant under the GFDL.


craig

-- 
craig sanders <[EMAIL PROTECTED]>   (part time cyborg)

Re: documentation x executable code

[Craig Sanders]

On Wed, Jan 05, 2005 at 04:09:26PM -0500, Glenn Maynard wrote:
> On Wed, Jan 05, 2005 at 07:36:02PM +1100, Craig Sanders wrote:
> > according to your particular degree of zealotry...but your zealotry is more
> > intense than what was common when we wrote the DFSG, so it's entirely 
> > possible
> > that even crazier lunatics will arrive in the future (encouraged, no doubt, 
> > by
> > the "successes" of the current crop of loonies).
> 
> Okay, since you refuse to converse civilly, without constantly throwing around
> "zealot", "lunatic" and "loonies", I'm not going to converse with you.  (I
> don't really have to, since your flaming rants aren't convincing anyone, and
> I've never expected to convince you directly.)  

a lame excuse for dropping out of an argument that you're losing. 

> Once you understand that people can, in fact, rationally disagree with
> you, you might have more success in debate.

yes, it's possible to disagree with me without being a loony or a zealot or a
fuckwit or a moron.  honest disagreements are possible (and even common).

in this particular case, however, i've observed the lunacy of the principle
anti-GFDL zealots over a number of years.  "lunatic" IS a valid and accurate
description.  they are, for the most part, the same lunatics who regularly try
to have the non-free archives deleted.  their behaviour is entirely consistent
with the theory that they are motivated by the desire to prove themselves
Holier Than Stallman.  they are the free-software world's equivalent of
fundamentalist religious fanatics - i.e. zealots.


craig

-- 
craig sanders <[EMAIL PROTECTED]>   (part time cyborg)

Re: Debian Free Documentation Guidelines was: License of oldGNUEmacsmanual

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Florian Weimer <[EMAIL PROTECTED]> writes:

> * Gunnar Wolf:
>
>>> No, Debian distributes source and binaries on the same (virtual)
>>> medium.  This is different from handing over a physical object with
>>> the "binary" and providing a URL for some resource on the Internet.
>>
>> So... If I hand over a Debian CD to someone, will I be breaching the
>> law as I am giving him only the binaries, even if they have a very
>> easy way of getting the sources?
>
> It's generally believed that it's sufficient to offer a source code CD
> at the same time you give away the CD with binaries, as long as you
> are prepared to fulfill this offer.

If I give someone a printed GPL manual, I don't think that a request
for a printed copy of the source is unreasonable, provided they pay
the printing and distribution costs.  Providing a URL in addition
would be a more practical alternative for those who actually wanted to
use the source ;-)

(I did this last week actually.  I posted someone a printed GPL manual
accompanied by the source on a floppy.)


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFB3GguVcFcaSW/uEgRAoyQAJ9gZL+mkzlqwdtWWUxmP+Nu9tdN1wCbBpc1
8mViuu7/rShO2kW8SXFEx6k=
=g3w+
-END PGP SIGNATURE-

Re: documentation x executable code

[Glenn Maynard]

On Thu, Jan 06, 2005 at 09:14:44AM +1100, Craig Sanders wrote:
> > Okay, since you refuse to converse civilly, without constantly throwing 
> > around
> > "zealot", "lunatic" and "loonies", I'm not going to converse with you.  (I
> > don't really have to, since your flaming rants aren't convincing anyone, and
> > I've never expected to convince you directly.)  
> 
> a lame excuse for dropping out of an argument that you're losing. 

You can convince yourself (but only yourself) of that if it'll make you sleep
better.  :)

-- 
Glenn Maynard

Re: wrong meaning of "GNU/Linux" on Debian Project mainpage

[Tollef Fog Heen]

* Johannes Rohr 

| Linus says: Linux is an OS, using the GNU tools and being packaged by
| distributors.

nah, he doesn't.  He says that Linux is a kernel and useless without
any programs to use.  It's also fairly boring to most people.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: License of old GNU Emacs manual

[Jose Carlos Garcia Sogo]

El mar, 04-01-2005 a las 19:50 -0500, Glenn Maynard escribió:
> On Wed, Jan 05, 2005 at 12:12:42AM +, Matthew Garrett wrote:
> > We can provide the logo under a free copyright license but fairly strict
> > trademark license. A restrictive copyright license prevents legitimate
> > modifications as well, which isn't what we want.
> 
> It's not clear whether a work which is affected by a "strict" trademark
> license is DFSG-free.  I don't think much headway has ever been made
> on figuring out how trademarks and the DFSG interact, probably because
> there hasn't been much need (the logos clearly havn't been sufficient).
> I suspect the Mozilla issue may make that happen, though.

  But trademarks are strict and not free by default. If I can use a
trademark to name my own products when they don't belong to me, it is no
longer a trademark.

  If formulae for Coca-Cola were GPL, I could make my own coke and also
distribute it, but I don't think I could use the name Coca-Cola in the
market and the glass bottle.

  And that is something that will happen with every trademark, as
trademark law is quite different from copyright one.
 
  Greetings, 

-- 
Jose Carlos Garcia Sogo
   [EMAIL PROTECTED]


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente

Re: HELP FINDING DISTRO

[Bas Zoetekouw]

Hi Rybon,!

You wrote:

>I recieved a Dell 5160 laptop as a holiday gift and require assistance
>finding a distro that supports the included components.  I have tried
>several live disks (knoppix, linspire, mandrake) but wireless
>networking and video components continue to be problematic.  Can you
>make a recommendation or direct me to a forum where I might find users
>with similar experience?

The website http://www.linux-laptop.net/ has notes and howto's about
a lot of laptops.  The Dell 5160 is in their list, and people seem to
have gotten everything to work.

PS: please ask these kinds of questions on debian-user@lists.debian.org
(or debian-laptop@lists.debian.org) in the future.  The debian-project
list is meant for non-technical discussies about the Debian project.

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 

Re: HELP FINDING DISTRO

[cuc]

A Dimecres 05 Gener 2005 21:19, Rybon, John P. va escriure:
> Greetings and Happy New Year!
>
> I recieved a Dell 5160 laptop as a holiday gift and require assistance
> finding a distro that supports the included components.  I have tried
> several live disks (knoppix, linspire, mandrake) but wireless networking
> and video components continue to be problematic.  Can you make a
> recommendation or direct me to a forum where I might find users with
> similar experience?

Try with

http://www.linux-on-laptops.com/ 
http://tuxmobil.org/mylaptops.html

Re: License of old GNU Emacs manual

[Glenn Maynard]

On Thu, Jan 06, 2005 at 01:23:33AM +0100, Jose Carlos Garcia Sogo wrote:
>   But trademarks are strict and not free by default. If I can use a
> trademark to name my own products when they don't belong to me, it is no
> longer a trademark.

Sure.  A trademark license that's "free"--when evaluated as if it was a
copyright license, say--is probably lost, which is where the claim that
"enforcable trademarks can't be Free" comes from.

What I'm not sure about is whether, and when, this is a problem.  Debian
clearly allows copyright licenses to say "if you modify this software,
change the name".  What's the problem with implementing that same
restriction with a trademark (which is the "correct" way of doing it,
anyway)?  It's a little more complicated, conceptually, since instead
of evaluating a work and its license, we're evaluating a work with a
name, the work's license, and the name's license, but at a high level
it doesn't seem any different.

Now, from another perspective: if Debian needs to modify Mozilla in
a way that would cause other parties (doing the same thing) to have to
rename it, Debian shouldn't be shipping it as "Mozilla" (even if special
permission is given).  That means that a competing fork of Debian would
be placed at a disadvantage, having to rename packages away from their
familiar names; it feels like a DFSG#8 problem (as has been mentioned),
though exactly how isn't quite clear.


We can look at the same thing from a copyright standpoint, to avoid
having to talk about trademarks, which are somewhat less well-explored
here.  A license can say "if you modify this, you must rename it".  The
Debian package modifies the package, but the upstream author says
"Debian's cool, don't bother renaming it".  What does Debian do?  The
license--even without the special permission--is DFSG-free.  The
additional permission doesn't change that.  Debian can either accept
the additional permission and not rename it (but getting an "unfair
advantage against forks" in the process), or rename it anyway.  What
happens?

-- 
Glenn Maynard

Re: Debian Free Documentation Guidelines was: License ofoldGNUEmacsmanual

[Gunnar Wolf]

Florian Weimer dijo [Wed, Jan 05, 2005 at 10:16:11PM +0100]:
> > So... If I hand over a Debian CD to someone, will I be breaching the
> > law as I am giving him only the binaries, even if they have a very
> > easy way of getting the sources?
> 
> It's generally believed that it's sufficient to offer a source code CD
> at the same time you give away the CD with binaries, as long as you
> are prepared to fulfill this offer.

So is it generally believed that live CDs (which have become _way_ too
popular not to be taken into account) do not count as distribution? 

> > Or, if we talk about other distributions (which _are_ usually
> > distributed via CDs), do they breach the GPL?
> 
> All distributions I bought so far had source code on the same CD, or
> came with separate source code CDs.

I just checked the CD I got from the Ubuntu guys - It does not contain
any source packages. And I hold the Ubuntu guys as more committed to
Free Software than most other comercial distributions.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF