Stallman rants about FreeBIOS

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
60 answers Last reply
More about stallman rants freebios
  1. 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
  2. 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
  3. 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
  4. 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
  5. 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.
  6. 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
  7. 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
  8. 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
  9. 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.
  10. 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
  11. 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.
  12. 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/
  13. 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
  14. 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/
  15. 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/>

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

    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)
  16. 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_specification.htm

    <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
  17. 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.
  18. 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.
  19. 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_specification.htm
    >
    > <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
  20. 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.
  21. 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
  22. 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).
  23. 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
  24. 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/
  25. 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/
  26. 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/
  27. 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_specification.htm
    > >
    > > <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.
  28. 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
  29. 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.
  30. 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
  31. 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
  32. 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
  33. 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 +++
  34. 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
  35. 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
  36. 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/
  37. 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_20040903.pdf

    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
  38. 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/
  39. 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
  40. 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>

    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-07482.PDF
    (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>
  41. 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.pdf.

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

    regards,
    alexander.
  42. 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
  43. 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.
  44. 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_20040903.pdf

    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%40web.de

    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%40web.de
  45. 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/
  46. 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.
  47. 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.
  48. 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
  49. 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_20040903.pdf

    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/
Ask a new question

Read More

CPUs Hardware