- Wine-devel - list.winehq.org

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