This is why you always publish code separately from blog posts and the like, when you're talking about reversing. As long as all you're doing is talking about it (and showing things like protocol structures, dumps, etc), there's nothing they can do. Back in ~2005, I took to writing blog posts that gave you everything you'd need to know to, say, implement Apple's Fairplay DRM. Because there was no code, they couldn't take it down, and it was able to propagate trivially -- in effect, a specification in narrative form.
That didn't stop Apple from going after bluwiki a couple of years ago for something as simple as reverse engineering the iPhone file transfer protocol. "There's nothing they can do" is never really true when you're talking about huge corporations with lawyers.
I'm not sure of the details of the bluwiki fiasco, but I can certainly say that this worked for me through my battles with Apple -- we had our share of issues, but never once did one of my blog posts (detailing everything that you'd need to know to reimplement any of the code) get a DMCA takedown notice or the like.
While I have no problem with anonymous publishing, I much prefer to operate in clear sight under my own name. Not only for the obvious benefits to me (e.g. my work with iTunes jumpstarted my career), but because I strongly feel that what I do is completely in the right, and publishing it anonymously simply gives the wrong impression.
Yes. Copyright covers exactly what's in their binaries, not anything you learn from their binaries.
I would argue that the opcodes in the binary are covered by copyright, but if you reverse-engineer those into C, that's your own creative work. Apparently Skype's lawyers did not see it this way, but why would they? If you're going to lie, you have to first convince yourself.
Copyright doesn't just cover "exactly what's in their binaries", because of the derivative works statutes. If you translate a book from English to French, the resulting book is still under the copyright of the original author; the same goes for taking disassembly -> decompiled C.
Something becomes a derivative work when excessive amounts of the source material structure comes from a copyrighted work. If you reverse engenear a program create a spec and have someone else code to that spec then copyright does not cover you.
You could create an original novel that was not a derivative work by taking once sentience from every book in a library and trying to create a meaningful work of art from it. Doing the same thing using a single book would probably not fly.
Yep, that's why the concept of clean-room reversing exists, to get around the derivative work concepts. It's not the only option, but it's probably the safest.
That's an interesting question. I'd be inclined to say no, but without precedent in court on this, it's tough to say. The reason I'd say no is that while pseudocode serves the same function as a "narrative spec" in this case, it's inherently not a new creative work -- it'd be easy to allege that it's a derivative work. I don't think you'll have an easy time convincing any judge that just because your 'code' doesn't compile or run, it's not still code and treated the same as, say, some C or Python.
