Jesse Keating wrote:
On Thu, 25 Oct 2007 15:38:22 +0200
Ralf Ertzinger <fedora@xxxxxxxxxxxxxx> 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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
