OpenBIOS news.

[Eivind Eklund]

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? I am
> >    not really into that licencing stuff. Would it be better to use some
> >    kind of BSD licence or even the Netscape NPL? I want to make sure that
> >    this project will remain free forever and people can use it for free,
> >    no matter whether it is commercial use or not. And, of course, I think
> >    it would be best, if changes made by foreign contributors are included into
> >    the official project. 
> 
> I thought a bit about that too. I think it should be GPL, no sane
> person should consider the chip set registers or motherboard
> interconnect trade secrets. And why use another license if you have no
> secrets?

As the person (or one of the persons) who originally posted that wish,
I'll try to explain my position and reasons.

First note that for this project, 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).  It does _not_ work
similarly to the BSD license, which allow anybody to binary
distribution without source and with restrictions on re-distribution.
You may want to modify the NPL to be broader than it normally is,
infecting things similarly to the GPL; this can of course also be done
by re-licensing.

Now, the reasons (sorry for the length - if you're evaluating this,
please take the time to read all of it).  I'll use my own employer to
give the examples, as that is the most realistic set of examples I can
give.  Be aware that we may not be able to use OpenBIOS no matter
what, as it is (at least presently) closed to the non-Linux world, due
to a lot of Linux-isms :-(

I am a FreeBSD developer; I also work for a company that has an
embedded FreeBSD system as one of its products.  When creating this
product, I found that there are a lot of changes that I do that are
basically 'tweaks' - changing the system to be better at what we use
it for, while making it unsuitable for general use (e.g. globally
changing constants to make the drivers we run work more efficiently,
while breaking a lot of drivers we don't use).  The tweaks are usually
things that are pretty simple to do, but require quite a bit of work
or very detailed knowledge of the source to know where/how to do.
There are also many changes we do that are generally beneficial; so
far, we've never kept any of these changes properitary.  I know of
only one such change that has not been put back in the original
sourcebase things came from; this was due to the developer of said
sourcebase declaring it dead, and saying that he would never ever
release a new version (preferring instead to rewrite the code; we've
contributed to the new version).

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.  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.  With a GPLed sourcebase, we might utilize it, but
we probably wouldn't spend much time on it, and we'd be pretty likely
to switch to another sourcebase at some point.

One example of re-licensing that might be interesting to both a
company like mine and the OpenBIOS developers is an arrangement where
an OpenBIOS developer get free access to our sourcecode, and is
allowed to take any change (with the exception that any cryptographic
keys must be cleared) and merge it into the main sourcebase - but is
not allowed to release our changes _without_ merging them into the
main tree.

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.
* Change timing to fit the minimum for parts we actually have, instead
  of for the specs
* Remove probes, replacing them with fixed setups
* 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 :-)

However, how this would benefit companies like mine (and thus increase
the chance of participation with the srouce base) isn't the main clue
- the main clue is that the NPL allow the original developers to make
the decisions necessary if it turn out that other licensing terms
might be more beneficial.  With the GPL, you have to contact _every
single contributor_ if you ever want to make an arrangement.  It
doesn't matter if the arrangement is what gives maximum advantage to
the open source community - every contributor have to be contacted and
say 'OK'.  This very quickly becomes unfeasible.

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.

Eivind.