Some thoughts about firmware inclusion.

[Hans de Goede]

Jesse Keating wrote:
> On Thu, 25 Oct 2007 15:38:22 +0200
> Ralf Ertzinger <fedora at camperquake.de> wrote:
> 
>> 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).
> 
> That's cheating IMHO.  That's like saying a .jar file doesn't execute
> on the system CPU because the JVM executes it.
> 

Yes and No,

As said before I think the current guidelines work well, quoting some parts of 
them relevant to this discussion:

All from http://fedoraproject.org/wiki/Packaging/Guidelines # Legal:


"Shareware

Shareware applications are not Open Source code, and are not acceptable for Fedora.

However, it is worth noting that some non-executable content exists that is 
required to make Open Source applications functional. An example of this would 
be open sourced game engines, such as Doom, Heretic, and Descent. These game 
engines come with freely distributable shareware gamedata files.

In this case, the gamedata files can be packaged and included in Fedora, as 
long as the files meet the requirements for binary firmware."

Key here is not executable, which as this discussion turns out is a bit grey 
though, since game levels often contain a form of "instructions" to the game 
engine, so one could argue the game engine is a vm and the levels are executed 
on that vm.

Note that I'm not arguing in favor of this, I think the current interpretation 
that game engines are not vm's and thus game content is not executed but merely 
used as content is the correct interpretation, and that we should stick with 
this interpretation.


"Emulators

Most emulators (applications which emulate another platform) are not permitted 
for inclusion in Fedora. The rule of thumb to follow is: If it requires ROMs 
(or image files in any format) of copyrighted or patented material to be useful 
(and the owners of those copyrights and patents have not given their express 
written permission), then it's not permitted."

Notice how it says nowhere in the above that the ROMS themselves must be OSS, 
they merely must be freely distributable. We might want to clarify this by 
saying that emulator roms must meet the firmware guidelines.

Now here we hit some interesting ground which indeed needs more discussion. I'm 
in favor of treating BIOS(ish) roms of old computers, which are now freely 
redistributable like the amstrad ones, as content, if only because the sources 
are probably for ever lost.

However there are various freely redistributable dos games^H^H^H^H^Hprograms 
which run onder dosbox, and dosbox is clearly an emulator (it will run x86 
games hapily on powerpc). So do we allow packaging of these games, I say NO. 
Notice that this NO can be motived by the current rules as these programs are 
not required for the program (the emulator) to be usefull. Without _a_ dos 
program dosbox isn't very usefull, but not necessarily _this_ or _that_ 
program, much unlike a BIOS-ish rom where specifically that rom is required for 
the emulator to function.

So maybe for emulators we must make a distinction between wether or not some 
piece of data is required for it to function. If it is, we treat it as content 
(like the system and vga bios images for qemu). If it isn't, or iow if it 
merely is some software which can be run by the emulator we treat it as code. 
This is what we've been doing sofar, and I guess its time to codify this into 
some rules now.

---

Then another question is what do we do with free software which cannot be 
rebuilt from sources for whatever reason, here is what first popped up in ym mind:

1) If the software is native Linux software (iow elf-arch binaries) it _MUST_
    be rebuild from source, so that it is build against Fedora libs, using
    Fedora compilers and Fedora CFLAGS and normally will be available for all
    Fedora supported archs

2) If it is not native Linux software but rather runs under an emulator, for
    example old amstrad software, and it is opensource, then an srpm maybe used
    which contains both the sources and binaries from one and the same upstream.

On a second look I do not like 2 myself though, for one there seems little gain 
in rebuilding for example freedos from sources (see p.s.), actually in the 
ideal situation the resulting binaries would be identical to the ones 
distributed by freedos, as that is how most testing of this software is done, 
and thus we then don't loose a lot of QA. OTOH if our users cannot rebuild 
freedos (as example) from source under Fedora, then they loose some significant 
software freedoms, and the software effectively becomes non-free, and thus we 
do not want to distribute it.

Conclusion, free software which does not fall under the firmware exception may 
only be included in Fedore of build from source.

Regards,

Hans



p.s.

And in the past there have been discussions about freedos, and I was given 
permission (never got around to it) to package it using an srpm which included 
both the sources and the prebuild binaries from upstream. Instead of rebuilding 
from the freedos sources, as freedos cannot be compiled from sources under 
Fedora. This was not seen as a problem since the freedos binaries are not 
native Linux binaries, but are running under an emulator (they are running on 
the native CPU in v86 mode though). Freedos is a special case as it is freesoft 
ware, but cannot be built (it requires the free as in beer borland compiler, 
which in turn requires freedos + dosemu to run). I'm merely mentioning freedos 
to explain that there are many shades of gray here.