Re: main vs. contrib and their purposes
[Changing the Subject, because we've really started two threads here.]
On 20/02/14 14:41, Markus Koschany wrote:
> In my opinion the interpreter is either free software or not.
Its own freeness determines whether it goes in (main | contrib) or
non-free. The discriminating factor between main and contrib has nothing
to do with the interpreter's own freeness.
Free software that requires non-free software is exactly what contrib is
there for. I think the original statement on this is SC §1, "We will
never make the system require the use of a non-free component". Its
restatements in Policy, "None of the packages in the /main/ archive area
require software outside of that area to function" and "The contrib
archive area contains supplemental packages intended to work with the
Debian distribution, but which require software outside of the
distribution to either build or function", seem to be based on
interpreting that clause of SC §1 via saying that if anything in main
requires a non-free component, then main as a whole requires a non-free
component.
> The affiliation of a package to main or contrib is often not decided
> by its license or if it can be compiled or executed without non-free
> software but it is often a matter of subjective and arbitrary beliefs
> of single individuals and those are error-prone.
Of course, it's possible to argue about whether residualvm requires Grim
Fandango or Escape from Monkey Island to function. I personally think
it's hard to claim that an interpreter specifically written to interpret
two proprietary games, and for which no alternative data-set exists,
does not require one of those games; you seem to disagree with that
point of view. I'm not aware of any project-wide consensus or position
statement either way. In the absence of consensus, the best-placed
people to decide seem to be the ftpmasters and the maintainer.
> Why do we ship scottfree in main?
>
> My main concern is that we act not consistently.
Right, that does look like it might be a bug in one direction or the
other. If there's no Free game data interpretable by scottfree floating
around, then residualvm and scottfree should both be in the same archive
area - I'd say contrib, you'd say main.
> That leads to the strange situation where neither maintainers nor
> users care about the distinction between main or contrib anymore.
> "Just enable contrib, it's free anyway".
If what you want to do is, for instance,
* get inspiration from source code
* copy nice algorithms into your Free project (which you intend to
be in main)
* develop alternative assets that can replace the non-free ones
then yes, it is completely valid to not care about the distinction
between main and contrib: everything in contrib is Free. You might not
be able to compile it without installing anything non-DFSG (or modifying
it to use a Free library/compiler/whatever), but if you can, the
resulting binaries are equally Free. Similarly, you might not be able to
use it without installing something non-DFSG (or developing a free
replacement).
If what you want to do is *use* the software in its current form - "deb"
rather than "deb-src" in your sources.list - *then* the distinction matters.
> ioquake3 is an outstanding game engine. Even without OpenArena it
> would be a great piece of software to study but this should happen in
> main, in the Debian distribution.
I disagree (and, consistent with that, I uploaded yamagi-quake2 to
contrib). There is nothing wrong with studying yamagi-quake2 and copying
particularly good bits into Free projects - indeed, I suspect darkplaces
is quite likely to contain code from the Quake II engine - but that
doesn't mean it belongs in main.
Debian's primary mission is not promoting free software, or constructing
a mirror network for miscellaneous free software source code and assets.
Those are good things to do, we do them as a side-effect of working on
Debian, and I'm sure there are plenty of Debian contributors who
consider them to be more important than Debian itself, but they're not
the Debian project's purpose. What we do as a project is to make a free
operating system, containing software that can be used together; and
that's why I think "yes, but what does it *do*, in practice?" is a valid
question to ask.
S
Reply to: