OpenBIOS news.

daniel.engstrom at riksnett.no daniel.engstrom at riksnett.no
Sat Nov 21 15:44:30 CET 1998


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).

> 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.
 
> Does this relate to OpenBIOS?  Quite a bit.  Embedded systems
> developers are probably the people that work most on BIOSes as the
> field presently is; most embedded systems developers commercially
> license BIOS source code.  

I do embedded systems my self, tech. support, though.

> 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.

> 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.

> * 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

> * 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.

> * 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.

> Of course, 'other licensing terms' also include the ability to later
> change your minds and go with a pure GPL.  Just re-license the
> sourcebase.
As I already have used 3rd party GPL code in this, this discussion is
purely theoretical.

/Daniel
-- 



More information about the openbios mailing list