Without the Clean Room

[Chris Whittington]

Clean Room Design from wiki

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

A feature of open source publishing, whether Crafty, Fruit, whatever, it that it deprives a competing developer of "clean room" protection. Obviously any developer will have read or be able to read the sources in detail. It is legally arguable therefore that open source would be

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

How might this be legally interpreted? The developer of R could argue, and I think he does argue on occasion: having studied and taken ideas from F, and other open sources, some of those ideas were implemented and because of the unclearable and unrebootable nature of the brain, it is perfectly possible and quite likely that segments or bits of F or algorithms of F or sequences of F found their way into R despite our best efforts and intentions otherwise. What else could the publisher of F expect? By publishing his sources, he has weakened his copyright.

[hyatt]

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]

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.

[Chris Whittington]

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.

continuing ...

Since the Crafty source exists in the public domain, Developer A cannot realistically claim not to have read it, indeed, he is encouraged to read it to maintain capitalistic competitiveness, so clean room can't be used or even apply. With published source, it is now open to developer A to short-circuit the clean-room process, study the source, write his own spec and then write his own program. He can then defend, if attacked on a similarity comparison, by asserting no cut and paste, a specific attempt to get away from simple copying by going bitboard, asserting all his own work, and explaining away similarities on the basis that his brain will have absorbed material despite his best attempts otherwise.

It all comes down to the grey area of "how similar", indeed given that the closed room approach can lead to "similarities" in any case, one would expect a few more similarities over and above those, due to lack of closed room. Basically, in this scenario, the increase in similarities is the "fault" of the publisher of the open source and that will be reflected in any legal process by tipping the balance towards developer A, and away from the open source publisher.

The question remains for open source publishers .... this is a capitalistic and competitive world, what else would you expect?

[hyatt]

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...

[BB+]

(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.

[Hood]

Is that problem possible to solve at all ?

[Chris Whittington]

(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.

Well, it has been 14 years now

The spec of a spec in this case is that the spec goes past a lawyer who deems whether or not it has any copyright material in it. If not, it's clear to go, and the product resulting from the spec is clean.

So, back to move ordering:

if the spec is as above: null first, then hash, then killer, then history. Will a lawyer clear that, or say the ordering and/or inclusion/exclusion is copyrightable? Remember we're dealing here with well known chess program chunks.


Going off on one of my hobbyhorses ...... I think this whole discussion is predicated on the idea that chess programs and chess programmers are highly complex works of art and great genius, we should hang on their every word and all their code is unique and brilliant, even to the great beauty of the ordering of null first, then hash, then killer, then history. When, in actualty, chess programmers are just putting together known stuff, in very similar ways and there is very little new under the sun.

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.

[Chris Whittington]

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...

It is quite simple. If the specification does not contain copyright material, then the product written from the specification won't contain copyright material either.

In the case of open source, the "second" developer can also justifiably claim that elements of his product are reasonably "contaminated" with elements of the original because the first developer is responsible for the contaminating memes by publishing them.

It's therefore a question of degree, how much contamination, for the original developer has weakened his copyright protection.

[orgfert]

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.

This seems to undermine your other hobbyhorse, that of giving creators (i.e. ego-tripping children playing with blocks, pretending, faking, etc.) more rights in a forum than everyone else.