Samuel Verschelde a écrit :
Hi,

I've reread our policy, but it's unclear to me where to put free software that
can't work (in a useful way for a user) without non-free data.

We currently have a mix of situations (sometimes in core, sometimes in
nonfree), which shows that it's not totally clear to other packagers either.

I see 2 different situations:

--- redistributable data ---
Data is put in nonfree media, so the binaries are put in nonfree too because
we can't put a requires from core to nonfree

Example : warsow and warsow-data

--- non redistributable data ---
Here two different policies seem to be applied, depending on the packager:
1°) put the binaries in core, since they are free
2°) put the binaries in non-free, since they are useless without non-free data
(extrapolation of the "self-contained" rule of core)

And there are grayzone cases, such as:
- prboom (free) which is meant to work with Doom's wads (nonfree) but can also
work with freedoom (free), so it's in core even if we apply 2°
- ioquake3, which is an engine that can be used by other free games (although
I think they often ship their own modified version), so it's in core even if we
apply 2°


So, can we reach a consensus about something we could write in the policy so
that there's no more confusion, and move the relevant packages from nonfree to
core or core to nonfree?

- If a package has any dependancies (requires or suggests) in nonfree, it should go into nonfree. Why I include suggests is because in the rpmdrake, the main graphical interface, suggests are treated the same as requires. And in urpmi, suggests are installed by default. If the user were queried for each suggest, I might change my mind about suggests.

- If the package cannot be run without non-free data, I would also put it in nonfree, since it would be useless without non-free data. Following the principal of core not requiring non-free.

However if free data is readily available (or creatable), even if the default data is non-free, I would put the package into core. (without the default non-free data.) This I would do even if the default non-free data were redistributable. I don't see a problem with putting redistributable non-free data in nonfree, with a comment to that effect in the free core package, as long as free alternative data exists. (But no link to such non-free data from core.) In such a case, I would prefer to install the alternate free data with the main package, or at least instructions detailing how to create or otherwise obtain it.
Best regards

Samuel Verschelde

My 2 cents :)

--
André

Reply via email to