If I build a clean room implementation of some software, I have no trade secret problems. Right?

Maybe. It depends how you do it, and why. Trade secrets cover a number of things. Many of them are things which might have been patented, but were not. A patent has a limited life, but a trade secret is a secret as long as you can keep it one. If you discover the secret by illicit means, such as industrial espionage, expect trouble. However, the law in most countries respects reverse engineering these secrets for certain purposes as a legitimate activity. Interoperability is one such purpose. Reverse engineering interfaces is usually OK, although recent legislation in some countries (e.g. the DMCA in the USA) may negatively affect this freedom. Choosing the best place in which to reverse engineer may become important. It is always important to separate the secret from its implementation. You can reverse engineer an interface, and implement your own realisation of that interface. Copying parts of the actual hardware or software design which originally implemented it will get you into trouble.

If you follow the reverse engineering path, it is usually best to have some people work out the secrets, and document them. Then get a separate group of people to create a fresh new implementation that works against the documented interfaces, without any detailed knowledge of the original. Things seldom break down so cleanly into analysis and re-implementation. When interoperability tests are conducted with a new implementation, problems will often be found in some details of the original analysis. It is important to keep the two sides interacting at arms length, and not give in to the natural temptation to chat freely about problems, in order to resolve them efficiently. Implementors may only ask analysers questions specifically about details of behaviour. Analysers must not reveal anything they discover about implementation. It is best to undertake all interactions in writing, so an audit trail is available if disputes arrive.