wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 17 Dec '01

17 Dec '01

> > But you cannot change the license once it is mostly > complete; by then > > it will be too late. > > If it was mostly complete, what would it be too late for? Yes, I wonder that as well. To late for a 100% open source world perhaps, but then only the most naive (like Richard Stallman) actually think it is realistic. Open source is good for some things, but it is not the solutions to all problems. > Patrik Stridvall <ps(a)leissner.se> wrote: > > > Why would you want to change the license when it is mostly complete? > > > > There will be very little reason for companies to enter the market > > at that time and why try to make it difficult for the few > that might. > > I was using the following lines of thinking: If it were > mostly complete, > any changes would most likely be the result of bug fixes or > minor improvements. Exactly and therefore there would be very hard to find a niche for a company to profit in. > In the end, if you look at the larger projects (mozilla, > openoffice, perl), you will > see that any of them uses a straight *gpl scheme. My You mean _neither_ of them, I guess. > suggestion is that if you are > going to change it, change it to something like a currently > existing project that > has commericial involvement (mozilla/openoffice). And the advantage of this would be the following?

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 17 Dec '01

17 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So you mean that all the people that are current voluntering > > to work of Wine won't work on Wine if it is almost complete > > just because somebody else have done the parts they need > > to run their applications and that they will happily pay for > > the right to use it. > > No, I'm not saying they won't work on it when it's almost complete. > I'm saying that there may not be enough incentive to complete it if > all the parts are available under more or less proprietary > licenses. Maybe I'm wrong, but your reasoning that it's OK for people > who want games to have to pay for it certainly doesn't reassure me. What I meant is that for people that play games might it might make more sense to pay a monthly fee since most of them, I guess, lack the knowledge to contribute to Wine anyway. Companies wishing to use Winelib to port their productivity application are not in the same situation, they have the resources pay somebody to improve what they need or perhaps even do it themselves. Sure they can also choose to pay companies with business models like Transgaming but then they become dependent on them to fix bugs in the extra parts they supply. Actually, this is analogous to normal argument for using open source instead of proprietary software, nothing that is unique to Wine. In short: The incentive is the same as working on any open source software. Sometimes is makes sense, sometimes is doesn't. > > In that case it would be disasterous to make Wine run > > all Microsoft implemented non-core Wine DLL:s because > > then everybody would just be happy to use the Microsoft > > DLL:s and nothing beyond non-core would ever be > > implemented. > > It would not be a disaster, but it is certainly a potential problem > too. It is a smaller problem first because making the dlls run is > about as much work as reimplementing them, and because they are > completely proprietary, not half-way open source. But yes, I do think > a number of features could have improved faster if people didn't use > native dlls to work around the problems. There is a distinct possibillity that people used the time they didn't need to reimplement the working Microsoft implemented functions to implement functions that didn't work so it is quite hard to provide hard proof on this. Furthermore the fact that a lot of the Microsoft implement functions works might instead have encourage people to work on because SOMETHING work instead of giving up then NOTHING worked. In any case I think neither of us will be able prove the correctness of our respective theory.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 17 Dec '01

17 Dec '01

> > > and if it does happen, will we find enough people to do what > > > XFree86 has been doing for X11? Maybe, and maybe not. When I hear > > > people like Patrik saying that it's OK for parts of Wine to become > > > proprietary because we can't do everything anyway, I'm worried. > > > > If wine was even CLOSE to being complete, I would agree with you. > > But you cannot change the license once it is mostly complete; by then > it will be too late. Why would you want to change the license when it is mostly complete? There will be very little reason for companies to enter the market at that time and why try to make it difficult for the few that might.

2 1

win32eviceIoControl problem
by Ancient Computers 17 Dec '01

17 Dec '01

When trying to run a game called Visual Pinball, I get this as console output. The DecodeHash problem can be fixed by using a windows version of advapi. What about the win32eviceIoControl problem, what is it about ? [root@localhost Visual Pinball]# [root@localhost Visual Pinball]# wine Vpinball.exe x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403b58f8,00010022,2):stub fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x403b5d64)->(00000000,00001008) fixme:commdlg:GetFileName95 Flags 0x00000002 not yet implemented fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device VNETBIOS fixme:win32eviceIoControl Unimplemented control 256 for VxD device NWLINK fixme:advapi:CryptAcquireContextA (0x405b5c30, (null), (null), 1, f0000008): stub! fixme:advapi:CryptCreateHash (0x405b5c34, 0x8001, 0x0, 00000000, 0x405b5c58): stub! fixme:advapi:CryptHashData (0x10010, 0x49ab80, 14, 00000000): stub! fixme:advapi:CryptHashData (0x10010, 0x405b5c5c, 4, 00000000): stub! fixme:advapi:CryptHashData (0x10010, 0x405b583c, 4, 00000000): stub! fixme:advapi:CryptHashData (0x10010, 0x41615710, 4, 00000000): stub! _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 17 Dec '01

17 Dec '01

> While I am thinking about this, there are some interesting > things in the > LGPL. One of these is that you can modify the LGPL library > to work with > your code. The catch is that you have to release source to the > modifications and that the modifications must not require that your > proprietary component be included. The text of the license > mentions that > if you modify a function that computes square roots to hook into your > proprietary components that the function must still compute > square roots. > But in Wine's case, many functions don't do what they are > supposed to do, > or they do what they are supposed to do but that's not what > actually needs > to be done. That is a very intresting point. Thank you for bring it to my attention. I didn't realize that. Hmm. I will have to think about it what this means, if it indeed means something. > This stuck out like a sore thumb to me, but > maybe it's not > such a big deal. Can you perhaps say exactly what bothered you?

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 17 Dec '01

17 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > > No, of course the LGPL doesn't provide absolute > protection; nothing > > > does, and I don't think absolute protection is desirable > either. There > > > are some things that the LGPL clearly allows, some that it clearly > > > forbids, and a number of border cases, that frankly are only > > > interesting to people who want to try to get around the license > > > restrictions. And what would be the point of doing that? > > > > Making their business model work. > > Trying to ensure investment return. > > That would be the case if the code they are using magically turned > LGPL once they had invested millions. But that's not possible, since > only new code becomes LGPL. Indeed and that makes any protection LGPL gives even weaker. My earlier analysis was based a 100% LGPL:ed Wine... > Now, if someone is basing his business > model on turning LGPL code proprietary by exploiting possible > loopholes in the license, I wouldn't suggest investing in his > company... I don't think our goal in choosing a license is to make > sure every flawed business model can succeed. There are lots of > reasonable business models that can be built on a LGPL (or GPL) code > base. Lets arguments sake assume somebody is called Bar and have a business model that might possibly be illegal under your interpretation of the LPGL. What's preventing him from creating a library called bar under his proprietory license as well as supplying a patch under the LGPL that results in code looking like: void WINAPI Foo(void) { #if HAVE_LIBBAR BAR_Foo(); #else /* Old Wine code */ #endif } Wouldn't this always be legal under the LGPL? In that case the only thing you did by threatening to sue him was to increase his costs. The point is, you didn't get his code, that it seems, that you hoped you would get. > > The current license is something that is easy to understand and > > are unlikely to scare companies like Transgaming away, but can > > you really say the say same about LGPL? > > OK, now we are getting somewhere. So your argument is basically that > the LGPL might scare some companies away. Yes. > Yes, I agree that's a > possibility. Good. > Most likely these companies will have been scared away > from Linux already, since many other things they need are also LGPL > (most notably the C library). That is a claim that makes no sense at all. Why should anybody want to make a business model out of modify or making additions to the almost 100% complete C library? One of the main reason Wine has the possiblity at all to attract companies like Transgaming is that it is not complete far from it. > But of course this possibility cannot be > excluded. Indeed. > I think that the risk of this happening is not larger than the risk of > having companies hold hostage pieces of Wine, and the damage in the > second case is much larger; so I think the LGPL would minimize the > potential damage to the project, even if damage cannot be excluded in > any situation. Your analogy with hostage holding is a bad analogy, sure I understand that you are refering to Transgaming promises to release eventually. If you don't believe them announce that publicly and developers that might be hanging back in fear of doing "double" work might step forward. They might not, of course, but then perhaps nobody was intresting in doing work in that area, Transgaming or no Transgaming. > Of course only the future can tell us who is right. Agreed.

1 0

Filename case handling
by Duane Clark 17 Dec '01

17 Dec '01

I have a question about the handling of filename case when trying to find an existing file. When files are on a win filesystem, the case is ignored, by the setting of flags by DRIVE_GetFlags(). As expected. When on a ext filesystem, that call sets the DRIVE_CASE_SENSITIVE flag, which is ok. But then the flag is used in the call to DOSFS_FindUnixName() (from DOSFS_GetFullName()), and I guess the fundamental question I have is under what circumstances wine would want to do a case sensitive search. One of my apps (Xilinx ngdbuild) always supplies upper case names when searching for a file, but the files always have lower case names (they were created by another Xilinx app). When searching for this file in DOSFS_FindUnixName() on an ext filesystem, the first test always fails, because we do a case sensitive test: if (!ignore_case) { if (!strncmp( long_name, name, len )) break; } However, and here is the other part I am questioning, if the file is an 8.3 filename, an alternate dos filename is created by DOSFS_ToDosFCBFormat(), and then a second test is performed here: if (!strcmp( dos_name, short_name )) break; This call passes and the file is found. However, if the file is not an 8.3 filename, the call to DOSFS_ToDosFCBFormat() fails, and no case insensitive test is made. So it seems to me that either a case sensitive search should be made in both cases, or in neither case. And of course I think that it should be both cases (since this fixes my app) :-) Duane

3 4

Wine and Drivers
by Viacheslav Zilberfayn 17 Dec '01

17 Dec '01

Hello, I'm wondering if anyone ever attempted to use wine to run Windows driver, specifically videocard drivers. Or at least to load them. I'm thinking of using Wine to load windows drivers into Linux, along with whole DirectX. I understand that drivers are special s/w, but I guess they use smaller part of windows api. Any information/opinions would be appreciated. Slava ===== --- NOTE: EMAIL HAS CHANGED !!! --------------------- Slava Zilberfayn | Home +1(416)7838430 EMAIL: slavka012(a)yahoo.ca ADDRESS: appt 1219, 377 Ridelle ave, M6B1K2, Toronto, ON, CANADA ______________________________________________________ Send your holiday cheer with http://greetings.yahoo.ca

2 1

Microsoft Antitrust Remedy proposal, take 3
by Dan Kegel 17 Dec '01

17 Dec '01

I've learned a fair bit since putting together my essay on the States' proposed remedies. In particular, Microsoft's response to the States was enlightening; it pointed out the parts of the Court of Appeals ruling that need to be heeded when fashioning a remedy. I now feel that the States' proposal has little chance of being accepted by the judge. The Proposed Final Judgment negotiated by Microsoft and the DOJ is probably the right starting point for any new proposals. Accordingly, I've started over, and this time I'm sticking very close to the negotiated settlement, and paying close attention to the law. As before, you can read my proposals at http://www.kegel.com/remedy.html I'm looking forward to your feedback. I've set up a mailing list at http://groups.yahoo.com/group/ms-remedy/ (aka ms-remedy-subscribe(a)yahoogroups.com ) for those who want to discuss this further. Together we can find a way to make the settlement more just and fair, or I'll eat my hat. Dan Kegel http://www.kegel.com

1 0

Re: Big Bummer for running Shrinkered files!
by Mike McCormack 17 Dec '01

17 Dec '01

Hi Robert, Did you try running wine with -winver win98? Did you try finding an Un-Shrinker? A quick search using google turned up a few candidates. Haven't tried any out though. eg. http://www.programmerstools.org/unpackers.htm Mike > Given that the application appears to look into ntdll.dll's > code to compare it against essentially a magic number, is there > any hope of getting Shrinkered exe's to run under Wine? ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: Wine and Baldur's Gate
by Ian D . Stewart 17 Dec '01

17 Dec '01

On 2001.12.16 21:39:52 -0500 Peter Hunnisett wrote: > <snip> > > > fixme:dsound:IDirectSoundBufferImpl_QueryInterface > > Unknown GUID > > {31efac30-515c-11d0-a9aa-00aa0061be93} > > > > (undocumented API call?) > > > > Anybody knows what this GUID refers to, or how to > > research it, I would be > > much abliged. > > Get a copy of the DirectX SDK and check out, most > likely, dsound.h. The GUID defines the interface that > the application is trying to aquire through the > IDirectSoundBuffer interface it already has. You'll > probably find that it's basically asking for an > unimplemented feature of direct sound. Thanx Peter. I'll check it out (tomorrow... ;)) Ian -- Linux, the choice | "Eat, drink, and be merry, for tomorrow you of a GNU generation -o) | may work." Kernel 2.4.15-gr /\ | on a i686 _\_v | |

1 0

Re: Installshield 6 (inter-proc) patches
by Gerard Patel 17 Dec '01

17 Dec '01

At 02:20 PM 16/12/2001 -0800, you wrote: >Well, this sounds like an argument for the LGPL. There is absolutely >no guarantee of stability with the X11 license; anybody can start a >Wine tree under another license, and if developers think this is a >good idea there is nothing I or anybody else can do to prevent it. Theoretically yes. The project leader has a much higher chance to do it successfully in fact. Since he is fixing the rules in the first place he has to be more responsible IMO. >It's simply part of the existing rules that the rules can change. trusting people is always a problem, yes. >You know, that's exactly why we are having this discussion. If I was >as selfish as you seem to think, I could change the license today >without asking anybody. > I'm not doing it precisely because I *do* care >what people think, and I won't make the change unless it is acceptable >to at least a large majority of the people affected by the change (and >yes that includes Transgaming). it's for them (and possibly others professionals) to say then. Gerard

3 2

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 17 Dec '01

17 Dec '01

> It would help us in several ways. First, since we've > always effectively > treated the Wine code base as though it were LGPL, we would gain > the protection that the LGPL offers. If someone else takes > the code we've > worked on, and competes with us, we would gain back > any improvements that they make. For example, if Wine had been LGPL, > then Transgaming would have been oblidged to release > Installshield fixes > back > (after all, they do follow on work that we did). Not according to the David Elliot and I agree. Even according to a strict interpretation of the LGPL they would just have to provide their code in seperate files so everything could be relinked when new versions of Wine was released. > With better > InstallShield > support, for example, our CrossOver customers might have a > wider range > of plugins > that would successfully install. This is a pretty minor problem; I > can't think of a > significant plugin affected by this. :-) Of course you claim that. Even if it was a problem you probably wouldn't admit it since it might raise to price in any possible negotions with Transgaming. :-) > Further, I think I > understand why > Gav has > has hesitated on this issue, and I firmly believe that Transgamings > intentions > with regards to the Wine project are honorable and good. As said above the only thing it would enforce would be file seperation so you more easily could integrate the part from Transgaming in your CrossOver product. Of course distributing it after that would violate Transgamings copyright, so you really need their permission after all. The point is LGPL wouldn't help you here. > However, I can imagine alternate scenarios where we could > have all of > our hard work > used against us by others who are more ruthless than Gav, and so the > LGPL would at least offer us some protection from that threat. Does it? It seems you overestime any advantages of LGPL. > A second benefit is simplicity. I spend a lot of time discussing > license > issues with my customers, and fighting very difficult battles to > preserve the integrity of the Wine code base (and while that sounds > noble and all bear in mind that a single, coherent source > code base that > I can fully > use is a key part of my business strategy). So, if the > license were LGPL, > my negotiating requirements would be simplified. In fact, I > would feel > free to > encourage my clients (and my company) to ruthlessly take > advantage of every > possible opportunity to create competitive advantages, because I feel > that the LGPL would protect the integrity of Wine. The same question here: Are you sure you are not overestimating the protection LGPL provides? > Of course, there are a number of downsides. First of all, it is > possible that > I would have fewer clients; the LGPL is complex license, > and it's core premise can deter many people. That is one of my objections as well. > It is widely > believed in the > Wine community that Corel would have never touched Wine if it had > been LGPL, and Corel's contributions to Wine were very significant > (the irony of course, is that AFAIK, Corel treated Wine as though > it were LGPL). Side note: I am one of them. > Second of all, the LGPL does, oddly enough, take away some freedom > on my part. Today, I have a full range of choices available > to me with > every product I release or help a client to build. After a > switch to LGPL > (and after enough time had passed for the LGPL'd pieces to be > significant), I'd have to be very cirumspect every time a > public release > of a product was made to be certain that I had all of my licensing > ducks in a row. Exactly, it increases your cost of doing business. > For example, right now, we don't provide a copy of the > source code contained within our CrossOver Plugin Wine tree. The only > changes we have not published back into the main WineHQ tree are > ones specifically required to interoperate with a > Linux/Netscape plugin. > The changes we made to Wine would never have been accepted by > Alexandre as being good or generally useful patches, and yet > they could > conceivably give someone who wished to replicate our proprietary > Linux plugin code a good insight into how to go about doing > so. To be > honest, > we sweat a lot of blood and tears to learn how to do that > right, and it > would > hurt if someone were able quickly knock off CrossOver Plugin > because we were > forced to show that code. To be honest and actually say something in support of LGPL: This wouldn't be required even with a strict LGPL interpretation. You would have to provide object files for relinking but that would not be much worse than providing the binary. Reverse enginerring it will be almost as hard. > On the other hand, we also had a > heck of a lot > of work on the Plugin code that has nothing to do with Wine, and I'd > like to see someone knock that off quickly <grin>. :-) > With all that, speaking on behalf of CodeWeavers, I would neither > call for > nor oppose a switch to the LGPL. Since that change would > impact me and my > customers somewhat slowly, I think I could make the necessary > adjustments in time. Perhaps the clarifications above might make you change your mind? > The most important thing is for us to continue to have a vital and > thriving Wine community. Agreed. > Finally, speaking strictly on a personal basis, and with > no corporate > considerations whatsoever, I would welcome a change to the LGPL; > I have always preferred it to BSD style licenses (and to the GPL, > for that matter); with LGPL projects, I feel more certain that I know > exactly > where I stand and how my code will be used. Well, perhaps it is because you misunderstood what the LGPL means?

6 7

Wine and Baldur's Gate
by Ian D . Stewart 17 Dec '01

17 Dec '01

Well, Now that I've made it through the actual install, I figured I'ld take Baldur's Gate for a spin. The main screeen, where you select to play the game, change the configuration, etc, comes up fine. There's a slight pause after clicking 'Play' while BGMain.exe starts and X is set yo 640x480 (I'm guessing this has something to do with DETACH_PROCESS?), but that's no biggy. The opening credits and movie play just fine. I'm able to create the main character without any noticeable problems. The first 'problem' I ran into was at the opening of the 'Prologue' chapter. Under windows, a narrator's voice reads the opening text as it scrolls across the screen. Under wine, the text is scrolling, but sans naration. A bit annoying, but no biggy. The real fun starts when the game actually begins. First off, the sound, when there is any, cuts out quite a bit, with no apparent rhyme nor reason. Secondly, the left and bottom panels are covered by the main section. You have to click on the various buttons to make them display. The third 'error' appears to be related to X's virtual desktop. Moving the cursor to the left or bottom side of the screen moves the 'viewport' away from the window, instead of scrolling the view in the Baldur's Gate window. After shutting down Baldur's Gate, I noticed a whole slew of error messages in the xterm window I launched it from. Here are a few examples: fixme:module:CreateProcessA (BGMain.exe,...): DETACHED_PROCESS ignored fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x403f8034,00020021,3):stub fixme:dsound:IDirectSoundBufferImpl_QueryInterface Unknown GUID {31efac30-515c-11d0-a9aa-00aa0061be93} fixme:ddraw:Main_DirectDraw_CreateSurface App didn't request a valid surface type - assuming offscreenplain err:ddraw:Main_DirectDrawSurface_Lock Negative values in LPRECT !!! fixme:ddraw:DIB_DirectDrawSurface_Blt Unsupported flags: DDBLT_DDFX Any help in getting any of these issues resolved would be greatly appreciated! Thanx, Ian

2 3

Big Bummer for running Shrinkered files!
by Robert Baruch 17 Dec '01

17 Dec '01

The plot sickens... Here's the background info. I have a file, power-structure-demo.exe which can be obtained from www.write-brain.com. Uwe has another file, tar2001.exe. Both have been compressed by the commercial Shrinker utility. When these exe's are run under Wine, Wine will spin. A look at the +all debug messages shows that the app tries to write into its own code area in order to purposely throw an exception. Kind of like this: void my_function() { try { *(char *)&my_function = *(char *)&my_function; } catch (access violation) { } } Shrinker was written using Visual C++, since this article at MSJ (http://www.microsoft.com/msj/defaultframe.asp?page=/msj/0197/exception/exce…) describes the code's exception handler perfectly. The Visual C++ exception handler, which gets control of the app from ntdll.dll, first calls a filter function corresponding to the catch clause to see if the handler associated with the catch will handle the exception. If so, it passes control to that handler. Otherwise it moves to the next catch clause. Here's the weird thing. The filter function looks at the code which called the exception handler, which is in ntdll.dll. Under Windows, this code is FFD1 (call ecx). The filter function compares that code to the call ecx instruction. At first the only difference between Wine and Windows is this comparison. A register gets decremented if the comparison fails. However, then the function calls ReadProcessMemory with a handle of -1 (what does that do?) to read 8 bytes, and compares some of the data returned to FFD1, and to 648B25 (which is the beginning of the next instruction after call ecx, mov esp,fs:[00000000]). Things rapidly deviate from there, resulting in Wine spinning and Windows continuing execution. Given that the application appears to look into ntdll.dll's code to compare it against essentially a magic number, is there any hope of getting Shrinkered exe's to run under Wine? --Rob

1 0

Re: Installshield 6 (inter-proc) patches
by Gerard Patel 16 Dec '01

16 Dec '01

At 02:09 PM 16/12/2001 -0800, you wrote: >Gerard Patel wrote: >> I'd have no objection to Gpl *if* people having invested >> money in Wine success accept the move without problem.... > >I believe Gerard meant to write LGPL, not GPL. >There hasn't been any proposal to the the GPL on >wine, as far as I know. (The GPL might be too restrictive >IMHO.) Yes, correct. I said in my first post that from my (particular) point of view the licenses were similar. Gerard

1 0

Re: Installshield 6 (inter-proc) patches
by Gerard Patel 16 Dec '01

16 Dec '01

At 11:35 AM 15/12/2001 -0800, you wrote: >I think that's quite unfair. I have stated that I personally don't >care about games, I don't have a single application that even uses >DirectX. The only reason I think DirectX is an issue is because I see >users complaining that Wine doesn't run their favorite game, and I >want Wine to be useful for as many people as possible. This has nothing to do with license, Transgaming or anything. All that is needed is a developer writing code. If there is none, nothing is written. Before Lionel Ulmer, there was no big DirectX game that could be played under Wine I think. Now Lionel is not contributing anymore - did he say to you privately that this was because of Transgaming ? There are many other top developers who have faded away like he did since I began on Wine, so it could be for many other reasons. Now, game users can as well subscribe to Transgaming as far as I am concerned. The vast majority of them seem to need professionnal - paid - support anyway. <snip> >> You want to use the Gpl as a tool, but I don't see a lot of respect >> for the philosophy that is behind it. > >I must say I'm quite offended by your comments. The only reason I >raise the issue is because I want Wine to remain as useful as possible >for everybody. <snip> you are the leader of this project since 8 years : the Gpl already existed when you began to work on Wine. You could have switched the license at any time. I don't remember you ever expressing any interest in Gpl for Wine since 3 years I am following - and I have read also quite a few of your interviews. Looking from the outside, this has more the appearances of a knee-jerk reaction, not the result of a long reflection. > What I find even more disturbing in what you said is the allusion >> (when replying to Patrick) to a future tightening of copyright laws, >> a tendency that is in my opinion directly linked to the idea of >> copyright, patents, etc being 'intellectual property' assets, >> and infringers thieves stealing them. You seemed to welcome >> the additional protection it would give Wine. > >Absolutely not, and I don't know how you got this impression. I'd love >for copyright law to get back to sanity, but I don't see this >happening in the near future. Yes, there are a lot of abuses done in >the name of intellectual property these days. Does this mean we have >to let people hurt us and do nothing? You seem to think that users >rights are important, but how are you going to defend their rights if >not by using the only tool that we have, namely copyright law? No, that not what I was saying. If I am here, that's because I think that having Win32 Api outside of Windows is important. User rights have never got in the figure, since it was always acknowledged that people could take the stuff and turn it proprietary. Now that someone seems to succeed, you want to change the rules. Transgaming is playing by the existing rules, the rules you have enforced for a long time. If they are hurting you, that's surprising. They are not hurting me, since I have accepted your rules. What you are planning will hurt Transgaming business plan, by spreading Fear, Uncertainty and Doubt in their business discussions with potential customers. Business plan that they did and implemented in good faith, perfectly conforming to your rules and expecting their stability. I'd have no objection to Gpl *if* people having invested money in Wine success accept the move without problem. I think you should feel more responsibility towards people investing in Wine, not only responsibility towards the project - in other words you, because you are the Wine project. <snip> >I'm not planning to send anybody to jail, and I find that suggestion >insulting. What you are planning I don't know but in this context Gpl seems more a weapon than anything else. What happens when weapons are drawn can be anything. <snip> > I do think that given the lack >of developers, discouraging even a few of the existing ones can cause >a lot of harm to the project. I think that you will discourage one. Gerard

3 2

Re: create more window data structures before calling WH_CBT hooks.
by Uwe Bonnes 16 Dec '01

16 Dec '01

>>>>> "Rein" == Rein Klazes <rklazes(a)xs4all.nl> writes: Rein> The right patch attached this time. Rein. -- Rein Klazes This patch superceded my patch "Check WND structures before accessing", as it solved the problem with encarta99 startup Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: wine-devel digest, Vol 1 #584 - 10 msgs
by Roger Fujii 16 Dec '01

16 Dec '01

I tried to resist.... really..... "J.Brown (Ender/Amigo)" <ender(a)enderboi.com> wrote: > Possibly, however remember that license may not always be for the > application - it is for the product, including any proprietary works not > GPL'ed, or support rights. It is also however true that the GPL'ed > portion of the code may have no other restrictions placed on it's use. other than the restrictions that the GPL imposes... > Going back to the user, how could a user who brought this infringing > product be benefited from the developer suing? Mostly, they may not. In > other cases, they benefit from the fact the code is again public, and they > have a far easier way to see about getting bugs fixed, etc.. the usual > benefits a good open-source project has. Here is a good counter-example. Sun Microsystems developed a toolkit that would convert linux network drivers source to function with Solaris (their proprietary OS). It was just a toolkit. They weren't distributing driver binaries. AFAIK, this use is perfectly legal to do with the GPL. What happens? The GPL GNUts get all bent out of shape because it allowed use of their drivers under a proprietary OS, so Sun yanked it, even though they were not in violation. As a *USER*, this is a negative impact placed on me by the linux developers to exercise my rights, since it impedes my ability to USE GPLed software. > > The usual argument about Gpl, that courts would not accept the > > action because there is no material interest (money) for Linus > > Torvalds, for example, in Linux, is akin to mine, but my point of > > view is not legalistic. > That's a load of bull, of course. A copyright has been violated.. it's > like with a trademark - if someone violates a trademark, the owner comes > very likely to forgoing his rights on that mark for not enforcing it. You are confusing copyrights and trademarks. A copyright is not invalidated due to lack of an active defense. A trademark would. > All I wanted was installshield support! :p All I want is for VirtualDub to work! :) "Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote: > > I feel rather dismayed by the whole discussion. > Maybe this is so because the way you approached the issue. > See, you are concerned with the semantics of things, the 'why', I think the better question is "what" as in what is trying to be accomplished? > centuries. Second, even suggesting that a LGPL Wine will the an evil > 'intelectual property' monster is ridiculous. Just a reminder, most open > source projects are (L)GPL and _that_ community is the only significant > force in today's society fighting against such things as software patents, > DCMA, SSSCA, etc. I would not equate the LPF with the FSF. They have very different agendas. > If we agree up to this point, what is the 'syntax' I was referring to? > Well, IMO this is a stronger Wine that keeps evolving and that has a life > of its own. Wether this is good or not for users it's irrelevant. You probably meant something other than what you wrote here. Existence for the sake of existence is useless. I would presume the point of wine is to provide a WINXX environment on top of x86 platforms. If M$ was sued into oblivion tomorrow, and Wine was a *perfect* 95/98/ME/XP emulator, there would be no need for future development (other than to port to new platforms). The point is that the end goal is to attempt to be the perfect emulator for the USER - not to keep wine going indefinitely. > Some may say yes, others (e.g. Microsoft) may say no. I submit that we that this > goal as axiomatic and we go from there. > > Now, I can argue that this very axiom eliminates any sort of proprietary > licence, but I will not do it since it's understood by everybody here. I > will just look at the two possible options: BSD vs. LGPL. There are two > points in my axiom: > 1. we should try to make Wine stronger (e.g. evolve faster) > 2. Wine should have a life of it's own > > Let's look at the first part: make Wine evolve faster. > LGPL > pros: > -- _far_ bigger code base for sharing/reuse and how to do arrive at this? the modified BSD license is professed by FSF to be compatible with the GPL. > -- _far_ bigger developer base Can you actually say for certain that the gain of developers by using LGPL is less than the loss of developers by using BSD? > -cons: > -- we may lose developers that are opposed philosophically to the > GPL ideals > -- less commercial freedom when using the code base Setting philosophy aside, there are many companies that will not touch *anything* with the letters GPL in it, due to what is perceived (rightly or wrongly) to be its consequences. It is not an overstatement to say that *GPL is a net discouragement to commercial development - the GPL and FSF are openly hostile to proprietary software - PERIOD. Anyone who claims otherwise must also believe that M$ is "encouraging innovation". I can also add a few more cons: -- FSF discourages use of LGPL -- Discourages commercial companies for its use/development. -- Adds more confusion to the mix - LGPL ramifications is less understood than the GPL. > BSD > (just negate the above) > > And now for the second part: Wine should have a life of its own. This is, > to my mind, the crucial part. The problem with a BSD licence is that it > does not ensure that. and how do you arrive at this conclusion? I would say that apache, X11, BSD would disprove what you are saying. > The cool and amazing thing about the (L)GPL is that > it puts in place the right feedback loop (or vicious circle if you > will) that ensures a project a life of its own independent of who's > developing and maintaining it: the bigger the project becomes, the more > people will use it, (up to now BSD and GPL are the same), the more people > will contribute to it, the bigger the project becomes!!! It's the > equivalent for the 'rich get richer', but the currency is not money but > usefulness/code. It is simple, yet brilliant. This is an artifact of "open software". GPL is a *part* of open software - it is not the definition of open software. I don't believe anyone here is advocating making wine non-open. The problem wine has is that it is not a small endeavor like most GPLed software. If you look at the larger projects (gcc, gdb, openoffice, apache, x11, mozilla..), you will find the ones that are most successful long term are the ones with active corporate involvement. With this in mind, I think wine is better served by having its use proliferate and being more complete (even at the expense of having propriatary extensions), than having something that is incomplete but "free". As a side question, what IS the difference between what's available on winehq vs codeweavers? -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

4 4

Re: create more window data structures before calling WH_CBT hooks.
by Uwe Bonnes 16 Dec '01

16 Dec '01

>>>>> "Rein" == Rein Klazes <rklazes(a)xs4all.nl> writes: Rein> hi, My application, girotel v 2.1, crashes during the creating of Rein> its first windows when calling the CBT hooks in Rein> --- ./wine/windows/win.c Wed Sep 29 17:14:39 1999 Rein> +++ ./mywine/windows/win.c Tue Oct 12 20:24:27 1999 Rein, are you sure this is the right patch? It seems from 1999... I want it test the patch if it supercedes my recent get_whole_window patch... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 16 Dec '01

16 Dec '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Even according to a strict interpretation of the LGPL > > they would just have to provide their code in seperate > > files so everything could be relinked when new versions > > of Wine was released. > > It seems you really don't understand the LGPL. Modifications made to a > library released under the LGPL are a derivative work of this library, > and have to be LGPL no matter if they are in separate files or > not. Saying the ALL modifications gives rise to a derived works even if distributed seperately is a ridiculous proposition that is the main problem with (L)GPL. As I have been trying to explain is that the courts are unlikely to support this, at least not 100%. The question is where is borderline is. At the extreme end the courts might totaly reject the doctrine of derived work in favour of the doctrine of combined work what I have been talking about in previous mails. If somebody (A) only provide drop in files that replaces some functions say the Crypto API in ADVAPI32, they are not any combined work since they are 100% written by A. Sure the application/library as a whole is of course a combined work, but that doesn't matter if you do not distribute it as a whole. > This is the standard interpretation that just about anybody > except you agrees with. If you think everybody agrees what a derived work is you are badly mistaken. Even Richard Stallman himself admit that the power of (L)GPL is dependent on how far the courts will allow the doctrine of derived work. Note that I do not pretend to know how the courts will rule. But I do know that sticking the head in the sand and pretending that (L)GPL doesn't have large potential holes in it is quite naive and potentially dangerous.

3 2

Decision process on possible switch to LGPL
by Roger Fujii 16 Dec '01

16 Dec '01

Dan Kegel <dank(a)kegel.com> wrote: > > Who has to decide what in order for the Wine project > to switch to the LGPL? I believe the process involves all prior contributors allowing this, or have the non-LGPL code rewritten and that work be LGPLed. Pending on the number of authors, the effort can be non-trivial. Look at the license change discussions for mozilla and kde if you want to get the grasp of what is required. > Could it be as simple as the wine cvs tree accepting LGPL'd contributions > along with old-license contributions? Not if you want a "pure" LGPL distribution. > Or need one go so far as requiring all new contributions to the cvs > tree be under the LGPL? even further. > Would a valid way of voting be to open up a new cvs tree that > accepted only LGPL contributions, and giving maintainers the > choice of which tree (or both) to submit to? That would > within not too long show how contributors felt. This is going to encourage more development... NOT. What you definitely don't want is confusion over what license is being used. Unless you make a stipulation that the final license chosen will automatically convert the other license, it would just be a mess as you then will have 2 source trees which you have to go back and reconcile. -r -- Roger Fujii <rmf(a)lookhere.com> Underemployed, and trying to keep it that way....

2 1

OSS stuff
by Duane Clark 16 Dec '01

16 Dec '01

The recent OSS stuff is working pretty good. I have one area, where one sound clip stops and the next starts, that sometimes has problems. Sometimes the second clip runs normally, and sometimes there is just a brief bit of the very beginning of the second clip. I think this is where the problem is. The difference I see is that when it breaks, some wodNotifyClient msgs are received before the wodGetPosition messages are set to valid values for the new clip. When it works, those values get set before the wodNotifyClient msgs. Then again, I really don't understand what is going on. A trace from when it fails: trace:wave:wodRestart imhere[3-RESTARTING] trace:wave:wodPlayer_ProcessMessages Received WINE_WM_RESTARTING 0 trace:wave:wodPlayer_FeedDSP fragments=16/16, fragsize=1024, bytes=16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290cdf4.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce14.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 12288 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce34.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 8192 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce54.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 4096 trace:wave:wodPlayer waiting 46ms (132,46) trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=0/16, fragsize=1024, bytes=-1226 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CDF4 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE14 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE34 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE54 dwParam2 = 0000 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=4294966070 trace:wave:wodGetPosition TIME_SAMPLES=134217421 trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=1/16, fragsize=1024, bytes=742 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=742 trace:wave:wodGetPosition TIME_SAMPLES=185 trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=3/16, fragsize=1024, bytes=2694 trace:wave:wodPlayer waiting 110ms (110,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=2694 trace:wave:wodGetPosition TIME_SAMPLES=673 trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=5/16, fragsize=1024, bytes=4648 trace:wave:wodPlayer waiting 88ms (88,4294967295) It continues this way until the DSP buffer is empty, and nothing further is written to it. Here is when it works: trace:wave:wodRestart imhere[3-RESTARTING] trace:wave:wodPlayer_ProcessMessages Received WINE_WM_RESTARTING 0 trace:wave:wodPlayer_FeedDSP fragments=16/16, fragsize=1024, bytes=16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290cdf4.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 16384 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce14.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 12288 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce34.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 8192 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce54.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 4096 dwLength 4096 available space was 4096 trace:wave:wodPlayer waiting 46ms (132,46) trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200 trace:wave:wodGetPosition dwPlayedTotal=78 trace:wave:wodGetPosition TIME_SAMPLES=19 trace:wave:OSS_wodMessage (0, 0009, 0000001C, 4290CE74, 00000020); trace:wave:wodWrite (0, 0x4290ce74, 00000020); trace:wave:wodWrite imhere[3-HEADER] trace:wave:wodPlayer_ProcessMessages Received WINE_WM_HEADER 4290ce74 trace:wave:wodPlayer_FeedDSP fragments=1/16, fragsize=1024, bytes=108 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce74.0[4096] trace:wave:wodPlayer_WriteMaxFrags Written 108 dwLength 4096 available space was 108 trace:wave:wodPlayer waiting 45ms (132,45) trace:wave:wodPlayer_FeedDSP fragments=0/16, fragsize=1024, bytes=-990 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CDF4 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE14 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE34 dwParam2 = 0000 trace:wave:wodNotifyClient wMsg = 0x03bd dwParm1 = 4290CE54 dwParam2 = 0000 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:OSS_wodMessage (0, 000D, 0000001C, 42BD6EE0, 0000000C); trace:wave:wodGetPosition (0, 0x42bd6ee0, 12); trace:wave:wodPlayer_ProcessMessages Received WINE_WM_UPDATE 0 trace:wave:wodPlayer_FeedDSP fragments=2/16, fragsize=1024, bytes=928 trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4290ce74.108[4096] trace:wave:wodPlayer_WriteMaxFrags Written 928 dwLength 3988 available space was 928 trace:wave:wodPlayer waiting 132ms (132,4294967295) trace:wave:wodGetPosition wType=0002 wBitsPerSample=16 nSamplesPerSec=22050 nChannels=2 nAvgBytesPerSec=88200

1 0

Adding protections in map_image
by Robert Baruch 16 Dec '01

16 Dec '01

Hi all, Uwe and I have been working on several executables which have been compressed by Shrinker. Basically, under win98 it tries to load a VXD which is disallowed. The prospects are better under nt40 mode, but it looks like Shrinker purposely causes read and write exceptions. After looking at this for a little over a week, I've found that there are two problems which need to be solved. The first is that the exception handler installed by Shrinker under Wine causes another fault and then a spin. Under WinDbg (in W2K/VMWare) the exception handler does not cause another fault, and execution continues nicely. The second is that WinDbg finds a write fault where Wine does not. To fix this, Wine must set protections on the executable's image map. I came up with a patch to do this, and it worked for my Shrinkered exe, but not for Uwe's. Uwe's exe loads MSVCRT20.DLL, and then Wine calls PE_fixup_imports, which attempts to write to that DLL's .idata section, which had been set read-only. Clearly Wine needs to write to that section to set up imports which haven't been implemented. Now, my patch put the protections on the mapped image right at the end of map_image. This works when map_image is called (eventually) from PROCESS_InitWine, so that the initial executable gets its protections set right. However, it doesn't work for PE_LoadLibraryExA (called by LoadLibraryExA) because it first checks to see if the library has already been loaded. If it has been loaded, it calls PE_fixup_imports. If it has not been loaded, it calls (eventually) map_image. So if the library has already been loaded, it has already had its protections set up by map_image at some point in the past. Then when PE_fixup_imports is called, a protection violation occurs. My current idea is to go into PE_fixup_imports, unprotect the .idata section, do the fixups, and reprotect the section. The bad thing is that if someone else in the future writes some code that does additional fixups to other sections, they are also going to have to unprotect and reprotect. This might turn out to be a good thing, though, if it forces you to do that. What does everyone think? Thanks, --Rob

2 6

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 16 Dec '01

16 Dec '01

> > Note that I do not pretend to know how the courts will rule. > > But I do know that sticking the head in the sand and pretending > > that (L)GPL doesn't have large potential holes in it is quite > > naive and potentially dangerous. > > Then if the LGPL holes are dangerous, the X11 license should be even > more dangerous; after all it's a much larger hole than the LGPL will > ever have. I still don't understand where you are trying to go with > your argument. Sure it has a larger hole. But at least it is obvious that is does. It doesn't make you believe good things will happend. The point is that you seem to wish some things to happend and I point out that LGPL provides not guarentee that it will actually will happend despite that LGPL at a quick glance looks like it in some meaning forces what you wish to happend. One the other hand the LGPL might scare away potential companies wishing to extend Wine. See below. > No, of course the LGPL doesn't provide absolute protection; nothing > does, and I don't think absolute protection is desirable either. There > are some things that the LGPL clearly allows, some that it clearly > forbids, and a number of border cases, that frankly are only > interesting to people who want to try to get around the license > restrictions. And what would be the point of doing that? Making their business model work. Trying to ensure investment return. > If the > license is not acceptable to someone, they don't have to use the > code. Who would risk bad PR and potential lawsuits just to prove that > they can find a loophole in the LGPL? So we lose some possible companies willing to help in two step. 1. Because they do not dare 2. Because you (or somebody else) sue them Great idea. NOT. > You really make it sound like the LGPL is some kind of unexplored > wilderness that we shouldn't venture into. We are not a normal software project and thus what really is a derived work when faced with a lot unimplemented stuff are much more difficult to know. I have tried to show that LGPL in itself is pretty weak and are likely to be even weaker then faced with Wine's special circumstances. > The fact is that a large > majority of free software projects use either the GPL or the LGPL, and > in practice it works just fine for them, just as I'm confident it > would work just fine for us. Normal software project doesn't have any large design with a lot of not yet implemented functions, there it makes sense for some company to say: Hey I could provide an implementation of this special part under this special business model. Face it we are not a normal software project and the arguments they used for chosing (L)GPL are not really relevant here. Note that I'm not denying that convincing arguements for choosing LGPL might exists, but reference to earlier success is not one of them. Your argument that LGPL forces good things to happend is not entirely convincing either for reasons stated earlier. The current license is something that is easy to understand and are unlikely to scare companies like Transgaming away, but can you really say the say same about LGPL?

2 1

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