copy protection - was: Re: Is it time for playing games on WINE?
Geoff Thorpe
geoff at geoffthorpe.net
Wed Nov 5 17:00:31 CST 2003
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/
More information about the wine-devel
mailing list