Some thoughts about firmware inclusion.

Hans de Goede j.w.r.degoede at hhs.nl
Thu Oct 25 14:43:59 UTC 2007


Adam Jackson wrote:
> 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
>> change that.
>>
>> 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
> http://fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware for
> the details.
> 
> - 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
> free license.
> 
> 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.
> 

Well written, and I fully agree, except that besides an exception for game 
data, I would also like to see an exception for system ROM's for old computers 
like the amstrad, where amstrad has been so kind to allow free redistribution 
of the roms. I'm not advocating to make the same exception for software that 
ran on these old computers, merely for the code that was in ROM's _inside_ the 
sytem and thus is needed for the emulator to function _at all_, to me this 
clearly is firmware.

Regards,

Hans




More information about the fedora-devel-list mailing list