On Mon, Dec 07, 1998 at 04:19:13AM -0500, Gregory Stark wrote:
>
> For the record I think we have to do something like Ian's new DFSG. The key
> aspect I find compelling about the new DFSG is the method of disallowing *all*
> restrictions, and then exempting specific types of restrictions. In the long
> term this method is actually far more robust than trying to list every type of
> restriction we don't like.
And /FAR/ more restrictive ourselves, I much prefer the approach of
listing what we consider non-free and if we run into something which is
blatantly non-free which we have not covered then we go through the run of
changing the DFSG, and yes, doing so would be a lot of trouble, thats
the whole idea of it...
For things which are borderline, it can basicly come down to the vote,
we don't want to end up with cases like 'well, its not really a non-free
requirement, but its not listed, so we won't take it for a few months
well we vote on possibly allowing said restriction, why don't you just
change your license?', which will happen from time to time..
>
> A few miscellaneous related opinions and responses (I haven't been reading my
> mail every day and so this is a kind of batch reply to lots of posts in this
> thread):
>
> Wooly language yay: I don't believe any attempt to make language more precise
> by making it wordier has actually yielded fewer arguments over its meaning.
> The existing DFSG is direct and explicit, it's quite well-written, I just
> think the new methodology is better. Ideally I think we need a DFSG about the
> length and precision of the old one but in the format of the new one where it
> prohibits everything and then lists exceptions allowed.
See above for the prohibits everything stuff..
As far as the rest of it, yes, I don't think it will help matters much,
if at all, to try and make it more precise by making it wordier..
>
> Patch releases boo: I would never undertake to manage a software derivative
> that I had to distribute via a patch, and if I wouldn't want to do it then I'm
> not comfortable saying it's ok for me to require others to. I don't want to
> prohibit Qt et al completely though, I'm beginning to think we need a class of
> software we consider free enough to include in the distribution but not free
> enough to consider "core" Debian software.
If its free it can go in main, if its free but depends on non-free then
it can go in contrib, if its non-free then it goes in non-free..
Very simple, I see no point in adding more layers of 'free'..
If the DFSG says its free then its free, if the DFSG says its not free
then its not free..
>
> Mutable standards yay: The claim that mutable standards are anathema (is that
> even proper grammar? :) is poppycock. An exception to allow requirements to
> change the name on such changes is plenty of protection for standards and as
> much protection as any copyright can really provide in any case.
I see no reason why there should be a restriction against requiring that
modified works (be it software or otherwise) be released under a
different name, so why is this even a issue?
>
> Argument by assertion; Argument by repetition; Personal attacks; etc: BOO!
> Please everyone just state your opinion, response to questions and arguments
> with factual argumentative responses, don't just say "no you're stil wrong,
> nyah nyah!"
Amen.
Zephaniah E, Hull.
>
> --
> greg
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
PGP EA5198D1-Zephaniah E, Hull <warp@whitestar.soark.net>-GPG E65A7801
Keys available at http://whitestar.soark.net/~warp/public_keys.
CCs of replies from mailing lists are encouraged.
Attachment:
pgpb0cPCFlsSm.pgp
Description: PGP signature