Re: There are _TWO_ discussions here

[Dale Scheetz <dwarf@polaris.net>]

On Fri, 1 Aug 1997, Christian Schwarz wrote:

> 
> > 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.
>
Here we are at the nitty gritty of our differences. The extablished policy
makes it clear that the packages in contrib are not free. The DFSG doesn't
make this clear. You view this as a problem with contrib, while I view it
as a bug in the DFSG.

Bruce, am I the only one who thinks that we need to modify the DFSG to
explicitly declare these dependency criterion?

It has always been the case (before the DFSG) that packages that depend
for their execution or construction on any non-free software can not
appear in the distribution because they are not free. The distinction
between contrib and non-free has always been based on distribution
restrictions. The distinctions between contrib and main are on many
fronts.

Recent interpretation of the DFSG has pointed up a naming confusion
between these two directories.
 
> > > > > > 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.

This is not true. Many licenses read: "This software is may be freely used
and distributed with the following exceptions..."

In fact my lawyer made suggestions on a recent copyright that didn't
change the wording, but simply moved the restrictions to the beginning of
the copyright, followed by what was allowed.

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

If we can admit that the DFSG is in error and Free Software must also be
independent of non-free software, then the only thing left of the problem
is the confusing names of the two directories.

I would propose the following to "fix" that problem:

/main			# The free portion know as "The Distribution"
/non-free		# All non-free packages available on "this" archive
/non-free/restricted	# The old definition for non-free
/non-free/unrestricted	# What has been called contrib in the past

This is based on my conviction that we should make a distinction between
distribution restrictions and other "missing freedoms" of non-free
software.

> 
> > > 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'.
> 
Just because the mistake has been made already, doesn't mean we
can't/shouldn't fix it when it comes to our attention. Changing policy to
correct past errors doesn't seem appropriate.

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

It isn't just CD manufacturers who are effected by distribution
restrictions. Just as, making a copy of a piece of proprietary software
for you friend violates that software's license, there can be non-free
packages that restrict such activity as well. (I don't think anything in
non-free is THAT restrictive, but I hope you see my point)

This isn't just about you and me. If Debian is to penetrate the
"corporate" world we have to make it clear what areas have potential legal
problems for those users as well as "Joe Enthusiast", or they risk legal
action through ignorance.

> 
> > > > > > 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.
> 
I certainly don't see this at all.

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


Because it mixes the ideas of non-free and non-distributable in an
inappropriate fashion.

My objection stems from the difference in my view of what contrib is all
about. You and I are coming from different directions on that issue, and I
see this as the major sticking point for us coming to a "meeting of
minds".

Waiting is,

Dwarf
-- 
_-_-_-_-_-_-                                          _-_-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-



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