wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Macromedia Flash 5.0 ALMOST working (mouse button release bug)
by ivan 10 Feb '02

10 Feb '02

Hi I have run Flash 5 with no problems except for just _one_ annoying issue which is turning it unusable. Once the mouse button is clicked for drawing or placing an item it never gets released (it resizes the item as if you had the mouse button pressed all the time) I would like a lot if this was fixed because Flash is the only app which keeps me using Winblows sometimes. But i can't fix this myself because i don't know enough to do it. The error log which i get when running wine flash.exe is: [ivan@schnell Flash 5]$ wine flash.exe fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (Spanish keyboard layout) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. err:midi:OSS_MidiInit ioctl on midi info for device 0 failed. fixme:ole:CoRegisterMessageFilter stub fixme:ole:CoMarshalInterface Failed to Marshal the interface, 80070057? fixme:ole:_LocalServerThread CoMarshalInterface failed, 80070057! fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:storage:StgCreateDocfile Transacted mode not implemented. fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:mdi:MDIRefreshMenu partially function stub fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:imm:ImmGetContext (0x00020022): stub // the line above happens when i click a tool button fixme:imm:ImmGetContext (0x00020022): stub // the line above happens when i try to draw with that tool // after that i can't do anything else, because the cursor don't gets released // and keeps drawing or resizing Terminated // ctrl+c, the only way to stop it Anyone knows what's happening here? Do you need more info? I will do or test whatever you want to help solve it. TIA

1 0

Richard Stallman
by Brett Glass 10 Feb '02

10 Feb '02

Plato (tom(a)redant.freeserve.co.uk) writes: >Could you give me URLs to one or more of these essays? Last time I looked, they were all on Stallman's gnu.org site, in the "Philosophy" section. Unless, of course, he has expunged them to hide his true intentions. >> Software is "proprietary" if it does not interoperate with other software, >> does not conform to industry standards, and/or uses unique file formats >> or protocols so as to lock users in or deter competition. > >That is not true. In English, `propritetary' is an adjective used to describe >something which is the property of someone. If you were to use this definition, then all of the FSF's software would be "proprietary." (It is interesting that the FSF condemns software "hoarding" and yet has one of the largest hoards of source code in the world.) >In the computing world it is >generally used to describe software which does not allow redistribution and >modification. Not true. This is the way the FSF has attempted to REdefine it, but it is not the correct definition. >Again not true. Commercial software need not be *licensed* for money, it >only need be developed or marketed as a way of business. For something to be commercial, it must be the object of commerce. >Did you read the links I posted? I post them again and suggest you do so >before posting erroneous comments. How can you hope to win an argument when >you do not understand the issues involved? > >http://www.gnu.org/philosophy/words-to-avoid.html#Commercial >http://www.gnu.org/philosophy/software-libre-commercial-viability.html I have studied Stallman's propaganda at great length, and have written essays on the misleading rhetorical techniques it uses. I not only understand the issues involved; I also understand how Stallman has attempted to distort them and mislead programmers into hurting themselves, their profession, and their projects. --Brett

1 0

Re: Time for a Fork (fwd)
by winedev＠admdev.com 10 Feb '02

10 Feb '02

Wouldn't really work... Not only the extra work for Alexandre, but the fact the trees will become totally unsyched. Then there's pollution of code and licensing from one tree to the next.. The problems are too many to count. This is really an all-or-nothing decision. If we loose developers from making a license shift, then so be it... I think its inevitable, but I also think they will slowly start drifting back when they realise that it DOES work and isn't quite the evil they thought :) Regards, | It's always bad news in computing.. and beware | of anything claming to be good news - because | its probably a virus. - Salmon Days Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org] On Sat, 9 Feb 2002, Dan Kegel wrote: > Date: Sat, 09 Feb 2002 17:42:55 -0800 > From: Dan Kegel <dank(a)kegel.com> > To: wine-devel(a)winehq.com > Subject: Time for a Fork > > It seems clear to me that Wine is just like Unix: > some people prefer a BSD license, and others prefer a GPL license. > > BSD can never convince Linux people to switch licenses, and vice versa. > > So be it. > > Rather than endlessly debate the issues, I suggest we simply agree > on an amicable parting of ways. > > The current cvs tree and patch mailing lists would remain as is. > > A new LGPL-licensed tree and associated wine-lgpl-patches mailing list > would be created to accept LGPL-licensed patches. > > This would put an end to a lot of bickering, and would let us > see how the two license agreements work out in practice. > > Comments? > - Dan > > >

3 2

RE: Dr. Seuss, licensing, and WINE
by Patrik Stridvall 10 Feb '02

10 Feb '02

> On 2002.02.09 06:39 Patrik Stridvall wrote: > > > > You might believe me or you might not, as all people > arguing against > > > > me last time. Be that as it may, that discussing is dead and I > > > > will in the future concentrate on "If the LGPL means what you > > > > say it does, we don't want the LGPL". > > > > > > > Actually, IYRC, and IIRC, I pretty much agreed with you > that the LGPL > > > actually WOULD allow one to implement proprietary code simply > > > by releasing > > > small wrapper functions as LGPL code. > > > > Yes, but you was one of the few. Alexandre in particular seemed > > to believe it depended on some strange notation of whether it > > was intentional or. > > > In some ways it is. Many times when entities are violating > some license > or law a decision is partly based on what exactly their > intentions were. > Although I would not like to rely on this and I think > clarifying what and > what is not allowed is better than leaving it up to good intentions. Yes, but in the case of copyright it doesn't really make much sense. For determining the punishment for any infringment, yes. For determining whether something infringes, no. And sure I guess hiding behind fair use is harder if you intent is bad. However does the Joe Hacker in my earlier example that used a propriety library to avoid dual booting and shared it with fellow hobbyists have "intent to infringe"? I claim that every work either violates copyright in and of itself or not at all. Nothing else makes much sense. How can you determine the intent of the author of work, if for example the author is anonymous. Sure if the author or the process of authorship is unknown you really can't claim indepent derivation if you (not the author) distribute the work and if some judge thinks it similar enough with another work to infringe. However that judgement was for obvious reason made by examination of the work in and of itself. > > > Thus TransGaming does not hurt. Lindows really doesn't hurt > > > either, and > > > the users of Lindows win because should they need to > update the LGPL > > > components of Wine they can do so and still continue to link > > > to Lindows > > > binary only components. > > > > Exactly, but they will be able to do that without the LGPL. > > It is in the respective companies intrest to make it so. > > > If that is so, then why aren't they doing it already? 1. Lack of time. 2. Lack of insight what their users might want. 3. Lack of concerned users. I'm sure you can find more reasons. > > > Now you may consider this not enough to stop the less honourable > > > companies. Yeah, you're right. Lindows can continue to > > > build upon wine, > > > add their own stuff, and release a product. The only > > > difference is that > > > now they can't just fold all the wine code into the binary.. > > > they have to > > > allow the user to update the wine code. That is the purpose > > > of the LGPL. > > > Unlike the GPL which tries to make all software free > > > software, the LGPL > > > tries to keep free software as free software, and proprietary > > > software as > > > proprietary software. > > > > Yes. But that is NOT an argument for using LGPL as I have > said above. > > > Sure it is. The LGPL's purpose in life is to make sure the > users of the > program can continue to recompile the code that was LGPL to > begin with. OK. Reformulate. There is no reason to force this to happend, since it is likely to happend eventually anyway. See below. > > > Now let's say we take the stricter interpretation that you > > > cannot do the > > > above. That is bad I think. > > > > > > How about going to LGPL and add a clause that clarifies that > > > the above is > > > in fact allowed? > > > > Why confuse the company lawyer even more? > > > > Even if I would be inclined to agree, I would rather let > the FSF lawyers > > draw up a completely new license lets call it, hmm, MGPL (Middleware > > GPL), > > for use in, hmm, what should I call it, say two-ended > libraries that Wine > > IMHO really is. > > > > This MGPL should clarify that it is legal to "plug-in" proprietary > > application/libraries in both ends while code the middle that is > > the Wine source code should have some copyleft like protection and > > additional that sublicening the code as LGPL is allowed. > > > > Note however I'm not really proposing this but it might be > a reasonable > > compromise. Perhaps something for the LGPL camp to chew on. > > > What you describe sounds to me like what I am describing. A > modified and > clarified LGPL. Essentially when you start adding or > deleting from the > LGPL you are in fact making a new license. You are saying > the same thing > I am. As you wish, this is of no moment. > [SNIP] > [Quote Dennis Miller: Y'know.. I don't want to get off on a > rant here...] > > > > When the voters give any of them support, the problem is that > > > > they didn't really support the extreme views they presented, > > > > but they are forced to do it anyway in order of not being > > > > accussed of betraying the will of the voter. > > > > > > > You can thank the "liberal" media for that one. :-( > > > > Well, that is just the symptom. > > The ignorant masses are the real problem IMHO. > > > > Unfortunately, there is no serious alternative to democracy, > > so I'm a loss what to do. :-( > > > True. Actually, I think the media is more of a symptom of > politicians > catering to them for years now. Well of course they do since that is one of the few way they can reach their voters. It is still the ignorant masses that are the real problem unfortunately. Increased education will only get you so far and it is never any substitute for logical thinking. Of course, the ignorant masses really gets what they deserve. I primarily think it is unfortunate that I live in the same world as them. > Look at the administration > now. They > don't take any shit and just tell it like it is. Bush may not be an > excellent speaker but he seems to say what's on his mind and > doesn't try > to always be the media's bitch like Billy-boy and his wife did. Sometimes the ignorant masses are lucky sometimes they are not. > > Lets return the easy problem of finding of good license for > Wine. :-) > > > Yeah, sorry, just had to get off on a little rant about the media. :-) > > > Especially see MSNBC. What a crock of shit that is.. > > > figures, it being a > > > MS product and all :-). The reporters on that station are > > > just horrible. > > > They ask a question and when they get a totally straight > > > answer that they > > > don't agree with they just ask it again and again changing a > > > few words to > > > make it seem like it's a different question. > > > > Well, people watch the shit, so they get what the deserve. > > > > Unfortunately it hurt us other as well, but then we really can't > > limit their freedom of speech, can we? > > > Yeah, doesn't that suck. Kind of like people use proprietary > software so > they get what they deserve. We can't stop them from using it as that > limits the freedom's of the proprietary software companies > and the users > who want to use that software. However what we can do is > remove the need > to use proprietary software. Wine is a first step towards this. Yes, but I never think the need for proprietary software will disappear. > > > > In the cases of Wine. I hope that the people working with the > > > > Wine project are not among the ignorant masses and thus really > > > > are able to understand the subtle differences between different > > > > positions. > > > > > > > Yeah, so far it only seems like the people who caught > this story on > > > slashdot are among the ignorant masses. :-/ > > > > I wouldn't really call them the ignorant masses but rather the > > I-can-almost-but-not-quite-understand-this masses. Since they > > don't fully understand it they assume that it is something > > bad and post their unordered thoughts in hope that other might > > make something out of it. > > > Yeah, sometimes a little knowledge is far worse than none at > all. Usually > this is only the case when people think that a little > knowledge makes them > an expert and get big-egos. Very true. > > > We should collectively think of the different scenarios and > > > ask one very > > > important question: Do we /really/ want to prevent this > scenario from > > > happening? > > > > Ah, I forgot that very important question. I intend to supply it but > > somehow > > it got lost. But perhaps the question: > > > > 1. Do you consider his or her behavior morally or ethically > defendable? > > > > sums it up pretty well as well. > > > Sounds kind of like my.. do you think it should be allowed question, > although put in a better way. Ah yes, you are right, we probably should ask the opposite question as well: Do you consider it morally or ethically defendable to prevent this behavior? > > > Personally I have warmed up a slight bit to the idea of > > > Lindows. At first > > > I was a bit like.. those dickheads took wine, added a few > > > things, and are > > > gonna sell it for $100/seat and we're not getting any of that > > > or even any > > > improvements back!? That bites. > > > > > > But now I realize that we need to put that emotion aside and > > > look at how > > > exactly lindows harms wine (which it does). > > > > > > The first thing is the issue of binary-only wine that can't > > > be changed and > > > has absolutely no source. That really bites for the user > who is thus > > > locked into Lindows complete package and cannot even change > > > the parts of > > > wine that Lindows has nothing to do with. > > > > If Lindows prevents users from updating their version of Wine > > it is really their and their users problems not our problem. > > > This is simply not true. This is very much Wine's problem. > If I need > some of Lindows's functionality to run my program but would > still like to > be able to hack on other parts of Wine then I, as a developer > and user, am > screwed. So complain with Lindows support or abandon Lindows and use something else or whatever. Eventually they will learn to listen to their customers. > > > If we were LGPL > > > and allowed > > > importing functions from non-LGPL components then Lindows > > > could still add > > > value by implementing APIs in their own DLL or DLLs and > > > loading them from > > > wine. In fact, they don't need to be DLLs. They could just > > > put all their > > > stuff in their own closed source file, compile it, and > > > distribute the .o > > > so that end users (their customers) can later take that .o > > > file plus the > > > LGPLd modifications to wine that make it use the functions in > > > that .o, and > > > link it into a newer version of wine. > > > > I don't see why we should adapt our license to cater for people > > that make bad choices and suffer because of it. Especially > > when such a license might scare other people that might help > > us away. > > > Because people make mad choices every day and don't realize > it. Indeed, but stupidity is its own reward. > We cannot > put our work on the line and say "Well, hopefully no one will > make bad > choices with it". You can never prevent people from doing bad choice with a product: "Design a product even an idiot can use and only an idiot will use it" > > Regardless of any fun you might have had. Ask this question: > > > > Would you have consider it ethically or morally defendable if the > > Wine license had prevented you from using a proprietary ASPI > > library with Wine and distributing the result to your friends. > > > YES! That is my point. I would have done it anyway even if > their was a > proprietary version. And I think it is important that we > allow people to > use and distribute proprietary components with a free software Wine. Agreed. > > > Anyway.. these are just two.. there are more I'm sure.. I > > > really need to > > > go to bed though. > > > > Different time zones. I returned from a late breakfast to > > find your mail. :-) > > > Hmm, well, I suppose about the time I sent it I could've gone > to an early > breakfast since it was like 5am. Well, my father usual gets up at that time. :-) > What was it, like noon or 1 > where you > are? I recieve that mail at 11.20 am. Speaking of time it is now 1.00 am for me. Time for bed as soon as I finish answering this. > > > Before I do so, I would like to point you to the > wxWindows website. > > > > > > According to their short license summary they use LGPL but > > > also allow you > > > to distribute a binary linking with wxWindows included. That > > > exception > > > would not be appropriate for wine (in fact, it's like the > > > main advantage > > > for us to use the LGPL I think). However we could do a > similar style > > > thing and say: "We're LGPL but we specifically allow you to > > > create stub > > > functions in our library that call out to your > proprietary component. > > > > See my suggestion about the "MGPL" instead. > > > This is really the same thing as a clarified LGPL. It's not > necessary to > write from the ground up a new license, but if we need to > take the LGPL > and strike out certain sections and/or add to it then that is > far better > than writing a new license completely from scratch. No, it is not, because we want the license to be very clear on what is allowed and what is not. No patchwork. A clear license with only the absolute minimum number of paragraphs. Remember we want companies working on Wine without having to spend to much money on their lawyers. > > > Hopefully we can get this resolved this time... It's looking > > > promising > > > given the few and far between somewhat clear posts and > > > disregarding the > > > ill-informed wanna-be-on-slashdot shit. > > > > We will see. I'm neither optimistic nor pessimistic for the moment. > > > > > Well, I /hope/ we can get this resolved since we're talking > about the same > things. Your only real concern at this point seems to be > that if we were > to move to LGPL that some companies may not like it because > it's complex. Basicly but I very much fear that even a MGPL would be to complex. > They can pay lawyers to figure it out for them. Why do you > think lawyers > make all the money anyway. Because the money that they can avoid spending on lawyers could be spent on improving Wine instead.

2 1

RE: Dr. Seuss, licensing, and WINE
by Patrik Stridvall 10 Feb '02

10 Feb '02

> > You might believe me or you might not, as all people arguing against > > me last time. Be that as it may, that discussing is dead and I > > will in the future concentrate on "If the LGPL means what you > > say it does, we don't want the LGPL". > > > Actually, IYRC, and IIRC, I pretty much agreed with you that the LGPL > actually WOULD allow one to implement proprietary code simply > by releasing > small wrapper functions as LGPL code. Yes, but you was one of the few. Alexandre in particular seemed to believe it depended on some strange notation of whether it was intentional or. > As in: > > DWORD WINAPI FooMicrosoftApi(CHAR *bar, DWORD baz) > { > return someotherdll_FooMicrosoftApi(bar,baz); > } > > Which would be LGPL, and the someotherdll_FooMicrosoftApi > would be under a > different license. > > With this situation the stated purpose of the LGPL is still > upheld. The > stated purpose is to allow one to continue to update the > parts of the code > that are LGPL while still being able to link with proprietary > components. Exactly. However I see no reason particular reason why even less honourable companies wouldn't release the wrapper code to the us whether they were forced to or not. It is in their intrest to make it easy for Wine to use their library so they can limit the support for clueless users for example. This even if LGPL allowed it, is not a strong argument for LGPL. In this case it would only primarily the confusion on whether this is allowed, for little gain. > Thus TransGaming does not hurt. Lindows really doesn't hurt > either, and > the users of Lindows win because should they need to update the LGPL > components of Wine they can do so and still continue to link > to Lindows > binary only components. Exactly, but they will be able to do that without the LGPL. It is in the respective companies intrest to make it so. > Now you may consider this not enough to stop the less honourable > companies. Yeah, you're right. Lindows can continue to > build upon wine, > add their own stuff, and release a product. The only > difference is that > now they can't just fold all the wine code into the binary.. > they have to > allow the user to update the wine code. That is the purpose > of the LGPL. > Unlike the GPL which tries to make all software free > software, the LGPL > tries to keep free software as free software, and proprietary > software as > proprietary software. Yes. But that is NOT an argument for using LGPL as I have said above. > Now let's say we take the stricter interpretation that you > cannot do the > above. That is bad I think. > > How about going to LGPL and add a clause that clarifies that > the above is > in fact allowed? Why confuse the company lawyer even more? Even if I would be inclined to agree, I would rather let the FSF lawyers draw up a completely new license lets call it, hmm, MGPL (Middleware GPL), for use in, hmm, what should I call it, say two-ended libraries that Wine IMHO really is. This MGPL should clarify that it is legal to "plug-in" proprietary application/libraries in both ends while code the middle that is the Wine source code should have some copyleft like protection and additional that sublicening the code as LGPL is allowed. Note however I'm not really proposing this but it might be a reasonable compromise. Perhaps something for the LGPL camp to chew on. > > > I think it's more of an issue of people thinking too much in > > > black/white > > > terms and people that lean strong towards one side or the other. > > > > Yes. Perhaps they are not nessarily thinking in black and white > > but their arguments are often presented that way. > > > > I'm not entirely blameless on that point either, I will try > > to do better in the future. > > > > > Look no further than the US political system for a good > > > example. You have > > > the Republicans and the Democrats. Generally they take every > > > issue to > > > opposite ends of the extreme such that 99% of congress is at > > > one extreme > > > or the other, but 99% of the population wants neither extreme. > > > > Exactly, but that is because: > > 1. They want votes so they can do that they feel is right. > > 2. The ignorant masses are not likely to understand subtle > > differences in opionion. > > > > When the voters give any of them support, the problem is that > > they didn't really support the extreme views they presented, > > but they are forced to do it anyway in order of not being > > accussed of betraying the will of the voter. > > > You can thank the "liberal" media for that one. :-( Well, that is just the symptom. The ignorant masses are the real problem IMHO. Unfortunately, there is no serious alternative to democracy, so I'm a loss what to do. :-( Lets return the easy problem of finding of good license for Wine. :-) > Especially see MSNBC. What a crock of shit that is.. > figures, it being a > MS product and all :-). The reporters on that station are > just horrible. > They ask a question and when they get a totally straight > answer that they > don't agree with they just ask it again and again changing a > few words to > make it seem like it's a different question. Well, people watch the shit, so they get what the deserve. Unfortunately it hurt us other as well, but then we really can't limit their freedom of speech, can we? > > In the cases of Wine. I hope that the people working with the > > Wine project are not among the ignorant masses and thus really > > are able to understand the subtle differences between different > > positions. > > > Yeah, so far it only seems like the people who caught this story on > slashdot are among the ignorant masses. :-/ I wouldn't really call them the ignorant masses but rather the I-can-almost-but-not-quite-understand-this masses. Since they don't fully understand it they assume that it is something bad and post their unordered thoughts in hope that other might make something out of it. > > > Essentially we could go on forver about X11/BSD vs. GPL. > It's been > > > discussed to death already folks. What we need are reasonable > > > compromises. Of course you need to have people willing to > > > compromise to > > > do that. I suspect most developers are with the exception of > > > the view > > > vocal BSD people and the few vocal LGPL all the way people. > > > I myself am > > > certainly not at either extreme. > > > > Even if perhaps some people won't believe me. I not really > > an extremist. I try to take a pragmatic view of the world. > > > > I believe that GPL has its place, LGPL has it place and the BSD > > license has its place. > > > > However my analysis of the issues at hand makes me believe that > > LGPL would be really bad in the particular case of Wine, for > > reasons that I have tried to explain. > > > Personally I think the LGPL is pretty damn good and fits wine > pretty well > but we simply need to clarify the gray areas about what is and is not > allowed (see above). That is the point we disagree on, at least partly. > > I suggest that people try to think about scenarios of circumstances > > where possible extensions to Wine might be made. This might be > > business models like Transgaming or Lindows.com or just something > > Joe Hacker or Joe Ex-Windows-Shareware-Writer or Joe I'm-Conspiring > > -With-A-Proprietary-Library-Company-But-You-Can't-Prove-It > are doing. > > Just like the examples in the my last mail. > > > > Then ask the questions: > > 1. Do you consider his or her behavior morally or ethically > defendable? > > 2. Does it violate the letter of the LGPL? > > 3. Does it violate the spirit of the LGPL? > > 4. Does it violate the letter of copyright law? > > 5. Does it violate the spirit of copyright law? > > 6. Do you think any reasonable Judge/Jury would find him or > her guilty? > > > > With the spirit of copyright law I roughly mean: > > Is it what congress intended and/or is it constitutional? > > Notice the and/or: > > It is possible for act of congress to be constitutional without > > being the intention of the congress. > > > Hmm.. y'know that's a good idea. At least it something concrete to do instead on arguing back on forth about abtract fears. > We should collectively think of the different scenarios and > ask one very > important question: Do we /really/ want to prevent this scenario from > happening? Ah, I forgot that very important question. I intend to supply it but somehow it got lost. But perhaps the question: 1. Do you consider his or her behavior morally or ethically defendable? sums it up pretty well as well. I can't think about anything except egoistical concerns that could make anybody want to prevent something they thought morally and ethically defendable. > Personally I have warmed up a slight bit to the idea of > Lindows. At first > I was a bit like.. those dickheads took wine, added a few > things, and are > gonna sell it for $100/seat and we're not getting any of that > or even any > improvements back!? That bites. > > But now I realize that we need to put that emotion aside and > look at how > exactly lindows harms wine (which it does). > > The first thing is the issue of binary-only wine that can't > be changed and > has absolutely no source. That really bites for the user who is thus > locked into Lindows complete package and cannot even change > the parts of > wine that Lindows has nothing to do with. If Lindows prevents users from updating their version of Wine it is really their and their users problems not our problem. > If we were LGPL > and allowed > importing functions from non-LGPL components then Lindows > could still add > value by implementing APIs in their own DLL or DLLs and > loading them from > wine. In fact, they don't need to be DLLs. They could just > put all their > stuff in their own closed source file, compile it, and > distribute the .o > so that end users (their customers) can later take that .o > file plus the > LGPLd modifications to wine that make it use the functions in > that .o, and > link it into a newer version of wine. I don't see why we should adapt our license to cater for people that make bad choices and suffer because of it. Especially when such a license might scare other people that might help us away. > Now, the second issue, and the one Alexandre is (or maybe > just was) most > concerned about, was companies implementing functionality > that the real > wine does not have will sometimes reduce the incentive for a > developer to > work on it. That is to say that a good portion of developers > that would > otherwise be contributing to Wine making stuff work will stop > if they can > simply by Lindows for $100 and make that work. Perhaps, but you will have to take the good with the bad and licenses preventing this also prevents other things. Whether LGPL really does this or not is another question though. > Ironically > moving to LGPL > would actually make it easier for a wine developer to use > some lindows > functionality since they could update the rest of Wine. > However, at least > for me part of the reason I like hacking on Wine is to hack > on wine to > have a version that is free software. That is, let's say > there had been a > working closed source ASPI layer then I could've used my CD-R > in Wine and > maybe I wouldn't have fixed a bunch of stuff with ASPI. But > doing that > was a lot of fun and I would have been the one missing out by > falling back > to a lindows implementation and never considering actually > fixing the real > wine implementation. Plus in the meantime at least my CD-R would've > worked so it would have been a less pressing issue and would > have avoided > numerous reboots for me in trying to create a free version. Regardless of any fun you might have had. Ask this question: Would you have consider it ethically or morally defendable if the Wine license had prevented you from using a proprietary ASPI library with Wine and distributing the result to your friends. > Anyway.. these are just two.. there are more I'm sure.. I > really need to > go to bed though. Different time zones. I returned from a late breakfast to find your mail. :-) > Before I do so, I would like to point you to the wxWindows website. > > According to their short license summary they use LGPL but > also allow you > to distribute a binary linking with wxWindows included. That > exception > would not be appropriate for wine (in fact, it's like the > main advantage > for us to use the LGPL I think). However we could do a similar style > thing and say: "We're LGPL but we specifically allow you to > create stub > functions in our library that call out to your proprietary component. See my suggestion about the "MGPL" instead. > Hopefully we can get this resolved this time... It's looking > promising > given the few and far between somewhat clear posts and > disregarding the > ill-informed wanna-be-on-slashdot shit. We will see. I'm neither optimistic nor pessimistic for the moment.

3 3

Re: Dr. Seuss, licensing, and WINE
by Brett Glass 10 Feb '02

10 Feb '02

Plato (tom(a)redant.freeserve.co.uk) writes: >> Give me a break dude. Yes, the FSF wants all software to be free and >> wants to rid the world of commercial software altogether. >[...] > >I think it is worth pointing out the the Free Software Foundation does *not* >want to rid the world of commercial software. > >Stallman has, however, stated that he would like to rid the world of >*proprietary* software. Richard Stallman most certainly does want to rid the world of all commercial software. He says so in many of his essays. One of Stallman's propaganda techniques, alas, has been to refer to commercial software as "proprietary" software. He does this because the word "proprietary" has negative connotations. He hopes to co-opt those connotations so as to convince others to join him in his drive to destroy all commercial software. To set the record straight: Software is "proprietary" if it does not interoperate with other software, does not conform to industry standards, and/or uses unique file formats or protocols so as to lock users in or deter competition. Software is "commercial" (that is, the object of commerce) if it is licensed for money. GPLed software cannot be commercial because it cannot be licensed for money (the GPL prohibits this). You can sell a disc with GPLed software on it, but only the plastic disc is a commercial product -- not the code it contains. --Brett Glass

2 1

Re: Wine license change (fwd)
by winedev＠admdev.com 10 Feb '02

10 Feb '02

(Reposted, as I just realised my Pine roles wern't sending this from the right address :) Regards, | It's always bad news in computing.. and beware | of anything claming to be good news - because | its probably a virus. - Salmon Days Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org] ---------- Forwarded message ---------- Date: Sun, 10 Feb 2002 08:44:52 +0800 (WST) From: "J.Brown (Ender/Amigo)" <ender(a)enderboi.com> To: Brett Glass <brett(a)lariat.org> Cc: wine-devel(a)winehq.com Subject: Re: Wine license change > >John Carmack made an intresting point, he releases ID softwares older > >releases under the GPL. Why? Because after originally releasing an engine > >after a BSD-esque license, a project done some very major work to the > >engine... and then lost it in a harddrive crash. So his -main- reason for > >using the GPL is to prevent work done in the community from being lost. > > He really should take the time to back up his drives. ;-) But, assuming > that he wishes to use this rather unusual backup mechanism, why would the > GPL be any better at this than a BSD-style license? Sorry, let me clarify that point... the major work that was lost was done by a COMMUNITY project, not one of ID's in-house ones. His point is that as the xGPL forces the release of source code with any binaries, so any valuable work like this won't be lost to the community. This has intresting implications for wine too. It's nice to say that Codeweavers/Transgaming/Lindows/etc might feed slice of code 'x' back to Wine at 'i' time in the future. Of course, if said company goes bust (sorry guys, but this IS the post .com era ;), there is a chance that code could be lost for good. - Ender

1 0

RE: Wine, enthusiasts, businesses and the agony of the license
by Patrik Stridvall 09 Feb '02

09 Feb '02

> On Sat, 9 Feb 2002, Patrik Stridvall wrote: > > > I think you will be able convince both the lazy person above > > as well as the bean counter that this will be the best > > long time choice. > > > > > If Wine is LGPL they must release the patch if they want > to reap the > > > benefits of using Wine, and they can release it without > fear of giving > > > away money to someone else. It can even be argued that the > > > LGPL makes Wine > > > an even safer bet, since it guarantees that other companies > > > in this group > > > will chip in, this way Wine will be in even better shape when > > > the first > > > application was a smash hit and they decide to port their > next app! :) > > > > Correct, but this is likely to be true anyway for reasons > given above. > > > > This is what I imagine the LGPL proponents are dreaming > about at night. > > Unfortunately it is a dangerous dream since it total ignores the > > drawbacks with a LGPL:ed Wine. > > > > The drawback would be that it locks out the companies from > group 1 (yes, > you have pointed out technical problems that might render the LGPL > worthless, but I'll leave the bugfixing for now, lets just assume it > actually works). > > My question is, to you and everyone else, how valuable are > this kind of > companies to the Wine community? A relevant question, unfortunately the problem is much more complex that that. Assuming that LGPL really prevents wrapper libraries have very far reaching consequences. I have tried to give example of specific cases like the Joe Hacker hobbist with his proprietary hobby related library and his proprietary Windows application and his wish not to dual boot. I asked whether doing this (or for that matter preventing) this was among other things ethically or morally defendable. You can't just focus on the companies that wish to profit on Wine in some way. But yes, short answer: I believe such companies like Transgaming is valuable for the simply reason that our resources are limited, this allows us to concentrate on improving other parts of Wine. If in the future decide that hey now that we have more developer resources, now let do a really free DirectX, we can do that. Always remember that: He who defends everything, defends nothing. In short a strategic retreat means that we get resources to defend what we have and later take it back as we grow stronger. > Yes, they may make progress fast, maby they are even required > to take Wine > from the allmost but not quite stage to actually reach that > elusive goal > of 99.9% Windows compatibility. > > But at the same time this progress may never make it back to > the community. > And as pointed out by Alexandre, in the worst case scenario > they may halt > or slow down progress in the free version, because there is > no incentive > to implement some missing peice when it already exists and > can be bought > cheaply from company X. Well and as I pointed out. Most people have a Windows license and many Micrsoft DLL work fine under Wine. Yes, I know he thought that to was bad too. But then you can't both have the cake and eat it. The same thing with other proprietary extensions, except perhaps better from Alexandres point of view, since much more people have Windows licenses than a random proprietary library. > The limited experience shows that things has worked out OK. It will be > interesting to see what Lindows ends up doing, I wish they > would skip the > maketdroid speak for a while and join this discussion. Agreed. > > > have the least to gain from contributing anything back. The > > > companies in > > > group 2 have the least incentive to work on Wine, just > fix the bare > > > minimum to get their application to work, but instead > they can allow > > > themselves the luxury to contribute and score some goodwill. > > > > Since companies in group 2 are likely to contribiute back anyway > > for reasons given above I see no reason to hurt group 1 companies. > > > > Yes, each and every one has to go back to his own motivation > for working > on Wine, does it matter if the group 1 companies get a free lunch? Well, all users of Wine already get a free lunch, and they might already profit from being able to run say Microsoft Office under Linux so if you are worried about people getting a free lunch you already have a serious problem.

1 0

Re: Wine license change
by Brett Glass 09 Feb '02

09 Feb '02

Roland (roland(a)netquant.com.br) writes: >To write it again we have two interests: > >1. People who want to make money selling WINE or derivates == anti xGPL >2. People who contribute for free or have another business model than the >above == pro xGPL There are a few more categories who would not want the (L)GPL: 3. Professional programmers who would like to fix bugs (if the code is (L)GPLed, they can't without becoming "tainted" by having read the code); 4. Anyone who objects to viral licenses or the FSF's misleading propaganda; 5. Users who want to be able to buy a commercial product with professional support, especially good integration, and possibly enhanced features; 6. Anyone who does not want to see WINE fork into truly free and FSF-licensed versions; and 7. Anyone who cares, on principle, about software freedom and choice. --Brett Glass

4 4

RE: Wine, enthusiasts, businesses and the agony of the license
by Patrik Stridvall 09 Feb '02

09 Feb '02

> What's lacking in this discussion is some sensible analysis of what a > license need to contain to encourage future contributions to > Wine and to > protect the interests of the contributors. Fearmongering about Wine's > future and paranoid delusions about the GPL license doesn't > bring anything > to the table... Agreed. > Over to category two. Corel's source of income isn't from > improving Wine, > it's from selling their own work, Wine just makes their work > more valuable. > Here it doesn't really matter if Wine is BSD or LGPL > (remember that the > INTENT of the LGPL isn't to infect all and everything). > > A company that chooses this route may have to improve Wine > here and there > to fill in the missing pieces to make their port work, and by > releasing > this patch they will contribute to Wine as a whole. > > Unfortunatley they might not, don't underestimate the power > of laziness. > One other plausible reason is that some bean counter is afraid that > someone else will pick up their work for free and make money out of it > (i.e. Lindows) how'd you explain that to your shareholders? Companies in this group have several choices: 1. Don't use new improvement in the main Wine tree, only resync then a new major version of the application should be released. 2. Maintain a tree by themselves, continually resyncing in order to make even minor version take advantage of new improvements in the new Wine tree. 3. Have some sort of wrapper library that implement all the improvments that they don't what to release, that in turns calls the Wine real corresponding Wine function. Now they can, if the designed it correctly, use new versions of Wine without any problem. 4. Release the code to the Wine project and be able to run with the latest version of Wine without any problem. (1) and (2) are not very attractive. Resyncing the trees are quite time consuming. Especially (2) will not be fun at all. Both requires continously working with Wine. In any case I guess most companies want the Wine adaption to be a ONE TIME cost not a continous one. Likely they want to hire specialists from companies like CodeWeavers. This leaves (3) and (4). If you design (3) wrongly the application will break with newer version of Wine so it is not really a that good choice either. In addition it will require extra work just to be able to hide the improvments. This leaves (4) ie they treat Wine is LGPL even if it isn't. I think you will be able convince both the lazy person above as well as the bean counter that this will be the best long time choice. > If Wine is LGPL they must release the patch if they want to reap the > benefits of using Wine, and they can release it without fear of giving > away money to someone else. It can even be argued that the > LGPL makes Wine > an even safer bet, since it guarantees that other companies > in this group > will chip in, this way Wine will be in even better shape when > the first > application was a smash hit and they decide to port their next app! :) Correct, but this is likely to be true anyway for reasons given above. This is what I imagine the LGPL proponents are dreaming about at night. Unfortunately it is a dangerous dream since it total ignores the drawbacks with a LGPL:ed Wine. > Companies that decide to develop a new app and use Wine as the cross- > platform framework also belongs to this group. Partly, but new applications can avoid using unimplemented functions so they are less likely to contribute anything back. > Back to Wine again, the selfish motive here is to make Wine > better faster. > So if we get the choose between companies in group 1 or 2, who will > contribute the most? Obviously the ones in group 1 will do > the most work, > since their living relies on a perfectly working Wine, > unfortunatley they > have the least to gain from contributing anything back. The > companies in > group 2 have the least incentive to work on Wine, just fix the bare > minimum to get their application to work, but instead they can allow > themselves the luxury to contribute and score some goodwill. Since companies in group 2 are likely to contribiute back anyway for reasons given above I see no reason to hurt group 1 companies. > So what's the conclusion? Either you pick your favourite way of making > business and lobby for a compatible license, or you start > thinking out of > the box and find the perfect balance that let's everyone keep > the cake and > eat it... Well, that would be good. However I'm pretty convinced that a very good solution would be not moving to LGPL. While perhaps not the ultimate solution, I have a gut feeling that no better soltion exists in the real world. > I'll be back tomorrow with more opinions, and my stab at > thinking out of > the box. Your welcome.

2 1

Re: Dr. Seuss, licensing, and WINE
by David Elliott 09 Feb '02

09 Feb '02

On 2002.02.09 05:32 Plato wrote: > On Sat, Feb 09, 2002 at 03:50:09AM -0500, David Elliott wrote: > > On 2002.02.08 15:03 Brett Glass wrote: > > [...] > > >taxes: It will act in its own interest, not yours. The FSF's > > >sole goal is to destroy commercial software developers, and > [...] > > Give me a break dude. Yes, the FSF wants all software to be free and > > wants to rid the world of commercial software altogether. > [...] > > I think it is worth pointing out the the Free Software Foundation does > *not* > want to rid the world of commercial software. > > Stallman has, however, stated that he would like to rid the world of > *proprietary* software. > Whoops, sorry, you are correct about that. However to the person I was replying to commercial==proprietary. Red Hat Linux is a commercial product, but not proprietary (to give an example). Though I think Red Hat does have a few proprietary products they work on. > There is an incredibly important difference. Please do not use the terms > interchangably. See > > http://www.gnu.org/philosophy/words-to-avoid.html#Commercial > http://www.gnu.org/philosophy/software-libre-commercial-viability.html > Been there long ago.. just kinda forgot. -Dave

1 0

RE: Wine, enthusiasts, businesses and the agony of the license
by vinn 09 Feb '02

09 Feb '02

IANAL, yada, yada [nor can my involvement with Wine be considered anything more than minor] Patrik wrote: > Companies in this group have several choices: > 1. Don't use new improvement in the main Wine tree, only resync > then a new major version of the application should be released. > 2. Maintain a tree by themselves, continually resyncing in order > to make even minor version take advantage of new improvements > in the new Wine tree. I just want to throw a couple of ideas out about using an LGPL license. There's a lot of people with a heck of lot more at stake than me, and ultimately they deserve to have their opinions weighed more heavily than mine. Ultimately these ideas stem from the practice of licensing software rather than the theory (which is where this thread was headed). First, the LGPL doesn't really ever give a time frame for modifications to be released back. We can safely assume that it means "in a timely manner", since in practice this is how it works. I think we could collectively agree that a company such as Transgaming could be allowed a grace period in order to submit their modifications back. Whether this is a week or a year can be debated. If for no other reason than to ensure clean code. Now you may argue that a year is too long, but keep in mind that the modifications do have to be released, and if it takes them a year the amount of work required for a resync may impact other operations. Second, the LGPL doesn't state how the modifications have to be released. In practice this is done electronically via patch files or access to a modified tree. But there's no reason why the modifications couldn't be released on handwritten post-it notes available by request only. In this manner there is a non-trivial amount of work required to integrate the changes. ------ Brian Vincent vinn(a)theshell.com

3 2

something to do
by Jason Phillips 09 Feb '02

09 Feb '02

Hello everyone, I'm interested in doing some work on the wine project. There's quite a few bugs in the bug list are any in particular that someone would recommend as a good place to start? I might need to document for my own good also. Any guidelines on what/how that should be so it can be contributed? Jason Phillips

3 2

RE: Wine, enthusiasts, businesses and the agony of the license
by Patrik Stridvall 09 Feb '02

09 Feb '02

> On Sat, Feb 09, 2002 at 11:40:54AM +0100, Fredrik Ohrn wrote: > > Another observation is that companies in group 1 are in > direct competition > > with each other, so they want closed source. If TransGaming > released their > > DirectX work BSD style, Lindows would quickly be there to > appropriate it. > > You miss one case here: Companies in group 1 that also want > to make money > with group 2s business model. They could do that easily and > it would give > them a distinct competitive advantage over the group 2 only > type enterprises. > Result: The group 2 only companies *can't* release their > sources any more > if they want to stay in business. I'm not sure that I follow you. Groups 2 companies (like Corel) have one or more Windows application that are likely to be their primary source of income. How can group 1 (like CodeWeavers and Transgaming) companies compete with that? Sure they can compete other group 1 companies to get contract with the group 2 company. If the application was DirectX based I can imagine that Transgaming are likely to give a better bid. But I don't see how they compete with the group 2 company. And in the example above I'm sure that Gavriel according to his promises will release any non-DirectX related stuff he had to do in order to fulfill the contract and if group 2 company is nice perhaps they might even require him to release some of the DirectX related code.

1 0

RE: Dr. Seuss, licensing, and WINE
by Patrik Stridvall 09 Feb '02

09 Feb '02

> If people don't understand that some people are decent and > contribute back > regardless of whether they are forced to or not, but others > are not and > require a feedback loop to force this behavior, then they > don't understand > how the world works and we're just wasting time. That is not one of the problem, as far as I'm concerned I fully agree that there will be companies that will be, how should I put it, less honourable. There ALWAYS are in ALL markets. As I sidenote I would like to say that I believe that the LGPL for reasons stated in last debate will not be enough to stop less honourable companies from doing less honourable thing. You might believe me or you might not, as all people arguing against me last time. Be that as it may, that discussing is dead and I will in the future concentrate on "If the LGPL means what you say it does, we don't want the LGPL". > I think it's more of an issue of people thinking too much in > black/white > terms and people that lean strong towards one side or the other. Yes. Perhaps they are not nessarily thinking in black and white but their arguments are often presented that way. I'm not entirely blameless on that point either, I will try to do better in the future. > Look no further than the US political system for a good > example. You have > the Republicans and the Democrats. Generally they take every > issue to > opposite ends of the extreme such that 99% of congress is at > one extreme > or the other, but 99% of the population wants neither extreme. Exactly, but that is because: 1. They want votes so they can do that they feel is right. 2. The ignorant masses are not likely to understand subtle differences in opionion. When the voters give any of them support, the problem is that they didn't really support the extreme views they presented, but they are forced to do it anyway in order of not being accussed of betraying the will of the voter. In the cases of Wine. I hope that the people working with the Wine project are not among the ignorant masses and thus really are able to understand the subtle differences between different positions. > Essentially we could go on forver about X11/BSD vs. GPL. It's been > discussed to death already folks. What we need are reasonable > compromises. Of course you need to have people willing to > compromise to > do that. I suspect most developers are with the exception of > the view > vocal BSD people and the few vocal LGPL all the way people. > I myself am > certainly not at either extreme. Even if perhaps some people won't believe me. I not really an extremist. I try to take a pragmatic view of the world. I believe that GPL has its place, LGPL has it place and the BSD license has its place. However my analysis of the issues at hand makes me believe that LGPL would be really bad in the particular case of Wine, for reasons that I have tried to explain. I suggest that people try to think about scenarios of circumstances where possible extensions to Wine might be made. This might be business models like Transgaming or Lindows.com or just something Joe Hacker or Joe Ex-Windows-Shareware-Writer or Joe I'm-Conspiring -With-A-Proprietary-Library-Company-But-You-Can't-Prove-It are doing. Just like the examples in the my last mail. Then ask the questions: 1. Do you consider his or her behavior morally or ethically defendable? 2. Does it violate the letter of the LGPL? 3. Does it violate the spirit of the LGPL? 4. Does it violate the letter of copyright law? 5. Does it violate the spirit of copyright law? 6. Do you think any reasonable Judge/Jury would find him or her guilty? With the spirit of copyright law I roughly mean: Is it what congress intended and/or is it constitutional? Notice the and/or: It is possible for act of congress to be constitutional without being the intention of the congress.

2 1

Re: Dr. Seuss, licensing, and WINE
by Roger Fujii 09 Feb '02

09 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > Jeremy White, the man who posted the request for feedback that spawned > this discussion, the developer who is encouraging the Wine community to > adopt the LGPL, works for a company whose principal software product > (though not their only source of revenue) is a bundled package of a piece > of proprietary glue code and Wine functionality. > > Let me repeat. The person recommending the LGPL to us sells a proprietary > program built on top of Wine as part of the business model for his > company. if you are going to follow this line of reasoning, you have to ask jeremy whether or not the crossover plugin would have been written IN THE FIRST PLACE if wine was LGPLed at the time. I really think that LGPL would have at least *some* impact on the decision, which is why there is opposition - it impacts future contributers. > Now, do the people arguing that the LGPL would destroy all chance for > people to make a profit believe that Jeremy is stupid, or out to get you? I'll agree that the Brett overstated the case by saying "impossible". But it does make it very difficult and the thrust of the argument is sound. Even though I'm not too sure if codeweaver's business model is too sound (no flames please), but the request for LGPL makes sense because an LGPLed wine now would deny future competitors (even if they contribute) the advantage that they had. -r

1 0

Wine License change: Open question to Jeremy White
by Roland 08 Feb '02

08 Feb '02

Quote from Jeremy White: "However, with some recent events I cannot disclose, it is clear to me that the opportunity for Wine to be used in a proprietary product is too tempting and has caused some harm to the Wine project. Based on experience, I feel strongly that the potential for harm is great enough that CodeWeavers needs to take two actions. First, we would like to release all new code we develop under an LGPL style license. Second, I would like to open another call for a license change and thereby strongly add my voice to Alexandre's." Obviously you, Jeremy started this discussion. I don't want to sound curious, but I have the feeling that our discussion will be in vain if we don't know about those "events" you can't disclose. I mean suppose that the list reaches a consensus to stay at the BSD license. This wouldn't make a difference would it? You would simply say, sorry: but I have my reasons which I can't disclose and will start a xGPL fork of WINE now... So I think to consider all interests involved we must obviously first KNOW what they are specifically...otherwise we will just be wasting time without touching the really important points(your specific concerns among others...). Best regards, Roland

2 1

RE: Wine license change
by Patrik Stridvall 08 Feb '02

08 Feb '02

> I think that this message as well as many other bring up some > very good > points as to the needs of licensing within the wine project. > Many other > messages have been clearly in the realm of bsd-gpl feudalism. > I think that trying to find a license to fit the needs of the project > without first having a good understanding of the needs of the > project is a > serious error. Yes, that is what I have tried to say in my reply to Jeramy. We must define what we want to license to protect, but more importantly we must define what the we DON'T want the license to protect. Because "What doesn't the license protect?", more popularly known as "What can we get away with?" is the first question ALL new business models will ask. If the answer of that question is "Not Much" it might be very bad for most business module, but even worse if the answer to the question is "I don't know, it depends on your intent" or "I have no idea, the jury is still out" it will be very bad. >From my discussion with Alexandre last time he seems to believe that whether or it was allowed to implement a few function in some DLL in a LGPL Wine by linking to a proprietary library depended on my intent. I reject this absurd idea most violently. However consider for a moment: What if he is right? This means that with a LGPL:ed Wine: If somebody that had some proprietary library and thought hey with this library it should be quite easy to implement these functions in Wine that prevented these cool application to work. Some programming later... Great it works... Now I call Lindows, Red Hat, SuSE (whomever that distribute Wine) and tell them that I can license this library for $5 per end user to you. Some time later... Great at least some them accepted and the money keeps streaming in. Life is good. Questions: Is his intent bad? Would you sue him for violating the LGPL? If he publish his proprietary library function wrappers under the LGPL. If he didn't? What about the Linux distributor? Under what circumstances would you sue it? Another scenario: Joe Hacker has bought a proprietary library to use with his non Wine related hobby. One day he realizes that the one of his hobby related also proprietary Windows application he dual boots to since it never worked under Wine could be made to work by implementing the missing Wine functions with that library. He does so, it takes a weekend. It works. He puts out the patch to Wine under LGPL on a hobby related website for other that also owns the application and the library. He is happy since dual booting is but a memory. Life is good. Questions: Is his intent bad? Will you sue him? If some months or so later the maker of the protrietary library finds the patch and contacts the Linux distribution like in the case above. Will you sue the him, the proprietary library company or the Linux distribution? All this begs the questions: 1. Isn't it so, that as I claimed that the LGPL really doesn't protected this. 2. Or alternatively, if it really does make what some of the people above do illegal, do we REALLY want to use it? > It's pretty obvious that neither the a gpl > license nor a bsd > license are optimal. It only take the observation of the lack > on consensus > to see it. Quite. > All that I can really offer is this suggestion: end feuding > and start a > process to > 1. Gather the requirements to the licensing of the wine project > 2. Determine if any combination of existing licenses can meet the > requirements > 3. If no combination of existing licenses will suffice, write > a license > that does. Fully agree. > Additionally, I advise that everyone abandon there preconceptions of > licensing. There is no mandate that I know of to license the > whole project > under the same license, only use one license for any part of > the project, > only use existing licenses, license any part of the project > to different > groups under the same license. Quite true. However, take care with viral licenses, they might spill over to the other parts all the same.

1 0

Licensing
by Joe Tennies 08 Feb '02

08 Feb '02

I have personally always been a huge fan of the BSD license. It has always seemed to me to be more about standards. I know you guys are angered about TransGaming making their WineX version, but get over it. TransGaming is more than willing to place code back into the community. They are just making sure they can cover their own asses too. With the current state of open-sourced companies and internet companies in general, I think they have a decent plan. Also, switching to the LGPL will not make it impossible for TransGaming to make WineX. This has been discussed on the SDL list lately. All you need to do to make a closed source version of a LGPL library is have the LGPL library make calls into a closed source library. The theory behind the LGPL is fairly simple. Make sure that the LGPLed library can be recompiled if one of its dependancies either stops being made or changes dramatically. Basically, it's there to make sure things link 5 years from now. This will probably be my last message to this list as I am dropping it and going to the Mono project. Have fun!

1 0

Re: Wine license change
by g.russell＠ieee.org 08 Feb '02

08 Feb '02

I think that this message as well as many other bring up some very good points as to the needs of licensing within the wine project. Many other messages have been clearly in the realm of bsd-gpl feudalism. I think that trying to find a license to fit the needs of the project without first having a good understanding of the needs of the project is a serious error. It's pretty obvious that neither the a gpl license nor a bsd license are optimal. It only take the observation of the lack on consensus to see it. All that I can really offer is this suggestion: end feuding and start a process to 1. Gather the requirements to the licensing of the wine project 2. Determine if any combination of existing licenses can meet the requirements 3. If no combination of existing licenses will suffice, write a license that does. Additionally, I advise that everyone abandon there preconceptions of licensing. There is no mandate that I know of to license the whole project under the same license, only use one license for any part of the project, only use existing licenses, license any part of the project to different groups under the same license. Thanks for you ear - Gabriel Russell g.russell(a)ieee.org >Look at the copy protection stuff that transgaming have added to their >tree: they licensed it and thus quite likely can't publish the source >for this - but I still want to see this in the binary only releases >they make :-) Other scenarios I can imagine: drivers for hardware - >think of a company that wants to port their software to Linux via wine >but continue using a dongle or something like that: the dongle code >is quite likely to go into the kernel itself (and may need some support >for that by the wineserver). > Ciao > Jörg

2 1

Undocumented functions: a digest
by Jeremy White 08 Feb '02

08 Feb '02

Thanks to everyone who sent me examples of undocumented information; I have passed that along; I think it will be very helpful. I was hoping to edit it, and make it a bit more definitive, but I seem to have run out of time. So, I thought I'd just post the raw replies here so it didn't vanish into the bit bucket. Cheers, Jeremy

1 0

RE: Dr. Seuss, licensing, and WINE
by Medland, Bill 08 Feb '02

08 Feb '02

> -----Original Message----- > From: Dimitrie O. Paun [mailto:dimi@cs.toronto.edu] > Sent: Friday, February 08, 2002 6:35 AM > To: Brett Glass > Cc: wine-devel(a)winehq.com > Subject: Re: Dr. Seuss, licensing, and WINE > > > On Thu, 7 Feb 2002, Brett Glass wrote: > > > --Brett Glass (Who hasn't happened to contribute to WINE > yet, but may do so if > > it remains open source) > > Could you have finished wiht a more dumb line? LGPL _is_ open > source my > friend, go read about it first. > > I don't know about other people, but I'm so tired of these > arguments where > LGPL is 'fascist', 'proprietary', 'not open source', etc. > Once again, we > don't discuss what is important, but we keep arguing about mostly > irrelevant things, just like last time... :( Especially as the OP seems to be in favour of contributing to an "open source" set of code that is used for the basis of a "commercial closed source" product. Bill

1 0

License change: patenting for one year?
by Roland 08 Feb '02

08 Feb '02

Hello, someone here already had the idea of making a patenting scheme. Maybe this would be a good idea. A company can take the code, improve it and doesn't have to give modifications back until one year has passed. That would give them a competitive edge. Users would pay that company to be able to use always the newest versions. After one year, the code has to be contributed and is placed under the xGPL. The disadvantage of this would be that it would slow down the WINE progress or lead to code duplication. Free developers who don't want to wait a year would start duplicating the code that the company already has but doesn't want to give back yet... Maybe it would really be a good idea to open a web-site with a forum for this discussion, or how about another mailing list? I think the problem with this discussion is that we seem to have at least 2 distinctive groups: 1. People who want to make money selling WINE or derivatives == Anti xGPL 2. People who have no financial interest(individual developers) or companies who have another business model than the above == Pro xGPL Of course there are also people from group 2 that are against the xGPL for one reason or another. Ok, how do we solve this conflict? Maybe there is no solution other than splitting up WINE? That means we would have two code bases corresponding to the two conflicting interest groups. I think that the xGPL group will win on the long run because group one would consist of many people who have only a limited interest in sharing back! That means that the codebase wouldn't evolve much over the long run, and we would have more companies like Lindows who simply build their own version of WINE and improve it, without giving back. Of course there probably will be a group of people involved like on FreeBSD but I wonder if the xGPL group wouldn't have more members.... The problem with the actual license is that it has created exactly this kind of situation: Companies don't share back at all or only if certain requirements(incoming profit) have been fulfilled. This effectively created a situation that is similar to the proposed patenting scheme. So basically I see two options A. We make that patenting scheme official, which basically would correspond to the way things are NOW. B. We split WINE in two projects. B is my current prediction of what will happen. In fact CodeWeavers has already announced that this will happen(they will base their code on xGPL no matter what), so it is very obvious. The only alternative is if someone finds an ingenious solution but I doubt it is possible since the involved interests are so antagonistic. We simply cannot sit in the same boat if one group wants to go north, the other south. Roland

2 1

Re: Wine license change
by Roger Fujii 08 Feb '02

08 Feb '02

Marcus Meissner <marcus(a)jet.franken.de> wrote: > Hi, hello.... > On Thu, Feb 07, 2002 at 05:45:36PM -0500, Roger Fujii wrote: > > If you are using marketing speak for "contribute". GPL requires 1) > > for you to show your work 2) You effectively license your software to > > the FSF. It doesn't say it has to be in any useful form to be worked > > back into the originating project (if any). > License is not equal Copyright. > You don't automatically sign away your Copyright when switching to the GPL. ??? but I didn't mention copyright. I used the word "license" for this very reason. The copyright holder can later change the licensing policies (though the FSF says this is "ethically tainted"). But there still can be a *GPLed copy after the change.... > > Freedom means allowing people to do things, even things that you don't > > agree with. BSD = Free. GPL is not. Call a spade a spade.... > > Quoting: > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do ^^^^^^^^^^^^^^^^^^^^^^^^ > these things. I didn't mention cost for the same reason. It seems like a trivial academic exercise to show that something that has LESS restrictions is more "free" than something with more. Hence it is riduculous to say GPL is more "free" than X11/BSD (which is why I wrote that to begin with). Just because something claims it's 'free' doesn't mean it is, just as the "Democractic People's Republic or Korea" isn't democratic by most people's definition of democracy. GPLed programs are certainly infinitely more "free" than propriatary ones, but then, propriatory programs don't try to claim that they're "free" either. > The problem is not other people doing things with my stuff, the problem > is restricting ME as a developer. but that is PRECISELY the issue here, unless you consider someone not contributing is a restriction on a developer. The *GPL clearly restricts how something can be distributed: "rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program" The topic was opened again because there are concerns about how other people are using the source code. Yes, this is a problem, but the tendency is for *GPL advocates to claim that there will be no negative impact which is not the case. -r

2 1

more on wineconf 2002
by Michael Robertson 08 Feb '02

08 Feb '02

I've fielded a few questions from people who are interested in wineconf 2002. http://net2.com/lindows/hotels.htm For a list of hotels. The best on the cheap/close scale would probably probably be Homestead which are really nice suites (have a little kitchen I believe). Sorry about the short notice (by Feb 14th). That's of course not the cutoff to attend, but just the cutoff for those of you to attend that want Lindows.com to pick up the airfare. We don't intend on advertising it to the general public so we keep a high caliber of attendee. The only place the notification has gone is wine-devel list. We currently have about 15 people signed up. Alexandre told me to tell you he's coming if that will help get more people here. Please continue to send in your ideas about topics and speakers. This will help make the conference as informative and rewarding as possible. We'll also have a fun event planned for one of the evenings on Lindows.com so we'll try to make it a good social event as well as technical. -- MR Lindows.com michael(a)lindows.com 858-410-5941 Bring choice to computers: Become a Lindows.com Insider http://www.lindows.com/signup

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel