Re: vrms and contrib installers
Please follow up to debian-legal, where this belongs.
Mathieu Roy <firstname.lastname@example.org> writes:
> Wouter Verhelst <email@example.com> a tapoté :
>> Op di 02-09-2003, om 17:46 schreef Mathieu Roy:
>> > So, is there any obvious reason why some proprietary software get a
>> > "installer" package in contrib instead of a debian package in
>> > non-free? For instance, why the non-free flashplayer does not get a
>> > true debian package in non-free, to benefit truly of the debian tools.
>> There's one single requirement for software to go in non-free: we have
>> to be allowed to redistribute it.
>> In some cases, the license prohibits the act of redistribution -- even
>> if the software itself can be downloaded gratis from the author's
>> website. That's when installer packages get written :-)
> And so we have some almost meta-package in contrib, called
> installers, that install software that do not even fit for
> non-free. It's a strange workaround, to use contrib to provide
> packages that we cannot even provide in non-free.
Contrib is not a proper subset nor superset of non-free; neither is
Main a proper subset nor superset of Contrib.
> I'm puzzled. At first, I was thinking it was some kind of workaround
> to avoid entering non-free but, in fact, it would be a workaround for
> to enter debian for packages that would not be allowed at all in any
> other case -- which is in fact more sensible, easier to understand.
You are incorrect. Contrib is not part of Debian, any more than the
bug reports in the BTS are part of Debian: both are software
collections distributed by Debian. If the installer packages were in
Main, you'd have something to complain about, but they're not.
> Basically, if Microsoft Office someday works for GNU/Linux, we may
> have a free software in contrib that will install it,
I suspect MS would object to this.
> without the possibility to remove it with the standard debian tools.
By all means, file (wishlist?) bugs against any installer which does
not clean up the program when purged.
> Someone may say that are included in Debian only software estimated
> needed by users. But I'm sure we can found 30000000 companies that
> would switch over GNU/Linux if Microsoft Office was available.
> That's ok if we stick to the policy. But I'm not sure it was the
> spirit of the policy to allows that. And I think more important to
> try to stick to the spirit of the policy than to it's letter. Because
> changing its letter is always an option while changing its spirit is,
> I'm sure you'll agree, definitely not an option.
I think this contrasts interestingly with your stance on the GFDL:
even confronted with the intention of the author of the DFSG, you
argued that by the letter of its title, the DFSG should not apply to
Indeed, your opinion seems to have shifted from what would provoke an
argument there to what will provoke an argument here.
> I think that, at least, these installer, to be included in debian,
Conveniently, they're not in Debian, they're in Contrib.
> should be forced
IANADD, TINDA, but Policy in general seems to be descriptive, not proscriptive.
> to build a real debian package for this non-free
> software, when installing it. Some packages clearly identified that
> vrms can clearly identify, some package we can easily track and remove
> completely at will. So people would know what they exactly have on
> their computer. And I think that was the main point of the person who
> started the thread, the ability for the user to track this non-free
> software he got.
So should my web browser have to make .deb packages when I download an
RPM? How about when I download a TGZ? How about an ISO with a
Windows installation on it?
> So I think it would be appropriate to fill a bug for any of these
> installers, asking them to build a correct debian package for the
> software they install.
> What do you think?
I think that's insane. The installers are in contrib because they are
free software -- small installer programs -- which require non-free
software -- big useful non-free programs -- to run. They probably
should clean up after themselves when --purged, but I can see good
arguments against that as well.
Brian T. Sniffen firstname.lastname@example.org