Sign in with
Sign up | Sign in
Your question

Stallman rants about FreeBIOS

Last response: in CPUs
Share
Anonymous
a b à CPUs
March 7, 2005 4:31:09 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

I guess we will need a FreeBIOS eventually before DRM totally stops us
from even booting our PCs.

» Stallman's new campaign to free the BIOS | Open Source | ZDNet.com
http://blogs.zdnet.com/open-source/index.php?p=179

Yousuf Khan
Anonymous
a b à CPUs
March 7, 2005 9:42:25 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On 7 Mar 2005 13:31:09 -0800, "YKhan" <yjkhan@gmail.com> wrote:

>I guess we will need a FreeBIOS eventually before DRM totally stops us
>from even booting our PCs.
>
>» Stallman's new campaign to free the BIOS | Open Source | ZDNet.com
>http://blogs.zdnet.com/open-source/index.php?p=179
>

It could all be in silicon. Probably will be. Not just the BIOS.
Everything that makes money.

RM
Anonymous
a b à CPUs
March 7, 2005 10:22:14 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In article <1110231069.202730.243480@z14g2000cwz.googlegroups.com>,
YKhan <yjkhan@gmail.com> wrote:

>I guess we will need a FreeBIOS eventually before DRM totally stops us
>from even booting our PCs.

Old news; the Xbox has this feature. Fortunately, the average PC maker
doesn't have a business reason to do it, yet.

-- greg
Related resources
Anonymous
a b à CPUs
March 8, 2005 2:33:19 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

>> If it can be done in silicon, would that bring boot times down?
>
>If hardware is more uniform/standardized, boot time can
>be reduced. See Xbox or DVD players as an example.

Boot time can be reduced without changing hardware -- see LinuxBIOS
for an example. LinuxBIOS can actually boot a variety of OSes, not
just Linux. However, the information needed to fully initialize a lot
of PC hardware isn't availble -- video cards can be done efficiently
by emulating their BIOSes, but things like the memory controller and
stuff built into southbridges can't be done that way.

-- greg
Anonymous
a b à CPUs
March 9, 2005 1:14:15 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Greg Lindahl wrote:
> Boot time can be reduced without changing hardware -- see LinuxBIOS
> for an example. LinuxBIOS can actually boot a variety of OSes, not
> just Linux. However, the information needed to fully initialize a lot
> of PC hardware isn't availble -- video cards can be done efficiently
> by emulating their BIOSes, but things like the memory controller and
> stuff built into southbridges can't be done that way.

Does LinuxBIOS go into Protected Mode or does it stay in Real Mode like
regular BIOSes?

Yousuf Khan
Anonymous
a b à CPUs
March 9, 2005 2:31:40 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

"Robert Myers" <rmyers1400@comcast.net> wrote in message

snip

> >
> Intel wanted to provide a standard way to boot IA-64. A standard PC
> boot couldn't be used because itanium could not start (or execute,
> even) in IA-32 real mode. They had to do something, and EFI is what
> they did.
>
> I haven't had much of a chance to play with EFI, but what I've seen
> (you can get in there between the firmware and the OS, if you have to,
> and EFI applications run on a virtual machine) seems pretty
> attractive.
>

EFI is a small, very simple OS. It's not really a virtual machine
environment.
It provides various IO related interfaces to allow access to hardware in an
abstracted way. From its user interface side, it has a menu interface, and
there is a shell from which you can "run" EFI applications from a FAT
formatted disk partition. Applications can be as varied as a FTP program
(which exists), platform diagnostics, or boot loaders - a special type app
that loads some OS specific code, declares the end of boot services, and
never returns.

EFI also runs the platform and device initialization using ACPI - which
allows
the system vendor to embed a interpreted byte code that describes and
initializes non-standard things like core chip sets.

>
> Sure, the whole OS could migrate into EFI. It's already happened.
> With no disk installed, my itanium box boots into linux. Not an
> especially powerful linux, but that's a detail. You can boot into
> linux, fiddle things if you like, and then boot a disk-based OS.
>

Well... this isn't true as far as I know. Boot loaders are a special form
of EFI application used to load some OS specific code, transfer control
and never return. The Linux method is a EFI application called "elilo"
which is normally resident on a hard drive in the FAT formatted EFI
partition. "elilo" pulls in an image that contains a Linux kernel and
a memory disk. Or you could do a network boot using PXE (bootp on
steroids). But I don't know of anyone who is blasting "elilo" or the boot
kernel into flash ROM.

Intel could have used OpenBoot (Sun, Mac) as an alternative to rolling
their own. The advantage with EFI is that you can push things not
needed for booting onto mass storage instead of ever increasing ROM
sizes... things like diagnostics for example.
Anonymous
a b à CPUs
March 9, 2005 2:31:41 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In article <wBqXd.1299$Yv2.767@news.cpqcorp.net>,
FredK <fred.nospam@nospam.dec.com> wrote:

>EFI is a small, very simple OS.

This must involve a new definition of "small" and "very simple"!

>Intel could have used OpenBoot (Sun, Mac) as an alternative to rolling
>their own. The advantage with EFI is that you can push things not
>needed for booting onto mass storage instead of ever increasing ROM
>sizes... things like diagnostics for example.

Indeed, that's what LinuxBIOS does, too.

LinuxBIOS supports every device Linux does -- does EFI somehow use
drivers from some other OS, or are they unique?

-- greg
Anonymous
a b à CPUs
March 9, 2005 2:31:41 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On Tue, 08 Mar 2005 23:31:40 GMT, "FredK" <fred.nospam@nospam.dec.com>
wrote:

>
>"Robert Myers" <rmyers1400@comcast.net> wrote in message
>
>snip
>
>> >
>> Intel wanted to provide a standard way to boot IA-64. A standard PC
>> boot couldn't be used because itanium could not start (or execute,
>> even) in IA-32 real mode. They had to do something, and EFI is what
>> they did.
>>
>> I haven't had much of a chance to play with EFI, but what I've seen
>> (you can get in there between the firmware and the OS, if you have to,
>> and EFI applications run on a virtual machine) seems pretty
>> attractive.
>>
>
>EFI is a small, very simple OS. It's not really a virtual machine
>environment.

I'm sorry. I didn't mean to imply that the environment itself, which
as far as I know is linux, runs on a virtual machine. You'd have to
run a byte code interpreter in that environment to execute the kind of
EFI code that is interpreted at boot, but the intent, I believe, is
that device drivers be independent of CPU.

<snip>

>>
>> Sure, the whole OS could migrate into EFI. It's already happened.
>> With no disk installed, my itanium box boots into linux. Not an
>> especially powerful linux, but that's a detail. You can boot into
>> linux, fiddle things if you like, and then boot a disk-based OS.
>>
>
>Well... this isn't true as far as I know. Boot loaders are a special form
>of EFI application used to load some OS specific code, transfer control
>and never return. The Linux method is a EFI application called "elilo"
>which is normally resident on a hard drive in the FAT formatted EFI
>partition. "elilo" pulls in an image that contains a Linux kernel and
>a memory disk. Or you could do a network boot using PXE (bootp on
>steroids). But I don't know of anyone who is blasting "elilo" or the boot
>kernel into flash ROM.
>
I'm not sure what I said that you're disagreeing with. As far as I
know, the prompt I get at boot is linux. It isn't fully functional,
but, as I said, that's a detail. It's as much an OS as the ] prompt
was on an Apple ][--more actually, because it is a disk operating
system.

Sure, the widget that loads Linux (or whatever) loads from disk and
runs as a garden-variety program, but there is no reason at all why
full functionality couldn't be in firmware and, I believe, such a
thing will come to pass for thin, diskless clients. Such a client
will pull its operating system in via PXE? Maybe. No reason why it
has to, though.

RM
Anonymous
a b à CPUs
March 9, 2005 2:31:41 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

FredK wrote:
> Intel could have used OpenBoot (Sun, Mac) as an alternative to rolling
> their own. The advantage with EFI is that you can push things not
> needed for booting onto mass storage instead of ever increasing ROM
> sizes... things like diagnostics for example.

These days with big & cheap flash available for use as firmware, you
might as well put everything into ROM.

Yousuf Khan
Anonymous
a b à CPUs
March 9, 2005 3:32:18 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

"Greg Lindahl" <lindahl@pbm.com> wrote in message
news:422e362f$1@news.meer.net...
> In article <wBqXd.1299$Yv2.767@news.cpqcorp.net>,
> FredK <fred.nospam@nospam.dec.com> wrote:
>
> >EFI is a small, very simple OS.
>
> This must involve a new definition of "small" and "very simple"!
>

Well. Think about it. It is a ROM resident OS. It provides IO services,
memory management services, and a command line interface. It allows
you to write disk resident applications that it will simply run. It isn't
"that" big, or "that" complicated.

Now, EFI is just one *part* of the firmware - there is also ACPI, PAL
and SAL.

> >Intel could have used OpenBoot (Sun, Mac) as an alternative to rolling
> >their own. The advantage with EFI is that you can push things not
> >needed for booting onto mass storage instead of ever increasing ROM
> >sizes... things like diagnostics for example.
>
> Indeed, that's what LinuxBIOS does, too.
>
> LinuxBIOS supports every device Linux does -- does EFI somehow use
> drivers from some other OS, or are they unique?
>

Unique. They have a port/class like mechanism as I understand it, where
EFI abstracts the high level, and the devices themselves provide the low
level "port" code. PCI object format was extended so not only does it have
BIOS (ia32), and OpenSource (Forth), but also a new format for EFI.
Anonymous
a b à CPUs
March 9, 2005 3:32:19 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In article <murXd.1304$tB2.642@news.cpqcorp.net>,
FredK <fred.nospam@nospam.dec.com> wrote:

>> This must involve a new definition of "small" and "very simple"!
>
>Well. Think about it. It is a ROM resident OS. It provides IO services,
>memory management services, and a command line interface. It allows
>you to write disk resident applications that it will simply run. It isn't
>"that" big, or "that" complicated.

Ah. I wonder if it's bigger or smaller than LinuxBIOS. It certainly is
funny (ok, let's just say expensive) that EFI requires unique device
drivers.

Don Becker, champion of the "3 card monte" boot, which is quite similar
to LinuxBIOS, likes to make fun of EFI as being bloated in comparison.

-- greg
Anonymous
a b à CPUs
March 9, 2005 3:39:37 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

"Robert Myers" <rmyers1400@comcast.net> wrote in message
news:1tcs21ltapnsp1fdb6jn8lk0h1vvuffkvp@4ax.com...
> On Tue, 08 Mar 2005 23:31:40 GMT, "FredK" <fred.nospam@nospam.dec.com>
> wrote:
>
> >
> >"Robert Myers" <rmyers1400@comcast.net> wrote in message
> >
> >snip
> >
> >> >
> >> Intel wanted to provide a standard way to boot IA-64. A standard PC
> >> boot couldn't be used because itanium could not start (or execute,
> >> even) in IA-32 real mode. They had to do something, and EFI is what
> >> they did.
> >>
> >> I haven't had much of a chance to play with EFI, but what I've seen
> >> (you can get in there between the firmware and the OS, if you have to,
> >> and EFI applications run on a virtual machine) seems pretty
> >> attractive.
> >>
> >
> >EFI is a small, very simple OS. It's not really a virtual machine
> >environment.
>
> I'm sorry. I didn't mean to imply that the environment itself, which
> as far as I know is linux, runs on a virtual machine. You'd have to
> run a byte code interpreter in that environment to execute the kind of
> EFI code that is interpreted at boot, but the intent, I believe, is
> that device drivers be independent of CPU.
>

Nope. EFI and EFI applications are architecture specific - IA32 or
IA64 right now. The ACPI layer uses an interpreter for the "code"
that knows how to enumerate the platform and devices, and also
how to access that platform specific hardware (like a core chipset).

I also believe that the object format in the PCI devices ROM may
be an interpreted byte stream - but I don't recall offhand.

> <snip>
>
> >>
> >> Sure, the whole OS could migrate into EFI. It's already happened.
> >> With no disk installed, my itanium box boots into linux. Not an
> >> especially powerful linux, but that's a detail. You can boot into
> >> linux, fiddle things if you like, and then boot a disk-based OS.
> >>
> >
> >Well... this isn't true as far as I know. Boot loaders are a special
form
> >of EFI application used to load some OS specific code, transfer control
> >and never return. The Linux method is a EFI application called "elilo"
> >which is normally resident on a hard drive in the FAT formatted EFI
> >partition. "elilo" pulls in an image that contains a Linux kernel and
> >a memory disk. Or you could do a network boot using PXE (bootp on
> >steroids). But I don't know of anyone who is blasting "elilo" or the
boot
> >kernel into flash ROM.
> >
> I'm not sure what I said that you're disagreeing with. As far as I
> know, the prompt I get at boot is linux.

An Itanium system will initialize to a boot menu. One selection is
"shell" -
this is not Linux. If you put a Linux distribution CD into the system, it
"should" auto-boot it into a simple Linux kernel. But Linux isn't in the
ROM AFAIK on any Itanium system.

>
> Sure, the widget that loads Linux (or whatever) loads from disk and
> runs as a garden-variety program, but there is no reason at all why
> full functionality couldn't be in firmware and, I believe, such a
> thing will come to pass for thin, diskless clients. Such a client
> will pull its operating system in via PXE? Maybe. No reason why it
> has to, though.
>

It is certainly possible to blast it into the ROM or Flash instead of
having it disk resident.
Anonymous
a b à CPUs
March 9, 2005 7:06:26 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On 2005-03-08 21:14:15 -0600, Yousuf Khan <bbbl67@ezrs.com> said:

> Greg Lindahl wrote:
>> Boot time can be reduced without changing hardware -- see LinuxBIOS
>> for an example. LinuxBIOS can actually boot a variety of OSes, not
>> just Linux. However, the information needed to fully initialize a lot
>> of PC hardware isn't availble -- video cards can be done efficiently
>> by emulating their BIOSes, but things like the memory controller and
>> stuff built into southbridges can't be done that way.
>
> Does LinuxBIOS go into Protected Mode or does it stay in Real Mode like
> regular BIOSes?

IIRC, LinuxBIOS gets into protected mode ASAP, because it's easier to
code for. I don't know what that has to do with Greg's comment, though.

--
Wes Felter - wesley@felter.org - http://felter.org/wesley/
Anonymous
a b à CPUs
March 9, 2005 4:10:55 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Robert Myers <rmyers1400@comcast.net> writes:

>> The problem is also that this represents a loophole in the GPL. If
>> you embed DRM in the hardware and require the OS to be signed¹,
>> you could distribute GPL-compliant source code to your hearts content,
>> without granting the users the freedom to actually *run* modified
>> code.

> It is really hard to see how that could happen without turning the
> whole world of Linux software upside down. Maybe I just lack
> imagination.

I agree it's not likely to happen to computing in general. I don't
consider it unlikely to happen to niches -- after all, it is
approximately how the (unmodified) X-box works.

Let's say Sony (since it's more Linux agnostic) sets up PS3 to only
boot signed OSes. I don't think that's very far-fetched. Then they
are free to provides a signed Linux kernel for it, and thus you get to
run GPL software on it, without actually getting the freedoms the GPL
was supposed to ensure.

> Or, rather, the only way I see it happening is if the content owners
> give enough money to get congress to mandate such a thing.

If it is presented as elimination of software piracy and copyright
breach, I'm sure you could get at least some elected officials to
listen (even if very few in the industry actually want this to
happen).

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Anonymous
a b à CPUs
March 9, 2005 5:08:39 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Ketil Malde wrote:
> The problem is also that this represents a loophole in the GPL. If
> you embed DRM in the hardware and require the OS to be signed¹,
> you could distribute GPL-compliant source code to your hearts content,
> without granting the users the freedom to actually *run* modified
> code.

As I understand, the GPL requires you to ship *all* sources. If the
signature of the OS binary is a fundamental part of its functionality, you
have to include this private key into the source distribution.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Anonymous
a b à CPUs
March 9, 2005 8:26:33 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

FredK wrote:
> Nope. EFI and EFI applications are architecture specific - IA32 or
> IA64 right now.

I also had the impression that EFI applications could be using
bytecodes. I am sure it is not required, but isn't this a possibility ?

A search for "EFI application bytecode" returned this:
<URL:http://www.kernelthread.com/publications/firmware/&gt;

In all those posts I didn't see a single reference to EFI being
mostly open-sourced already:
<URL:http://www.tianocore.org/&gt;

Intel selected the BSD license for this code. I imagine that
the GPL may have caused quite a few legal issues for hardware
manufacturers. I understand that the code is not complete, however
it shouldn't be a surprise to anyone, given that Intel also needs
the support from traditional BIOS companies to promote EFI.

Eric

(who never had anything to do with EFI besides booting IPF
hardware)
Anonymous
a b à CPUs
March 9, 2005 8:26:34 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On Wed, 09 Mar 2005 17:26:33 GMT, Eric Gouriou <eric.gouriou@hp.com>
wrote:

>FredK wrote:
>> Nope. EFI and EFI applications are architecture specific - IA32 or
>> IA64 right now.
>
> I also had the impression that EFI applications could be using
>bytecodes. I am sure it is not required, but isn't this a possibility ?
>

http://developer.intel.com/technology/efi/main_specific...

<quote>

The EFI Driver Model is designed to be generic and can be adapted to
any type of bus or device. Also included in the EFI 1.10 Specification
is a set of companion documents that describe how to write PCI bus
drivers and PCI device drivers. These companion documents also
describe how to store an EFI driver in a PCI option ROM while
maintaining compatibility with legacy option ROM images. The EFI
Driver may be compiled for EFI Byte Code to enable a single image to
support multiple platforms, including IA-32 and Itanium®.

</quote>

RM
Anonymous
a b à CPUs
March 9, 2005 8:32:48 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Bernd Paysan <bernd.paysan@gmx.de> writes:

>Ketil Malde wrote:
>> The problem is also that this represents a loophole in the GPL. If
>> you embed DRM in the hardware and require the OS to be signed¹,
>> you could distribute GPL-compliant source code to your hearts content,
>> without granting the users the freedom to actually *run* modified
>> code.

>As I understand, the GPL requires you to ship *all* sources. If the
>signature of the OS binary is a fundamental part of its functionality, you
>have to include this private key into the source distribution.

Why the private key? Wouldn't just the signature suffice? After
all, it *is* sufficient to reproduce the binary.

I think requiring the private key is a stretch; if are also not
required to ship the sources of whatever else the linker deposits
in the binary, such as crt0.o, any shared data from libc, etc.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Anonymous
a b à CPUs
March 9, 2005 8:33:40 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Robert Myers <rmyers1400@comcast.net> writes:

>The EFI Driver Model is designed to be generic and can be adapted to
>any type of bus or device. Also included in the EFI 1.10 Specification
>is a set of companion documents that describe how to write PCI bus
>drivers and PCI device drivers. These companion documents also
>describe how to store an EFI driver in a PCI option ROM while
>maintaining compatibility with legacy option ROM images. The EFI
>Driver may be compiled for EFI Byte Code to enable a single image to
>support multiple platforms, including IA-32 and Itanium®.


Ah, the reinvention of IEE1275.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Anonymous
a b à CPUs
March 9, 2005 8:56:34 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Robert Myers wrote:
> On Wed, 09 Mar 2005 17:26:33 GMT, Eric Gouriou <eric.gouriou@hp.com>
> wrote:
>>FredK wrote:
>>
>>>Nope. EFI and EFI applications are architecture specific - IA32 or
>>>IA64 right now.
>>
>> I also had the impression that EFI applications could be using
>>bytecodes. I am sure it is not required, but isn't this a possibility ?
>
> http://developer.intel.com/technology/efi/main_specific...
>
> <quote>
>
> The EFI Driver Model is designed to be generic and can be adapted to
> any type of bus or device. Also included in the EFI 1.10 Specification
> is a set of companion documents that describe how to write PCI bus
> drivers and PCI device drivers. These companion documents also
> describe how to store an EFI driver in a PCI option ROM while
> maintaining compatibility with legacy option ROM images. The EFI
> Driver may be compiled for EFI Byte Code to enable a single image to
> support multiple platforms, including IA-32 and Itanium®.
>
> </quote>

Thanks, however Fred's post already mentioned that drivers could
be using bytecode. The question is about EFI 'applications', since
Fred appeared to make a distinction between driver and application.
I was not aware that there was a distinction between the two.

There were mentions of OpenFirmware in this thread. My understanding
is that OpenFirmware, while defined by some (ISO?) standard, is not
open by the current standards of 'Free Software' proponents. My impression
is that EFI ends up being more open, which probably annoys some zealots
so much that they have to conveniently ignore the facts (I am not
talking about RMS here).

Repeated disclaimer: I am just an interested bystander when it comes
to EFI.

Eric
Anonymous
a b à CPUs
March 9, 2005 8:56:35 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Eric Gouriou <eric.gouriou@hp.com> writes:

> There were mentions of OpenFirmware in this thread. My understanding
>is that OpenFirmware, while defined by some (ISO?) standard, is not
>open by the current standards of 'Free Software' proponents. My impression
>is that EFI ends up being more open, which probably annoys some zealots
>so much that they have to conveniently ignore the facts (I am not
>talking about RMS here).

Why is Open Firmware not open? Just because the Free Software
Zealots redefined what open means? C'mon.

I don't think there are free OpenFirmware implementation.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Anonymous
a b à CPUs
March 9, 2005 9:59:49 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In comp.sys.ibm.pc.hardware.chips David <david.nospam@westcontrol.removethis.com> wrote:
> You also have to include all required tools for building
> your modified code and making it runable, as part of the
> "source" of the gpl'ed code.

Where does it say this in GPL v2 ?

This is a hole I expect closed in v3.

-- Robert
Anonymous
a b à CPUs
March 9, 2005 10:30:13 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

YKhan wrote:
> I guess we will need a FreeBIOS eventually before DRM totally stops us
> from even booting our PCs.
>

As a tangential issue, is the term BIOS (Basic Input-Output System)
apposite anymore? Do any modern OSes or applications use the abstraction
layer the BIOS (is supposed to) implement?

As I understand it, and I might be wrong, the BIOS is only active during
the POST and in handing off control to whatever bootloader is installed
on the bootable media (disk, flash drive, network) the PC uses. In the
DOS and CP/M days, applications would actually call into the BIOS to get
the hardware to do stuff (not the fastest applications, but the system
calls were always there).
Anonymous
a b à CPUs
March 9, 2005 11:07:06 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Wes Felter wrote:
> On 2005-03-08 21:14:15 -0600, Yousuf Khan <bbbl67@ezrs.com> said:
>
>> Greg Lindahl wrote:
>>
>>> Boot time can be reduced without changing hardware -- see LinuxBIOS
>>> for an example. LinuxBIOS can actually boot a variety of OSes, not
>>> just Linux. However, the information needed to fully initialize a lot
>>> of PC hardware isn't availble -- video cards can be done efficiently
>>> by emulating their BIOSes, but things like the memory controller and
>>> stuff built into southbridges can't be done that way.
>>
>>
>> Does LinuxBIOS go into Protected Mode or does it stay in Real Mode
>> like regular BIOSes?
>
>
> IIRC, LinuxBIOS gets into protected mode ASAP, because it's easier to
> code for. I don't know what that has to do with Greg's comment, though.

Quite simple really, why would it be necessary to emulate the video bios
when all one would need to do is make a call to the actual video bios? I
was trying to figure out why the Linux bios isn't simply making a call
to the other bioses on the system. Obviously, a video bios is Real-mode
code, so the Linux bios cannot possibly make a simple call to it.

Yousuf Khan
Anonymous
a b à CPUs
March 10, 2005 12:15:59 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Casper H.S. Dik wrote:
> Why is Open Firmware not open? Just because the Free Software
> Zealots redefined what open means? C'mon.

Note also that the way Open Firmware exchanges drivers is by tokenized
*source*. Not exactly what Free Software Zealots want (comments don't get
tokenized), but close enough for all practical purposes.

> I don't think there are free OpenFirmware implementation.

www.openbios.org

Not completed, but with rapid progress.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Anonymous
a b à CPUs
March 10, 2005 12:47:11 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Ketil Malde wrote:

> The problem is also that this represents a loophole in the GPL. If
> you embed DRM in the hardware and require the OS to be signed¹,
> you could distribute GPL-compliant source code to your hearts content,
> without granting the users the freedom to actually *run* modified
> code.

According to humorix.org (http://humorix.org/articles/2004/12/preview/),
in their "Year 2005 in preview" this will be solved by RMS, thusly:

Dec. 2 -- The newly created Free Hardware Foundation, headed by Richard
M. Stallman, finally demonstrates a practical, non-evil application for
DRM hardware. Using an open BIOS architecture, the system will refuse to
run any software that is not released under an open source license.

"Our DRM system is designed to manage and protect your digital rights,
not the rights of Hollywood executives jockeying to buy their fifth
luxury yacht," RMS explains. "The idea is simple: All software must
include the source code, which is compiled on the fly by the CPU. All
binary code will be automatically chucked into /dev/null."

In another interview, RMS adds wryly, "This is one platform Microsoft
will not be able to embrace and extinguish. If they try to force Windows
to run on this hardware by hacking the DRM restrictions, then they will
be in violation of the DMCA. Bwahahahaha!"

--
Toon Moene - e-mail: toon@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
News on GNU Fortran 95: http://gfortran.org/
Anonymous
a b à CPUs
March 10, 2005 1:12:10 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Robert Redelmeier wrote:

> In comp.sys.ibm.pc.hardware.chips David
> <david.nospam@westcontrol.removethis.com> wrote:
>> You also have to include all required tools for building
>> your modified code and making it runable, as part of the
>> "source" of the gpl'ed code.
>
> Where does it say this in GPL v2 ?

In section 2:

" 2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.

b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
^^^^^^^^^^
parties under the terms of this License."

So if the signature is part of the *functionality* of the program, i.e. a
program without that signature would not do the same thing, the signature
is part of the program, and therefore the means to create it, the "source
code" to generate the signature (that's the private key, and in case of a
non-standard signature process, also the signature program) is part of the
overall source code.

If there's a loophole, than in sloppy interpretation of what the source code
is. The source code *is* the stuff to create the program from. It doesn't
need to be C code.

As I said in another posting, the mere fact of having a signature in a
source or binary package does not mean you have to give out your private
key. As long as the signature has no effect on the functionality of the
program, it is not part of the source code. I sign my program packages, but
you can build them to the same effect when you ignore my signature. It
doesn't contribute to the program, so it's a mere aggregate. And that's
clear - then it doesn't need to be GPL'd. If the signature is essential for
the program to work, it's no longer a mere aggregate, it's part of the
program.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Anonymous
a b à CPUs
March 10, 2005 1:29:48 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

"Eric Gouriou" <eric.gouriou@hp.com> wrote in message
news:mNGXd.1350$c33.1243@news.cpqcorp.net...
> Robert Myers wrote:
> > On Wed, 09 Mar 2005 17:26:33 GMT, Eric Gouriou <eric.gouriou@hp.com>
> > wrote:
> >>FredK wrote:
> >>
> >>>Nope. EFI and EFI applications are architecture specific - IA32 or
> >>>IA64 right now.
> >>
> >> I also had the impression that EFI applications could be using
> >>bytecodes. I am sure it is not required, but isn't this a possibility ?
> >
> > http://developer.intel.com/technology/efi/main_specific...
> >
> > <quote>
> >
> > The EFI Driver Model is designed to be generic and can be adapted to
> > any type of bus or device. Also included in the EFI 1.10 Specification
> > is a set of companion documents that describe how to write PCI bus
> > drivers and PCI device drivers. These companion documents also
> > describe how to store an EFI driver in a PCI option ROM while
> > maintaining compatibility with legacy option ROM images. The EFI
> > Driver may be compiled for EFI Byte Code to enable a single image to
> > support multiple platforms, including IA-32 and Itanium®.
> >
> > </quote>
>
> Thanks, however Fred's post already mentioned that drivers could
> be using bytecode. The question is about EFI 'applications', since
> Fred appeared to make a distinction between driver and application.
> I was not aware that there was a distinction between the two.
>
> There were mentions of OpenFirmware in this thread. My understanding
> is that OpenFirmware, while defined by some (ISO?) standard, is not
> open by the current standards of 'Free Software' proponents. My impression
> is that EFI ends up being more open, which probably annoys some zealots
> so much that they have to conveniently ignore the facts (I am not
> talking about RMS here).
>
> Repeated disclaimer: I am just an interested bystander when it comes
> to EFI.
>

My exposure to EFI was in relation to making VMS boot on Itanium.

EFI applications themselves are IA64 or IA32 binaries, they are not
interpreted. The drivers being in bytecode I think is an attempt to make
them architecture independent (so you don't need multiple objects in
ROM for each architecture), and in the context of drivers - there is an
interpreter and a virtual machine environment.

My only exposure to OpenBoot was in the context of an investigation to
replace the Alpha SRM and AlphaBIOS. It was developed by SUN, but
the developer got himself spun off into his own company to create
OpenBoot - which is used to boot MacOS, and could even be used to
boot a PC using a BIOS "wrapper". It is completely in Forth. You can
find OpenBoot drivers in some PCI adapters (if they work on Apple) -
which are a binary coded Forth.
Anonymous
a b à CPUs
March 10, 2005 1:46:46 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In article <422f33ff$0$28975$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:

> Why is Open Firmware not open? Just because the Free Software
> Zealots redefined what open means? C'mon.

Please don't throw stones at the wrong people. "Free Software
Zealots" generally care a lot about the meaning of "Free", but usually
not "Open".

For example, Stallman's recent "Free BIOS" rant only uses "open" when
talking about what the "Open Source" people are saying. He is using
their definition; no redefinition involved.

It's fine to disagree with what people say. But it's not as fine to
not get straight who said what.

-- greg
March 10, 2005 9:20:12 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On Wed, 09 Mar 2005 18:59:49 +0000, Robert Redelmeier wrote:

> In comp.sys.ibm.pc.hardware.chips David <david.nospam@westcontrol.removethis.com> wrote:
>> You also have to include all required tools for building
>> your modified code and making it runable, as part of the
>> "source" of the gpl'ed code.
>
> Where does it say this in GPL v2 ?
>
> This is a hole I expect closed in v3.
>
> -- Robert

From section 3 of GPL v2:

"The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source code
means all the source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control compilation
and installation of the executable. However, as a special exception, the
source code distributed need not include anything that is normally
distributed (in either source or binary form) with the major components
(compiler, kernel, and so on) of the operating system on which the
executable runs, unless that component itself accompanies the executable."

I don't know whether DRM signing would count as "scripts used to control
compilation and installation of the executable", but it could well do.
Anonymous
a b à CPUs
March 10, 2005 10:04:24 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In comp.sys.ibm.pc.hardware.chips David wrote:
> On Wed, 09 Mar 2005 18:59:49 +0000, Robert Redelmeier wrote:
>> In comp.sys.ibm.pc.hardware.chips David wrote:
>>> You also have to include all required tools for building
>>> your modified code and making it runable, as part of the
>>> "source" of the gpl'ed code.
>>
>> Where does it say this in GPL v2 ?
>
> From section 3 of GPL v2:
> "The source code for a work means the preferred form of the
> work for making modifications to it. For an executable work,
> complete source code means all the source code for all modules
> it contains, plus any associated interface definition files,
> plus the scripts used to control compilation and installation of
> the executable. However, as a special exception, the source code
> distributed need not include anything that is normally distributed
> (in either source or binary form) with the major components
> (compiler, kernel, and so on) of the operating system on which
> the executable runs, unless that component itself accompanies
> the executable."

> I don't know whether DRM signing would count as "scripts used
> to control compilation and installation of the executable",
> but it could well do.

I don't see any binary tools like compilers, checksum or signature
generators listed in sec 3, second sentence. "script" appears to
mean some sort of makefile. "interface def files" would appear
to be hw drivers. A sig.gen is neither of those, and even if it
were distributed, it might not contain the secret key that the
BIOS would need.

When you distribute GPG, you're not required to distribute keys.

Oddly, the last sentence excludes binaries that the second
sentence never included. What the second sentence could
[and perhaps should] have said is "plus any tool necessary
to modify and rebuild a binary runnable after modification."
Then let the last sentence exception operate.

Sony [neutral example] could distribute everything, but with
a single signature, valid only for a kernel complied exactly
per the makefile. Any mods would blow the sig.

The problem with this hole is it's locked in GPLv2, and
I doubt the Linux kernel can be shifted to v3 or later.
Hence we _really_ do need FreeBIOS or at least commercial
BIOSes without boot sigs.


-- Robert
Anonymous
a b à CPUs
March 10, 2005 11:54:27 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

On Thu, 10 Mar 2005 20:04:24 +0000, Robert Redelmeier wrote:

> In comp.sys.ibm.pc.hardware.chips David wrote:
>> On Wed, 09 Mar 2005 18:59:49 +0000, Robert Redelmeier wrote:
>>> In comp.sys.ibm.pc.hardware.chips David wrote:
>>>> You also have to include all required tools for building
>>>> your modified code and making it runable, as part of the
>>>> "source" of the gpl'ed code.
>>>
>>> Where does it say this in GPL v2 ?
>>
>> From section 3 of GPL v2:
>> "The source code for a work means the preferred form of the
>> work for making modifications to it. For an executable work,
>> complete source code means all the source code for all modules
>> it contains, plus any associated interface definition files,
>> plus the scripts used to control compilation and installation of
>> the executable. However, as a special exception, the source code
>> distributed need not include anything that is normally distributed
>> (in either source or binary form) with the major components
>> (compiler, kernel, and so on) of the operating system on which
>> the executable runs, unless that component itself accompanies
>> the executable."
>
>> I don't know whether DRM signing would count as "scripts used
>> to control compilation and installation of the executable",
>> but it could well do.
>
> I don't see any binary tools like compilers, checksum or signature
> generators listed in sec 3, second sentence.

I think that the first sentence "preferred form for .. making
modifications", and the third (special exception) probably covers it.
IANL etc. I.e., compilers would be included, because you need them in
order to make modifications, except they're excluded by sentence three,
because they're usually part of the target OS. I guess that if the target
OS is a BIOS which doesn't come with a compiler, then the OS
(program) distribution necessarily *does* include a compiler. Oh, look:
it does.

> "script" appears to
> mean some sort of makefile. "interface def files" would appear to be hw
> drivers. A sig.gen is neither of those, and even if it were
> distributed, it might not contain the secret key that the BIOS would
> need.

Then it wouldn't be a sufficient form for making modifications, would it?

> When you distribute GPG, you're not required to distribute keys.

No, but they're not necessary for making modifications to the GPG program.

> Oddly, the last sentence excludes binaries that the second sentence
> never included. What the second sentence could [and perhaps should]
> have said is "plus any tool necessary to modify and rebuild a binary
> runnable after modification." Then let the last sentence exception
> operate.

I reckon the first sentence covers this.

> Sony [neutral example] could distribute everything, but with a single
> signature, valid only for a kernel complied exactly per the makefile.
> Any mods would blow the sig.

Then that wouldn't be sufficient for making modifications.

> The problem with this hole is it's locked in GPLv2, and I doubt the
> Linux kernel can be shifted to v3 or later. Hence we _really_ do need
> FreeBIOS or at least commercial BIOSes without boot sigs.

The individual authors are free to release subsequent versions of their
software under whatever license they like. It would take consent from all
contributors, which would be a serious management problem, but unless
something in GPLv3 was very controversial, I doubt that you'd have much
more than that practical difficulty: if the authors used GPLv2 in the
first place, they'd probably be even happier to use GPLv3. Besides which,
doesn't GPLv2 contain words along the lines of "or any subsequent version
of this license"?

What I don't understand about the whole DRM'd BIOS issue is how they
expect it to achieve anything at all? Would it be impossible, or illegal
in some sense, to get an interpreter signed? If you've got a
signed perl or python executable, then you can still do whatever you like.
If you've got a signed JVM or Bochs/Dynamo/FX!32 then you can run
anything at all. If the answer is "yes" (no interpreters), then where
does that put the VBA part of MS-Word etc, or some random postscript
printer engine, or any other Turing-complete extension language?

Cheers,

--
Andrew
Anonymous
a b à CPUs
March 11, 2005 12:11:53 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In comp.sys.ibm.pc.hardware.chips Andrew Reilly <andrew-newspost@areilly.bpc-users.org> wrote:
> I think that the first sentence "preferred form for .. making
> modifications", and the third (special exception) probably
> covers it. IANL etc. I.e., compilers would be included,
> because you need them in order to make modifications,

But it just says "source in the preferred form for making mods".
That means ASCII text. It does not include tools.

> Then it wouldn't be a sufficient form for making
> modifications, would it?

It doesn't say anything about sufficient. It says "preferred
form" Interestingly, I once emailed RMS about some of my
pgms, which have no source, only executable (MS-DEBUG *.com).
He said that's allowed under the GPL.

> Besides which, doesn't GPLv2 contain words along the lines of
> "or any subsequent version of this license"?

Yes, but Linus dropped this phrase because it included
"at the option of the licencee".

> What I don't understand about the whole DRM'd BIOS issue is
> how they expect it to achieve anything at all? Would it be
> impossible, or illegal in some sense, to get an interpreter
> signed? If you've got a signed perl or python executable, then
> you can still do whatever you like. If you've got a signed
> JVM or Bochs/Dynamo/FX!32 then you can run anything at all.

I'd expect signed interpreters to not allow raw device access
if the media forbade it. So you can play a DVD with a signed
executable, but not copy it/portions to a file.

-- Robert
Anonymous
a b à CPUs
March 11, 2005 4:02:47 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In comp.arch David <david.nospam@westcontrol.removethis.com> wrote:
>
> I don't know whether DRM signing would count as "scripts used to control
> compilation and installation of the executable", but it could well do.
>

Why would one care? after all, as you'll get the source to the bios
that is in your machine you can modify to disable the check and then
publish both the source and binaries...

--
Sander

+++ Out of cheese error +++
Anonymous
a b à CPUs
March 11, 2005 12:07:05 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

David <david.nospam@westcontrol.removethis.com> writes:

> I don't know whether DRM signing would count as "scripts used to control
> compilation and installation of the executable", but it could well do.

I think it is fairly clear that whether or not DRM-controlled
exectution breaks with the wording of the GPL, it clearly breaks with
the *intent*, which is precisely to empower the user to make any
changes he desires to the software.

I've no idea how much that is worth in a court of law -- the system of
justice we are blessed with seems to be too arbitrary for a lay person
to predict with any degree of accuracy.

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Anonymous
a b à CPUs
March 11, 2005 2:10:47 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

> What I don't understand about the whole DRM'd BIOS issue is how they
> expect it to achieve anything at all? Would it be impossible, or illegal
> in some sense, to get an interpreter signed?

Unlikely illegal, but possibly impossible. It depends on whether the OS's
author - e.g., Microsoft - or the owners of certificates that have been
countersigned by the OS author are prepared to sign your code if that has
been written to circumvent a DRM mechanism supported by that OS. Whether
your code is an executable or interpreted is immaterial - after all, you
can view the processor as an interpreter of instructions.

Jan
Anonymous
a b à CPUs
March 11, 2005 4:07:23 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Robert Redelmeier wrote:
> But it just says "source in the preferred form for making mods".
> That means ASCII text. It does not include tools.

"However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable."

So you don't need to ship the compiler, since it is part of the OS on which
the executable runs. Or, use an entire different world, you don't need to
ship the synthesis and place&route tool for an FPGA, when you are shipping
free hardware, because that's what the FPGA vendor provides.

But if you need a secret key to make (working) modifications to the program,
you have to include it, or at least have an instance that does sign
whatever modified binary (or hash) you send them.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Anonymous
a b à CPUs
March 11, 2005 5:51:38 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Bernd Paysan wrote:
[...]
> But if you need a secret key to make (working) modifications to the program,
> you have to include it, or at least have an instance that does sign
> whatever modified binary (or hash) you send them.

According to the FSF, the GPL is not a contract.

Under copyright law one just can't restrict distribution of copies
(material objects) lawfully made. Electronic distribution implies
reproduction, but that right is also granted unilaterally to
everybody-and-his-dog by the GPL licensors. So all "copies" (17 USC
101) incorporating publicly available GPL'd works (and their
derivative works lawfully prepared and incorporated in "copies"
thanks the GPL unilateral grant, *not* restricted adaptation right
under 17 USC 117) are "lawfully made" and can be distributed as
their owners see fit notwithstanding purported "must be free"
restrictions stated in the GPL. That's because distribution of
copies lawfully made doesn't require permission of the copyright
proprietors. RedHat's lawyers simply erred in thinking that current
codification of "first sale" doctrine (17 USC 109) needs amendments
(formally codifying "digital first sale"... and as a byproduct, also
clearly stating legality of teleportation*** of books and etc. ;-) )
to break the GPL. The GPL is already totally broken.

< quotes from dmca/sec-104-report-vol-<2|3>.pdf >

Red Hat, Inc.:

Let me just clarify that I don't think anyone today intends to
impact our licensing practices. I haven't seen anything in the
comments, nor have I heard anything today that makes me think
someone does have that intention. What we're concerned about
are unintended consequences of any amendments to Section 109.
The primary difference between digital and nondigital products
with respect to Section 109 is that the former are frequently
licensed. ... product is also available for free downloaded
from the Internet without the printed documentation, without
the box, and without the installation service. Many open source
and free software products also embody the concept of copyleft.
... We are asking that amendments not be recommended that would
jeopardize the ability of open source and free software
licensor to require [blah blah]

Time Warner, Inc.:

We note that the initial downloading of a copy, from an
authorized source to a purchaser's computer, can result in
lawful ownership of a copy stored in a tangible medium.

Library Associations:

First, as conceded by Time Warner, digital transmissions can
result in the fixation of a tangible copy. By intentionally
engaging in digital transmissions with the awareness that a
tangible copy is made on the recipient's computer, copyright
owners are indeed transferring ownership of a copy of the work
to lawful recipients. Second, the position advanced by Time
Warner and the Copyright Industry Organizations is premised
on a formalistic reading of a particular codification of the
first sale doctrine. When technological change renders the
literal meaning of a statutory provision ambiguous, that
provision "must be construed in light of its basic purpose"
and "should not be so narrowly construed as to permit evasion
because of changing habits due to new inventions and
discoveries." Twentieth Century Music Corp. v. Aiken, 422 U.S.
151, 156-158 (1975). The basic purpose of the first sale
doctrine is to facilitate the continued flow of property
throughout society.

See also

http://www.oii.ox.ac.uk/resources/feedback/OIIFB_GPL3_2...

regards,
alexander.

***) http://www.research.ibm.com/quantuminfo/teleportation

--
"Other courts have reached the same conclusion: software is sold
and not licensed."
-- UNITED STATES DISTRICT COURT
CENTRAL DISTRICT OF CALIFORNIA
Anonymous
a b à CPUs
March 11, 2005 6:18:24 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Alexander Terekhov wrote:

>
> Bernd Paysan wrote:
> [...]
>> But if you need a secret key to make (working) modifications to the
>> program, you have to include it, or at least have an instance that does
>> sign whatever modified binary (or hash) you send them.
>
> According to the FSF, the GPL is not a contract.
>
> Under copyright law one just can't restrict distribution of copies
> (material objects) lawfully made. Electronic distribution implies
> reproduction, but that right is also granted unilaterally to
> everybody-and-his-dog by the GPL licensors

.... if the terms are accepted. The GPL is not really unilateral. I, as
author, give you an offer. If you accept that offer, you can exercise the
rights from that offer. If you don't, you can't. So if you do distribute a
signed Linux or whatever, that can only work *because it's signed*, it's a
derivative of Linux, and you either have to fully comply to the GPL (and
include the private key), or go straight to jail, do not pass go, and do
not collect $200. It's a simple copyright violation if you don't accept the
GPL, and violate the terms - i.e. it's not a lawful copy.

The question whether this is a contract or not depends on legal nitpicking.
In German law, a contract has an offer and an acceptance. The GPL is the
offer, the user has to accept it to exercise the rights. Therefore, in
German law, the GPL is a contract - and a German court ruled just last year
that the GPL is fully valid.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Anonymous
a b à CPUs
March 11, 2005 6:18:25 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Bernd Paysan wrote:
> Alexander Terekhov wrote:

[...]

> ... if the terms are accepted. The GPL is not really unilateral. I, as
> author, give you an offer. If you accept that offer, you can exercise the
> rights from that offer.

Terekhov is a well-known anti-GPL troll. He should be ignored; arguing
with him is a waste of time.

Paul
Anonymous
a b à CPUs
March 11, 2005 7:18:46 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Bernd Paysan wrote:
[...]
> if the terms are accepted.

The GPL is a bare copyright license, not a contract. It merely
misstates the law (go read both 17 USC 109 and 17 USC 117 to begin
with) and just can't legally compel you to relinquish rights that
you enjoy under copyright law (or any other rights; in contrast
to other contractual OSS licenses*** written by real IP lawyers,
not some obsessive and oppressive lunatic with the help of a law
historian fond of spreading anti-copyright-and-patent anarchistic
propaganda).

<quote source=http://tinyurl.com/3c2n2&gt;

Adobe characterizes each transaction throughout the entire stream
of commerce as a license.8 Adobe asserts that its license defines
the relationship between Adobe and any third-party such that a
breach of the license constitutes copyright infringement. This
assertion is not accurate because copyright law in fact provides
certain rights to owners of a particular copy. This grant of rights
is independent from any purported grant of rights from Adobe.

</quote>

s/Abobe/FSF

See also

http://www.nysd.uscourts.gov/courtweb/pdf/D02NYSC/01-07...
(Specht v. Netscape Communications Corp.)

Furthermore, FSF's expansive claims (just like SCO's -- see Tenth
IBM's defense) are barred by the doctrine of copyright misuse.

<quote source="Open Source Licensing: Virus or Virtue?">

Even if the open source license [GPL] is binding, the copyleft
provision may still not be enforceable as to independent
proprietary code, in light of the intellectual property misuse
doctrine. The doctrine is asserted as an affirmative defense to
an intellectual property infringement claim. Much like an unclean
hands defense, the misuse doctrine precludes enforcement of
intellectual property rights that have been extended beyond the
scope of those rights.

[...]

A successful misuse defense bars the misuser from prevailing
against anyone on an action for infringement of the misused
intellectual property, even against defendants who have not been
harmed or affected by the misuse.[76]

The misuse doctrine was judicially created, first in the patent
context. Only recently has the misuse doctrine been extended to
copyrights, building on the rich misuse history in the patent
law.[77] Importantly, most courts have found misuse without
requiring a finding of antitrust liability.[78] Thus, market
power is unnecessary, as is any analysis of the competitive and
anticompetitive impacts of the provision.[79]

The courts have yet to analyze a copyleft provision for misuse,
but the courts have addressed an analogous provision—the
grantback. A grantback provision requires that a licensee of
intellectual property grant back to the licensor a license or
ownership in creations made by the licensee. The typical
grantback provision requires that the licensee give the licensor
a nonexclusive license to any improvements or derivatives that
the licensee creates based on the original licensed property. The
idea is that the licensee would not have been able to make the
improvement or derivative without permission of the licensor or
at least access to the original; thus, the licensor should not
be blocked by an improvement or derivative he and his
intellectual property helped create. Giving the license back
encourages licensors to license, since it mitigates the risk of
becoming blocked by derivative intellectual property. Like a
grantback, copyleft requires the licensee to license back its
improvements. The copyleft provision is more expansive, though.

[...]

Although grantbacks have not come up in the copyright misuse
arena, they have in the patent context—and as we have seen, the
patent misuse cases form the underpinning for the copyright
misuse doctrine. Courts have found that grantback clauses
extending to improvements are not misuse, because the licensee
in some sense developed the improvement with the help of the
original patent. Where grantback clauses extend to preexisting
or unrelated patents, however, courts have found patent misuse.
Where "the scope of [licensee's] 'improvements' and inventions
required to be assigned to [the patent licensor] extended far
beyond the scope of [the] basic patent [licensed by licensor] the
effect was to extend unlawfully its monopoly and thus result in
patent misuse."[80] Plainly, the Patent Act does not give the
patent owner rights to other unrelated patents, and using a
patent to obtain such rights exceeds the scope of the patent.

Similarly, the Copyright Act's grant of rights does not extend
to unrelated works or preexisting (and therefore necessarily
nonderivative) works, and using the copyright license to extract
such rights exceeds the scope of the copyright grant. This may
constitute copyright misuse. A license to a copyrighted work on
condition that any work with which it is combined or shares data
must be licensed back to the licensor—and the entire world—on
the specific terms the licensor mandates, is beyond the scope of
the copyright in the originally licensed work. Yet this is what
the GPL apparently requires. The copyleft provision purports to
infect independent, separate works that are not derivative of the
open source code, and requires that such independent works be
licensed back to the licensor and the entire world under the GPL.
The Copyright Act does not give the copyright owner rights to
such independent nonderivative works. Attempting to extract such
rights exceeds the scope of the copyright. The fact that the GPL
mandates that the license be free and open is irrelevant; as
explained above, misuse doctrine does not require an analysis of
market share, or a weighing of the competitive and anticompetitive
effects of the provision.

If the copyleft provision constitutes misuse, then the plaintiff's
copyrights in the open source program are unenforceable until the
misuse is purged.[81] As a result, at least with respect to the
code contributed by any plaintiff, the defendant (and anyone else)
could infringe the copyright with impunity, including taking the
code private for his own commercial ends.[82] Thus, licensors
using copyleft licenses need to realize that they may be unable to
enforce the copyleft provision against separate works of the
licensee, and that any such attempt may at least temporarily
invalidate all their copyrights in the entire open source program.
Copyleft licenses are still valuable, however, where they do not
try to infect independent code. They should safely cover any
dependent derivative works based on the original GPL code.
Licensors simply need to understand the potential limitations and
risks of copyleft to employ it effectively.

</quote>

regards,
alexander.

***) e.g the CPL:

http://www.opensource.org/lice­nses/cpl.php

<quote>

No party to this Agreement will bring a legal action under this
Agreement more than one year after the cause of action arose.
Each party waives its rights to a jury trial in any resulting
litigation.

</quote>
Anonymous
a b à CPUs
March 11, 2005 7:42:48 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Bernd Paysan wrote:
[...]
> and a German court ruled just last year that the GPL is fully valid.

That's not true. It was about preliminary injunction (presumption,
etc) to begin with. Reread that "feedback" from Hoeren. BTW, go see
his profile:

http://arbiter.wipo.int/domains/panel/profiles/hoeren.p....

Note "Court of Appeal of Dusseldorf (Copyright Senate)".
^^^^^^^^^^^^^^^

regards,
alexander.
Anonymous
a b à CPUs
March 11, 2005 8:03:22 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

> Note "Court of Appeal of Dusseldorf (Copyright Senate)".
> ^^^^^^^^^^^^^^^

That's because all cases in intellectual property law in Germany are
initially heard at that level - I believe this is a translation of
"Landgericht", which for "normal" cases is indeed the court of appeal.

Jan
Anonymous
a b à CPUs
March 11, 2005 8:14:24 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Bernd Paysan wrote:
[...]
> It's a simple copyright violation if you don't accept the
> GPL, and violate the terms - i.e. it's not a lawful copy.

C'mon, as far as copyright is concerned, copies just can't become
unlawful just because they change owners under terms (or whatever)
you don't like. If I want to make a copy or two incorporating
protected elements from some publicly available GPL'd work(s), I
certainly have all the rights to copy and all those copies are
lawful.

http://gl.scofacts.org/gl-20031214210634851.html

Moglen: "Because the GPL does not require any promises in return
from licensees, it does not need contract enforcement in order to
work. A GPL licensor doesn't say in the event of trouble "But, judge,
the licensee promised me he wouldn't do what he's doing now." The
licensor plaintiff says 'Judge, the defendant is redistributing my
copyrighted work without permission.'"

And the defendant says "17 USC 109, Judge." Judge: Case closed.

Heck, what is so hard to understand here?

regards,
alexander.
Anonymous
a b à CPUs
March 11, 2005 8:42:49 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Jan Vorbrüggen wrote:
>
> > Note "Court of Appeal of Dusseldorf (Copyright Senate)".
> > ^^^^^^^^^^^^^^^
>
> That's because all cases in intellectual property law in Germany are
> initially heard at that level - I believe this is a translation of
> "Landgericht", which for "normal" cases is indeed the court of appeal.

Bzzt. Hoeren (Court of Appeal/*Ober*landesgericht, etc.) wrote

http://www.oii.ox.ac.uk/resources/feedback/OIIFB_GPL3_2...

as feedback on "final judgment" by Landgericht Muenchen I (district
court) in response to "appeal" (it is actual nothing but "you know,
we disagree" reply) to *the same court* (AFAIK Sitecom raised some
territorial issues and nothing having anything to do with the GPL,
BTW) in response to the initial "preliminary injunction"

http://www.google.de/groups?selm=40A1F61C.E8176A43%40we...

that the district court has made under presumption (not hearing
anything from the other side at all) that Welte is right.

regards,
alexander.

--
http://www.google.de/groups?selm=41055C8A.3D4940B7%40we...
Anonymous
a b à CPUs
March 11, 2005 9:04:45 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Alexander Terekhov wrote:

>
> Bernd Paysan wrote:
> [...]
>> if the terms are accepted.
>
> The GPL is a bare copyright license, not a contract. It merely
> misstates the law (go read both 17 USC 109 and 17 USC 117 to begin
> with) and just can't legally compel you to relinquish rights that
> you enjoy under copyright law

Sure it can't. But where is changing, modifying, and thus creating
derivatives of other people's code a right that's given to you under
copyright law? We don't talk about people reselling their CDs. We talk
about people who sign a Linux binary to be run under a DRM regime BIOS.
This is not a mere aggregate of the Linux binary and the signature, as both
form a functional unit. In other words: you can't change the Linux binary
without invalidating the signature, and the signature is necessary to run
the binary. Makes it part of the binary, and therefore the whole thing a
derivative.

If you tell me that I can legally modify Windows, and sell the derivatives
to whoever likes it, I'll do so from tomorrow. Microsoft won't be happy ;-)

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Anonymous
a b à CPUs
March 11, 2005 10:04:29 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Bernd Paysan wrote:
[...]
> Sure it can't. But where is changing, modifying, and thus creating
> derivatives of other people's code a right that's given to you under
> copyright law?

EU aside for a moment, "the owner of a copy of a computer program"
can create derivatives called "adaptations". 17 USC 117. BTW, it
gives legal basis to a work around the GPL by patching (apart from
17 USC 109 and unilateral grant of right to prepare derivative works
that has nothing to do with 17 USC 117 adaptations) with patches
distributed under "proprietary" licenses and patching done by
recipients. It works because patches are not derivative works under
copyright law as long as they don't contain any protected elements
from the originals. And references are not protected elements. As
for Windows, IIRC, they really try to obtain strong manifestation
of assent (you press "I accept" or something) to a contract. Well,
but I sorta like this (wink):

http://cr.yp.to/softwarelaw.html

"Software user's rights

In the United States, once you own a copy of a program, you can
back it up, compile it, run it, and even modify it as necessary,
without permission from the copyright holder. See 17 USC 117.

For example, after purchasing a copy of Microsoft Windows NT 4.0
Workstation---which is a poorly tuned version of NT 4.0 Server,
minus a few utilities---you can back it up, apply a small patch
that fixes the tuning, and run the result.

Microsoft hates this. Of course, Microsoft could restrict your
rights by demanding that you sign a contract before you get a
copy of Windows NT, but this would not do wonders for Windows
sales.

So Microsoft puts a ``license'' on all of its software and
pretends that you don't have the right to use the software
unless you agree to the ``license.'' You can't patch Windows
without their permission, according to the license; you can't
use NT Workstation for more than 10 simultaneous connections;
you must give Microsoft your first-born son. (Or something like
that.)

The problem with Microsoft's license is that it's unenforceable.
You can simply ignore it. Microsoft can't win a copyright
infringement lawsuit: you own the software that Microsoft sold
you, and Congress gave you the right to use it.

Ten years ago, the SPA convinced Louisiana to subvert the will
of Congress by passing a law that declared shrinkwrap licenses
enforceable. In Vault v. Quaid, 847 F.2d 255 (5th Cir. 1988),
this law was struck down. Federal copyright law preempts state
law.

The SPA didn't give up. It keeps arguing in court that, gee, if
all these software makers claim that you can't use the software
without a license, then they can't all be wrong, can they?
(Ignore the fact that they're willingly selling their software
to the public.)

The SPA lost again in Step-Saver but then won in ProCD. I
expect the Supreme Court to step in within the next few years
to resolve the dispute in favor of Vault and Step-Saver."

regards,
alexander.
Anonymous
a b à CPUs
March 11, 2005 11:15:05 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Bernd Paysan <bernd.paysan@gmx.de> writes:

>But if you need a secret key to make (working) modifications to the program,
>you have to include it, or at least have an instance that does sign
>whatever modified binary (or hash) you send them.

Ah, but the program works on any hardware which doesn't enforce
signatures. Is there a requirement that you can run the modified
program on the same hardware? Also, by shipping the signature
you allow people to recreate the binary.

You could also ship the signature as part of the signature
verification system and not as part of the binary.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Anonymous
a b à CPUs
March 12, 2005 1:31:30 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

In comp.sys.ibm.pc.hardware.chips Bernd Paysan <bernd.paysan@gmx.de> wrote:
> b) You must cause any work that you distribute or publish, that in
> whole or in part contains or is derived from the Program or any
> part thereof, to be licensed as a whole at no charge to all third
> ^^^^^^^^^^
> parties under the terms of this License."
>
> So if the signature is part of the *functionality* of the
> program, i.e. a program without that signature would not
> do the same thing, the signature is part of the program,
> and therefore the means to create it, the "source code"
> to generate the signature (that's the private key, and in
> case of a non-standard signature process, also the signature
> program) is part of the overall source code.

You could distribute a signature that is only valid for unchanged
source. The meets the definition of "licenced as a whole".

> If there's a loophole, than in sloppy interpretation of
> what the source code is. The source code *is* the stuff to
> create the program from. It doesn't need to be C code.

Quite true, but the GPL doesn't say this. And any ambiguities
in the GPL will be construed against the draftor [licensor]
because they had the means to eliminate the ambiguity.
Intent is only considered when words are absolutely unclear.

> have to give out your private key. As long as the signature
> has no effect on the functionality of the program, it is
> not part of the source code.

And perhaps as some one else commented, the signature
would have no effect on a system that didn't enforce
signatures. So the problem gets back to BIOS.

-- Robert
Anonymous
a b à CPUs
March 12, 2005 4:55:22 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.arch (More info?)

Alexander Terekhov wrote:

>
> Jan Vorbrüggen wrote:
>>
>> > Note "Court of Appeal of Dusseldorf (Copyright Senate)".
>> > ^^^^^^^^^^^^^^^
>>
>> That's because all cases in intellectual property law in Germany are
>> initially heard at that level - I believe this is a translation of
>> "Landgericht", which for "normal" cases is indeed the court of appeal.
>
> Bzzt. Hoeren (Court of Appeal/*Ober*landesgericht, etc.) wrote
>
> http://www.oii.ox.ac.uk/resources/feedback/OIIFB_GPL3_2...

It is no surprise that German and US court decisions are not compatible -
they occur under fundamentally different civil law systems (German civil
law is based on Code Napoleon, while the US civil law is based on the older
pre-revolution British law). As far as I know, the GPL has a number of
loopholes under US law, which it apparently hasn't under (continental*)
European law. I can't see how to close those loopholes under current US
law, but your example with patching Windows to Windows Server shows a way:
Microsoft, being furious about US law, buys itself a new copyright
amendment, which then helps the GPL ;-). The GPL, after all, hacks
copyright law to make its intention legally binding, and the stronger
copyright law is, the more legally binding is the GPL.

Some parts of the text above are pretty funny. E.g. that a German court
ignores the US law environment of the GPL. A German court is only bound to
German law, that's how it works (everywhere). It *has* to ignore US law. If
I go to a US court, I hope that they also are only bound to US law, and
will completely ignore Iran or Saudi-Arabic law. The quality of our
court-decisions is generally not very high, but neither is that of the US
system (e.g. spilled hot coffee ;-).

*) most continental European nations have a civil law based on Code
Napoleon.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
!