Dr. Dobb's Journal December, 2004
DMCA and the Apple/Real Debates
Dear DDJ,
There are a couple of points Jonathan Erickson failed to mention in his editorial "Reverse Engineering" (DDJ, October 2004).
According to my own (admittedly non-expert) reading of the reverse-engineering clause of the DMCA, it permits reverse engineering only for interoperability of programs, not documents. Real could reverse-engineer FairPlay if they found it necessary for a software product to interoperate with Apple's software. For instance, if they ship a RealOne player that interfaces with QuickTime for playback of iTMS purchases. But the DMCA does not seem to permit this reverse engineering for any other purpose. Which would include for the purpose of applying the reverse-engineered DRM to new documents.
Of course, this assumes that Real actually did reverse-engineer FairPlay. Real maintains that they did not. If, as Real claims, they simply used public-domain information about FairPlay to develop its code, it becomes a different story. Assuming, of course, that the information it used wasn't published by someone who violated the DMCA as a part of his own reverse engineering effort. (I don't know if the DMCA's restrictions are viral or not—if information obtained in violation of the DMCA is illegal for third parties to possess or not.)
All that being said, I actually hope that Apple's FairPlay does get opened up to the world. I think it's good for the iPod owner (if not for Apple) if music from the widest variety of sources can be used with iTunes/iPod.
However, I do not want Real to be the one to break the ice. They have a long history of developing proprietary closed software. They have sued others for reverse engineering Real's streaming media formats. A company like this does not have the moral high ground to be demanding openness from others.
I am morally and ethically opposed to the very concept of the DMCA, but as long as it's the law of the land, why shouldn't a company I respect (like Apple) be allowed to use it against a company I despise (like Real)? Why should it remain in the domain of record/movie companies that are using it to sue old ladies and small children?
David Charlap
shamino@mindspring.com
More Reverse Engineering
Dear DDJ,
In regards to Jonathan Erickson's "Reverse Engineering" editorial (DDJ, October 2004), I just want to let you know that the notes in French are: Do Re, Mi, Fa, Sol, La, Si, Do so you can't have fa-so-la-ti-do. It should be fa-sol-la-si-do.
Remi Ricard
Remi.Ricard@simlog.com
P.S. As my music teacher was used to say: "Re-mi fa do-do avec ses souliers fa-si-la-si-re," or in normal French, "Remi fait dodo avec ses souliers façile a cirer."
Jon replies: Blame Rodgers and Hammerstein.
On Being Professional Engineers
Dear DDJ,
I read the rebuttals to Jonathan Erickson's "Editorial" (DDJ, June 2003) and it seems to me that both Jonathan and the respondents are missing some key points. One key point is that the question of whether someone is an "engineer" or not is a legal—not technical—issue, although to be sure, the engineer's technical capabilities are closely intertwined with the legalities.
Before someone is certified by a state to be an "engineer" (of any sort), and practice engineering in situations that affect the safety of life and property, he has to show he is qualified to do so, at least to some minimum extent. Furthermore, as at least one respondent described, engineers must periodically demonstrate they are maintaining and upgrading their qualifications.
To demonstrate qualifications, presumptive engineers must demonstrate at least a minimum amount of knowledge of the standard practices of their discipline...This is true whether the discipline is mechanical, electrical, chemical, or any other kind of engineering. The result of demonstrating their qualifications is that engineers obtain a license of some sort, giving them formal and official permission to practice their discipline. A key piece of showing their qualifications is demonstrating that they know and can apply standard practices; this then immediately leads to the question of the very existence of "standard practices." In the hardware engineering disciplines, these have been developed over many years, by virtue of...mathematical theory pertaining to that discipline combined with extensive experience in the application of those theories in actual practice. Unfortunately, software engineering seems to be lacking in both areas. This is to some extent inevitable, since the discipline is very young compared to the other engineering disciplines. Certainly, "best practices" are still evolving.
By way of analogy, in the hardware world, mechanical engineers can prove, using known theory and known properties of materials, that a bridge or other structure or machine is "correct" in that it will withstand a certain load. In the software world, we cannot, in general, prove that a program will perform correctly. Formal "correctness proofs" of software are limited in scope, esoteric at best, and never—to my knowledge—used in practical development—a far cry from what the hardware engineers are used to doing routinely.
Presumably (and hopefully), this situation will change as the discipline of software development matures. Until it does, we hardly have a basis for claiming equality with the hardware engineering disciplines. These are all legal issues. If the Texas legislature wants to legislate nomenclature, I suppose that's its right, although it does remind me of something I read a long time ago: The legislature of a state (which I leave nameless) passed a law that pi would henceforth be 22/7. These things are not unknown. Sometimes we just have to grin and bear them.
But as I see it, we should get our own house in order before we can be in a position to make the case for calling ourselves whatever we feel we want to be called. Until then, we'd be hard put to make those claims.
Howard Mark
hlmark@prodigy.net
Little Languages
Dear DDJ,
One piece of info should be upfront in all language descriptions—are they line oriented? Ruby is presented as if it isn't—which is good; is that the case? As a practical matter, this can be important; one of the continuing annoyances of even the giant Visual Basic is those lines. And...many of the UNIX little languages are line oriented.
While I'm here, my theory is that UNIX/Linux has all these little languages because they never had Philippe Kahn and Turbo Pascal; it's still so awful to compile/debug C in UNIX that people constantly turn to scripts...while in CP/M, MS-DOS, and Windows, similar yearnings were crushed in the face of the incredibly convenient Turbo languages.
J.G. Owen
owen_labs@bigfoot.com
DDJ