copy protection - was: Re: Is it time for playing games on WINE?

[Geoff Thorpe]

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

-- 
Geoff Thorpe
geoff at geoffthorpe.net
http://www.geoffthorpe.net/