OpenChess

Clean room design
From Wikipedia, the free encyclopedia
For the manufacturing process setting, used for example in integrated circuit manufacture, see Clean room. For the meaning of Clean room engineering in software development, see Cleanroom Software Engineering.
Clean room design (also known as the Chinese wall technique) is the method of copying a design by reverse engineering and then recreating it without infringing any of the copyrights and trade secrets associated with the original design. Clean room design is useful as a defense against copyright and trade secret infringement because it relies on independent invention. However, because independent invention is not a defense against patents, clean room designs typically cannot be used to circumvent patent restrictions.
The term implies that the design team works in an environment that is 'clean', or demonstrably uncontaminated by any knowledge of the proprietary techniques used by the competitor.
Typically, a clean room design is done by having someone examine the system to be reimplemented and having this person write a specification. This specification is then reviewed by a lawyer to ensure that no copyrighted material is included. The specification is then implemented by a team with no connection to the original examiners.
Contents [hide]
1 Examples
2 Case law
3 See also
4 References
[edit]Examples

A famous example is that of Columbia Data Products who built the first clone of an IBM computer through a clean room implementation of its BIOS. Another is VTech's successful clones of the Apple II ROMs for the Laser 128, the only computer model, among dozens of Apple II compatibles, which survived litigation brought by Apple Computer. ReactOS is an open source operating system made from clean room reverse engineered components of Windows.
[edit]Case law

Sony Computer Entertainment, Inc. v. Connectix Corporation was a 1999 lawsuit which established an important precedent in regard to reverse engineering. Sony sought damages for copyright infringement over Connectix's Virtual Game Station emulator, alleging that its proprietary BIOS code had been copied into Connectix's product without permission. Sony won the initial judgment, but the ruling was overturned on appeal. Sony eventually purchased the rights to Virtual Game Station to prevent its further sale and development. This established a precedent addressing the legal implications of commercial reverse engineering efforts.
During production, Connectix unsuccessfully attempted a Chinese wall approach to reverse engineer the BIOS, so its engineers disassembled the object code directly. Connectix's successful appeal maintained that the direct disassembly and observation of proprietary code was necessary because there was no other way to determine its behavior. From the ruling:
Some works are closer to the core of intended copyright protection than others. Sony's BIOS lay at a distance from the core because it contains unprotected aspects that cannot be examined without copying. The court of appeal therefore accorded it a lower degree of protection than more traditional literary works.
[edit]See also

Chinese wall
Code morphing

accorded it a lower degree of protection than more traditional literary works

hyatt wrote:All well and good. But if you study A, and then write B, they will not be structured exactly the same, same data structures, same program structures, same procedures (not talking names here but again program structure, such as two searches or one search, two quiesce searches, or just one, multiple eval procedures or one big one, etc...)

All the hand-waving in the world won't make that issue go away for someone that has been grading student assignments for 40+ years, from the simple (a bubble sort) to the sublime (a complete FORTRAN/BASIC/Pascal/etc compiler in a compiler course). Programs in the same course are not very similar, and _never_ identical for big blocks of code...

Chris Whittington wrote:

hyatt wrote:All well and good. But if you study A, and then write B, they will not be structured exactly the same, same data structures, same program structures, same procedures (not talking names here but again program structure, such as two searches or one search, two quiesce searches, or just one, multiple eval procedures or one big one, etc...)

All the hand-waving in the world won't make that issue go away for someone that has been grading student assignments for 40+ years, from the simple (a bubble sort) to the sublime (a complete FORTRAN/BASIC/Pascal/etc compiler in a compiler course). Programs in the same course are not very similar, and _never_ identical for big blocks of code...

Just to disagree for a moment, you've never shown "identical for big blocks of code" for Rybka/Fruit and one would not expect that for a mailbox/bitboard comparison.

Perhaps agreement is possible over the following hypothetical .......

Program developer A gives expert B the Crafty executable. Expert B disassembles the exe and writes a specification from it. Developer A sits in a clean room, studies the specification for MoveSelection (null first, then hash, then killer, then history for example) and implements these publicly known chess program chunks as part of program A. Legal? Looks to be. Extend to whole program. Legal? I think so, all that A is doing is using known and available ideas, expressing them himself. A's defence, if attacked, is clean room and no cut and paste.

(null first, then hash, then killer, then history for example)

BB+ wrote:

(null first, then hash, then killer, then history for example)

Not your point, but: it would be rather a strange ordering to omit captures... Having a "rare" common component could well be on the precipice of the spec/code border. I think it boils down to what a "spec" is.

hyatt wrote:The problem is one of "program structure/organization". Some have one search function (Crafty of today, not a year ago). Some have two, SearchRoot() and Search(). Some extend this to SearchRootPV(), SearchRootNonPV(), SearchPV() and SearchNonPV(). Etc. If two programs do something the same way, with the same structure, there is more than just "ideas" being borrowed. Other examples. Some do their extensions inline in Search() (and the search cousins if there are more than one). Some do it in a function/procedure. Some have separate NextMove() functions (such as Crafty for NextMove, NextEvasion, NextRootMove, plus NextCapture which does not exist but has been manually inlined into Quiesce()) Some have one large evaluation function, some have a main eval + procedures for each piece type, relying on the compiler to inline these for speed while keeping them separate in the source for ease of change... Some do hash probes inline, some have a separate function. Some have their hash function pass an entry back to search which makes the pruning decisions, while others (like Crafty) do all of that inside HashProbe(). The more that matches, the more likely the program share ancestry.

Even if you studied a program and, in your words, write a specification, the implementation still won't be the same. There are too many ways to express an algorithm in a high-level language, just as there are many different ways to express the same idea in a written statement here. handwriting analysis depends heavily on "style" when you look at the internet, since there is no "handwriting" to examine. But every person has a different way of expressing their thoughts/ideas that is as unique as their fingerprint... Same goes for programming...

Chris Whittington wrote:It's all a big ego trip. Take Bob, who has to be the first to ever implement anything, or if he wasn't had to know intimately and exclusively the person who did. For such a high priest anyone else doing better, in less time, has to be, well, all those nasty things he said about Vas. As soon as it is admitted that the chess program chunks are simple and almost anyone can put them together, and mostly they get put together is similar ways, and that most of the "tuning" is tinkering around, we can begin to see that chess programs are LEGO like constructions and the participating programmers are just children playing, pretending to be. It's all an existential problem as per usual.