I wouldn't worry about anyone but Microsoft stealing Wine. In order to develop Wine you must be an expert C++ programmer. That requires an enormous amount of work and thieves are usually lazy.
A new teacher came to the master. "I have developed some new techniques that make teaching much better." "How can I prevent other teachers from stealing them?" "Your worry is needless", replied the master. "If your techniques are any good you will have to force others to use them." With that the master threw an eraser at him.
The same can be said about Wine and Microsoft.
Hi,
On Mon, May 09, 2005 at 07:19:31AM -0400, gslink wrote:
I wouldn't worry about anyone but Microsoft stealing Wine. In order to develop Wine you must be an expert C++ programmer. That requires an enormous amount of work and thieves are usually lazy.
Maybe you wouldn't worry, but I'd bet a sizeable number of Wine programmers sure as hell do.
Wine has become a very useful and big piece of software, and the bigger and more successful a software becomes, the more likely it gets misappropriated (i.e. making use of its code without giving back improvements).
We've already had some corner cases (I won't mention names here, but many people probably know it anyway), and you could bet that Wine would have found relatively widespread abusive use if there hadn't been an LGPL change.
And the fact that "thieves are usually lazy" is the very reason why people add foreign (debugged and working) code to their program... Adapting is often much easier than writing from scratch on your own.
Andreas Mohr
Andreas Mohr wrote:
Hi,
On Mon, May 09, 2005 at 07:19:31AM -0400, gslink wrote:
I wouldn't worry about anyone but Microsoft stealing Wine. In order to develop Wine you must be an expert C++ programmer. That requires an enormous amount of work and thieves are usually lazy.
Maybe you wouldn't worry, but I'd bet a sizeable number of Wine programmers sure as hell do.
Wine has become a very useful and big piece of software, and the bigger and more successful a software becomes, the more likely it gets misappropriated (i.e. making use of its code without giving back improvements).
We've already had some corner cases (I won't mention names here, but many people probably know it anyway), and you could bet that Wine would have found relatively widespread abusive use if there hadn't been an LGPL change.
And the fact that "thieves are usually lazy" is the very reason why people add foreign (debugged and working) code to their program... Adapting is often much easier than writing from scratch on your own.
Andreas Mohr
All that you say is quite true but I still think that the main enemy of Wine is Microsoft. Microsoft will eventually attempt to destroy Wine because only they are threatened by it. There was an LGPL change true but did that change stop anyone from stealing Wine? I seriously doubt it because what would happen if someone stole the library? Wine would need to hunt up some rather obscure program and prove from the binary that Wine code was stolen. This sort of thing is unlikely to happen because it requires too much education and work on the part of the thief. If you don't believe me try including Wine or the library in another program and getting the result to work correctly. You will have to figure out what the Wine code is doing first and that is hard work. Besides, there is no reasonable way to keep Wine from being incorporated in another product as long as the license is followed and who would want to. If others believe theft to be a problem then I suggest looking at and DEALING with the recording industry. The startup recording artist has the same problems as Wine and the recording industry banded together to be a very effective counter. They and the film industry are the only ones who might be able to counter Microsoft. Wine would be well advised not to leave Microsoft out of their calculations because my biggest fear is still a suit charging Wine with stealing all the code and the idea from Microsoft. In such a case merit has nothing to do with it.
gslink schreef:
All that you say is quite true but I still think that the main enemy of Wine is Microsoft. Microsoft will eventually attempt to destroy Wine because only they are threatened by it. There was an LGPL change true but did that change stop anyone from stealing Wine? I seriously doubt it because what would happen if someone stole the library? Wine would need to hunt up some rather obscure program and prove from the binary that Wine code was stolen. This sort of thing is unlikely to happen because it requires too much education and work on the part of the thief. If you don't believe me try including Wine or the library in another program and getting the result to work correctly. You will have to figure out what the Wine code is doing first and that is hard work. Besides, there is no reasonable way to keep Wine from being incorporated in another product as long as the license is followed and who would want to. If others believe theft to be a problem then I suggest looking at and DEALING with the recording industry. The startup recording artist has the same problems as Wine and the recording industry banded together to be a very effective counter. They and the film industry are the only ones who might be able to counter Microsoft. Wine would be well advised not to leave Microsoft out of their calculations because my biggest fear is still a suit charging Wine with stealing all the code and the idea from Microsoft. In such a case merit has nothing to do with it.
If this is your belief, and we accept it as fact for the purposes of this discussion, then two things are implied.
1) You're right; any listing of commercial supporters at this time is an error, because you are then making such companies a target for possible Microsoft coercion-- which is not a nice thing to do to your friends, and many of the entities that potentially might contribute are not necessarily prepared to stand up to MS coercion;
2) Wine is on the radar now, and must find a way to interact with others like a "player" (which also means a "target", obviously). How can this project protect its friends (or itself) from such threats? Somebody on this list previously said that the project can't even give an "official" receipt to contributors for tax purposes.
If the project intends to enter the "commercial" realm visibly by soliciting/publishing donations in an organized fashion from corporate entities that need such documentation, there must be some kind of infrastructure that interacts with the "commercial" world as it exists now, both in its good points (the paperwork) and bad points (the threats).
What, for example, is the project's assurance that any sponsor-submitted code will not trigger the very lawsuit you're afraid of? If it did, what would the liability of the other sponsors be? If the "bad code" was related to another sponsor's code in some way, but the second sponsor was not otherwise 'affiliated' with the project (the bad code gave them an idea, they wrote something based on it and sent it in, then disappeared)? If they had submitted code unrelated to the "bad" code, but after the actionable code had been integrated into the project as a whole? Would this second sponsor be liable or not? Somebody would have to be dedicated to check submitted code thorougly for such problems, or somebody would have to draw up some kind of liability limitation statement for code submissions. IANAL (obviously, I'm sure), but this is the kind of thing that occurs to me with even my limited knowledge. It certainly would require (human) resources that the project may well have available, but unactivated.
Basically, if the project is "big" enough (in terms of code success) to be such a threat as you describe to Microsoft, then the project is likely also "big enough" (in terms of having friends with useful capacities-- financial, legal, or other) to protect itself from them to greater or lesser degree. What seems really to be a danger is the "sucker punch"-- a forceful strike at an unaware or unprepared victim. Naturally, the possibility of such increases the longer one continues to behave as if one is completely safe and unnoticeable, in defiance of an apparently increasingly threatening reality, which seems to be what you're warning of.
I admit that I don't know what kind of entity could encompass the project's current nature and also have the kind of clout necessary to repel the kind of threats you're concerned about.
But it certainly sounds like a team should be dedicated to finding out before the project comes yet further "out of the closet".
Holly
-
Andreas Mohr -
gslink -
Holly Bostick