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