How clean must the room be? [LWN.net]

The discussion on what features should be merged into the 2.6.18 kernel has begun (see this week's Kernel Page for the details). One item which was mentioned is the acx100 driver, which has been sitting in the -mm tree for some time. This driver works, is useful to a broad community of users, and appears to be entirely acceptable to the kernel developers who have reviewed it - except for one little problem.

This driver, it seems, was developed by reverse engineering a binary-only driver released by TI for the 2.4 kernels. Reverse engineering is not a problem in itself, as long as due care is taken to avoid copying any code from the non-free driver. The normal way of taking due care is to employ a "clean room" technique: the person who does the reverse engineering work writes a document describing how the hardware functions, but does not write any code. Instead, another developer, who has never looked at the original driver in any way, writes the new driver based on the information in the document. This approach shields the developers from any charges of copying code, since they have never seen the code in question.

The acx100 driver was not developed in this way; instead, the people who did the reverse engineering went on to implement the new driver directly. Nobody has alleged that these developers copied any code in this process. But the process they used opens the door to such charges in the future. So the code is seen as being tainted, even though it is probably entirely legitimate. This taint has been enough to keep the driver out of the kernel.

One kernel developer objects to this course of events, calling it excessive:

I disagree there (not speaking for any company just for myself here): the "clean room" thing is ONLY a USA thing, and is not even required in the USA. It is a "we want to be extra safe in the USA" thing only.

He goes on to say that, if the developers can certify that they copied no code, and especially if the work was done outside of the USA, the driver should be able to go into the mainline kernel.

Others disagree, however, noting that "being extra safe" is no bad thing. The SCO case has shown how disruptive a copyright-based challenge to the Linux code base can be. Linux has, by all appearances, come through that challenge looking even better than it did before; the kernel code truly is clean. What a shame it would be to merge code which ends up bringing on another lawyer storm and ruining the kernel's hard-won clean bill of health. Sad though it may be, leaving out the driver might be the better choice.

Still, there is a lingering issue here: which laws should be allowed to control which code is accepted into the kernel? By many accounts, the acx100 driver would pass muster in Europe; it is U.S. laws that are of concern. But the laws of, for example, Haiti, Egypt, and Georgia have not been consulted. Complying with laws across the entire planet would be a tall order. Conflicts with laws on, say, spectrum use, surveillance capabilities, or "piracy prevention" in various parts of the world seem increasingly likely. Steering a global operating system through this maze will be an interesting challenge.

(Log in to post comments)

Which country's law?

Posted Jun 8, 2006 8:19 UTC (Thu) by ekj (subscriber, #1524) [Link]

But those risks aren't that large.

I mean, assume Linus accepts the patch, in good faith, having received confirmation from the developer that he copied nothing from the closed driver.

Let's say it later turns out that 4 of the functions still do show signs of being copied from the closed driver. What would be the result ?

First, those functions would have to be removed from the Kernel. No question about it. They could however be rewritten, using clean-room techniques if desired. (I remove the functions, and send you a written document with no code that describe their workings, you write new replacement-functions)

Yes this is bad. But there's no way to guard against it.

Whenever you accept a new driver from someone. You cannot 100% certainly *know* that that driver isn't partly copied from reverse-engineered closed drivers. You just have to trust the developer. And on the rare occasions where hes wrong, or outrigth lying, revert the patch lateron.

Which is why ...

Posted Jun 8, 2006 8:36 UTC (Thu) by AnswerGuy (subscriber, #1256) [Link]

... almost no one from any significant corporation would sign off on such a review request.

You can't just go to some company and say: "here's a pile of code; will you compare it to yours and certify that it's NOT infringing on anything you own?"

TI is far, Far, FAR more likely to just release their own code under the GPL (where they retain ownership, attribution, and some assurance that any improvments that are done by other parties and distributed have to be contributed back) then they are to give anyone a "get of litigation free" card. It would cost them far less (in term of labor at the very least).

(That's assuming that they actually own any of the code; it may be that they have only licensed some rights to it from some other party --- which might be why it's proprietary).

JimD

But maybe...

Posted Jun 8, 2006 9:07 UTC (Thu) by eyal (subscriber, #949) [Link]

the code should be delivered to TI with a letter that says:

"We've reversed engineered your driver, and we've written a new driver that does not contain any code copied from yours. Please inspect out code, and inform us of any violation of your copyrights over the code. If you don't respond within XX days, we'll assume that there aren't any such violations."

IANAL, but at least in some jurisdictions it will be very hard for TI to claim wrong-doing in the future.

Eyal.

But maybe...

Posted Jun 8, 2006 12:25 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]

Need to appeal to their bottom line:
"We'd like to tout TI as a progressive, user-oriented company, committed to fairness and reasonability on all sides of the patent/trademark/copyright questions involved in this bit of code. Help us advertise TI."

But maybe...

Posted Jun 8, 2006 14:44 UTC (Thu) by bronson (subscriber, #4806) [Link]

I hope nobody takes this advice. This is as bad as the old "put something in an envelope, mail it to yourself, and submit the unopened, postmarked envelope to the court as legal evidence" technique. Te most junior litigator will shoot it full of holes inside a minute. It's just not worth your time or the price of the stamp.

But maybe...

Posted Jun 9, 2006 2:26 UTC (Fri) by khim (subscriber, #9252) [Link]

May be U.S. "most junior litigator will shoot it full of holes inside a minute", but in Russia it works just fine. Of course you need registered letter (the kind used to deliver official documents). Not only an envelope is supposed to be impenetrable, but letter must also contain number and this number is registered in central office - exactly to make it possible to prove that this letter was indeed sent by this time and date.

Law declares that such number and/or envelope is enough to prevent $1'000'000'000 fine in tax avoidance case (at least it does in Russia) - what reason do you have against using it for copyright case with many times less money at stake ?

Again: different countries, different law...

But maybe...

Posted Jun 8, 2006 17:01 UTC (Thu) by Los__D (subscriber, #15263) [Link]

I can't really see this working...

I'm pretty sure that TI has no obligation to do that work.

It would be a bit like sending a letter to someone, where you explain to them that if they don't answer back within XX days, you'll consider it ok that you take their car.

But maybe...

Posted Jun 15, 2006 8:10 UTC (Thu) by Wol (guest, #4433) [Link]

Actually, there's a BIG difference between the two examples.

In the TI case, you're saying "we believe we're clean. Please will you confirm everything is okay".

In your car example, it's "we're going to break the law, and if you don't tell us otherwise we'll assume we have your permission".

The difference is clear and simple. Is the basic act (absent permission) legit or not. In the first case it's "we believe it's legit, but we would like your confirmation". In the second case it's "we know it's not legit unless you give permission".

Cheers,
Wol

But maybe...

Posted Jun 15, 2006 14:14 UTC (Thu) by arcticwolf (guest, #8341) [Link]

The two examples have something in common, too, though - namely, in both cases, you're essentially saying "we assume that your not reacting in any way at all means that you really are reacting a certain way (that's favourable for us)".

The problem is not that you're seeking justification for something you know is illegal; it's that you're assuming that when TI doesn't say anything, they really are saying "you got our blessings". And *that* is something that you can't do, of course, and that won't be worth a penny if the whole thing should go to court later on.

How clean must the room be?

Posted Jun 11, 2006 22:56 UTC (Sun) by arjan (subscriber, #36785) [Link]

Just to clarify a bit; it seems I got sort of misunderstood by many.

The clean room approach is obviously by far preferable to follow for any reverse engineering. If you can do it, it's really great. For example the broadcom wireless driver in 2.6.16/17 is done this way, and my appreciation to the developers for doing this effort is great.

However there is a flipside; doing this is a LOT more work, and the side of the clean room work that has to write the document has a job that many open source developers would consider boring, after all it is not about coding but only about writing documentation ... (and not even about something you can be proud of as your own work).

If this high standard for reverse engineering would be the kernels minimum standard, I am afraid that will just put off developers where we need them most; it's not like Linux has plenty of wireless drivers for current hardware for example. (Sure there are the Intel drivers, where my employer is putting in quite an effort to have that work, and there now is the broadcom one, but still, the state of wireless in Linux isn't all that good; I don't think anyone will disagree with me on that)

And from a legal point of view, any lawyer will be able to tell you that the cleanroom approach is not the only approach that would satisfy even the USA legislation. What exactly would is a bit of an open question, and I would love to get a lawyer to teach us about this, say at OLS or the kernel summit. The biggest concern with reverse engineering as I understand it is that someone can claim you copied from their code. With the clean room approach you can show that that is imposible, so obviously that's the prefered method. Other methods can satisfy the same thing. Don't ask me where the line is, I'm not a lawyer, and I would suggest to both talk to one and be careful.... but again the balance is between being super careful and getting any kind of driver contributions at all ;-(. Quite a few drivers in Linux exist because someone reverse engineered another driver in the past; and quite a few of those did not follow strict clean room process.

[Note: the entire rev engineering debate changes when some sort of copy protection device gets involved, then the DMCA gets involved with all the consequences. Thankfully for this driver that appears to not be the case at all so we can avoid that political flamewar]