Comment by BaseballPhysics | Hacker News Reader

Comment by BaseballPhysics | Hacker News Reader

Parent Full thread

BaseballPhysics

A bit of an aside:

> "Clean-room design" was an underhanded way to legally reverse engineer and clone a competitor's product. It works like this: engineer A produces a specification after studying the competing product, a lawyer signs off on the spec not including copyrighted material, and engineer B re-implements the product from the spec A created. A and B have the same employer, but since they're not the same person there's technically no copyright infringement. This technique was used during the fiercely-competitive market rush of early personal computing.

What a weird way to position this.

There's nothing "underhanded" about it. There is literally no copyright infringement in this case. It's pure reverse engineering as is done in many other industries and fields.

And the outcome is increased interoperability and improved competition by eliminating artificial barriers of entry in the market. Without it, the computing world would be a very different place, and I doubt anyone would like it.

In fact, the market was far from "fiercely competitive" prior to the IBM BIOS being reverse engineered. Before that work was done, IBM basically had a lock on the PC market. It wasn't until the clone rush of the 80s that prices came down and computing became accessible to everyone. Hell, IBM valued that near-monopoly so much they introduced the MCA bus in the hopes of locking the PC back down. Fortunately their competitors succeeded in establishing open alternatives, including PCI and so forth, and the rest is history.

I wonder how this author feels about the Google v Oracle lawsuit regarding Google's reimplementation of a bunch of core Java APIs...

EISA was the rest of the industry's middle finger response to IBM's MCA:

https://en.wikipedia.org/wiki/Extended_Industry_Standard_Arc...

As a former field engineer I was glad to see the back of MCA.

Ah! Thank you! I knew PCI was a later standard, but I'll be damned if I could remember the one that preceded it...

I seem to remember Windows 95 and the quest for "plug 'n play" being what pushed the PCI standard into wide spread use. Basically the first standard that didn't require all the tedious mucking about with IRQ's, DMA and I/O Ports.

IIRC it was considered fashionable back in the day to install a card, wait for it not to work and then make a joke about "plug 'n pray" before finding an older, ISA card and getting it to work by setting the jumpers correctly.

In the mass market, that would be VESA Local Bus ;)

I recall vesa was only used for graphics cards. There was ISA and extended ISA for the rest (like modems and sound cards).

VESA Local Bus supplemented ISA. It did mostly see use as a graphics card expansion slot, but you could get various I/O cards. I saw a couple of boards in my lifetime that had those slots, thankfully didn't need to support them.

Hey! Some of us remember the microbus fondly! :-)

I was fully ticketed by IBM as a field engineer, but it still didn't make me like Microchannel any better :)

> IBM BIOS being reverse engineered

I assume "clean room" BIOS implementations were important to avoid copyright infringement claims since the BIOS source code was actually provided by IBM in the system's technical reference manual (similarly to other systems of the time):

https://retrocomputing.stackexchange.com/questions/12018/why...

Shame that modern vendors don't provide their system firmware source code.

There is no copyright infringement when an engineer studies a competitors product and pretends that their design is independent?

I don't know if this is a real thing or not (I can see it being real in smaller companies, but incompetent when it comes to these things so what do I know), but that's the case described.

> There is no copyright infringement when an engineer studies a competitors product and pretends that their design is independent?

So long as no actual code was copied, no, there isn't.

An independent re-implementation of an API/interface/whatever for the purpose of interoperability is perfectly legal. This explains the clean-room approach, as it ensures that the developer re-implementing the functionality has absolutely no access to the original code, thus making it impossible for them to engage in copyright infringement (BTW, if you want to watch a fantastic dramatization of this, go watch Halt and Catch Fire. I love the show for a lot of reasons, but their dramatization of the reverse engineering of the PC BIOS was just... so good).

This is why, for example, LibreOffice can go ahead and implement their own Word doc implementation without worrying about Microsoft suing the pants off of them.

It's also why Wine is perfectly legal (though not without controversy when developers have tried to take shortcuts).

Heck, we wouldn't have AMD if this type of thing was illegal! AMD got into the microprocessor market by, yup, reverse engineering the Intel 8080 and cloning it:

https://en.wikipedia.org/wiki/AMD_Am9080

> It was originally produced without license as a clone of the Intel 8080, reverse-engineered by Ashawna Hailey, Kim Hailey and Jay Kumar by photographing an early Intel chip and developing a schematic and logic diagrams from the images.

So how come you can independently re implement an API but if you try and do that with a hard good and slap a ford mustang badge you reimplemented independently onto it you get sued? Further more this is software. Why can't the team looking at the source code just write up the new code rather than write up a spec? Seems like such a useless performance considering you could just run a diff or something to catch plaigerism.

> do that with a hard good and slap a ford mustang badge you reimplemented independently onto it you get sued?

Ah, now we're getting into a completely different forms of IP protection.

The Ford Mustang badge is a protected trademark, so you're not allowed to use it without their permission.

The car itself might also contain patented technical or design elements that you may not be allowed to duplicate without a license.

Broadly there's four classes of IP protection out there: copyrights, patents, trademarks, and trade secrets. This discussion vis a vis reverse engineering is primarily centered around copyright protections.

As for the rest of your comment, check out my other reply where I hopefully clarified things.

Because if you basically just rename variables and some other lazy obfuscations, it's still a copyright violation. This isn't about efficiency. It's about using a process that's relatively resistant to legal challenge.

Copyright is the exclusive right to a particular creative expression, traditionally text. If you recreate the same functionality as another program without copying its text, there is no copyright violation. There may be patent infringement, but that's another matter.

They don't pretend the design is independent, they explicitly have studied the design. The implementation is independent, because they have not studied the code. The code is what is protected by copyright. The design would be in the realm of patents.

On the last point, it's interesting to note that, at the time the IBM BIOS was being reverse engineered by various parties (around 1981/82), software patents were still not particularly well established. It wasn't until the Federal Circuit was established in '82 that there was a consistent treatment of software patent litigation:

https://en.wikipedia.org/wiki/Software_patent#United_States

One has to wonder if, today, the reverse engineering of the IBM BIOS would be possible, given the likelihood that IBM would've patented their implementation.

Interesting point. We partially originally had software licensing in the IBM System/360 days because IBM was skeptical about how useful software patents were as a means of IP protection.

A great example of this would be called an emulator, and I'd argue that, yes - those are completely independent designs. So does the law. :)

Something I've never understood is the requirement to have separate people doing the design and the implementation. How does that provide greater legal protection than one person doing the design, a lawyer signing off on it, and that same person doing the implementation?

The person doing the design studies the original product and will likely gain incidental knowledge of how the original product is implemented. The person doing the implementation ideally has no exposure to the implementation of the original product, so they can't copy the original, not even subconsciously.

Another way to look at this is: what would a judge believe?

Software developers independently come up with the same solution to common problems all the time! We even have names for it: algorithms, design patterns, etc.

If the same person both reverse engineers an existing implementation, and then writes a new one, then that kind of incidental duplication could look like copyright infringement, and the only defense is the developer saying they didn't do it. That's pretty tough to prove.

A clean-room approach solves this problem. Parallel re-invention of the same solution can easily be proven because the developer genuinely never saw the original implementation in the first place, and a lawyer examined the reverse engineered specification to ensure no copyrighted material was contained therein.

So I'm still struggling to get this. Why can't you just directly design and implement sans copywrited material? How is that different than designing without copywrited material then having someone else an employee B do the implementation without the copywrited material. Does this method somehow let you use copywrited material? How would engineer B even know about the copywrited material in that case if they are supposedly 'blind'?

Basically they are documenting non-copyrightable parts of the interface. If you put these numbers in these registers and call this interrupt the result is foo. You need to write a routine to do that but we're not going to tell you what the IBM code did to produce foo.

Let's use a specific(ish) example.

Suppose I've developed an API that has a few function calls:

void foo(int)

int bar(char **)

char *baz(float)

I have then written a bunch of code that defines my specific implementation of 'foo', 'bar', and 'baz'.

That specific implementation--my specific code--is subject to copyright and no one is allowed to copy my code and use it without my express permission. And that includes obvious things like copying the code and obfuscating what you did via renaming of variables and so forth.

But suppose you want to implement your own compatible version of that API so that someone else can use your library instead of mine.

To create your version you decompile the code and you see that the API is composed of those three functions 'foo', 'bar', and baz'. You then read the decompiled versions of those functions and you see what they're logically doing.

You absolutely can then go away and write your own version of this API! As long as you don't literally take copies of my code and just go write 'foo', 'bar', and 'baz' in a way that semantically does the same thing, then you're safe!

However, suppose 'bar' is a simple in-place sort, and you and I both implement a standard quicksort to do the job.

Sure, you wrote yours totally independently of me, but I could still go to a judge and claim that, no, you copied my version! Your copy of 'bar' is in fact a copyright violation because you just stole my code!

How would you prove otherwise?

So instead, what we do is get a third party. Their job is to read the decompiled versions of 'foo', 'bar', and 'baz', and then write down a totally independent specification that describes how those functions work, but doesn't contain any of the code.

To be extra safe, we even get a lawyer to read the resulting specification and certify that, indeed, no copyrighted code is present.

Then we hand you the specification, and you use that specification to implement 'foo', 'bar', and 'baz'.

Now, the specification might say 'bar is an in-place sorting function', and so you go ahead and implement your own version of quicksort.

But now, when I claim you copied my code, you can go to the judge and say "Au contraire! I worked strictly from this specification, here, that my lawyer has verified contains no copyrighted code. The only person that actually read the code is that guy over there points dramatically to the audience and he didn't write any of the code."

This provides a much much stronger defense that your implementation cannot possibly contain illegally duplicated, copyrighted code, and that any similarities are entirely incidental.

Yes, this whole thing probably seems like a crazy dog and pony show, but when you're a little upstart company like Compaq going up against the behemoth that is IBM, you can be damn sure you're gonna dot all your i's and cross all your t's, because they will send an army of lawyers your way, and it won't be pleasant.

You can't possibly have infringed copyright if you never touched the copyrighted material yourself. So companies have other engineers examine that material and produce documentation that you can use to write code. A simple layer of indirection between developers and any legally toxic material.

This is just a popular method to increase the likelihood of success in the event of lawsuit. It's not actually standard, required or anything of the sort. It certainly doesn't prevent competitors from suing you anyway and burning your time and money in court. They can also be awarded an injuction that stops you from making money until the courts decide who's right.

Sony vs Connectix is an example of a company that directly reverse engineered firmware and still won in court but still lost in the market due to an injunction.

https://en.wikipedia.org/wiki/Sony_Computer_Entertainment,_I....

> the PlayStation firmware fell under a lowered degree of copyright protection because it contained unprotected parts (functional elements) that could not be examined without copying.

> While Connectix did disassemble and copy the Sony BIOS repeatedly over the course of reverse engineering, the final product of the Virtual Game Station contained no infringing material.

Independent creation is a defense to copyright infringement, but only if the accused did not have access to the original work.

In the BIOS cases, this means that the implémenter can produce the exact same assembly code as the original BIOS and it’s not copyright infringement, but only if the implementer never saw the original code.

> Independent creation is a defense to copyright infringement,

Yes.

> but only if the accused did not have access to the original work.

No, but the accused having access to the original work makes it less likely that a trier of fact (jury or judge depending on the kind of trial) will conclude that the creation was independent rather than copying.

You’re right. I should be more careful about using “only if”. Practically, however, access to the original will probably defeat the independent creation defense.

The person doing the specification has been "contaminated" by the original's documentation and product; it's possible to argue that they carried over knowledge directly from the original product. The lawyer in the middle establishes a firewall ensuring nothing was taken from the original outside of the specification.

I don't know of any actual cases that hinged on this, but lawyers tend to be belt-and-suspenders types. One remnant is the advice from the GNU folks on building clones of Unix tools---you could even be tainted by looking at the Unix source, as long as the clone was architecturally very different. (Which led to a lot of better implementations of Unix tools...)

It's an extra precaution: it guarantees that the people who are doing the implementation never see the original copyrighted work, so copying is impossible.

If the same person reviews the product being cloned, writes a spec, has it reviewed, and does the implementation, the other side can argue that knowledge that was not in the spec was used in the development. They might or might not succeed in this argument, but cautious companies firewall off those who have seen the original product and those who develop the clone, especially if the competing company has a litigious reputation.

If you've never read "Lord of the Flies", you'll have an easier time convincing people that your new book about a bunch of shipwrecked boys doesn't infringe its copyright.

Reply on news.ycombinator.com