On Thu, 2007-10-25 at 15:38 +0200, Ralf Ertzinger wrote:
The finer point of this thread is whether it is permissible to ship
binary only, executable content in Fedora, as long as these binaries
are not executed on the main CPU. There is precedent in the form of
firmware, which executes on some hardware subsystem (the WLAN card,
for example), which we allow.
Now someone threw Win32 binaries into the pool, which are, however,
not the same kind of beast, since they _do_ execute, natively, at least
in part, on the main CPU. That they require WINE to run at all does not
Then there is the third group of binaries for non host native binaries
(for example, arcade ROM files) which do not execute on the main CPU,
since they were written for a completely different hardware (again,
for example, Motorola 68xxx CPUs). Apart from copyright concerns,
would this be permissible? The binary would not run on the main CPU,
but on a virtual one, which is provided by an emulator (which, in turn,
does run on the main CPU).
This is actually a subtle point. The Debian criteria for this is
whether the distribution contains the preferred form of modification,
but they don't bother to define that, it's merely in the eye of the
original author. As such, you could upload an ELF file you wrote by
hand in a hex editor and claim it's how you wanted to write it.
The Fedora Packaging Guidelines actually specifically prohibit this:
"All binaries or libraries included with Fedora packages must have been
built from sourcecode included in the source package." So to address
the cases you just gave:
- Firmware (defined by not running on the host CPU) is permissible as
long as it's transitively freely distributable; see
- win32 binaries (or Mach-O for OSX, or whatever else) that run on the
host CPU under a compatibility runtime like wine are permissible, as
long as they are built from source as part of the rpmbuild process, and
the source and binaries are under an acceptable free license.
- ROMs or other binary images that run under a CPU emulator are
permissible, as long as they are assembled from source as part of the
rpmbuild process, and the source and binaries are under an acceptable
There's another point in this spectrum that is instructive to compare
to: bytecode for various high-level languages. We wouldn't allow a
python .pyc or .pyo without source, even though it's bytecode in the
"Python" instruction set. Neither would we allow an Amiga ROM without
source, which is just a bytecode in the m68k instruction set.
I suppose, if I had to think about it, that the policy on game data sort
of contradicts this nice clean delineation, since game data files often
include a scripting language for in-game logic. That's not necessarily
a problem, merely an exception. Personally I'm fine with it, but it
seems difficult to construct a (non-emotional) justification for it that
doesn't expand to cover win32 binaries or ROMs without source.