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?
- Supported hardware Many people told me that they would like to see support for recent PCI hardware only. I think this makes sense, because it's easy to autoprobe chipset type and SuperIO type on the PCI bus. This allows us to have one generic firmware image that can be flashed to a couple of different machines that have different motherboards. This is especially nice for people with large computer pools (like admins of universitiy pools)
I'd say it is hard to probe the PCI bus before you're up and running (DRAM working at least) and to come up and run you need to know which chip set you're on... Besides in addition to what chip set and which super I/O chip that is attached you might need to know hove some things are wired on the mother board.
- There have been many new wishes on the wishlist today, please check them out at http://www.freiburg.linux.de/OpenBIOS/wishlist/ and *DO* comment on them.
I have my own agenda quite clear... First get the thing runnig on one or two chip sets, do FD and IDE read-only drivers, implement something like syslinux that can boot a hacked Linux kernel in PM from disk. After that we can start to take requests... :)
- I thought about writing email to some chipset manufacturers to ask whether they want to participate in our project by writing free code for their hardware. Does anyone have an idea what to write?
Opti, SiS and Intel at least have docs available on the web, Ali doesn't even have an email address to mail to on their web site... (Anyone who knows an Ali sales rep?)
/Daniel --
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.
On 21 Nov, Eivind Eklund wrote:
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?
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 --
On Sat, Nov 21, 1998 at 03:44:30PM +0100, daniel.engstrom@riksnett.no wrote:
On 21 Nov, Eivind Eklund wrote:
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?
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.
- Licence
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?
The way I look at it is: if we want the actual source code to be used in lots of commercial projects, then it should be BSD based so that no one's legal department makes trouble.
But if we are more concerned with providing "living documentation" for the various chipsets -- actual, working examples of how to use all this hardware -- then the GPL is probably better because it forces everyone who touches the code base to give out at least the firmware source to anyone who buys their product.
I have my own agenda quite clear... First get the thing runnig on one or two chip sets, do FD and IDE read-only drivers, implement something like syslinux that can boot a hacked Linux kernel in PM from disk. After that we can start to take requests... :)
Yes, that sounds like the most important stuff. Once you can rough out a protected mode startup environment, we can start talking to all the various kernel groups (Linux, *BSD, Be, maybe even the commercial guys) and try to hammer out a boot environment that the various kernels can all live with. I don't expect this to be hard; most kernels should need the same basic stuff -- "start me up with an identity memory map and a few megs at zero..." -- we might have to devise some data structures that communicate from the BIOS to the kernel, and tell them what to expect.
Todd Whitesel toddpw @ best.com
-
daniel.engstrom＠riksnett.no -
Eivind Eklund -
Todd Whitesel