On Sat, Nov 21, 1998 at 12:04:16AM +0100, daniel.engstrom@riksnett.no wrote:
On 20 Nov, Stefan Reinauer wrote:
- 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.