Re: There are _TWO_ discussions here

[Christian Schwarz <schwarz@monet.m.isar.de>]

On Thu, 31 Jul 1997, Dale Scheetz wrote:

> On Thu, 31 Jul 1997, Christian Schwarz wrote:
> 
> > (How much time are you spending on this discussion? I feel like I explain
> > everything over and over again but am presented with the same arguments
> > all the time.)
> 
> Because you have not conviced us that your explaination is correct. I
> could make the same statement. I make my points and you ignore them and
> continue to discuss your points as though they were an answer to my
> points. One of my problems with your position is that it is based on, what
> I see as, false assumptions, several of which appear in this posting.

Oh, ok. I think you're right, the same applies to me :-) (it's not that I
didn't had a look at your arguments--I think we have different point of
views and are not focusing on the same facts)

> I will try, one more time to point these out.

Ok, I'll try this too ...

> > I've listed the 6 packages in another mail from yesterday, I think. These
> > packages are _not_ DFSG compliant, but may be in main according to our
> > current definition. 
> 
> No non-compliant software may be in main!

Oops, I meant "non-free" instead of "main". Sorry.

> If we change policy to make all contrib packages apply
> > to DFSG too, these packages will have to be moved to non-free (which is no
> > problem for me, since they are "non free", according to the DFSG).
> > 
> So are all the other packages in contrib!

The question is whether some software is `free' if its license applies to
the DFSG but the software depends on a `non-free' program. 

Currently, we say that the DFSG does _not_ include the `consistency rule'.
Thus, packages in main have to comply to 1. DFSG and 2. consistency rule
and this results in the fact, that `contrib' contains also some `free'
programs (i.e. DFSG compliant software) that depend on non-free packages,
though.

> > > > > while providing protection from the legal implications of the
> > > > > licenses of packages currently found in "non-free". 
> > > > 
> > > > I wouldn't call it `protection' if we encourage CD manufacturers to
> > > > include contrib and have 11 packages in contrib now which have severe
> > > > license `problems'. (That's 42 total packages, so 26%.) The problem is
> > > > that `the average maintainer' does not know enough about licenses (or does
> > > > not want to know enough :) to distinguish contrib from non-free.
> > > 
> > > Then we clearly need some legal help vetting software licenses. I don't
> > > see a solution from "This is really confusing, lets lump all the confusing
> > > stuff together".
> > 
> > I feel like you don't read our mails carefully enough :-(
> > 
> > The complete opposite is true. As Guy said in another mail here two days
> > ago, we have a rather good definition for `free' (DFSG), but a rather bad
> > explanation of which packages are `freely-distributable'. 
> 
> Well, I disagree with both of you on this point. I find it quite simple
> to decide. You look for restrictive statements and see what they address.
> If they address distribution then, most probably, there is some
> distribution restriction on the software. That's all that needs to be
> decided, not the character of the restriction, but simply the existance of
> a distribution restriction.

(Now we are make progress!) The problem with your suggestion--to look for
restrictions--is that everything which is not explicitely allowed is
considered as `not allowed'. Thus, you can't say ``this software is not
distribution restricted''. You'll have to define what must be allowed--not
what is forbidden.

> While I agree that someone will still disagree with someone else as to
> whether or not this is true, that is something that I can't fix ;-)

I don't expect that somoene of us changes his mind on this. However, we'll
need a solution _now_.

> > So I'm not suggesting to `lump all the confusing stuff together' but to
> > sort the `confusing stuff' into `free' and `non-free' which is quite
> > easy for the average maintainer. The rest is up to the CD manufacturers,
> > since `freely-distributable' also varies from manufacturer to manufacturer
> 
> Which is exactly why any package that fits any manufacturer as a
> restriction should be held seperately from all other non-free software
> that has no such distribution restrictions.

We simply don't want to make any classification of `non-free' software.
There is `main' which is totally free, `contrib' with free stuff that
depends on non-free stuff (so it's `partially free') and `non-free' for
the rest (of course, we must be allowed to distribute the non-free
packages via ftp).

The CD manufacturers (and other distributors) have to check the non-free
licenses themselves. I am a CD manufacturer (as you are too) so we both 
know that this can easily be done.

> > (I can ship most of non-free, for example, so these packages are also
> > `freely-distributable').
> > 
> I only found 20 in non-free that I can distribute without permission from
> the author. It didn't feel like "most" to me.

I can ship 92 of 138 non-free packages.

> > > > And all CD manufacturers (as you and me) rely on their decision...
> > > > 
> Which is why we have a bug tracking system.

But it's probably too late... For example, current `contrib' contains a
few distribution restricted packages, which are on all `Debian Official
CDs'.

And why should we bother > 200 maintainers to check whether a package can
be distributed by all CD manufacturers if there are approx. 10 CD
manufactures (if at all--most of them simply distribute the official
images).

> > > > > While I appreciate that merging the two would make archive maintainance
> > > > > simpler, I don't think it will get more software on a CD.
> > > > 
> > > > We don't propose to "merge" contrib and non-free. We propose to make all
> > > > contrib packages apply to the DFSG too. This will move only 6 packages
> > > > from contrib to non-free--that's not much. But it will make life a lot
> > > > easier for maintainers and a lot safer for CD manufacturers.
> > > > 
> > > It is still my position that DFSG compliant should equal "goes into main".
> > > (This requires that you accept that the DFSG at least implies that
> > > packages that depend on no-free software are themselves non-free)
> > 
> > The only way I see to implement this standpoint, is to "merge" contrib and
> > non-free. Otherwise, we would have to specify the difference between
> > contrib and non-free in more detail--which is against our goals.
> > 
> I don't see a goal conflict here. Communicating information to our users
> that helps them use non-free packages effectively certainly falls within
> our social contract.

Moving 6 packages from contrib to non-free does not affect the `use' of
non-free software. But we'd have to write a DNFBFDSG (Debian Non-Free But
Freely Distributable Software Guidelines ;-) document which would be
against our goals.

> > > > And according to Bruce' last message, this change will also allow
> > > > "contrib" to go on the official CD image--which is currently not included
> > > > because of the `license troubles'.
> > > > 
> > > I thought it was not included because it was not free software.
> > 
> > Yes, that's what I wanted to say. I think Bruce will only let DFSG
> > compliant packages on the CD.
> > 
> > > > > I would rather see the DFSG expanded to speak to the issues of package 
> > > > > dependence on non-free software and what the implications are for that 
> > > > > dependence on the "freedoms" that can be associated with the dependent 
> > > > > code.
> > > > 
> > > > Some people said that the way they interpret the DFSG, these dependency
> > > > rules are already implied :-) 
> > > > 
> 
> And therein lies the confusion. Making these issues explicit in the Guide
> would reduce the confusion in this discussion and bring us to closure
> faster on the "interpertation" issues.

I agree that it would things a bit less confusing, but it's not the
necessary to get a decision on this topic here.

I'm starting to write pro and cons about my suggestion to make all contrib
packages apply to the DFSG. Can you please tell me (once again) why you
have a problem with this? (Currently, I don't see a single good argument
against this proposal. So it's better you summarize your standpoint than
if I would try to do it.)


Thanks,

Chris

--                  Christian Schwarz
                     schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian is looking     schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
for a logo! Have a
look at our drafts     PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
at    http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .