The half of the clean room effort that does the implementation are the one's making the clone, they don't see source code, disassemblies, etc. The other half doing the reverse engineering in order to develop the specification have to discover the *intent* of the original developers with respect to functionality. That discover is easier when you have their commented source code rather than a disassembly of a binary.

The dancing you refer to is for non-clean room scenarios where the developer implementing the compatible non-infringing clone has access to the original copyrighted code. And that dance occurs regardless of whether he/she is working from a binary disassembly or commented source code. Lawyers literally look at the code and say these ten or so lines in the new are too similar to these ten or so lines in the original. Disassembly or source has this same problem. Now source still has the advantage of better divining the original intent, so having the source is also a win in the non-clean room scenario.

No, it didn't. The fact that IBM provided source code to all PC programmers as a way of documenting the BIOS API actually made things simpler despite such a desire. If IBM was to act in a manner more consistent with that desire so as to hamper Compaq et al they would have simply provided PC programmers with registers for input/output parameters and the interrupts to use to invoke an API call. As was done with DOS.

A clean room design involves *two* teams. A dirty team that reverse engineers and writes a specification for a compatible device, and a clean team that does the actual implementation using only the provided specification. The "wall" is between these two teams, the implementation team has no contact other than the specification.

The dirty part of the team had a much easier time creating the specification given that they had commented source code. This source code, widely distributed by IBM to PC programmers, was the BIOS API documentation. This is a night and day difference with respect to reverse engineering and the fact that IBM didn't want a compatible BIOS to be produced does not change this.

As an example of IBM being open with their BIOS source code see their PC Hardware reference manual:

http://www.retroarchive.org/do...

Open listings like this were *the* documentation on how to use the BIOS API calls.

Wrong. Are you under the mistaken impression that "open" means the source code is also free to re-use and distribute? It does not, contrary to how the FSF would like to redefine "open". The fact remains that the IBM PC BIOS was open, PC developers had access to the source code. This source code was part of the documentation provided by IBM to PC programmers so that they could call the BIOS API. The comments in the source code were the API spec. We weren't using pirated copies, we were using official copies provided by IBM.

I don't think "clean room" was as you described. I believe one team had access to copyrighted materials including the commented source code. They created a specification that describes the required compatible behavior without any mention of any copyrighted. The "clean" part of the process is the next step. A separate team implements a compatible BIOS working *only* from this specification. The implementation team has no contact with the specification team other than this specification. I think the implementation team was also selected from people who had never programmed the PC before.

The fact that IBM was open with the source code and the specification team had access to commented source rather than disassembled binaries was a great advantage. Keep in mind that this source code listing was official IBM documentation on how to use the BIOS. IBM intended it to be viewed by PC programmers so that they could make use of BIOS API calls.

The corporate market influences the consumer. Many consumers want personal gear compatible with work.

"Open" does not mean without copyright. The fact is those working on a compatible BIOS had the IBM source code with comments to work from in order to define what a compatible system needed to do. That is a huge advantage compared to disassembling binaries. The fact remains that IBM published the source code to the embedded firmware, that is by definition open. The fact that it is copyrighted and may not be distributed without permission does not change this.

There are two parts to the clean room approach. One is the specification phase where one team defines the necessary behavior for a compatible system. This team may look at the copyrighted material. In the IBM PC case the fact that this team was looking at commented source code rather than disassembled binaries was a big advantage, it made their job far easier.

The second phase, which is performed by an entirely different team with no connection to the specification team (other than their output, the specification), is the implementation. Whether the specification they received came from disassembled binaries or source code makes no difference. Well, other than if the spec is source code based it is probably more compatible. So in the IBM PC case we may have had fewer incompatibilities in the spec which made implementation easier too, fewer bug hunts later on.

IBM published the source code to their BIOS. That is pretty open and greatly facilitated the creation of a compatible BIOS.

Compaq et al were able to create clones because the IBM PC was an open platform.

"Lowe presented a detailed business plan that proposed that the new computer have an open architecture, use non-proprietary components and software, and be sold through retail stores, all contrary to IBM tradition"
http://en.wikipedia.org/wiki/I...

Not necessarily. Like Google, IBM once created an open platform and Microsoft got into a serious fight with them. Microsoft won. And IBM was a 500lb gorilla in those days like Google is today, a very different IBM than today.

The PC vs Mac platform fight was separate from the fight within the PC platform over the operating system. Similarly the Android vs iOS platform fight may be separate for an operating system fight within Android.

If Microsoft can do something to better integrate Cyanogen based devices into the corporate workflow they might have some leverage. Plus an operating system that gets bug fixes and security updates might warrant some attention.

The fact that an exchange offers both online wallets and merchant services means nothing. Two different services, as your own quote points out they provide services to *both* merchants and consumers. What a consumer does on an exchange is irrelevant to a merchant.

The fact remains that a merchant does not need a bitcoin wallet, does not need to see or touch a bitcoin, does not need to take on any bitcoin price fluctuation risk, and gets paid out daily in fiat. Which has been my point and stands independently of your tangents.

My use of "professional" was in the context of being the provider chosen by Google, Dell, Paypal, etc.

Perhaps you should look at the link I provide and note its a professional operation being used by various large corporations.

https://www.coinbase.com/merch...

You seem to misunderstand the merchant services I am referring to. A merchant does not need an online wallet. The merchant never sees or touches a bitcoin, the payment address is the exchange's, the exchange pays out the merchant daily in fiat.

You are confusing people trading and using online wallets at exchanges with merchant services at an exchange. They are two very different things.

To get familiar with the sort of thing I am discussing see https://www.coinbase.com/clien...