According to Slashdot, Microsoft has released the Windows CE source code under one of their "shared source" licenses. Needless to say, it would be an *extremely* bad idea for anyone associated with the Wine project to look at it.
This leads me to wonder if anyone's ever thought of taking steps to protect Wine from "contamination" by Microsoft IP (legally, not tech- nically :-). As the number of programmers who have been exposed to MS source code grows the chances of this happening will increase. I believe that the FSF uses some type of form/statement before they will accept code, and it seems like the nature of this project would make it particularly beneficial.
Ian Pilcher wrote:
According to Slashdot, Microsoft has released the Windows CE source code under one of their "shared source" licenses. Needless to say, it would be an *extremely* bad idea for anyone associated with the Wine project to look at it.
While I agree that it is probably not a great idea to look at the CE code at this point, Microsoft's 'Shared Source' license is *very* interesting in a number of respects. First and foremost, the license is by far the most simple and straightforward software copyright license that I have ever seen. There is barely a hint of legalese about it.
As such, it appears to me that there may be some interesting ways in which the license can be exploited to benefit Wine. 8-)
Note that I'm not suggesting that anyone go out and do this without spending a fair bit of time (and money, unfortunately) with a lawyer. Certainly, no one at TransGaming is going to be downloading or looking at those sources.
So - on to some analysis of the license. Everything below is based only on my own personal understanding of the legal issues involved, nothing more.
This License governs use of the accompanying Software.
Well, first off, copyright law generally governs copying, not use. Attempts to overreach the provisions of copyright law through additional clauses in shrink-wrap/click-wrap and other contracts have been turned aside in some court cases. In the US, federal copyright law trumps state contract law, from what I've read. Thus, the license starts off on shaky ground.
You can use this Software for any non-commercial purpose, including distributing derivatives. Running your business operations would not be considered non-commercial.
Again, the use issue rears its head. Another interesting question here is the one of derivatives. It is possible that knowledge gained by study of the source code, which is then applied to Wine, would not in and of itself cause Wine to become a 'derived' work, assuming that no actual source code was used. It is a somewhat grey area that I don't know very well, but it may be worth investigating.
For commercial purposes, you can reference this software solely to assist in developing and testing your own software and hardware for the Windows CE platform.
Here again, we have the usage issue, as well as the platform-restrictive clause for commercial users. The platform restrictions may constitute anti-competitive 'copyright misuse', and thus be unenforceable. The language used here is also interesting - they say 'reference', rather than 'use'. I suspect that they are trying to explicitly restrict efforts like Wine from even studying their code - an apparent violation of 'fair use' provisions of copyright law.
The rest of the license is pretty straightforward with nothing that's too objectionable that I can see immediately. I won't bother going through it in detail.
That said, nothing I can see appears to restrict someone who has accepted their license from answering explicit questions we might have, so long as they are not doing so for hire (thus 'commercially'), and so long as they don't distribute source code. A fair bit of useful knowledge might be gained in that way, albeit slowly.
Anyhow, a useful link for anyone interested in more background on some of the legal issues is: http://www.richmond.edu/~jolt/v1i1/liberman.html
Take care, -Gav
Gavriel State wrote:
Well, first off, copyright law generally governs copying, not use. Attempts to overreach the provisions of copyright law through additional clauses in shrink-wrap/click-wrap and other contracts have been turned aside in some court cases. In the US, federal copyright law trumps state contract law, from what I've read. Thus, the license starts off on shaky ground.
As you point out below, contract law is also involved. Add the DMCA, UCITA, and Bush 2.0 to the mix, and any lawyer who says he actually knows what's legal is lying.
Again, the use issue rears its head. Another interesting question here is the one of derivatives. It is possible that knowledge gained by study of the source code, which is then applied to Wine, would not in and of itself cause Wine to become a 'derived' work, assuming that no actual source code was used. It is a somewhat grey area that I don't know very well, but it may be worth investigating.
There'a a legal doctrine whose name I can remember (I'm too young for senior moments!) ... "inevitable contamination" or something like that. The basic idea is that someone who had been exposed to Microsoft source code and then worked on Wine within a given period of time would be assumed to have used knowledge gained from that exposure. I believe that the burden would be on that person or the Wine project to show the opposite.
This is what I'm really worried about. Some well-meaning hacker takes "Advanced Operating System Theory" at a Microsoft-beholden university and then makes a contribution to Wine. (The more I think about it, I'm surprised Microsoft isn't trying harder to expose more people to their code and license.)
Here again, we have the usage issue, as well as the platform-restrictive clause for commercial users. The platform restrictions may constitute anti-competitive 'copyright misuse', and thus be unenforceable. The language used here is also interesting - they say 'reference', rather than 'use'. I suspect that they are trying to explicitly restrict efforts like Wine from even studying their code - an apparent violation of 'fair use' provisions of copyright law.
Fair use? We don't need stinking fair use! After all, that might interfere with corporate earnings reports. (I'm too old to become a communist!)
That said, nothing I can see appears to restrict someone who has accepted their license from answering explicit questions we might have, so long as they are not doing so for hire (thus 'commercially'), and so long as they don't distribute source code. A fair bit of useful knowledge might be gained in that way, albeit slowly.
Now you're really scaring me!
Anyhow, a useful link for anyone interested in more background on some of the legal issues is: http://www.richmond.edu/~jolt/v1i1/liberman.html
Good link, but dated. UCITA explicitly legitimizes most of the shrink- wrap and click-wrap license provisions that courts have previously found unenforceable. It'll be interesting to see if it dies a well deserved death, gains momentum, or (most likely) rears its hydra-like head in a different disguise a year or two down the road.
IANAL, but I think that this is worth discussing. Thaks for the thoughtful response! (Anyone on this list know a good IP lawyer who's had an attack of conscience and wants to do some pro bono work?)
On Sat, 21 Jul 2001, Ian Pilcher wrote:
This leads me to wonder if anyone's ever thought of taking steps to protect Wine from "contamination" by Microsoft IP (legally, not tech- nically :-).
What can we do about that? Since none of the people involved is going to have a look at the actual M$ source, how are we supposed to know if a patch posted on the list is taken from them?
Worse yet: If we coincidentally use similar code to theirs, how can we prove we haven't looked at their code? If I were paranoid, I'd say the single purpose of releasing the source was to get wine in trouble.
I believe that the FSF uses some type of form/statement before they will accept code, and it seems like the nature of this project would make it particularly beneficial.
That won't do much good, because e-mailed statements/forms aren't legally binding. #include <fix-the-law.h>
LLAP bero
Bernhard Rosenkraenzer wrote:
What can we do about that? Since none of the people involved is going to have a look at the actual M$ source, how are we supposed to know if a patch posted on the list is taken from them?
Well, asking is a good start. I'm more concerned about a well meaning person doing something without realizing the consequences that I am about deliberate malfeasance. So making people think is the first step.
Worse yet: If we coincidentally use similar code to theirs, how can we prove we haven't looked at their code? If I were paranoid, I'd say the single purpose of releasing the source was to get wine in trouble.
It's not paranoia when they really are out to get you!
IANAL, but distribution has been limited enough to this point that they would probably have to show some plausible manner in which the exposure could have occured. That's why I think wider distribution increases the vigilance required.
That won't do much good, because e-mailed statements/forms aren't legally binding. #include <fix-the-law.h>
Snail mail?
Ian Pilcher ian.pilcher@home.com wrote in article 3B59F1DE.5010904@home.com...
According to Slashdot, Microsoft has released the Windows CE source code under one of their "shared source" licenses. Needless to say, it would be an *extremely* bad idea for anyone associated with the Wine project to look at it.
I must admit that as a newcomer to the Wine project I would appreciate a little guidance on what are and are not valid methods for investigating Windows sufficiently to work on the Wine project. This cuts two ways: 1. What methods are accepted as legal for obtaining information and what methods must not be used (in order to protect Wine) 2. What methods are especially effective and what methods are a waste of time (in order to improve the learning curve for contributors)
Should there be a section in the Wine Development HQ
(Or is it already there and I missed it).
Bill
On Mon, Jul 23, 2001 at 02:39:02PM +0000, Bill Medland wrote:
I must admit that as a newcomer to the Wine project I would appreciate a little guidance on what are and are not valid methods for investigating Windows sufficiently to work on the Wine project. This cuts two ways:
- What methods are accepted as legal for obtaining information and what
methods must not be used (in order to protect Wine) 2. What methods are especially effective and what methods are a waste of time (in order to improve the learning curve for contributors)
Should there be a section in the Wine Development HQ
(Or is it already there and I missed it).
Bill
I want to know too.
Maciek
-
Bernhard Rosenkraenzer -
Bill Medland -
Gavriel State -
Ian Pilcher -
kenon＠go2.pl