On November 5, 2003 01:00 am, Jonathan Wilson wrote:
Basicly as long as our code: A.cant run "copied" safedisk disks ("perfect copies" and "no-cd cracks" aside) and B.cant be modified to run "copied" safedisk disks (e.g. by disabling some parts of the WINE code that performed checks) then I think that we would probobly not be violating the DMCA (although IANAL)
This is slippery ground. Given that Wine is open source (and moreover, very clearly laid-out, non-obfuscated, *structured* code), you can't possibly satisfy (A) and (B) in such a way that they aren't "easy" to bypass (ie. such that I can't simply comment out a couple of lines of code and type "make").
As we've seen with encryption regulations in the past, the issue of control-circumvention law dissolves in the face of open-source software. Moreover, in the face of (L)GPL open-source software, it dissolves by *design* - you can not withhold source-code if you want to release binaries. IIRC, this was one of the major stumbling blocks for Transgaming and the Wine/LGPL debate - they have copyprotection support that they legally can not dream of releasing source for. Some argue that binaries are a form of source code anyway, and that you can "read" them in the sense that you can interpret and modify their operation. However, the lawyers seem reasonably comfortable with that argument - they call it reverse engineering and it's "bad"(tm). It is my personal opinion that this legal anomaly with copyleft is no accident - Microsoft (and the RIAA) lobby harder than most, and laws that are impossible to abide by in open source are "good" laws for lawyers and their preferred clients, and "bad" for disreputable communists (as we most surely must be if we don't feel like trading binaries commercially). But I digress.
What you've said about putting safedisk support into Wine is analogous to saying (a few years ago) that you could add an open-source encrypted filesystem to the O/S by only allowing the use of 40-bit cipher keys to satisfy export regulations. The fact that any dolt with gcc and a text-editor can type "s/40/128/g" makes that an insufficient defense, unfortunately. Somewhere in the callstack between the application and the kernel's CD driver needs to be something that is closed-source and not subject to trivial circumvention. I can't see how this can be done without requiring a DMCA violation in Wine, the O/S kernel, or requiring the copying of a closed-source driver that *itself* is irreplacable (choosing to load it from Wine and say "don't edit this Wine code to circumvent the commercial driver" in a C comment won't jive). Perhaps I've misunderstood something about the copy-protection model here, but the law itself seems to preclude a general open source solution, no matter how you slice it.
FWIW: as far as I can tell, the majority of americans would not support this sort of legal framework if it was explained to them (especially if they were shown a DVD using some of the xine skins), and apparently the US is a democracy with enormous pride in free speech and other convenient catch-phrases, but these flavours of legally bullying continue to pick up steam and the US is starting to repress itself on a scale they have so often criticised in other nations. <sigh> But I'm digressing, again. Sorry.
Cheers, Geoff