OpenBIOS news.

[Eivind Eklund]

On Sat, Nov 21, 1998 at 03:44:30PM +0100, daniel.engstrom at riksnett.no wrote:
> On 21 Nov, Eivind Eklund wrote:
> > On Sat, Nov 21, 1998 at 12:04:16AM +0100, daniel.engstrom at riksnett.no wrote:
> >> On 20 Nov, Stefan Reinauer wrote:
> >> > 1) Licence
> >> >    Is anything speaking against using GPL as licence for OpenBIOS? 
> 
> > As the person (or one of the persons) who originally posted that wish,
> > I'll try to explain my position and reasons.
> 
> First we should note that changing it from GPL is not an option, these
> is already some Linux code in there and I expect that there will be
> more. Look in the source (boot/init32 in the released version,
> firmware/init in my current tree).

As far as I could tell, that was pretty small amounts of code.  There
are other sources for OS/hardware code (*BSD, for instance), so fixing
this would probably not be too much work.

> > I argue in favour of the NPL (which
> > as far as I can tell work almost like the GPL, with the large
> > exception that it allow the original developer to re-license under
> > another license if this fit his/her goals). 
> 
> The GPL does not prevent the copyright holder of the code to relicense
> it under a different license.

Copyrights don't go on a file-by-file basis; closer to line-by-line.
If somebody has contributed more than 10 continious lines, you'd have
to get their permission.  In effect, the GPL of a project done
bazaar-style takes _all rights except utilisation rights_ away from
the authors.  I know cases where this has bitten people that release
open source stuff in the same area as they do their regular commerical
programming; they've accepted external changes, and have had to
re-write their stuff when they needed to use it in a commercial
setting to avoid extra work.

> > As for my company, we're just running on
> > standard BIOSes at the moment, as we've not had enough pain to warrant
> > the cost of a BIOS source code license.  However, if we were to use a
> > custom BIOS, we'd have a hard time choosing whether to pay for a
> > license or use a GPLed sourcebase.  This is because a very large cost
> > is the time spent learning the sourcebase, and doing small,
> > non-general modifications to it.  This is a part of what gives us
> > competetive edge.
>   
> I personally don't want any person or company to use my work to get a
> 'competative edge' if they keep their changes propetary. They can
> always find another source-base to abuse.

Note that I'm not arguing that you should do BSD/X-licensing - I argue
that you should keep the option of doing re-licensing, to be able to
evaluate this at a later point (when you actually have the possibility
of more fully evaluating it, because you have the data on what happens
then, but do not have the data now).

Also; you're misinterpreting my example.  They're not using your work.
They may be using _part of_ _their_ work.  This seems to be a common
misunderstanding (or language manipulation?) among the advocates of
the GPL.

> > Examples of changes that could be relevant for our use (but not
> > generally relevant):
> > 
> > * Reading boot code out of a properitary file system layout.  Done to
> >   avoid people pirating parts of our system for use in competing
> >   system.
> See above about source abuse.

I don't get what you try to refer to.  To use my own company as an
example again, tt works like this: We create thingy.  We sell thingy
to customers, sharing cost of creating thingy among customers.  We
don't allow our distributors to re-produce what we've created and sell
it; if we did, we would have to charge the first customer for all the
cost of producing the thingy.  This would not be fair to the first
customer; the charge should be much closer to the marginal cost.

We contribute back the changes that have general use (I put all
changes I _can_ put back into the FreeBSD source base).  Due to the
fact that we have a FreeBSD-based product (which we would not have if
we couldn't keep changes properitary, since we'd deem it too high
risk), I can contribute quite a few changes back to FreeBSD.  More
than I would have been able to if we couldn't keep things properitary.
If you still consider what we do 'abuse', then I'm sorry - I won't be
able to please you.  I'll just say that I very sincerely want open
source to succed and be as good as it can be - and contribute what I
can towards this (the only way I could do more is by either dropping
having a life, or by pretending I'm unable to get a job, go on social
security, and work on open source).

> > * Change timing to fit the minimum for parts we actually have, instead
> >   of for the specs
> Why keep it a secret? It might be useful for somebody else

To make it harder for somebody to directly dupe your product.  Each of
the changes by themselves is not really significant; the problem is
when you have to disclose _everything_.  If you can only do this at
the utilitarian level, you have much less 

> > * Remove probes, replacing them with fixed setups
> Typically, there are no probes in a BIOS. Settings are either hard-coded
> or read form the NVRAM.

Typically, modern BIOSen probe for disks, RAM, keyboard, and display
card, at least.

> > * Add cryptographic code and keys to de-crypt further code, to deny
> >   the possibility of cracker activity (given that firmware overwrites
> >   would be _very_ hard compared to most other cracks).  The code might
> >   be of general interest; the keys certainly shouldn't be generally
> >   available (even with public key cryptography attacks are much less
> >   feasible against keys you don't have :-)
> 
> Security is ok, but if you feel that you need to keep the source a
> secret for it to work, you have implemented security through obscurity.

'Security through obscurity' can be a significant layer in a security
scheme; it should not be everything, but it can strengthen the scheme.
For a large number of cases it is not possible to do anything beyond
'security through obscurity', laws, and quantum mechanics.

Besides this, the 'source code' when you're including parts of an RSA
public key pair could be deemed to be the initial primes.  Being able
to not include this (and have no legal risk of having to include it)
is _very_ important to security.  (I don't believe there is a large
risk of that interpretation, but given my lack of experience with US
law and the way it is interpreted, I'd for that case have to get a US
lawyer to check.  That can quickly get expensive.)

Eivind.