Re: There are _TWO_ discussions here

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

On Wed, 30 Jul 1997, Dale Scheetz wrote:

> On Wed, 30 Jul 1997, Christian Schwarz wrote:
> 
> > On Tue, 29 Jul 1997, Dale Scheetz wrote:
> > 
> > > On 29 Jul 1997, Guy Maor wrote:
> > > 
> > > > Just in case it's not emminently clear to all, there are two things
> > > > being discussed here.
> > > > 
> > > > First, Christian and I (and possibly others), want to make contrib
> > > > packages DFSG compliant.  This is an important issue, and practically
> > > > nobody has responded to it.
> > > 
> > > It was always my understanding that the packages in contrib were not Free
> > > Software. Although the new DFSG doesn't explicity declare this to be the
> > > case, I seems to be implied.
> > 
> > The DFSG itself does not say anything about our "distributions"--it's the
> > policy. You are right, until now contrib was ``non-free'' too, but this is
> > what seems to confuse some people.
> > 
> > > The distinction that I would hate to see blurred is the distinction
> > > between not-free for distribution restrictions and not-free for other
> > > considerations.
> > 
> > The problem is that it's hard to specify any general rules for a
> > ``non-free-but-freely-distributable'' (i.e. contrib) package. Of course,
> > we could write some guidelines for this as with the DFSG, but this is
> > probably against our goals--we want to encourage the authors to produce
> > "free" software, not "contrib" software.
> 
> But the guidelines say that we "support" the distribution of non-free
> packages as well, for the needs of our user base. We also don't want to
> "punish" authors or software that is not entirely free.

Which guidelines are you referring too? The DFSG just says:

  ``We will support our users who develop and run non-free software on
Debian, but we will never make the system depend on an item of non-free
software. [...]

Thus, although non-free software isn't a part of Debian, we support its
use, and we provide infrastructure (such as our bug-tracking system and
mailing lists) for non-free software packages.''

And moving a package from "contrib" to "non-free" isn't a punishment!

On the other hand, Bruce said that contrib with its current definition
will _not_ go on the official CDs anymore. If we'd change policy to make
contrib==dfsg, than contrib could go on the official CDs again. Thus,
leaving policy as it is now is a `punishment' for DFSG compliant packages
in contrib!

> > > This distinction is very helpful in promoting the distribution of
> > > contrib,
> > 
> > moving 6 packages from contrib and non-free wouldn't make much difference 
> > 
> I keep hearing about these 6 packages. Which ones are we talking about? It
> sounds like these packages should never have been in contrib at all. If we
> are talking about packages that provide no source, these packages probably
> have no distribution restrictions and could go on my CD in any case.

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

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

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

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
(I can ship most of non-free, for example, so these packages are also
`freely-distributable').

> > And all CD manufacturers (as you and me) rely on their decision...
> > 
> > > 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.

> > 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 others are arguing that contrib would equal free if it weren't for
> these dependency issues, that contrib is mostly DFSG compliant and can be
> made so by removing several packages. It is this contention that I have a
> problem with.



Thanks,

Chris

--                  Christian Schwarz
                   schwarz@monet.m.isar.de, schwarz@schwarz-online.com
                  schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
                       
                PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
              
 CS Software goes online! Visit our new home page at
 	                                     http://www.schwarz-online.com



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