Re: a Free Platform License?
- To: "Clark C. Evans" <firstname.lastname@example.org>
- Cc: Ben Finney <email@example.com>, firstname.lastname@example.org
- Subject: Re: a Free Platform License?
- From: Jeff Epler <email@example.com>
- Date: Sat, 17 Dec 2011 08:58:13 -0600
- Message-id: <20111217145812.GB12627@unpythonic.net>
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
I doubt it is possible to distribute any software for common x86 PCs in
compliance with your proposed license.
For instance, hypothetical FPL-licensed software cannot be distributed
for Linux, because Linux relies on ACPI which is a part of the
proprietary system BIOS.
Linux also depends on a bootloader. Unfortunately, the bootloader
depends on BIOS or EFI services, which are also proprietary software.
Hypothetical FPL-licensed software on common x86 PCs will also execute
x86 instructions, some of which are interpreted by updatable microcode
in the CPU. Even if a traditional CPU with a fixed microcode escapes
the "free platform" requriement, a CPU with the ability to update and
upgrade its microcode must fall within the purview of a "free platform"
Even when you make use of efforts to extend freedom as early in the boot
process as possible (e.g., coreboot) the typical PC-based system will
still require use of a proprietary VGA BIOS to initialize the video
card; it appears that coreboot is also designed to be shipped with
Intel's microcode updates though doubtless you could disable this if you
didn't mind your CPU having whatever errata the microcode updates fix.
(and you *want* these updates---for instance, I found that Intel used a
microcode update to fix erratum AG37, the description of which makes it
sound like it would make an implementation of 'memchr' that used the
'rep scas' instruction fail when >=4GB of memory is being searched)