Re: documentation x executable code
> by insisting on the right to delete/change attribution, and the right to
> delete/change secondary sections, that is *exactly* what you are
> demanding - the right to plagiarise and misrepresent.
How can you know why someone else wants to modify an invariant section?
Maybe they simply want to correct mispellings or something. (Yes, we know
they can make an addendum to do that.)
Why does documentation have these special needs that software doesn't need.
Let's say I had the following program:
// Begin invariant
int
main( int, char ** ){
std::cout << "All hail the zurg! The zurg is supreme commander!" << endl;
// End invariant
return 0;
}
I license it GPL + a clause "sections marked invariant may not be removed,
physically or logically". (I.e. I can't #if 0 them out.) Now I get hit by
a bus and you realize "zurg" was supposed to be "zerg".
Do you really think that this solution is acceptable?
// Begin invariant
int
main( int, char ** ){
std::cout << "All hail the zurg! The zurg is supreme commander!" <<
std::endl;
// End invariant
std::cout << "zurg should be spelled zerg" << std::endl;
return 0;
}
If it's not a good solution for free software why is it a good solution for
free documentation?
If I'm not supposed to censor or plagarise, then I'm not supposed
regardless of the licensing, right? Right now I can make GPL programs that
report the author's name report my name instead. Yet this doesn't seem to
tbe a rampant problem. Why is documentation different?
> it doesn't matter whether these things are specifically forbiden by a
> license or not, because they are either unethical or illegal or both,
> anyway.
Exactly, hence invariants seem unnecessary. They also feel non-free to me
but I'm still listening to the debate.
> claiming that the GFDL is non-free doesn't make it so. if you make a
> claim, the onus is on you to prove it.
You keep claiming invariants (and the other issues which seem to be
considered secondary) are necessary for documentation even though they
don't seem to be for source code. The onus is on you to defend this
position in this debate. (Bonus points for doing it without calling anyone
names.) If you've already explained this elsewhere a link or cut and paste
is fine with me.
> we already allow invariant sections in software (particularly software
> license texts and copyright notices etc) so it's not as if this is some
> amazingly new and unprecedented exception just for the GFDL - it's a
> practical necessity to enable us to do our work of producing and
> distributing a free software distribution.
Copyright notices are a special case. Where else are there invariants?
There's the "practical necessity" assertion again. Why is it necessary?
> no, it's not false. there is no explicit exception for the GPL or any
> other invariant license text anywhere in the DFSG or debian developer
> guidelines or policies. it has just been assumed that it isn't a
> problem, that it doesn't conflict with the DFSG.
You address why this makes sense here:
> [1] practical reasons including: we wouldn't be able to distribute GPL
> software at all, and nobody really needs to be able to change the GPL
> text - same as nobody really needs to be able to plagiarise or put words
> in people's mouths.
You can modify GPL text all you want. But you can't relicense software
that you don't hold copyright for, so you legally have no right to modify
license text. I think you already know that though.
Take care,
Dale
--
Dale E. Martin - [EMAIL PROTECTED]
http://the-martins.org/~dmartin
Re: documentation x executable code
ots are trying to change that and impose their own insane > interpretation. I don't think this is a fair representation. If invariants are allowed, I think they need to be addressed in the DFSG. If they're not, they're not. I don't find this to be "insane" in any way. Reasonable people can disagree of course. Take care, Dale -- Dale E. Martin - [EMAIL PROTECTED] http://the-martins.org/~dmartin
Re: A bit of history
> It's amazing how little things like dch (and all of devscripts in fact) > make maintaining packages so much easier. Our newer maintainers might be > horrified to hear that we didn't have build-depends back then; the dpkg > changelog shows they were added Christmas day (!) 1999. And apt was only > created in 1998. Yeah, but "dpkg -iGROEB ." was still MUCH cooler than swapping all of those floppies full of tar files like Slackware had then ;-) Take care, Dale -- Dale E. Martin - [EMAIL PROTECTED] http://the-martins.org/~dmartin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: comment on "User Review of Debian GNU/Linux"
> > The fact that no version of Debian has a complete edition of KDE 3.x > > doesn't make the argument that more people should use it any easier. > > Well, unstable does. Actually, right now several critical pieces of KDE are missing from unstable: kdenetwork kmail kdepim I've known at least one "real user" who upgraded to unstable when they heard that KDE had finally entered unstable, only to get burned by the fact that these packages are missing. Furthermore, when I checked debian-kde several days ago it wasn't clear to me what's holding these packages up, which is slightly frustrating. Fortunately there are unofficial apt sources of these packages available, but technically "no version of Debian has a complete edition of KDE 3.x". Take care, Dale -- Dale E. Martin, Clifton Labs, Inc. Senior Computer Engineer [EMAIL PROTECTED] http://www.cliftonlabs.com pgp key available pgpysnCSrWFrG.pgp Description: PGP signature
Re: comment on "User Review of Debian GNU/Linux"
> don't know what your luck is like, but the Debian mirrors I've tried > (wustl.edu and rutguers.edu) are overloaded about half the time I access > them. "apt-get install netselect" and then run this command: netselect -vvv $(host http.us.debian.org | cut -f3) It will tell you which official mirror is the fastest from the site you run it on. Take care, Dale -- Dale E. Martin, Clifton Labs, Inc. Senior Computer Engineer [EMAIL PROTECTED] http://www.cliftonlabs.com pgp key available pgpC4ZWV0jMGv.pgp Description: PGP signature
Re: handling Mozilla with kid gloves [was: GUADEC report]
> > You're seriously suggesting that Debian wouldn't be laughed out of the > > park for releasing without Mozilla at the moment? If you aren't > > suggesting this, then that comment is irrelevant. > > We don't seem to fear the laughter of others when it comes to AMD64 > support. Just a guess here but it would seem that omitting mozilla would affect a larger number of users than AMD64, given that the x86 distribution should run fine on AMD64 platforms. Also we have released mozilla in the past so there is an existing user base among Debian users. Even so we clearly need to resolve the MPL issues that have come up. Take care, Dale -- Dale E. Martin, Clifton Labs, Inc. Senior Computer Engineer [EMAIL PROTECTED] http://www.cliftonlabs.com pgp key available signature.asc Description: Digital signature
Re: Boot Floppy
On Thu, Aug 05, 2004 at 02:39:57AM -0700, melborg wrote: > I know you are mostly volunteers, and so I know that you're all extremely > busy, but I was hoping for a favor if you happen to get a free few minutes. I'm taking this up off-list - I'll help him out. Take care, Dale -- Dale E. Martin, Clifton Labs, Inc. Senior Computer Engineer [EMAIL PROTECTED] http://www.cliftonlabs.com pgp key available
Re: When are u realising the next stable Debian Version?
On Mon, Aug 09, 2004 at 09:36:01PM -0300, Vagner R. F. S. wrote: > > I'd like to know how long it will take for the next Debian Stable > Version to come up. Is it only in December or before it? The standard answer is "when it's ready" and "sooner if you help". However, the base system is now mostly frozen and the hope is that Sarge will be releasable in the fall or early winter. Take care, Dale -- Dale E. Martin, Clifton Labs, Inc. Senior Computer Engineer [EMAIL PROTECTED] http://www.cliftonlabs.com pgp key available
