On Sun, 8 Aug 1999 20:02:20 -0400, David J. Coffin wrote:
On Sun, Aug 08, 1999 at 05:35:25PM -0230, James Oakley wrote:
"Timothy J. Massey" wrote:
Even if your BIOS bears no resemblance to the one you disassembled, because you *did* disassemble it, the makers of the BIOS you disassembled can say to you, "But you saw our code and did it yourself. That's illegal." And they'd be right.
Reverse engineering is very legal in Sweden, although itmay soon be illegal in the USA. There wouldn't *be* any BIOS industry today if Phoenix hadn't reverse-engineered IBM's code.
So Phoenix, which now owns Award, is going to prosecutesome college student in Sweden for doing exactly what they did. Not likely.
No, they would prosecute some college student in Sweden for breaking the law. Phoenix was **VERY** careful in how they reverse-engineered IBM's BIOS. There were two teams. Team one disassembled the IBM code and wrote a detailed english-language description of what IBM did: This function when called this way does this. No code was contained in this description.
Team two had **NEVER** (not once, not ever) in any way disassembled any BIOS code ever, had never seen IBM's code ever, etc. They took that english-language description and wrote their own code. Even if there were parts of the code that were exactly identical, it wouldn't have mattered, because they came up with them on their own. That's why it's called "clean room" development. The guys that have never seen the code they're trying to copy are in a clean room: free from suspicion.
*That* is perfectly legal. But once having seen copyrighted code, you **cannot** write code that does the same thing without opening the possiblity of lawsuit. I'm not saying that they'd win, but there is the possibility of a lawsuit. And if **any** similarity was found (even if it were coincidental), you would lose.
This is very true. A couple of years back, some guys who worked for Matrox quit and started their own video chipset company. Matrox successfully blocked their entry into the market because they saw proprietary Matrox engineering information.
Not the same thing. Those engineers had to sign stacks ofnon-disclosure and non-competition agreements before they could see Matrox's designs. They clearly violated those contracts.
Even if they hadn't, they would still have been in the wrong. If I'm an engine designer for Ford and leave to start my own engine-designing company, Ford would have every right to go over my designs with a fine-tooth comb. And if something even coincidentally looked the same, I would be in big trouble.
That doesn't mean that I couldn't leave Ford and start my company. Look at Lee Iacocca (sp?), or John DeLorean. But it opens the *possibility* of attacks.
Niklaus would be taking a bigger risk if he signed Intel'sNDA. Right now, he has no legal obligation to protect anyone's secrets.
And once Niklaus signed Intel's NDA, he would be UNABLE to contribute to OpenBIOS. Ever.
If a disgruntled chemist at Coca-Cola gave you their secretformula, he would be in deep trouble. But no one could stop you from selling cola drink (you couldn't *call* it "Coca-Cola", of course), or posting the formula on the web.
Yes they could. If I were given the text of a book from a disgruntled publishing employee, and I put it on my website, could I be prosecuted? Not until I was told of the copyright violation. But once I was told, that's it. I am open to prosecution.
And, if I were found publishing a manuscript that was given to me, and it was found that the manuscript was not owned by the person who gave it to me (just as if I were given the secret Coke formula by an unauthorized person), I would be in big trouble. Ignorance of the law is no excuse: it's still illegal.
So, all of the actions that you describe are quite illegal. Duplication of copyrighted material is a crime. Period. And once you've seen copyrighted material, copying that material (even if it's by rewriting it yourself from your understanding of that material) in any way opens you up to possible prosecution as well.
Tim Massey
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
I guess I am partly responsible for creating the vast amount of exchanges concerning the "clean room" approach to building a GNUBIOS or OpenBIOS and I have read with great interest the comments over the last several days.
First, I disagree that there are no coders available for the project. It is quite possible that I would qualify. I am a EE by training who started out as a main frame programmer. I have done tens of thousands of lines of main frame assembly language operating system coding but not one line of 80x86 coding. The only PC assembly language code I have ever seen was CPM for the 8080. I am now a government employee working as a EE developing PC hardware for space applications. I have signed no NDA's with any company. The reason I became interested in this group was for a personal hardware project I wanted to do about a year ago for which I needed a custom BIOS. The effort required for me to build a custom BIOS was greater than I wanted and I thought by contributing some effort to the group, I could get a open source which I could customize. I also realized the need to the PC community for an open source BIOS.
Second, I do agree with the statements by several of the need for strict controls over the groups and the keeping of notebooks. I don't know if Award, Phoenix, etc. would want to challenge any product of this group legally. I don't think we are likely to affect their bottom line by more than a few pennies since only a few nut cases (like me) are likely to modify OpenBIOS for their own use. And with a GNU type public license, no one else would be able to use a derivative work to compete commercially with Award, etc.
Which brings up the question, how does GNU enforce their public license? So far, they seem to be very effective. Could we not come under their umbrella? Someone must be providing the open source community with legal protection.
As to the comment that the identities of the clean room team should be known to only a few individuals. Let me say that the identities of the clean room team should be known to only ONE person other than the team. That one person's function would be to convey the results to the "dirty room" team with no additional comments. His/her job would be strictly limited to forwarding the results.
Finally, I have been on this list for about a year. I have seen discussions flare up from time to time after a month or so of dormancy. I have tried to support what I thought were suggestions from members who have ideas which would lead to an OpenBIOS. I will continue to support anyone who wants make progress toward that goal. But I do know that there is a standard way of buiding a software system: requirements => preliminary design => detailed design => unit coding => unit testing => system testing. The first step is always the requirements and if we can't, as a group, determine a set of requirements then this group will slowly twist in the wind until long after the 512 bit PC's have passed into oblivion.
For my part, I will contribute in whatever area I am able. But please, can we build a set of requirements. And please, can we find out if the is any legal assistance available to us so see that this effort will be fruitful. - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
As to the comment that the identities of the clean room team should be known to only a few individuals. Let me say that the identities of the clean room team should be known to only ONE person other than the team. That one person's function would be to convey the results to the "dirty room" team with no additional comments. His/her job would be strictly limited to forwarding the results.
There is an obvious flaw in the notion of ONE person being the only one to know the identities of the clean room people. Any node without backup is subject to catastrophic failure. Care and caution need to be exercised in managing the blind structure of the linkage between clean and dirty teams, and unless clean tem members are to be given the identity of one or more dirty team members (thus tainting the isolation model) the entire project could be jeopardized by the accidental incapacitation of one person.
William Meyer
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
Ed Brinker wrote:
Finally, I have been on this list for about a year. I have seen discussions flare up from time to time after a month or so of dormancy. ... But I do know that there is a standard way of buiding a software system: requirements => preliminary design => detailed design => unit coding => unit testing => system testing. The first step is always the requirements and if we can't, as a group, determine a set of requirements then this group will slowly twist in the wind until long after the 512 bit PC's have passed into oblivion. ... But please, can we build a set of requirements. ...
This is my attempt to figure out how OpenBIOS development should be run
Stage 0: divide BIOS into several tasks:
1 initialization of chipset - mandatory 2 booting OS from FDD - mandatory for the initial phase 3 configuration 4 BIOS services 5 floppy based diagnostics, embedded in ROM diagnostics 6 booting OS from HDD 7 booting OS from CD-ROM, Network 8 serial console 9 network console - this is my proposal for avoiding inefficient serial communications 10 USB keyboard support 11 Open-SCSI-BIOS 12 Open-VGA-BIOS 13 Open-Net-BIOS 11 power saving and sleeping 12 get used to another name for BIOS - it's not I/O system anymore and this name is confusing
To my mind the only OS that should have the possibility to boot for the first time must be Linux. This will give the project initial user base and attract possible developers. This OS like other can live mostly without BIOS. Boot loader maybe customized for this OS to be more strait forward then current implementations
Stage 1: develop set of routines for BIOS developers and testers - requirements (general hardware - chipset, processor, M/B make etc. and maybe specific hardware, which can be implemented easily) - software tools
Stage 2: ...
I've just found OpenBIOS project about 2 weeks ago and took it close though I can see some indications of no real achievements so far. Anyway in near time I'm going to study downloadable software and summarize my suggestions on web. Sorry, if this reading was just waste of time for you but this is the best of my efforts this moment. I'm really wish contribute to this project with my skills and available hardware though I may not be seen as person who can be in the clean room. I've seen a lot of BIOS source for XT/AT and it doesn't make sense for me to re-implement it. Hope you don't find this reading useless, yours Mark Zhitomirski - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
Mark Zhitomirski wrote:
Your message is good, though I have some comments.
This is my attempt to figure out how OpenBIOS development should be run
Stage 0: divide BIOS into several tasks:
1 initialization of chipset - mandatory 2 booting OS from FDD - mandatory for the initial phase
I think I'm not the only one who wants to eliminate dumb limitations in current BIOS software. Unfortunately, all x86 operating systems is written to handle these limitations, which often fail miserably (motherboard less than a year old, my 10GB HD reported as 540MB, had to use Linux fdisk to actually use the damn thing).
I sent a message a little while ago about how we should work with the Linux kernel people to define a new booting specification. Ask them what they want. We can implement that first and set up compatibility modes (DOS, etc) later, when our heads are more fully wrapped around this thing. I'm just waiting for some sort of confirmation or denial on this.
James Oakley - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
Your message is good, though I have some comments.
This is my attempt to figure out how OpenBIOS development should be run
Stage 0: divide BIOS into several tasks:
1 initialization of chipset - mandatory 2 booting OS from FDD - mandatory for the initial phase
[Cut....]
I sent a message a little while ago about how we should work with the Linux kernel people to define a new booting specification. Ask them what they want. We can implement that first and set up compatibility modes (DOS, etc) later, when our heads are more fully wrapped around this thing. I'm just waiting for some sort of confirmation or denial on this.
The linux kernel guys are sometimes a fussy bunch; such a spec already exists, take a look at MultiBoot standard at http://www.uruk.org/~erich/grub/boot-proposal.html, but I don't believe they've adopted it yet.
Joseph
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
"Joseph D. Foley" wrote:
The linux kernel guys are sometimes a fussy bunch; such a spec already exists, take a look at MultiBoot standard at http://www.uruk.org/~erich/grub/boot-proposal.html, but I don't believe they've adopted it yet.
Didn't know it existed. It's interesting reading, but too narrow.
What we want to know is what BIOS calls the kernel uses and then hash out new ways of achieving what is needed. APM is one example, there's also memory reporting, hard disk parameter passing (LILO isn't infallible on large drives), USB, PCI, etc.
It won't be an easy task, unfortunately. I think we can come up with something though.
James Oakley - To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message
-
Ed Brinker -
James Oakley -
Joseph D. Foley -
Mark Zhitomirski -
Timothy J. Massey -
William Meyer