Packages in contrib solely because they allow using non-free software

[Johannes Schauer Marin Rodrigues]

Quoting Simon McVittie (2021-04-04 13:55:21)
> On Sun, 04 Apr 2021 at 13:23:14 +0200, Joerg Jaspert wrote:
> > On 16093 March 1977, Dominik George wrote:
> > > That surprised me. If a package is free software, in ful laccordance
> > > with the DFSG, why is it put into contrib?
> > 
> > There is, as usual, no clear answer.
> > 
> > The policy for main is clear on that it needs to be self contained. So
> > software in main must not require something outside to work and do its job.
> > Contrib is the area where that is allowed. License wise its the same as
> > main, but it allows to depend on something not available for building or
> > working.
> 
> There was some discussion relevant to this on debian-devel-games earlier
> this year: the subthread starts at
> <https://lists.debian.org/debian-devel-games/2021/01/msg00014.html>.
> 
> I don't think the rule can be as simple as "must not require something
> outside to work and do its job", because we have Free clients for non-Free
> network services (like all the instant messaging services that used to
> exist), and those were always in main. Similarly, it would be absurd to
> kick out email clients into contrib just because they are primarily used
> to read non-Free email messages like this one! :-)
> 
> As I mentioned on d-d-games, one of the major things I tend to ask myself
> when thinking about the borderline between main and contrib is: if the
> content that this package downloads was somehow in the Debian archive,
> would the downloader have a Depends or Recommends on it, or would it be
> a Suggests or no dependency at all?
> 
> Another factor in choosing main or contrib, for me, is whether the
> downloader is specifically hard-coded to work with particular content,
> or whether it generically works with any content in a particular
> format. game-data-packager and quakespasm are both close to the main/contrib
> borderline, and this factor is why I think they are in the correct archive
> areas: g-d-p downloads and repackages specific non-Free games, so it's
> in contrib, whereas quakespasm can play any Free or non-Free set of
> Quake-compatible levels, so it's in main.
> 
> I think winetricks is *probably* correctly in contrib, because it has
> hard-coded knowledge of how to best to download and install specific
> non-Free Windows DLLs? Like game-data-packager, it's quite close to the
> line between main and contrib, but I think it does make sense to consider
> it to be on the contrib side of that line (although I'm sure I could be
> convinced otherwise).
> 
> As Joerg says, this is all fairly subjective and unclear, but I think we
> do have an approximately coherent policy for what can and can't be in main,
> and that's realistically the best thing we are going to get.

another way to answer the question is to find some software similar to the one
that you want to package and see if that software is in Debian main or in
contrib. If it is in main, then at least one DD and FTP master already agreed
that packages of that nature are fit for main.

Maybe the comparison to winetricks is not very fitting because I think
winetricks can *only* download non-free software while lutris can also download
games that their developers distribute under a DFSG license?

Let me show you a package of mine that is still in Debian main even though it
is a "downloader [that is] specifically hard-coded to work with particular
[non-free] content" and thus fails Simon's test from above:

https://packages.debian.org/source/unstable/rss-bridge

I guess most people will use that package to access non-free services like
Facebook, Instagram or YouTube. After all, rss-bridge was specifically written
to work around the limitations of these non-free services:

https://github.com/RSS-Bridge/rss-bridge/#rant

Should anybody ever file an RC bug against the package I will point out that it
is also able to work with DFSG free software like Mediawiki. Maybe you can do
the same?

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-games-devel/attachments/20210405/62e99e71/attachment.sig>