-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi jason,
Great work, and its good to know we are making progress. I spend most of my time working on small tutorials and demos which highlight a specific problem, and havent yet had the 'pleasure' of spending much time playing the games I have got working!! A list like this is really good (as is the fact you have been creating patches!! - I'm not sure about the device.c one though, as I think copyrects is hacked to allow back buffer updating which would otherwise fail as you are copying to a render target). All patches, help and assistance welcome
I think we can easily fix the two cases unsupported on CopyRect
- I spend far too many nights up to about 1am trying to get things working.
As me :)
Personally I would love to have someone maintain a list of things which work and which fail, and test them periodically, seperated into the d3d level. One huge problem I have is regressions - I can code something to fix a particular feature but its very easy to break something else, and similarly its nice to know that a particular change actually fixes some other games!!
:)
Finally some info, I am currently spending my time trying to get some features of d3d8 working. I have put on hold render to texture and am concentrating on some other areas, although I want to get that one working. I then need to make a choice - I can either concentrate on performance, on adding hardware vertex shader support or on adding d3d9 support, and I havent decided which.
For hardware vertex shader, i'll send my proto when glx cards drivers will really support it with usable performances (it's unusable on my gf4 card and the support of pixels shaders have to wait for a glx driver that support it for testing)
I think d3d9 would make sense to wait until last otherwise any performance work will need doing in one place. I have an idea on some ways of speeding things up and have a glcore type setup which has been discussed before.
I think beginning with moving drawing code and texture code from d3d8 to wined3d should be easy.
One other thought. At some point in time we will have to address copy protection. I dont want to get into legal discussions and I dont intend looking into it (yet), BUT would I be correct in saying that if someone worked out the first point at which copy protection fails, and codes a basic application which emulates this behaviour. Since this simple app works on windows, then someone else could then work on getting the basic program working under wine without being contaminated by knowledge of the internals of the copy protection itself? If this is the case, it would be a useful thing to put on the projects page. If the legality of this is dodgy, forget it - there are always hacks around, its just frustrating.
For what i remember, copy protection is almost specific how cdrom windows driver work. We "only" have to completely emulate this behavior
Anyway, back to my next problem. Jason
And me to my dmusic code for unreal2 Regards, Raphael
PS: when i'll get this dmusic code working, i'll return to d3d8-9 :)
On Sunday 02 November 2003 03.58, Raphaël Junqueira wrote:
One other thought. At some point in time we will have to address copy protection. I dont want to get into legal discussions and I dont intend looking into it (yet), BUT would I be correct in saying that if someone worked out the first point at which copy protection fails, and codes a basic application which emulates this behaviour. Since this simple app works on windows, then someone else could then work on getting the basic program working under wine without being contaminated by knowledge of the internals of the copy protection itself? If this is the case, it would be a useful thing to put on the projects page. If the legality of this is dodgy, forget it - there are always hacks around, its just frustrating.
For what i remember, copy protection is almost specific how cdrom windows driver work. We "only" have to completely emulate this behavior
AFAIK there is no problem with the cdrom handling. The problem is that copy protection is usually implemented in drivers (*.sys files), which cannot be loaded by wine.
If I remember correctly then Laurent Pincharts safedisk patch consisted of the next logical parts: 1. fix a process startup race - if the child process was created suspended, then some wineserver messages got overwritten by new messages. 2. add code to handle scsi cdrom ioctls (used by the copy protection to read some raw data from the cd). 3. return EXCEPTION_PRIV_INSTRUCTION instead of EXCEPTION_ACCESS_VIOLATION when a some exception was raised by the user 4. support shared memory beetween kernel space and user space (see SharedUserData in ntddk.h) 5. implement SECDRV device handler
For all this to work it is necessary to set winver to nt40 (or some other from the nt line).
The current status is (AFAIK): 2 was committed to wine CVS. The problems behind 1 and 3 were fixed in the meanwhile. I have read a discussion about 4 on wine-devel. If I remember correctly it was aggreed that it should be added to wine sooner or later. But I dont see it yet in the CVS.
5 is the only part which is related to safedisc. The SECDRV device handler is implemented in the secdrv.sys file which comes with the copy protected CD. The problem is that wine can't load .sys files. Laurent solved the issue by reimplementing the secdrv.sys in wine, but this brings fort the legal issues.
So this is what I think that the status of copy protection is. If I'm wrong somewhere then please correct me.
Regards Zsolt
Zsolt Rizsanyi wrote:
So this is what I think that the status of copy protection is. If I'm wrong somewhere then please correct me.
Hi,
Yea I think your correct...... here is his post... http://www.winehq.com/hypermail/wine-patches/2002/04/0194.html
And our last exchange: Zsolt http://www.winehq.com/hypermail/wine-devel/2002/12/0462.html
And Patrik Stridvall's reply http://www.winehq.com/hypermail/wine-devel/2002/12/0461.html
To quote Patrick
"Correct, it didn't support SafeDisc 2. However I think that at least part of it was accepted. Anyway the reason that some part was not not accepted was not DMCA related."
Okay.... If its not the DCMA then why has this code not been accepted??
In Laurent Pincharts words........
"safedisc-dmca.diff contains the code which *might* infringe the DMCA. In my opinion it doesn't, but I'm not a lawyer."
So......
Alexandre, is there any chance of this code *ever* being excepted into the wine tree? If not what would need to be done for exceptence to take place?
If this code has a "snowballs chance in hell" of ever being excepted into the tree then "please" let me and the others here know....
Or better yet...... if Jer, has a lawyer who is setting around looking at his secretaries back end.. He could ask him what his thoughts on this would be, and this whole discussion could come to a....... well lets only hope a happy end......
Please reply...... As I hate spam but i'm not over spamming to get a reply ;)
Tom
Regards Zsolt
Tom twickline@skybest.com writes:
Alexandre, is there any chance of this code *ever* being excepted into the wine tree?
None whatsoever, the driver "reimplementation" is clearly a DMCA violation. The proper way to do that is to somehow load the driver and let it perform all the checks it wants to perform; a dummy driver that returns magic values to bypass the checks is not acceptable.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Le Tuesday 04 November 2003 23:07, Alexandre Julliard a écrit :
Tom twickline@skybest.com writes:
Alexandre, is there any chance of this code *ever* being excepted into the wine tree?
None whatsoever, the driver "reimplementation" is clearly a DMCA violation. The proper way to do that is to somehow load the driver and let it perform all the checks it wants to perform; a dummy driver that returns magic values to bypass the checks is not acceptable.
Why about trying to get this driver working on top of current ntdll ? All drivers accesses should pass by kernel calls no ?
Regards, Raphael
El mié, 05 de nov de 2003, a las 00:50, Raphaël Junqueira escribio:
Alexandre, is there any chance of this code *ever* being excepted into the wine tree?
None whatsoever, the driver "reimplementation" is clearly a DMCA violation. The proper way to do that is to somehow load the driver and let it perform all the checks it wants to perform; a dummy driver that returns magic values to bypass the checks is not acceptable.
Why about trying to get this driver working on top of current ntdll ? All drivers accesses should pass by kernel calls no ?
Hmm, really loading/running the driver we will only move the "magic" a bit lower. If i have understood correctly what secdrv.sys does, it simply checks if there is a debugger running. So, in some point it will have to ask to the core (wine):
secdrv.sys = "is there a debugger running there?" wine = "Here?? Noo!!!, how can you think so? ;)"
I think that we should ask to a lawyer, because we could be sitting a bad precedent, about what can be implemented, and what can't :/
Regards, Carlos.
None whatsoever, the driver "reimplementation" is clearly a DMCA violation. The proper way to do that is to somehow load the driver and let it perform all the checks it wants to perform; a dummy driver that returns magic values to bypass the checks is not acceptable.
From what I know about copy protection, they basicly work as follows: 1.There is special code that is designed to detect the presense of a debugger such as SoftIce 2.There is special code to read special "hidden" information from the CD (and if it doesnt exist or isnt correct, reject the CD as copied) and 3.There are modifications to the exe file/game code (e.g. encrypted code or messed up Import Address Tables or whatever else), sometimes relying on the hidden CD data, sometimes not.
From looking at the posted "safedisk-dmca.diff" and from looking at secrdv.sys in IDA pro it would appear that the primary purpose of secdrv.sys is to allow access to areas in kernel mode not normally accessable to userland code, more specificly, its used to check certain things for the presense of a kernel level debugger (e.g. SoftIce).
The actual copy protection code is (as far as I know, correct me if I am wrong) contained in various dlls and other code (including code thats inside the game exe itself) that operates in userland and sends IOCTLs to the CDROM drive to get the secret data back.
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)
If someone wants to disagree with me or has evidence refuting my statements (legally or technically, please do post here or mail me.
On Wednesday 05 November 2003 6:00 am, you wrote:
None whatsoever, the driver "reimplementation" is clearly a DMCA violation. The proper way to do that is to somehow load the driver and let it perform all the checks it wants to perform; a dummy driver that returns magic values to bypass the checks is not acceptable.
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)
I agree. It would appear that secdrv.sys is not an essential part to the decrypting process. If it were then there would be loads of "secdrv-hacked.sys" type files floating around the internet. In actual fact, most people seem to be able to decrypt the contents without touching this file.
Rob
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 wrote:
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").
I don't get it. As far as I understand, so long as the code in the Wine archives does not allow running copied discs, we are not violating the DMCA. If someone else takes Wine code and modifies it, that's where the DMCA violation happens.
If this becomes a real issue, I can offer to host the Wine sources in a DMCA free country. I'm sure you'll all agree with me that the sources are the only prolematic part (if a given binary does not allow copied discs to run, it cannot be said to be infringing).
Shachar
Shachar Shemesh wine-devel@shemesh.biz writes:
I don't get it. As far as I understand, so long as the code in the Wine archives does not allow running copied discs, we are not violating the DMCA. If someone else takes Wine code and modifies it, that's where the DMCA violation happens.
The DMCA does not require copyright violation, what is illegal is "circumventing" the protection measure, it doesn't really matter if the replacement code has the same functionality or not. For example it's illegal to decrypt your own DVDs with DeCSS, but it's legal to do it with an "approved" player, even though they are of course both running the exact same algorithm. Yes it's absurd, but that's the way the law is written.
So the question is whether the code in question is "circumventing" the protection or not. I think you would have a hard time convincing someone that a dummy driver that returns magic values is not circumventing part of the copy protection, even if the resulting behavior is identical to the original. OTOH you can make a pretty good case that a generic "Windows driver loader" is not circumventing anything, it's just doing what any Windows replacement is supposed to do.
If this becomes a real issue, I can offer to host the Wine sources in a DMCA free country. I'm sure you'll all agree with me that the sources are the only prolematic part (if a given binary does not allow copied discs to run, it cannot be said to be infringing).
No, a binary is problematic too. The DeCSS exe is just as illegal as the source.
Alexandre Julliard wrote:
Shachar Shemesh wine-devel@shemesh.biz writes:
I don't get it. As far as I understand, so long as the code in the Wine archives does not allow running copied discs, we are not violating the DMCA. If someone else takes Wine code and modifies it, that's where the DMCA violation happens.
The DMCA does not require copyright violation, what is illegal is "circumventing" the protection measure, it doesn't really matter if the replacement code has the same functionality or not. For example it's illegal to decrypt your own DVDs with DeCSS, but it's legal to do it with an "approved" player, even though they are of course both running the exact same algorithm. Yes it's absurd, but that's the way the law is written.
So the question is whether the code in question is "circumventing" the protection or not.
If the code in Wine still doesn't allow unprotected CDs from running, there can be no problem.
I think you would have a hard time convincing someone that a dummy driver that returns magic values is not circumventing part of the copy protection, even if the resulting behavior is identical to the original.
If the resulting behaviour is that copied CDs don't work, while original ones do, there is no circumvention (the mechanism that protects access to a copyrighted work is still in place).
If this driver works with a CD, regardless of whether it was or was not copied, then we have a problem, yes.
If this becomes a real issue, I can offer to host the Wine sources in a DMCA free country. I'm sure you'll all agree with me that the sources are the only prolematic part (if a given binary does not allow copied discs to run, it cannot be said to be infringing).
No, a binary is problematic too. The DeCSS exe is just as illegal as the source.
That's because of what DeCSS does. DeCSS is the circumvention device itself. It takes an encrypted DVD and produces unencrypted MPEGs. For example - I'm pretty sure that if you statically link Xine with libdecss, you will get a binary that is perfectly legal (region codes non-withstanding). It doesn't strip away (circumvent) the protection, it's just a player (i.e. - used the same way as it was meant to be used). I'm not sure how legal the source for that will be, but like I said, I think I can provide a place where the sources should be safe. Personally, I think the sources should also be legal, so long as we don't place a prominant #ifdef that, if set, produces a circumvention device.
Remeber, the "chilling effect" is when we let the DMCA control what we do further than what it was meant to do to begin with. I can't see anyone taking you to court saying "look, it's true that with Wine you can't do anything that you can't do without, but it's an unlicensed version, so it's a DMCA violation".
Shachar Shemesh wine-devel@shemesh.biz writes:
If the code in Wine still doesn't allow unprotected CDs from running, there can be no problem.
No, it's not that simple. By providing a replacement driver, you are circumventing a technical measure controlling access to the work. The fact is that without the driver you don't get access, and with the dummy Wine driver you do; since the dummy Wine driver is not an "authorized" way to get access it's circumvention. It doesn't matter at all whether it lets you use copied CDs or not.
Besides, I don't see how you could possibly prove that our implementation does exactly the same thing as the original one. Maybe the original doesn't only prevent copied CDs, maybe it also checks the phase of the moon or whatever, you have no way to make sure the protection is implemented correctly.
That's because of what DeCSS does. DeCSS is the circumvention device itself. It takes an encrypted DVD and produces unencrypted MPEGs. For example - I'm pretty sure that if you statically link Xine with libdecss, you will get a binary that is perfectly legal (region codes non-withstanding).
I'm not so sure. Since it decrypts DVDs in a way that is not authorized by the copyright holder, technically it's circumvention. It doesn't matter whether it lets you infringe copyright or not.
Remeber, the "chilling effect" is when we let the DMCA control what we do further than what it was meant to do to begin with. I can't see anyone taking you to court saying "look, it's true that with Wine you can't do anything that you can't do without, but it's an unlicensed version, so it's a DMCA violation".
Actually I think this is pretty likely. Nobody is going to go to the trouble of investigating exactly what the driver does, when it's much easier to simply send the lawyers and get rid of it; especially when we are dealing with a company like Macrovision that makes a living selling this snake oil^H^H^H^H^H^H^Hcopy protection stuff. This is why it's important to not only make sure it is legal, but also make sure it looks obviously legitimate to a casual observer. The dummy driver fails that test.
Hi there,
On November 6, 2003 02:18 pm, Shachar Shemesh wrote:
Alexandre Julliard wrote:
So the question is whether the code in question is "circumventing" the protection or not.
If the code in Wine still doesn't allow unprotected CDs from running, there can be no problem.
I think you would have a hard time convincing someone that a dummy driver that returns magic values is not circumventing part of the copy protection, even if the resulting behavior is identical to the original.
If the resulting behaviour is that copied CDs don't work, while original ones do, there is no circumvention (the mechanism that protects access to a copyrighted work is still in place).
If this driver works with a CD, regardless of whether it was or was not copied, then we have a problem, yes.
Of course, IANAL, YANAL, and MOUANLE (Most Of Us Are Not Lawyers Either). However I think the point here, and it seems to be Alexandre's reading of it too if I understood the thrust of his post, is that the "protection mechanism" here is a backdoor between the driver and the kernel that ensure, in the windows environment, that Microsoft (and whoever produce the driver) control your use of the protected CD. You cannot put a "virtualisation" layer in between the application using this "protection mechanism" such that it no longer has any assurance that the protection mechanism is authentic. In a sense, the protection procedure *can* be circumvented, which means it *has* been.
Yeah this is totally ridiculous, but the DMCA is totally ridiculous. We won't have difficulty finding common ground there. :-)
Remeber, the "chilling effect" is when we let the DMCA control what we do further than what it was meant to do to begin with. I can't see anyone taking you to court saying "look, it's true that with Wine you can't do anything that you can't do without, but it's an unlicensed version, so it's a DMCA violation".
War crime tribunals, environmental protection treaties, privacy legislation, ... the ability to let chilling effects meet little or no significant organised obstacle has become the trademark of a certain breed of "freedom-loving" people. Bruce Schneier once said that the "war on drugs" was the root password to the US constitution. I think they changed the password recently to use "terrorism" instead of "drugs", but it's still much the same dance - ridiculous legislation is ushered in in the name of "protecting rights" when in fact it is invariably used to achieve quite the opposite. The issue is not whether you exercise a personal disobedience to it, because Wine itself certainly can't, but whether something can be done to aid efforts to overturn these laws. In the mean time, (and as long as people in the US are involved in Wine,) we're stuck with them.
Cheers, Geoff
On Thursday 06 November 2003 03:31 pm, Geoff Thorpe wrote:
War crime tribunals, environmental protection treaties, privacy legislation, ... the ability to let chilling effects meet little or no significant organised obstacle has become the trademark of a certain breed of "freedom-loving" people. Bruce Schneier once said that the "war on drugs" was the root password to the US constitution. I think they changed the password recently to use "terrorism" instead of "drugs", but it's still much the same dance - ridiculous legislation is ushered in in the name of "protecting rights" when in fact it is invariably used to achieve quite the opposite. The issue is not whether you exercise a personal disobedience to it, because Wine itself certainly can't, but whether something can be done to aid efforts to overturn these laws. In the mean time, (and as long as people in the US are involved in Wine,) we're stuck with them.
Here here!
It is really unfortunate that wine is another victim of the DMCA, but I'd rather Alexandre played it safe, lest we be made an "example." If some rebellious individuals want to contribute these sorts of patches, as sort of an act of civil disobedience, I suggest they post them to /freenet/. Once the DMCA is eliminated (one can hope...), then A can reconsider.
My argument is that it is not a "Protection Machanisim" as defined by the DMCA.
IANAL but from reading the DMCA information on various places (including the act itself), the folowing is true: 1.an Access Control Measure is something that prevents unauthorized access to a Copyrighted work. 2.Therefore, in order for someone to have "circumvented an access control measure", it means that whatever they have done makes it possible to make and/or use an unauthorized copy of a copy protected work. 3.Therefore, by extention, any tool that is illegal under the DMCA must: A.allow soneone to make and/or use an unauthorized copy of a protected work in a way that is not possible without said tool. or B.be capable of being modified to enable A to happen.
IANAL or a windows-kernel-mode-guru but from my reading of secdrv.sys clone code and also secdrv.sys itself in a disassembly, its sole purpose is to provide access to kernel-mode memory necessary to identify SoftIce (and probobly other similar kernel-mode debugger). And, assuming this is true, no modification, re-write, clone, stub or replacement for secdrv.sys will enable someone to make and/or use an unathorized copy of a protected work in a way that is not possible without said special secdrv.sys. Therefore, the wine secdrv.sys is not a violation.
Therefore, 1 of 3 things is true: 1.my interpretation of the DMCA in the paragraph above is wrong 2.it is correct but my interpretation of what secdrv.sys is wrong (and in fact there is a way to use a modified/re-written/cloned/stubbed in wine/whatever version of secdrv.sys to make and/or use an unauthorized copy of a protected work in a way that is not possible without said version of secdrv.sys) or 3.neither of 1 or 2 is true and therefore the clone of secdrv.sys is not a DMCA violation and can go into the WINE tree.
Feedback from anyone that knows more about either the technical aspects (i.e. just what secdrv.sys actually does) or the legal aspects (i.e. what the DMCA says counts as a tool that circumvents an access control measure) would be good.
Jonathan Wilson wrote:
3.neither of 1 or 2 is true and therefore the clone of secdrv.sys is not a DMCA violation and can go into the WINE tree.
4. Neither 1 nor 2 are true in the strict sense of the word, but wer'e not sure that safedisk's manufacturer will think the same. So the code still cannot go in because we are afraid of being sued.
*sigh*
Like I said, I'm more worried about the cases that are NOT DMCA violations, but people still don't do them for fear of the DMCA (because it "sounds like").
Shachar
On Fri, 7 Nov 2003 05:59, Alexandre Julliard wrote:
The DMCA does not require copyright violation, what is illegal is "circumventing" the protection measure, it doesn't really matter if the replacement code has the same functionality or not.
Decryption is a different matter - that's banned whether it is done for the purpose of providing the same functionality or not. Providing identical functionality to correctly implement other mechanisms not involving decryption is not as much of a problem.
On Thu, 6 Nov 2003 20:00, Shachar Shemesh wrote:
I don't get it. As far as I understand, so long as the code in the Wine archives does not allow running copied discs, we are not violating the DMCA. If someone else takes Wine code and modifies it, that's where the DMCA violation happens.
I briefly checked the area of the US Code covering this last week, and based on my non-thorough reading you are correct, as long as you're not acting in concert with the person who modifies it.
Geoff Thorpe wrote:
[snip]
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.
[snip]
How about interoperability?
See: http://maccentral.macworld.com/news/2003/10/30/lexmarkcase/
"the Copyright Office ruled that the DMCA does not block software developers from using reverse engineering to circumvent digital protection of copyright material if they do so to achieve interoperability with an independently created computer program."
regards, Jakob
-
Alexandre Julliard -
Carlos Lozano -
Geoff Thorpe -
Gregory M. Turner -
Jakob Eriksson -
Jonathan Wilson -
Raphaël Junqueira -
Robert Shearman -
Shachar Shemesh -
Tom -
Troy Rollo -
Zsolt Rizsanyi