- wine-devel - winehq.org

RE: License change vote results
by Patrik Stridvall 19 Feb '02

19 Feb '02

> Here is the summary of the votes I received in answer to the request > to switch to a copyleft-style license: > > Agree Disagree Indifferent > > All votes: 76 (70%) 15 (14%) 17 (16%) > > Contributors: 39 (66%) 7 (12%) 13 (22%) > > Contrib. weighted: 59 (64%) 13 (14%) 20 (22%) > > The first line counts all the votes I received. The second line counts > the votes of all people/companies who contributed some code to the > project. The last line counts all contributors again but with each > being given 1, 2, or 3 votes depending on the importance of his > contributions (this evaluation is obviously a bit subjective, but I > think the overall trend is clear). Intresting to note is that contributors that disagree are on average ranked higher (almost 2) but the contributors that agree are ranked lower (about 1.5). This means that people that has more effort to protect are less willing to do so. Very intresting. The only reasonably conclusion for this that I can think of is that people with more to protect have thought more on the drawbacks on copyleft licenses (especially the LGPL) than people with less to protect. > The obvious result of this vote is that my previous conclusion was > wrong: there is clearly widespread support in the community for a > copyleft-style license. For some copyleft-style license perhaps. I'm not entirely against copyleft-style licenses either even if I voted disagree. However don't be so sure that all that voted for it really wants a license like the LGPL that prevent (at least according to your interpretation) using for example proprietary libraries to implement some functionalility. Or for that matter prevents Transgaming to add copy protection that they can't release openly because of a NDA. Calling proprietary libraries is something that I have been trying to explain is not just something "evil" companies out to earn a profit do, but also quite reasonably people just trying to help themselves or some friends to run applications under Wine. Is it really morally or ethically right to prevent that? I also asked how that is compatible with freedom 3 of the Free Software defintion: "The freedom to improve the program, and release your improvements to the public, so that the whole community benefits." > With 2 out of 3 contributors in favor of the > switch, and less than 15% opposed to it, it's clear that we are going > to proceed with the change. > > We now have to decide the implementation details, like the exact > license used, whether to require copyright assignments, etc. I think the first thing me need to do is to properly discuss what we want to accieve with the license and even more importantly what we think is acceptable to sacrifice. Then we must vote on what is important to prevent and what is important to avoid preventing. Especially we must vote on for example whether preventing Transgamings business model is reasonable and similar specific cases. After we have done that we can see if any existing license fits something that the majority agrees on or whether it is appropriete design a license of our own that does. I'm not at all sure that the LGPL is a good alternative at least not without properly clarify what paragraph 2d means as well as making certain that the majority of contributors really wants a license that means whatever paragraph 2d means. Another thing. It is not nessary to have the whole of wine under the same license. For example the header files (wine/include/*.h) might be appropriate to have under the current license or even under public domain to facillitate sharing with other projects. > My > suggestion is that we create a separate mailing list to discuss that, > to avoid drowning wine-devel under yet another license flame war. Agreed. I have subscribed to it and are ready to continue the debate there.

3 2

languages for wine tests
by Andriy Palamarchuk 19 Feb '02

19 Feb '02

Are we going to use other languages than Perl and C for tests creation? I created a small shell test script to test other shell scripts, which are part of Wine (namely regapi scripts). It is easy to rewrite the test script in Perl. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com

2 1

RE: License change vote results
by Patrik Stridvall 19 Feb '02

19 Feb '02

> > For some copyleft-style license perhaps. I'm not entirely against > > copyleft-style licenses either even if I voted disagree. > > > However don't be so sure that all that voted for it really wants > > a license like the LGPL that prevent (at least according to your > > interpretation) using for example proprietary libraries to > > implement some functionalility. > > This is a spurious argument. You tell us that you voted that you > disagree, then ask us to not assume that those who voted in > favor agree > with the LGPL -- but provide no evidence to the contrary? The evidence is that the question didn't ask the whether the voters agreed with the LGPL it asked whether they thought copyleft was good. No bait and switch tactics thank you very much. Copyleft doesn't imply that everything it uses or in the case of GPL even what uses it should be copyleft only whatever is derived from it. A proprietary library that is called from a copylefted application is obviously not derived from it. Yet the LGPL under some interpretations prevent this. So the LGPL goes further than the definition of copyleft so the question whether supporters of copyleft support the LGPL is quite valid. > In any case, the precise license chosen is an issue yet to be > hashed out; > and it seems the wine-license mailing list is the place to do that. True. But I don't think all intrested have signed up yet. I will continue cross-posting a while yet. > > Or for that matter prevents Transgaming to add copy > protection that they > > can't release openly because of a NDA. > > I'm afraid Transgaming gets no sympathy from me if a future > Wine license > prevents them from working on copy protection functionality. > The DMCA is > fundamentally broken; technological mechanisms to prevent copying are > fundamentally broken because there can be no protection for fair use > rights; and any company that uses such copy protection > mechanisms should > be thoroughly boycotted. While I don't condemn TransGaming > for trying to > support copy-protection mechanisms in Wine -- corporations are by > definition amoral -- The DMCA might be (and is IMHO) fundamently broken but NDA:s are not. The copy protection that Transgaming has implemented is just an exemple of things that might come under a NDA. I can imagine 3D accelerators and a lot of other things that might fall under NDA:s. Note that some NDA might only be temporary before a product is released. Surely it would be nice to have Wine working on the release day. > I also won't shed any tears if this particular > business model falls by the wayside. No business model can exists that requires NDA:s if disclosure of source is mandated. If it could be hidden in a external library everthing would be OK, but alas the LGPL doesn't allow that under Alexandre's interpretation.

2 1

Re:GetStdHandle Problem
by Ignasi Villagrasa 19 Feb '02

19 Feb '02

Here is the .spec I'm using: name mcwine type win32 mode cuiexe init main I compile it using winebuild -fPIC -o mcwine.c -spec mcwine.spec It generates a mcwine.c file, that I include in my makefile. I add several wine libraries and create the executable without problems. When trying to execute, I get the following message: wine client error:(nil): sendmsg: Descriptor de fichero err¾neo (In spanish, error in file handle) If I run the program using gdb, I see the following: (gdb) r Starting program: /usr/client/mcc_gnu/cmpm/cmpmgnu /B100 /Oaaaa-1.ovl Breakpoint 1, McConsole::Inicializar (this=0x80aa528) at /usr/comun/src/mc_vis32.cpp:429 429 conhanout = GetStdHandle(STD_OUTPUT_HANDLE); 1: conhanin = 0 (gdb) n 430 conhanin = GetStdHandle(STD_INPUT_HANDLE); 1: conhanin = 0 (gdb) n 431 FlushConsoleInputBuffer(conhanin); 1: conhanin = 0 (gdb) n wine client error:(nil): sendmsg: Descriptor de fichero err¾neo Program exited with code 01. (gdb) So I know the problem comes from GetStdHandle, but I don't know why, because the program links properly, and I suppose GetStdHandle, a basic Win32 function, should work. Any hint ? Perhaps the libraries I'm linking ? Compiler/linker options ? Thanks in advance, Ignasi Villagrasa.

2 1

Controls and TWEAK_WineLook
by Andrew McCall 19 Feb '02

19 Feb '02

Now that the license discussion is dying down a bit... I've been working on porting a couple of aps in house via WineLib over the past couple of days. While in general it's been great, I've decided that I would like these applications to have a more linuxy type of look and feel. (As well as other programs I run via Wine.) I started to look at the controls implementation in WineLib. (I'm a very newbie Wine Hacker here, so I had to do a bit of searching...) I've been working with the control code in wine/controls. Now, just to be sure that I'm looking at this the right way: It appears that the Win31 look is implemented in general, inside the drawcode for each control, while the WinME/NT look is implemented mostly in uitools.c. Is this correct? I've started small trying to change some of the L&F behavoir of the push buttons. (Doing simple things like creating rounded edges/etc...) I've come to a couple of conclusions while trying to do this. I think it might be a good idea to try to move more of the Win31 look inside of the DrawFrameControl function. Is there something I'm missing as to why this hasn't been done already? I have considered a few options for my app: the first being to implement the new look just as the Win31 look is implemented now. I dislike this because of the added complexity it would give the already complex button/control code. The best method that I currently see is to modify the DrawFrameControl code to be friendly toward adding different looks. A benefit of this approach is that it would allow much of the Win31 look code to be moved into the DrawFrameControl function, allowing aps using that function call to keep a similar look throughout. I believe this could be done by adding a swtich statement or using function pointers in the current DrawFrameControl and then reimplementing each of the relevant functions for my wanted new look. Perhaps each of the new sets of UITOOLSXX functions could be moved into a different file. (Win31UITOOLS, LinuxUITools, Win95UITools.) If noone else is working on this code, I'd like to see what I could do with it... It think it's a fairly nice place to start in Winehacking. Is there a codestyle guide FAQ around that I could look at? ===== ---- Andrew McCall - andrew(a)nrrds.com __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com

1 0

RE: License change vote results
by Patrik Stridvall 19 Feb '02

19 Feb '02

> > I thought that Jeremy's suggestion of wine-legal was a > better idea... > > Hmm. I had probably Uwe's requests for wine-license in mind more than > anything else, so must have missed that. But should we change the list > name now? I personally think that wine-license is a better name. There is very little reason to discuss other legal issues except for licenses and the license discussion might expand to other issues than just legal ones.

2 1

How do interrupts in wine work?
by Nog 19 Feb '02

19 Feb '02

Hi, I got this feeling that I'm absolutly wrong in this but here goes... The way that I see Interrupt handling in wine is that when a real-mode dos executable is loaded, the processor (or the os mabe?) is forced into v86 were the int xx intruction is not privilaged. In this mode an exception is issued when an int xx is encountered and is then handeld by the exception handler is dosvm.c. Which in turn checks if the we have a builtin handler for the interrupt and if so then we simply call its handler as defined in real_mode_handlers. But when the app switches to protected mode, the int xx instuction becomes privilaged and gets handeld by EmulateInstruction. In this function the 32-bit version is not implemented but the 16-bit version is (Is this correct (the one is 16-bit the other 32-bit)? If not then what does long_op symbolise?) Is it likley that this piece of code will ever get called? And if so then why does it assume that the insterrupt it is emulating is not builtin? What all of this probable garbage came from is: What will it take to emulate int xx from 32-bit code? nog.

2 6

Re: Jeremy makes a persuasive argument for LGPL (MS Kerberos stuff)
by Igor Furlan 19 Feb '02

19 Feb '02

On Tue, 19 February 2002, Sean Farley wrote: > > On Tue, 19 Feb 2002 12:17, Roland wrote: > > > At 09:07 PM 2/18/02 -0500, Anthony Taylor wrote: > > <snip> > > > >Take, for instance, Microsoft's attempted hijacking of the Kerberos > > >protocol. MS almost took an accepted standard, and almost perverted it > > > > Well, I think we are still better off as when M$ would have created their > > own protcol from scratch. They certainly have the money to do that. The way > > it is now, we just have to implement the extensions to be able to use > > M$-Kerberos. I don't see where the BSD license has brought any kind of > > disadvantage here. > > Actually, the open-sourced implementation changed their specification > and forced Microsoft into explaining what they changed, but my memory > about it is not the greatest. > > Sean > -------------- > scf(a)farley.org Yes.. they published their change... but they said in the same time that you are not allowed to implement it anywhere, because the changes are copyright-ed by them. It is basicaly the same as their "shared source" approach: you can see it but you are not allowed to use it. Igor

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 19 Feb '02

19 Feb '02

> First, and formost, we have now heard the oppinion of two big > (from Wine > POV) commercial players: Gav and Jeremy. Now, it was > painfully obvious to > me that Jeremy had the power of reason on his side, while Gav only a > strong emotional impulse. Since choosing the LGPL is a one way street, it is hard to not be emotional, when arguing against it. It is much easier for the LGPL propenents to be emotionally detached. If you lose now, ou can come back next month, next year or whenever and try again. The LGPL oppents can't for obvious reasons. > And there's reason for that -- the > LGPL make a > lot more sense for Wine. Still think that after reading my reply to Jeremy? > We've heard countless arguments why that's not that case. A > lot of them > where simply nonsense. The few that made some sense, were ALL > based on a > false premise: that Wine is a monolithic product. I have never believed that Wine is a monolithics product. > Now, this is a _fundamental_ point that is ignored over and over > again: Wine is a _collection_ of products, just like a Linux > distribution. Which means that the viral aspect of the LGPL _stops_ at > every DLL boundary. Very true and this significantly weakens any "protection" that the LGPL offers. > It is easy to see now that this does not > preclude most > commercial implementations. In fact, it encourages them givin > them a level > playing field. Just like Linux does. Perhaps, but at a terrible price. Read my reply to Jeremy. > People, for crying out loud, _think_ about it, and the conclusion will > jump right out at you. THIS IS WHAT WE WANT: > -- if a company invests a _little_ to improve a DLL, we > should have no > moral problem requireing them to contribute that back. Since > it's just a > little contribution, no business will be destroyed because of it. > -- if a company makes a huge improvement (like > Transgaming), they can > simply drop the original Wine code, and keep everything > propriatary. Now, > compared to the _huge_ improvement, the cost of > reimplementing the mostly > non-working Wine code should be trivial. > > Bottom line is: > -- are we raising the bar for comercial companies with a LGPL > licence? YES! > -- how _much_ are we raising it? BY A TRIVIALLY SMALL AMOUNT! > -- do we invalidate TG business model? NO! Somehow you seem to believe that all reasonable business models will strictly following DLL boundaries, but you have given. absolutely no proof of this, you just assume it. Face it the design of the Windows API are a terrible mess that doesn't follow DLL boundaries.

9 18

Re: Licensing Open Source in General
by Roland 19 Feb '02

19 Feb '02

At 10:03 AM 2/19/02 +0100, Bernhard Rosenkraenzer wrote: >It *IS* a fair point of view - if someone just adds a bit of value, why >should they be able to make loads of cash of the much bigger original work >without giving anything back? No one will make loads of cash by just adding a bit of value. Why? Simply because no one would pay them much for that. It would be simpler to add that bit of value yourself or hire a programmer to do that in a weekend. People would only pay for big improvements, like Lindows, they invested around 5 million AFAIK. >Selling a proprietary fork of an open source application is much more like >stealing a car, giving it a new paint, and then selling it. >The thief added value (the new paint), so by your argumentation, he >should be able to make money of it and what he's doing is perfectly ok. First of all, you cannot steal something that is already free. But lets apply the rest of your analogy: Suppose the car is under a BSD license, which means everyone can get one for free. Now, someone gets the car, gives it a new paint and sells that product. How much would you pay him? Of course, since you can get that very same car for free also, you would only pay him the amount equivalent for the paint + the work involved in painting. If he wanted to charge you 10.000 for the painted car, you would laugh on his face, get that car for free and paint it yourself over the weekend(or pay someone else to do that). But if he charged you 40 $, you would probably pay him, since he as a professional would do a better job and you wouldn't have to make your hands dirty. In effect that 40 would probably be cheaper than the money it would cost you to do the job yourself, if you also count the time investment necessary on your side. So I think this business model is perfectly ok! This is the great advantage of the BSD license. It enables business. With the BSD license applied to your analogy we soon would have lots of businesses created to enhance the car: Painting, Putting sound equipment to the car, increasing the engine power, etc...Customers interested in one enhancement or the other would be willing to pay for it. Eventually one enhancement would be so popular that a group of volunteers would integrate it into the original car. What would be the GPL equivalent in your analogy: you can have the car for free, but any enhancements you make have to be given back at 0 cost also. Now suppose a guy wants to make the paint job. He will have to make it for free! So no one would do that of course. The result of this would be that if you want to paint the car you will have to do it yourself. Or you have to wait till someone else wants to do it and give it back for free afterwards. The GPL discourages business... Of course there are still business models possible, though restricted, for example: you hire the guy for painting the car as you wish. But that means you pay him in advance. And if this has been done once...no one else has to pay for it again... > > The GPL prevents this from happening but where is the advantage in > > that? > >Forcing everyone to contribute, preventing this type of theft. As I said, you cannot steal what is already free. >They are, if they choose to go by sane licenses. >Releasing products as Open Source certainly hasn't hurt companies that >aren't scared of doing it. Hmm, that might be true in some cases, especially where the software requires some kind of specialized support, where you pay more for the support than the software itself. >The problem is that many companies refuse to even consider sane licenses, >not that they couldn't do it. I don't consider the xGPL to be that sane anymore. > > Personally I keep wondering if it would be that bad if we had a company > > producing a better version of WINE than the free one. Why should this be > > bad? > >- it would take users (and therefore potential developers) away from the > real version. If that was true no one would be making Mozilla, OpenOffice, even Linux. When Linux started the proprietary Unix was MUCH better. History showed, that the opensource Linux was capable of catching up with UNIX and even become better. >- why should someone who made just a couple of changes make lots of profit > from (mostly) someone else's work without giving anything back to that > someone else? It's certainly not fair. Read above again. If you want to make big money you will have to invest MUCH. It is fair to get a corresponding return for that. I dare to claim that Linux distributors have done a lot more for Linux >than Apple has done for the BSDs, partially because licenses forced them >to give back rather than just keeping things closed. I wonder how profitable the Linux distributions are...and will be in the long run... Roland

1 0

Jeremy makes a persuasive argument for LGPL
by dschwarz＠bellatlantic.net 19 Feb '02

19 Feb '02

Well, I'm fairly convinced after reading his argument that LGPL is the right way to go. I think it's better for the Wine project over the long term. For those companies who have built a business model on closed source enhancements to Wine, there is still a way to play the game: At some point Wine is going to improve to the point where the core code works well enough to do almost everything we need. There will always be room for improvement, but the action may shift to reimplementing Microsoft applications that have important APIs (Internet Explorer, Windows Media Player...). I'm sure that Microsoft will change its EULAs to prohibit use of applications such as MSIE on a Non-Microsoft OS. It has already started doing this for some programs. Companies could respond by selling open or closed source reimplementations of these applications, bundled with a LGPL Wine. There will always be plenty of ways to add value on top of the core Wine code. Meanwhile, LGPL ensures that core code improvements will flow back to benefit all, not just those individuals and companies that have an altruistic bent. Regards, Daniel Schwarz dschwarz(a)bellatlantic.net http://www.winecentric.com http://winecentric.com/wiki

9 11

RE: Licensing Open Source in General
by Patrik Stridvall 19 Feb '02

19 Feb '02

> On Mon, 18 Feb 2002, Roland wrote: > > > I think one of the main reason for the xGPL is that > developers have the > > fear that their project might be hijacked and their work > used to make > > profit by some companies. As Brett Glass pointed out, this > is not a fair > > point of view. After all if a companies adds value to a > project by creating > > new features why shouldn't it be allowed to sell it and > make money out of > > it? > > It *IS* a fair point of view - if someone just adds a bit of > value, why > should they be able to make loads of cash of the much bigger > original work > without giving anything back? If somebody just adds a _bit_ of value and are able to make loads of cash on it I or somebody else are very likely to be easily able to duplicate the effort. Try again. > Selling a proprietary fork of an open source application is > much more like > stealing a car, giving it a new paint, and then selling it. > The thief added value (the new paint), so by your argumentation, he > should be able to make money of it and what he's doing is > perfectly ok. First of all copyright and theft have very little to do with each other. Theft by it definition involves depriving somebody from his property. Secondly if the license is the current licence this is obviously legal. Thirdly if it just requires a little "paint" to it make money I or somebody else can duplicate that and make the money instead. > > The GPL prevents this from happening but where is the advantage in > > that? > > Forcing everyone to contribute, preventing this type of theft. What theft? There is no theft going on. With the LGPL copyright infringement might be going on but then as I have trying to explain in countless mails it is easy to circumvent it even with obviously "trickery" that is obviously legal. If you trust your lawyers there are even more "trickery" you can do. > > I think the GPL retricts software development because many good > > projects cannot be done by companies because they are not > allowed to use > > any GPL code as basis of their products. > > They are, if they choose to go by sane licenses. > Releasing products as Open Source certainly hasn't hurt > companies that > aren't scared of doing it. > > On the contrary: Stronghold used to be proprietary before Red > Hat bought > the company making it. Now it's open source and the moment > that happened, > the sales numbers actually went UP (and the price is still > roughly the > same). Stronghold was presumably a WORKING product. Wine is not. If you make comparisions compare situations that are similar. > The problem is that many companies refuse to even consider > sane licenses, > not that they couldn't do it. Well, if that is a problem a complex license like LGPL certainly isn't the answer. > > Personally I keep wondering if it would be that bad if we > had a company > > producing a better version of WINE than the free one. Why > should this be > > bad? > > - it would take users (and therefore potential developers) > away from the > real version. What potential developers? If the source is closed they can't work on it. If the source is available like Transgamings why should they work for them without pay. Why not do as Marcus did and look at the code and reimplement it in the main tree instead. :-) > - why should someone who made just a couple of changes make > lots of profit > from (mostly) someone else's work without giving anything > back to that > someone else? It's certainly not fair. Again, if somebody can make a couple of changes and make money I can duplicate it and make the money instead or for that matter post it on wine-patches.

1 0

Licensing Open Source in General
by Roland 19 Feb '02

19 Feb '02

Hello all, with the ongoing discussion about this topic has brought me to think about licensing open source(OS) in general. I think a broad discussion involving all major OS advocates is long overdue. I think there should be made a webpage somewhere to start discussing this topic on a serious basis. Two important licenses: 1. BSD-style 2. xGPL Many projects are started with the xGPL nowadays. It just seems natural. Any other license for open source looks unnatural at first glance. I think the popularity of Linux has contributed to this. But is the xGPL a good license? I think one of the main reason for the xGPL is that developers have the fear that their project might be hijacked and their work used to make profit by some companies. As Brett Glass pointed out, this is not a fair point of view. After all if a companies adds value to a project by creating new features why shouldn't it be allowed to sell it and make money out of it? The GPL prevents this from happening but where is the advantage in that? I think the GPL retricts software development because many good projects cannot be done by companies because they are not allowed to use any GPL code as basis of their products. The sad thing is that this affects mostly small companies. Big companies can allow themselves to reinvent the wheel, coding everything they need. I think a lot of small businesses could do money out of open source if the licensing allowed this. Linus Torvalds wrote: "But _personally_ I don't want to do significant work under that kind of copyright and having to wonder whether the best version of Wine will be free in the future.." http://groups.google.com/groups?q=Ingo+Molnar+group:comp.emulators.ms-windo… Personally I keep wondering if it would be that bad if we had a company producing a better version of WINE than the free one. Why should this be bad? If you don't like it, you still can use the free version. And look at FreeBSD. AFAIK there is no proprietary version better than the free version. Apple based his OS X on lots of free software and contributed back a lot: http://developer.apple.com/darwin/ This wouldn't be possible with Linux I think. Best regards, Roland

4 3

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 19 Feb '02

19 Feb '02

> At 02:19 AM 2/16/2002, Patrik Stridvall wrote: > > >> So now you've made your point, constantly, how about we just > >> take it for > >> granted that for every email sent to the list saying 'the > gpl is good > >> because...' you and Patrik will reply with 'No! It's evil, > >> RMS is satan, > >> viral licensing, noone will use it, blah blah blah'.... > > > >I have never said that. > >I do admit that Brett Glass have said that. > > No, I never have. You haven't? OK, perhaps not word by word, but I fully understand if people interpret your position that way. I'm sorry if I sound a little angry but it seems that some of people have found me guilty by association with you and that irritates me quite a bit. What you are doing IMHO is pure fear mongering, it will not help the case against LGPL. I firmly believe that the GPL and the LGPL has a place in the world. However that place is not in Wine project. The LGPL is IMHO for libraries that are pure libraries and have all functions implemented. Wine fullfills neither the pure criteria nor the have all functions implemented criteria. In such cases this allows bugfixes to go back, but new functions can be put in the application or in a new library not nessarily in the library itself that have to be under the LGPL. Then companies can choose for themselves whether they want the LGPL protection for their new functions or not.

4 6

RE: TransGaming LGPL clarifications
by Patrik Stridvall 18 Feb '02

18 Feb '02

> > My LGPL concerns are: > > > > 1) We support copy protected CDs in our WineX binary > releases. This support > > This is a valid issue, and I am sure that the Wine community > would more > than happy to provide hooks for you for exactly this purpose. > There's no > other option in this case, so I don't think it' even an issue. Hooks is not possible because it would violate the paragraph 2d of the LGPL. At least according to Alexandre's interpretation of it. Every LGPL:ed function must do what every application expects even if the application (read: execution enviroment) doesn't provide the hook function. Since the hook function in the Transgaming execution enviroment would cause copy protected games to work, according to Alexandre's interpretation copy protected games must also work in the normal Wine execution enviroment that doesn't have the hook function. Of course Alexandre's interpretation might be wrong. However in that case wrapper libraries if definitively allowed and thus the LGPL is all but meaningless for new functionallity. Just put a new functionallity in a proprietary library and add a wrapper that calls it. In that case almost everything most LGPL proponents claim is good with the LGPL is gone. > > 4) Most importantly, the LGPL is a one way road. > > But that's one of it's features, you know... :) It's what gives people > piece of mind, Peace of mind. Ha ha ha. Allow me to laugh. Please, you can weld stuck the rudder of ship and claim that now that the rudder is stuck since we needn't argue anymore and now we can have peace of mind from the endless debates on where we should go. This is not what I would call peace of mind. > and what I feel creates the level playing > field. Whether this is true or not is basicly what the whole debate is about so this is just a unsupported statement of opinion. > Just PD, > and BSD are manyway roads. That is, this is not a valid > point. If you want > to argue that, we're stuck with BSD, period. Of course it a valid point: We can always change to LGPL later it will NEVER be to late. However can you say the same about changing now? > > That said, I believe that my WineCorp suggestions address > both my concerns as well > > as the issues raised by the LGPL camp. > > I personally despise the idea, On practical, and > phylosophical grounds. > And if we go that route, I don't think I'll follow. For the record: I'm not particular fond of the idea either, but mostly for practical reasons. I'm prepared to talk about it though.

1 0

GetStdHandle problem
by Ignasi Villagrasa 18 Feb '02

18 Feb '02

After having some problems, I could recompile and link my programs using Wine. When running, The call to GetStdHandle(STD_OUTPUT_HANDLE) fails. It return 0. In windows enviroment this functions returns a numeric handle I use later to print onto the console. What's happening ? Is this a bug ? Can I solve it changing code ? Thanks in advance. Ignasi Villagrasa.

3 2

Re:compiling problem
by Ignasi Villagrasa 18 Feb '02

18 Feb '02

Thanks for answering to everyone. The problem came from gcc compiler version. I changed it and the problem was solved. Ignasi Villagrasa.

2 1

Re: RESUBMIT: Some more Shlwapi ordinal routines
by Alexandre Julliard 18 Feb '02

18 Feb '02

"Guy L. Albertelli" <galberte(a)neo.lrun.com> writes: > > > dlls/shlwapi/ordinal-cmap.h <--- new file > > > - Has the 32k bytes that are returned by SHGetInverseCMAP. I'm a bit concerned about this one. Do you have an algorithm for generating it, or is it simply a dump of the native dll? This might get us in trouble. -- Alexandre Julliard julliard(a)winehq.com

2 1

Request for wine-license again
by Uwe Bonnes 18 Feb '02

18 Feb '02

Hallo, somebody asked not to send more than two messages regarding this thread. So sorry for my abuse now, but a zillion messages regarding that thread have been exchanged since my last mail... Please, can we have a wine-license list? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

4 3

RE: Clarification on my call for license change
by Patrik Stridvall 18 Feb '02

18 Feb '02

> At 08:58 PM 2/15/02 +0100, Patrik Stridvall wrote: > > >Just because you might possibly be right as far as CodeWeavers > >are concern doesn't nessarily mean that it is good for Wine. > > > > > >Yes and it makes sense that you do because increasing > >the amount of freely available Wine code can only benifit > >you, since you can use it in other projects for other > >customers. > > > Patrik, doesn't this also benefit WINE? If we increase the > amount of freely > available WINE code this is certainly good isn't it? > So there is also a strong argument in favor of the xGPL in your post. If the code is under the LGPL it is not freely available in the same meaning as if it was freely available under BSD. For the end user it is true that it doesn't matter at least not short term. However in the long term if set of viable business models to cover the cost of producing new code are less, less code is likely to be produce. Of course this is not quite that simple because the LGPL forces companies that would have produced the improvement anyway to release it when they would have held on to it for competive advantage or whatever just in case. This amount of code coming from this group is almost impossible to measure how large it is, especially since there are ways to circumvent the LGPL if the need for competetive advantage or whatever is large enough. And no I'm not primary talking about interpreting paragraph 2d of the LGPL in clever ways. That is one way if course but it is probably to legally risky for most companies. You can for exampel build a layer between the application and Wine. Let say Windows API function Foo is not properly implemented. The you do: BOOL LAYER_Foo(DWORD flags) { if(flags & FLAGS_NOT_SUPPORTED_BY_WINE) { /* Implement flags not supported by Wine */ } else { return Foo(flags); /* Call Wine */ } } With some clever macros and/or inline functions you can transpartantly hide the existance of this layer for the application. This quite obviously do not violate the LGPL. Especially not paragraph 2d. So the LGPL will not force the, in the future, hopefully largest group of companies that uses Wine to release anything they would prefer not to release. The things that they don't care about they would anyway even under the current license to save money avoiding the work to maintain it. So frankly I can't really see the great advantages on the LGPL. I can see the drawbacks that I have meantioned before that people just seem to ignore. In short: With the good comes that bad (as always) and futhermore the good might be less than you expect.

1 0

RE: Clarification on my call for license change
by Patrik Stridvall 18 Feb '02

18 Feb '02

> On Fri, 2002-02-15 at 09:49, Roland wrote: > > At 08:19 AM 2/15/02 -0600, Jeremy White wrote: > > >Several people have asked me to clarify my original post. > > > > I just don't understand one thing: > > How does your company expect to make money once WINE is > xGPLed? If all your > > code has to be contributed back, why should I buy it from > your company? > > > > Well, for one, we have a proprietary product that links to > Wine; we would continue to sell that. > > For another, we would continue to sell services to organizations > who wish to use Wine, but can't because it isn't complete enough. > > And finally, we would sell services to organizations that need > to depend on Wine, but cannot do so without the assurance of > qualified support to back up that dependence. So you have answered the first question. CodeWeavers might survive. Good for you. But the second more important question was (in my words): Why should I buy a Wine distribution from you? If you are forced to contribute back everything I can just do: cvs update ; ./configure ; make install What I and other have been trying to say is that some business models like consulting business makes sense with a LGPL:ed Wine but others like Transgaming:s might not. Read what Gavriel wrote in his first(?) reply again.

4 3

compiling problem
by Ignasi Villagrasa 18 Feb '02

18 Feb '02

I have several Win32 console applications. I want to migrate them to Linux, and have installed and configured Wine. My target is to migrate the programs via winelib. So I don't want to run my applications on the fly as windows binary code, but recompile them in Linux enviroment and use following WINE console display functions: WriteConsoleOutput SetConsoleCursorPosition GetStdHandle FlushConsoleInputBuffer SetConsoleMode ReadConsoleOutput ScrollConsoleScreenBuffer GetConsoleCursorInfo SetConsoleCursorInfo GetNumberOfConsoleInputEvents ReadConsoleInput The first step is recompile C modules, but I find unexpected errors. Here is the output I get recompiling code. In file included from /usr/comun/src/mc_vis32.cpp:201: /opt/wine/include/wine/wincon.h:25: parse error before `__attribute__' /opt/wine/include/wine/wincon.h:229: `PHANDLER_ROUTINE' was not declared in this scope . . . Inspecting code, I notice the error always relates to the typedef PHANDLER_ROUTINE. I don't find it in any include and don't know where it's implemented. But the compiler doesn't find it. Does anyone know where to find this definition ? Which include file should I add to compilation process ? Could anyone help me ? Thanks in advance. Ignasi Villagrasa. GRI S.L.

2 1

wineinstall broken
by Christian Jiresjö 18 Feb '02

18 Feb '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Downloaded the cvs this morning (2002-02-18) and found that tools/wineinstall wouldn't run properly. It will stop after the configure step since in the latest configure script generation of config.cache is disabled. Is the wineinstall script depreceated or should it be fixed? Is it the configure-script that should be fixed? A temporary fix is adding --cache-file=config.cache to CONFARGS in wineinstall to reenable config.cache generation. Mvh Christian Jiresjö Key ID / Fingerprint 0x7798D5A3 / 2743 5DC4 1618 F24C F265 3070 A070 5EF2 7798 D5A3 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBPHFBm6A7mjo2YYwkEQKYfQCaAs/wDd7MS3I62gDL/xmTSK4kSVkAoI7j TE+MfkYLdY7HGHKvJLl2RySm =karS -----END PGP SIGNATURE-----

1 0

RE: Clarification on my call for license change
by Patrik Stridvall 18 Feb '02

18 Feb '02

> First of all, let me say that my call for a change was not > based on a single mysterious event. It was triggered > by an event that I cannot discuss due to a confidentiality > agreement. More important, it is a culmination of a number > of events and disturbing trends which I can freely discuss. For the record: As far as I'm concerned, I do believe you, when you say that. This however doesn't mean that your conclusion is correct. In your case there is really two questions: Is LGPL good for CodeWeavers? Is LGPL good for Wine? Just because you might possibly be right as far as CodeWeavers are concern doesn't nessarily mean that it is good for Wine. > We've already discussed the concern with the InstallShield > related patches of Transgaming; I won't belabor > that now. But doesn't it bother anyone else that > Marcus spent 5 weeks redoing work that they already had? I think this perfectly illustrates the danger in believing that not giving back things that are not strategically important for a specific business model is a viable thing to do. That said, I do regret that Marcus had to spend time to in concrete terms illustrating that point. > Wouldn't you rather be able to better play Monkey Island instead? Actually no, I don't like Monkey Island. :-) Seriously, I don't think anybody believe that double work is good, so the answer is pretty obvious. > I have always felt that in order for Wine to progress, > it was important that changes to Wine be returned > to the Wine project. Yes, so far we agree. > It has always been clear to me > that if everyone returns the work, in the long run, > everyone benefits. I think the flaw in your thinking lies here. At first glance this seems to be an obviously true statement. However, if you analyze it more carefully, you will find that it is not nessarily so that the persons that benefits from the work are the same people that are able to do the work. This is not a problem if you have a free market, then the people that benefits for the work will hire those people that can do the work if the benefit outweights the costs. If futhermore some sort of work protection exist then you can more efficiently share the cost since you don't have to worry that somebody steals (read: copies) the work after it is done and can try to recoup the remaining, costs after you have done the work. In short: With work protection people able to do the work don't need to find enough people benefiting from a work to cover all the costs from start. The LGPL means that no work protection exists anymore you have to give the work back and thus people doing the work must have full costs covered before doing the work. You can absurdly enough compare it to a world without copyright protection. The arguments against using the LGPL for a project is basicly the same as the one for having copyright protection in the world. Now you probably think I'm a total nutcase. You will probably say: "The arguments for copyright protection can clearly not be the same as the one against LGPL." No they can't, of course not, but I didn't say that: Notice the difference of scale "for a project" compared to "in the world". This makes your statement below false, since it the dual of your statement, a IMHO good slogan for people that believes all information should be free is the following: "If everybody can use everybody else work, in the long run, everybody benefits" You see the similarity don't you? This is of course not a conclusive argument against the LGPL, I do not claim it is, but it still makes your statement false. > So, with each and every one of my major > customers over the past three years, I have had a major, knock > down, drag out fight over licensing. I have always > insisted that changes we make to Wine be returned to > Wine. This has meant (while in a sales situation) > explaining the complexities of BSD versus GPL > licenses. Yes and it makes sense that you do because increasing the amount of freely available Wine code can only benifit you, since you can use it in other projects for other customers. >From this doesn't follow that LGPL is a good license from Wine. It might marginally simplify your life at a terrible price. Some questions: Wouldn't abolishing copyright simplify your life? Probably? Right? Would you be prepared to pay the price? Probably not? Right? > Wine still requires huge capital investments to > make it work, and any company that is going to > invest hundreds of thousands of dollars is > naturally going to demand ownership of the resulting > work product. It it were LGPL, it would be > an easy negotiation - I'd just say "Sorry, can't > do it." End of story. If copyright didn't exists you could release the code anyway, but as I said you wouldn't want to pay the price would you? > I know that the naysayers will jump on this and say > "Oh, but then you wouldn't have had any customers, > they would have been scared away by the LGPL." > To this I respond very simply: bullshit. > I was there for each of these sales processes, > and each customer was primarily interested > in the end result, not in the nitty gritty > license details. The question is not whether LGPL scare away your customers, the question is whether it scares away other businesses from investing in Wine. Obviously specialist consulting services like CodeWeavers can survive in any market almost regardless of the rules of the market, as I explain in another mail. This is quite unintresting as far as LGPL is concerned though. > There is an analogy I recall from when I took > a physics and public policy class. If a physicist > stands up and says "It's a bad idea to build > chemical weapons" nobody will listen to the physicist's > opinion - they just get a different physicist to do the > dirty work. If, instead, she stands up and says "It won't work. > The inverse poleron field conclusively prevents that." > There is no more debate, and public policy moves on to protecting > chickens from acid rain or something else. Obviously, if something is impossible then it is. > So, my business is threatened, because CodeWeavers > is trying to be the best physicists in town. > If I, as a matter of principle, refuse > to work on chemical weapons, I lose business because > my customers hire different physicists who will > build chemical weapons. OK. I can see your point but that comes with as I said a terrible price. > Okay, let me drop the analogy and come back to > straightforward facts. If I believe in the LGPL, > and release all of my code to WineHQ under the > BSD despite that, then I am a fool. Transgaming, > Lindows, name your new competitor, each of them > can take the best of my work and use it in their > product. The world is not a simple place. There are few things that are 100% wrong or 100% right. Yes, you can get some "protection" but are you prepared to pay the price? > I'm sure Transgaming doesn't have any problem using any > of the great new Window management code or > Window messaging code we wrote. In fact, the > InstallShield 6 stuff wouldn't be *possible* > without that code. However, if I had it to do > over again, I would not have released that code > under the BSD license. Please note what Dimitrie O. Paun said that the LGPL only extends to the DLL boundaries. That was one of the few things everybody seemed to argee on, even Alexandre last debate. So even with LGPL, they could still have used it. the DCOM stuff they did was in another DLL. I must emphasize this. This is VERY IMPORTANT that you realize. > So, I think there are several fundamental problems: > > 1. The current license encourages forks. > > We have the WineX fork; I think that Lindows > is still formulating their strategy, but > they have publicly stated that they like > having some proprietary pieces, this certainly > suggests another fork of Wine. > > You can argue that the pain of maintaining > a separate fork is so great, and the work of > merging in the BSD code is so hard, that people will > just naturally contribute their code back. > > We do merges of six month drifts on a regular > basis; it's just not that painful (the last > one took Francois 2 days; the resulting bug > fixes probably took 3 or 4 days). The question is not how hard it is rather why they would want to waste any resources on it at all. Most companies would benefit very little from not submitting non strategic code. > If this argument held any water, then Transgaming > would have just been forced to contribute > the Direct3D and IS6 support back. The Direct3D stuff is quite seperate and the IS6 stuff are IIRC in quite seldom changed parts of Wine. Your real world example is not very good. > 2. The current license discourages competitors > from releasing their code. > > Since I believe in the LGPL, but compete with Transgaming > and Lindows, contributing my code under the current license > is like giving my competitors my very best and getting nothing > in return. > > You know, the concept of making money on Free > software is crazy > enough without enabling your competitors into the mix. > > And, much as Gav and I are friends, we do compete. I > have been > in > sales situations with embedded customers where gaming > expertise > was required. Now, Gav has the best of what I can do, and I > have > little or none of what Transgaming did. > > In hindsight, if I had it to do over again, > I would have held out all code we had done > over the past year or two. Where would Wine > and Transgaming be if we had done that? Hard to tell. But everything comes with a price. Will you pay it? And even if if you will. Should Wine? > 3. The current license is harmful to the growth > of Wine, because it creates a murky, uncertain ground. > > This is true for a lot of reasons. First, I think > we all sort of kind of hope that any corporate > Wine citizens will follow some sort of unwritten > ethical code of conduct. That is, we'd like > the corporate citizens to pitch in and help Wine > to grow. > > Having unwritten rules is foolish, IMO. > > The current license specifies: go ahead and do > anything you want - we don't care. But I think > we do care (*I* care). So corporate citizens > spend all their time worrying about this > middle ground of perception (how much time > do you think this debate is taking away from > my people, and the Wine hacking they could do?) > > Well, a Copyleft license provides potential > corporate citiziens with written rules. > > Second, it clarifies the code issues. Right now, > say I wanted to work on a game. Well, gosh, just > how should I do that? Should I work against the WineX > tree? But if I do that, I can't really talk about > it on wine-devel, and I can't really share my work > with others. Ah heck, maybe Transgaming will fix > my game. I'm just going to reboot over to Windows. > > And if you don't think that's a serious problem, > just look at the Wine project historically. Over > the past five years, game related patches have > overwhelmingly dominated wine-devel. Over the > past 12-18 months of Transgaming? Virtually dead. > > Add to that the new problem of CodeWeavers now > being unwilling to contribute their code under > the current license. > > In my opinion, all the developers will just throw > up their hands and go work on something else, and > I think that would be a great tragedy. Well we will see, however we should think both once or twice before going down the one way street that LGPL is. > I hope that helps. > > Looking back on this, I see nothing but kindling. > > If you want to raise a point or an argument that is a variation on > something we've heard before, just don't. > > And if you're not a contributor to Wine, please don't > respond at all. You can flame me privately. Or go find a different > mailing list. > > I would really prefer to hear only what Wine contributors > think about this. Well, I really hope I qualify. Read what I have written and think about it. > p.s. For the record, in my mind, Dan Kegel qualifies as a major > contributor to Wine. It is through his hard work that we > have a chance > that the U.S. court system will put into place systems that will make > Wine development easier and protect Wine from predatory action > from Microsoft. I guess that was I stab at me. As explaination I was irritated on all non-contributors that posted their crap, so I just happend to take it out on somebody whose name I didn't recognize, so I'm sorry that Dan Kegel happend to get in the way.

2 1

Scrollbar: Overflow
by Phillip Ezolt 18 Feb '02

18 Feb '02

Hi, I've been trying to fix up the code in controls/scrollbar.c to deal with overflow of a 32-bit int, but I've run into a problem. In my test application, InfoPtr->MaxVal= is 0x7FFFFFFF (The largest signed int). InfoPtr->MinVal = 0. However, in various places in the code "infoPtr->MaxVal-infoPtr->MinVal+1" is calculated. This wraps the value around and causes bad things to happen. Does anyone know if the "+1" is necessary? Something has to be done differently, because what is happening now isn't right. --Phil Compaq: High Performance Server Systems Quality & Performance Engineering --------------------------------------------------------------------------- Phillip.Ezolt(a)compaq.com Performance Tools/Analysis

1 0

Re: I've tried to change keyboard table.. No good...
by Björn Róbertsson 18 Feb '02

18 Feb '02

Please give us a solution! I see that the only "solution" for this has been Thomas' Quinots patch for x11lib, which only works for XFree 3.3.1 which is only available in some ancient ... well considering we'd prefer to run RedHat 7.X or SuSE 7.X or Mandrake 8.X running RH 5.0 is somewhat too old... I've done the Xmodmap thing and it does work for me, but I cannot suggest Linux as an alternative desktop solution. Bjorn Robertsson bjornr(a)nyherji.is

1 0

Re:compiling problem
by Ignasi Villagrasa 18 Feb '02

18 Feb '02

Thanks for answering at first, Eric. I'm using gcc version 2.91.66, the default compiler for Red Hat 6.2, and this is the operative system I'm interested in.

1 0

Re:compiling problem
by Eric Pouech 18 Feb '02

18 Feb '02

> In file included from /usr/comun/src/mc_vis32.cpp:201: > /opt/wine/include/wine/wincon.h:25: parse error before `__attribute__' > /opt/wine/include/wine/wincon.h:229: `PHANDLER_ROUTINE' was not declared > in this > scope which compiler do you use? (name and version and which platform ?) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

1 0

Clarification on my call for license change
by Jeremy White 18 Feb '02

18 Feb '02

Several people have asked me to clarify my original post. I apologize for not replying sooner; to be honest, I have been hoping that the flames would die down, and I was very reluctant to fan the flames in any way. Further, I'm not sure if I have anything to add other than kindling. But, I don't mean to 'hide', so here goes. First of all, let me say that my call for a change was not based on a single mysterious event. It was triggered by an event that I cannot discuss due to a confidentiality agreement. More important, it is a culmination of a number of events and disturbing trends which I can freely discuss. We've already discussed the concern with the InstallShield related patches of Transgaming; I won't belabor that now. But doesn't it bother anyone else that Marcus spent 5 weeks redoing work that they already had? Wouldn't you rather be able to better play Monkey Island instead? I have always felt that in order for Wine to progress, it was important that changes to Wine be returned to the Wine project. It has always been clear to me that if everyone returns the work, in the long run, everyone benefits. So, with each and every one of my major customers over the past three years, I have had a major, knock down, drag out fight over licensing. I have always insisted that changes we make to Wine be returned to Wine. This has meant (while in a sales situation) explaining the complexities of BSD versus GPL licenses. Wine still requires huge capital investments to make it work, and any company that is going to invest hundreds of thousands of dollars is naturally going to demand ownership of the resulting work product. It it were LGPL, it would be an easy negotiation - I'd just say "Sorry, can't do it." End of story. I know that the naysayers will jump on this and say "Oh, but then you wouldn't have had any customers, they would have been scared away by the LGPL." To this I respond very simply: bullshit. I was there for each of these sales processes, and each customer was primarily interested in the end result, not in the nitty gritty license details. There is an analogy I recall from when I took a physics and public policy class. If a physicist stands up and says "It's a bad idea to build chemical weapons" nobody will listen to the physicist's opinion - they just get a different physicist to do the dirty work. If, instead, she stands up and says "It won't work. The inverse poleron field conclusively prevents that." There is no more debate, and public policy moves on to protecting chickens from acid rain or something else. So, my business is threatened, because CodeWeavers is trying to be the best physicists in town. If I, as a matter of principle, refuse to work on chemical weapons, I lose business because my customers hire different physicists who will build chemical weapons. Okay, let me drop the analogy and come back to straightforward facts. If I believe in the LGPL, and release all of my code to WineHQ under the BSD despite that, then I am a fool. Transgaming, Lindows, name your new competitor, each of them can take the best of my work and use it in their product. I'm sure Transgaming doesn't have any problem using any of the great new Window management code or Window messaging code we wrote. In fact, the InstallShield 6 stuff wouldn't be *possible* without that code. However, if I had it to do over again, I would not have released that code under the BSD license. So, I think there are several fundamental problems: 1. The current license encourages forks. We have the WineX fork; I think that Lindows is still formulating their strategy, but they have publicly stated that they like having some proprietary pieces, this certainly suggests another fork of Wine. You can argue that the pain of maintaining a separate fork is so great, and the work of merging in the BSD code is so hard, that people will just naturally contribute their code back. We do merges of six month drifts on a regular basis; it's just not that painful (the last one took Francois 2 days; the resulting bug fixes probably took 3 or 4 days). If this argument held any water, then Transgaming would have just been forced to contribute the Direct3D and IS6 support back. 2. The current license discourages competitors from releasing their code. Since I believe in the LGPL, but compete with Transgaming and Lindows, contributing my code under the current license is like giving my competitors my very best and getting nothing in return. You know, the concept of making money on Free software is crazy enough without enabling your competitors into the mix. And, much as Gav and I are friends, we do compete. I have been in sales situations with embedded customers where gaming expertise was required. Now, Gav has the best of what I can do, and I have little or none of what Transgaming did. In hindsight, if I had it to do over again, I would have held out all code we had done over the past year or two. Where would Wine and Transgaming be if we had done that? 3. The current license is harmful to the growth of Wine, because it creates a murky, uncertain ground. This is true for a lot of reasons. First, I think we all sort of kind of hope that any corporate Wine citizens will follow some sort of unwritten ethical code of conduct. That is, we'd like the corporate citizens to pitch in and help Wine to grow. Having unwritten rules is foolish, IMO. The current license specifies: go ahead and do anything you want - we don't care. But I think we do care (*I* care). So corporate citizens spend all their time worrying about this middle ground of perception (how much time do you think this debate is taking away from my people, and the Wine hacking they could do?) Well, a Copyleft license provides potential corporate citiziens with written rules. Second, it clarifies the code issues. Right now, say I wanted to work on a game. Well, gosh, just how should I do that? Should I work against the WineX tree? But if I do that, I can't really talk about it on wine-devel, and I can't really share my work with others. Ah heck, maybe Transgaming will fix my game. I'm just going to reboot over to Windows. And if you don't think that's a serious problem, just look at the Wine project historically. Over the past five years, game related patches have overwhelmingly dominated wine-devel. Over the past 12-18 months of Transgaming? Virtually dead. Add to that the new problem of CodeWeavers now being unwilling to contribute their code under the current license. In my opinion, all the developers will just throw up their hands and go work on something else, and I think that would be a great tragedy. I hope that helps. Looking back on this, I see nothing but kindling. If you want to raise a point or an argument that is a variation on something we've heard before, just don't. And if you're not a contributor to Wine, please don't respond at all. You can flame me privately. Or go find a different mailing list. I would really prefer to hear only what Wine contributors think about this. Jeremy p.s. For the record, in my mind, Dan Kegel qualifies as a major contributor to Wine. It is through his hard work that we have a chance that the U.S. court system will put into place systems that will make Wine development easier and protect Wine from predatory action from Microsoft.

17 29

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 17 Feb '02

17 Feb '02

> Patrik Stridvall wrote: > > > But the point I'm trying to make is that I can be in violation of > > > your RELICENSE. I can make a claim that YOUR work is > > > covered by the *GPL, so that your RElicense to me doesn't apply. > > > If this holds, then my original statement that you gave up your > > > copyright protection holds. > > > > I'm not sure I follow you. > > > > Yes, if my work is covered by *GPL, you can ALWAYS use it if you > > follow the conditions in the license. > > yes, even if it contradicts your relicense. If you "work on" > an *GPLed > product, what you do is automatically claimed by *GPL, thus you can't > make any license on your work that is *GPL free. The *GPL only claim parts that are considered a derived work of the *GPL work. So if I write a function A and use that to improve the implementation of a *GPL:Ed function B, the *GPL claims my function A under the *GPL because of the existance of code in B calling my function A and thus the work I distribute as a whole includes my function A as a derived work. However my function A in and of itself is not a derived work of the *GPL:ed work so the *GPL only claims the function A as a part of what I did above. This means that I can relicense the implementation of function A under another license and the *GPL can't claim any indepedent modifications to it since it is not by itself a derived work of the *GPL:ed work. > > Of course, if you later decide that oh well following the *GPL > > is not that bad in comparison after all, it is possible and > > even probably that I can't sue you for breaking the relicense > > as long as you follow the *GPL. > > and if your are relying on your copyright protection to allow you > to benefit on the relicense, you don't have it in this case. > Remember also that the *GPL is pretty much irrelevent so long > as you are > not distributing to the public, so it's not a great cost to choose to > go that route. If you are not distributing to the public you don't need a relicense, the *GPL only forces you to release your work if you distribute to the public. > > The point it that you must show that you follow either *GPL > > or my relicense in order to not be a copyright infringer. > > You don't have to follow both though. > > It's a little different, because I think the burden of proof is > different. Pending on the what you have in your relicense, it's > easy to show that the receiver is covered because they have the > software. On a GPL violation, you have to show that what they are > doing with the software is in violation of the license - which might > be much harder to show. I think we are coming to much of topic by discussing the burden of proof. The point is that if you distribute without the permission of the *GPL or my relicense you are a copyright infringer. Whether in pratice I can detect it or prove it, is irrellevant as far as choosing a license for Wine is concerned.

1 0

Update: Compiling with Winelib and msvcrt
by David Walser 17 Feb '02

17 Feb '02

I modified the winemaker command I issued to: winemaker --console -I/usr/include/wine/msvcrt -I/usr/include/wine/wine -L/usr/lib/wine -lmsvcrt -lkernel32 --single-target ex3 . and now: c++ -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o ex3.so ex3.o ex3.spec.o -L/usr/lib/wine -lmsvcrt -lkernel32 -L/usr/lib -lwine -lwine_unicode -lwine_uuid -lm -L/usr/lib/wine ex3.o: In function `main': /home/walser/cosc/450/ex3/ex3.cpp:25: undefined reference to `GetSystemTime' /home/walser/cosc/450/ex3/ex3.cpp:43: undefined reference to `GetSystemTime' test -e ex3 || ln -s /usr/bin/wine ex3 so that's progress. I thought GetSystemTime was in kernel32, and doing strings on it shows it is (as well as in several others). What should I be linking in for GetSystemTime? Thanks.

1 0

Compiling with Winelib and msvcrt
by David Walser 17 Feb '02

17 Feb '02

Hi, I'm trying to compile a simple Win32 console app ( http://luigiwalser.homeip.net:8080/~walser/cosc/450/ex3/ex3.cpp if you want to see it). I did: winemaker --console -I/usr/include/wine/msvcrt -I/usr/include/wine/wine -imsvcrt.dll --single-target ex3 ./configure --with-wine-libraries=/usr/lib --with-wine-includes=/usr/include/wine --with-wine-dlls=/usr/lib/wine --with-wine-tools=/usr/bin But make ends like this: gcc -c -g -O2 -fPIC -D_REENTRANT -DWINELIB -I. -I/usr/include/wine/msvcrt -I/usr/include/wine/wine -I/usr/include/wine -o ex3.spec.o ex3.spec.c c++ -shared -Wl,-rpath,/usr/local/lib -Wl,-Bsymbolic -o ex3.so ex3.o ex3.spec.o -L/usr/lib -lwine -lwine_unicode -lwine_uuid -lm ex3.spec.o: In function `__wine_exe_main': /home/walser/cosc/450/ex3/ex3.spec.c:52: undefined reference to `__wine_get_main_args' /home/walser/cosc/450/ex3/ex3.spec.c:53: undefined reference to `ExitProcess' ex3.o: In function `main': /home/walser/cosc/450/ex3/ex3.cpp:25: undefined reference to `GetSystemTime' /home/walser/cosc/450/ex3/ex3.cpp:36: undefined reference to `_beginthread' /home/walser/cosc/450/ex3/ex3.cpp:37: undefined reference to `Sleep' /home/walser/cosc/450/ex3/ex3.cpp:43: undefined reference to `GetSystemTime' /home/walser/cosc/450/ex3/ex3.cpp:47: undefined reference to `Sleep' /home/walser/cosc/450/ex3/ex3.cpp:49: undefined reference to `Sleep' ex3.o: In function `threadWork(void *)': /home/walser/cosc/450/ex3/ex3.cpp:81: undefined reference to `Sleep' test -e ex3 || ln -s /usr/bin/wine ex3 Note: it is computer science HW but building it with WINE isn't part of the homework, so I'm not asking you to do my HW for me :o) http://facultyfp.salisbury.edu/taanastasio/COSC450/Spr02/Assignments/Exerci… is the assignment. Info about my WINE installation: It's WINE 20011226 compiled from Mandrake SRPMS, the packages I have are: wine libwine1 libwine1-devel wine-utils you can look on rpmfind.net if you want to see what they include. Can anybody please help me get this working? Last note: if this is a mailing list, I'm not subscribed to it. Thanks.

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 17 Feb '02

17 Feb '02

> > > if you have to give out an unlimited, royalty free license to your > > > work, I think it's not unfair to say that you have given up your > > > copyright protection. As the copyright holder, it's true that you > > > can relicense it to suit other licenses, but it's not clear to me > > > that you can clearly make a copyright infringment case if there is > > > an LGPLed copy in the public. > > Well if somebody uses my work in a way either not permitted by LGPL > > or explicitly permited by me through some other license I can't see > > why I can't sue. > > But the point I'm trying to make is that I can be in violation of > your RELICENSE. I can make a claim that YOUR work is > covered by the *GPL, so that your RElicense to me doesn't apply. > If this holds, then my original statement that you gave up your > copyright protection holds. I'm not sure I follow you. Yes, if my work is covered by *GPL, you can ALWAYS use it if you follow the conditions in the license. However if you for some reason can't or won't, you can ask me for a relicense. If you don't I can sue you for violating the *GPL. If you do, you have to follow the conditions of the new license otherwise I can sue you. Of course, if you later decide that oh well following the *GPL is not that bad in comparison after all, it is possible and even probably that I can't sue you for breaking the relicense as long as you follow the *GPL. The point it that you must show that you follow either *GPL or my relicense in order to not be a copyright infringer. You don't have to follow both though.

2 1

winsock.h vs. unistd.h
by Francois Gouget 17 Feb '02

17 Feb '02

Here's a patch that takes care of the current winsock.h vs. unistd.h incompatibility. I am only half happy with it as it means that winsock.h will include unistd.h if you have not done so already. This is the only way I see to support both #include <unistd.h> #include <windows.h> and #include <windows.h> #include <unistd.h> If the patch is modified to handle only the first case, then winsock.h does not need to include 'unistd.h'. Index: include/winsock.h =================================================================== RCS file: /home/wine/wine/include/winsock.h,v retrieving revision 1.39 diff -u -r1.39 winsock.h --- include/winsock.h 2002/01/29 02:55:41 1.39 +++ include/winsock.h 2002/02/17 18:53:38 @@ -63,6 +63,26 @@ # define WS_DEFINE_HTONL #endif /* __WINE_USE_MSVCRT */ +#ifndef USE_WS_PREFIX +/* One cannot include both winsock.h and unistd.h because their definition + * of gethostname() conflicts. This is normally not a problem in Winelib + * applications because unistd.h does not exist on Windows and thus Windows + * source code should not use unistd.h. + * But there are still situations where one may want to use both so we are + * taking some specific steps to avoid problems. + */ +# ifdef R_OK +/* unistd.h has already been defined */ +# define gethostname You_should_not_include_unistd_h +# else +# define gethostname unix_gethostname +# include <unistd.h> +# undef gethostname +# define WS_DEFINE_GETHOSTNAME +# endif /* R_OK */ +#else +# define WS_DEFINE_GETHOSTNAME +#endif /* USE_WS_PREFIX */ /* @@ -898,7 +918,9 @@ int WINAPI WS(connect)(SOCKET,const struct WS(sockaddr)*,int); struct WS(hostent)* WINAPI WS(gethostbyaddr)(const char*,int,int); struct WS(hostent)* WINAPI WS(gethostbyname)(const char*); +#ifdef WS_DEFINE_GETHOSTNAME int WINAPI WS(gethostname)(char*,int); +#endif int WINAPI WS(getpeername)(SOCKET,struct WS(sockaddr)*,int*); struct WS(protoent)* WINAPI WS(getprotobyname)(const char*); struct WS(protoent)* WINAPI WS(getprotobynumber)(int); -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

1 0

Re: Clarification on my call for license change
by Roger Fujii 17 Feb '02

17 Feb '02

David Elliott <dfe(a)tgwbd.org> wrote: > > but I have yet to see a successful mode that has no propriatary component. > At the moment, this is true. Most of the open source companies have at > least some proprietary software built on top of an open source foundation. [snip] > I think that in fact > it will become much more viable. The key is that in order to make this > model work you need to be selling to a market that is unable or unwilling > to provide their own support. As mentioned before, Red Hat may not be > doing great, but if you take into account that they have a very small > viable market (that is, the people actually willing to pay for support) > then they are doing pretty damn well. don't know about that. Considering their cost of goods conceptually is zero... As for support, I don't see it ever being a panacea for the industry. Various models for support have already been tried by commerical companies with varying levels of success. However, there's a really bad side to this model, as it puts the economic incentive on generating support calls - which means that there is LESS incentive for fixing bugs (even in site support, you're less apt to buy it if the program is trouble free). > > > It is these sorts of people and companies that we want to target. And > > > financially Patrik's money for his license or even the money form all > > > the wine developers would be nearly insignificant compared to a 100+ > > > seat site license. > > uh, how can you sell a N-seat site license with something that is covered > > by *GPL (since this would be a violation of the license)? If your model > > is to sell by seat, I would like you see the reasoning between the > > difference of a 10 seat license and a 100 seat license with the *GPL. > If you are selling support then you can most definitely sell per-seat. If that what they are doing (Selling a support contract for N seats). Hard to tell by the wording. > You cannot expect to sell a free product without some sort of value > added. That value can be a proprietary component or can be support for > free components or can be other stuff that no-one as yet thought of. If > your business model is to sell only what your customers can get for free > then you are really, really, really, stupid. no argument here. > > As I said before, if a copyleft is all that is needed, choose a copyleft > > that makes SENSE. LGPL may be convienient, but I have seen no rational > > argument in having the *GPL's brand of copyleft (other than it's widely > > used). I think the mozilla project would be a good place to look... > > > This is a very valid argument. Although realize that they are now > MPL/LGPL/GPL triple licensed. And the only reason I could see for having > the MPL in there was so Netscape can take the code and release > closed-source versions. maybe so, but I think that LGPL/GPL was ADDED because mozilla touched too many things under those licenses. MPL has a 1 year grace period, plus its copyleft is not nearly as viral. I'm not saying it's perfect, but is a good place to start. > This doesn't really work well for Wine as the codebase is not owned\ > by a single entity. well, that benefit wouldn't be realized, but there is more to the license. > If you have a copyleft license that you feel would make more sense for > Wine than the LGPL, please discuss it with us. There's a gazillion licenses. Haven't seen any concensus on what the license should have (just what it SHOULDN'T have). Would think anything FSF considers a weak copyleft would be something to look at IF you want a copyleft. Wonder if Gav has any opinions on a copyleft license... -r -r

2 2

Fun with argv
by Paul Millar 17 Feb '02

17 Feb '02

Hi everyone, I've been looking at the installer for Office97. You call setup.exe which runs acmsetup.exe with a bunch of options, specifically: 'E:\~MSSETUP.T\~msstfof.t\acmsetup /T Off97Pro.stf /S "D:\office\" ' Here, I've used single quotes to delimit the string. I'll carry on this convention because it will get confusing otherwise. The problem is build_argv() assumes the command line is suitably escaped (as from a bash command line, for example), and so mangles the above line to the following values: 'E:\~MSSETUP.T\~msstfof.t\acmsetup' '/T' 'Off97Pro.stf' '/S' 'D:\office" ' But, the fun continues as you can pass arguments to setup.exe, which augment the arguments passed to acmsetup.exe, so running: wine setup.exe 'a a' '"b "B' results in argv[] for setup.exe being: 'setup.exe' 'a a' '"b "B' setup.exe then calls GetCommandLineA, which returns: 'setup.exe "a a" "\"b \"B"' and then it tries to exec 'E:\~MSSETUP.T\~msstfof.t\acmsetup /T Off97Pro.stf /S "D:\office\" "a a" "\"b \"B"' A command line with both unix-style escaped quotes and normal text. The build_argv result is: 'E:\~MSSETUP.T\~msstfof.t\acmsetup' [...] '/S' 'D:\office" a' 'a "b' '"B' and subsequent call to GetCommandLineA returns: 'E:\~MSSETUP.T\~msstfof.t\acmsetup /T Off97Pro.stf /S "D:\office\" a" "a \"b" \"B' What a mess! >From what I can see, the problem is ENV_BuildCommandLine build a command line that is \-escaped (" => \" and \ => \\). Windows programs might use this as part of a WinExec call (as above), which in general is not \-escaped. The only way around this problem (I could think of) is to stop ENV_BuildCommandLine from \-escaping the command line. This implies that we cannot accept double-quotes on the command line as part of an argument. I have a patch which is a hack-and-slash to remove the \-escaping and the resulting build processes arguments consistently (and Office97 setup gets a bit further). However, someone's obviously gone to the trouble of coding in support for double-quotes, so is this needed? Is there an alternative solution? Cheers, Paul.

4 6

Re: Wine license change
by David Elliott 17 Feb '02

17 Feb '02

On 2002.02.09 18:31 Brett Glass wrote: > At 04:06 PM 2/9/2002, David Elliott wrote: > > >Yes, the purpose of LGPL is to force proprietary components to be in > seperate relinkable object files. > > I wouldn't call this its "purpose," just one of its many requirements. > The purpose of the FSF is to eliminate all commercial software and > compromise programmers' livelihoods (as Stallman specifically writes > in many places, including his "GNU Manifesto"). > Really???? The FSF's purpose is to elimnate all proprietary software???? Who'da thunk it? Is there someone who doesn't know this.. it's written all over the website.. jesus, you act like it's some big secret. > >The only symbols you'll have to export from these proprietary > > [Snip] > > Not proprietary, but commercial. > No, proprietary. You can both sell and develop free software as a commercial entity. End of discussion. Everything CodeWeavers has put into Wine is commercial, but it is not proprietary. I see you seemed to concede my point that you only need show the symbols you are exporting. > >And don't be concerned about looking at LGPL code either. I too develop > proprietary software and I develop some of that software using free > (LGPL) libraries. There is nothing preventing me from looking at the > source to these libraries I am using. > > Yes, there is. If you write anything like it -- ever -- the owner of the > copyright on the code you have perused can claim that what you wrote is > a derivative work and demand that you forfeit all rewards from it. This > is > one of the many hidden "booby traps" in the GPL and LGPL. > This is classic FUD. Fits the definition perfectly. Fear, Uncertainty, and Doubt. > As the licenses' viral spread has continued, the FSF and other zealots > have gradually gotten bolder and bolder. While they have not played this > card yet, they can -- and will -- if they see it as being to their > advantage > in their war against commercial software developers everywhere. > The FSFs purpose and goals are irrelevant. The Wine developers purpose and goals are what is relevant. I see you are clearly interested in not helping Wine, but instead making sure that Wine stays both free software and free for you to fold into proprietary products. -Dave

18 45

Re: Bug in ICO_ExtractIconExW
by Gerard Patel 17 Feb '02

17 Feb '02

At 03:01 PM 2/17/02 +0100, you wrote: >Hi, > >I have a systematic crash when browsing a folder which has a *.gz file >inside (for example using GetOpenFileName). <snip> >=>0 0x4082ba06 (ICO_ExtractIconExW+0x386(lpszExeFileName=0x403c4558, >RetPtr=0x405c59a8, nIconIndex=0xffffff69, nIcons=0x1, cxDesired=0x20, >cyDesired=0x20) [exticon.c:325] in libuser32.so) (ebp=405c5910) > 1 0x4082c1c5 (PrivateExtractIconsW+0xf5(lpwstrFile=0x403c4558, >nIndex=0xffffff69, sizeX=0x20, sizeY=0x20, phicon=0x405c59a8, w=0x0, >nIcons=0x1, y=0x0) [exticon.c:555] in libuser32.so) (ebp=405c5948) > 2 0x4082c251 (PrivateExtractIconsA+0x71(lpstrFile=0x405c5a20, >nIndex=0xffffff69, sizeX=0x20, sizeY=0x20, phicon=0x405c59a8, w=0x0, >nIcons=0x1, y=0x0) [exticon.c:578] in libuser32.so) (ebp=405c597c) > 3 0x4065ed8d (SIC_LoadIcon+0x3d(sSourceFile=0x405c5a20, >dwSourceIndex=0xffffff69) [iconcache.c:115] in libshell32.so) (ebp=405c59b8) > 4 0x4065eeb9 (SIC_GetIconIndex+0xb9(sSourceFile=0x405c5a20, >dwSourceIndex=0xffffff69) [iconcache.c:154] in libshell32.so) (ebp=405c5a00) > 5 0x4065f32c (PidlToSicIndex+0xcc(sh=0x403c48f4, pidl=0x403b6cb0, >bBigIcon=0x0, uFlags=0x0, pIndex=0x405c5b58) [iconcache.c:311] in >libshell32.so) (ebp=405c5b3c) Well, this value of 0xffffff69 is suspicious. I think that this code may be too optimist : BOOL HCR_GetDefaultIcon (LPCSTR szClass, LPSTR szDest, DWORD len, LPDWORD dwNr) { HKEY hkey; char sTemp[MAX_PATH]; char sNum[5]; DWORD dwType; BOOL ret = FALSE; TRACE("%s\n",szClass ); sprintf(sTemp, "%s\\DefaultIcon",szClass); if (!RegOpenKeyExA(HKEY_CLASSES_ROOT,sTemp,0,0x02000000,&hkey)) { if (!RegQueryValueExA(hkey, NULL, 0, &dwType, szDest, &len)) { if (dwType == REG_EXPAND_SZ) { ExpandEnvironmentStringsA(szDest, sTemp, MAX_PATH); strcpy(szDest, sTemp); } if (ParseFieldA (szDest, 2, sNum, 5)) *dwNr=atoi(sNum); ParseFieldA (szDest, 1, szDest, len); ret = TRUE; } RegCloseKey(hkey); } TRACE("-- %s %li\n", szDest, *dwNr ); return ret; } in this case, maybe you could try something like : if (ParseFieldA(szDest, 2, sNum, 5)) *dwNr = atoi(sNum); else *dwNr = 0; I'm not sure it's correct, since it would mean that Wine would always search for the icon 0 in the file. As I don't know what is the exact meaning of the icon number in the registry, I can't say more. However, it *should* not crash anymore (if I'm right) as at least dwNr would be initialized. Gerard

2 1

Bug in ICO_ExtractIconExW
by mehmet yasar 17 Feb '02

17 Feb '02

Hi, I have a systematic crash when browsing a folder which has a *.gz file inside (for example using GetOpenFileName). In my system, the icon of "gz" files are associated to an external "ico" file, I see it with --debugmsg +shell : warn:shell:ParseFieldA ("C:\\PROGRAM FILES\\POWERARCHIVER\\ICONS\\GZIP.ICO",0x00000002,0x405c574c,5) semi-stub. The crash happens in line 325 of exticon.c: RetPtr[i-nIconIndex] = LookupIconIdFromDirectoryEx( pCIDir, TRUE, cxDesired, cyDesired, 0); With Winedbg we see : i = 65386, nIconIndex = -151, nIcons = 1 and IconDirCount = 1 It seems to be linked to this bogus test (line 314): else if( nIconIndex < iconDirCount ) where nIconIndex(INT)=-151 and iconDirCount(UINT16)=1. I Hope this will help finding the correct solution. (Odd fact : when activating +relay there is no more crash ...) Mehmet YASAR --------------- Backtrace with Wine20020122 --------------- First chance exception: page fault on write access to 0x406059a8 in 32-bit code (0x4082ba06). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:4082ba06 ESP:405c5888 EBP:405c5910 EFLAGS:00210287( R- 00 I S - -P1C) EAX:00000000 EBX:408c9b78 ECX:405c59a8 EDX:00010000 ESI:ffffff6a EDI:ffffff69 Stack dump: 0x405c5888 (NTDLL.DLL.memcpy+0x31fb08): 405c58d4 00000104 ffffff69 405c597c 0x405c5898 (NTDLL.DLL.memcpy+0x31fb18): 00000020 40a29a58 40388974 403aafce 0x405c58a8 (NTDLL.DLL.memcpy+0x31fb28): 405c59cc 40a17878 00000000 4006c7ea 0x405c58b8 (NTDLL.DLL.memcpy+0x31fb38): 400aa1ba 400ae78d 401018d7 405c5a2e 0x405c58c8 (NTDLL.DLL.memcpy+0x31fb48): 40133efe 403b6cbe 405c5a24 00000000 0x405c58d8 (NTDLL.DLL.memcpy+0x31fb58): 00000000 403c40b8 408bffb5 00000f6e 0x405c58e8 (NTDLL.DLL.memcpy+0x31fb68): 0011: sel=008f base=4011a4e0 limit=00000fff 32-bit rw- Backtrace: =>0 0x4082ba06 (ICO_ExtractIconExW+0x386(lpszExeFileName=0x403c4558, RetPtr=0x405c59a8, nIconIndex=0xffffff69, nIcons=0x1, cxDesired=0x20, cyDesired=0x20) [exticon.c:325] in libuser32.so) (ebp=405c5910) 1 0x4082c1c5 (PrivateExtractIconsW+0xf5(lpwstrFile=0x403c4558, nIndex=0xffffff69, sizeX=0x20, sizeY=0x20, phicon=0x405c59a8, w=0x0, nIcons=0x1, y=0x0) [exticon.c:555] in libuser32.so) (ebp=405c5948) 2 0x4082c251 (PrivateExtractIconsA+0x71(lpstrFile=0x405c5a20, nIndex=0xffffff69, sizeX=0x20, sizeY=0x20, phicon=0x405c59a8, w=0x0, nIcons=0x1, y=0x0) [exticon.c:578] in libuser32.so) (ebp=405c597c) 3 0x4065ed8d (SIC_LoadIcon+0x3d(sSourceFile=0x405c5a20, dwSourceIndex=0xffffff69) [iconcache.c:115] in libshell32.so) (ebp=405c59b8) 4 0x4065eeb9 (SIC_GetIconIndex+0xb9(sSourceFile=0x405c5a20, dwSourceIndex=0xffffff69) [iconcache.c:154] in libshell32.so) (ebp=405c5a00) 5 0x4065f32c (PidlToSicIndex+0xcc(sh=0x403c48f4, pidl=0x403b6cb0, bBigIcon=0x0, uFlags=0x0, pIndex=0x405c5b58) [iconcache.c:311] in libshell32.so) (ebp=405c5b3c) 6 0x4065f3d2 (SHMapPIDLToSystemImageListIndex+0x72(sh=0x403c48f4, pidl=0x403b6cb0, pIndex=0x0) [iconcache.c:346] in libshell32.so) (ebp=405c5b68) 7 0x40677e61 (ShellView_OnNotify+0x3b1(This=0x403bd0c4, CtlID=0xffffff4f, lpnmh=0x405c626c) [shlview.c:1178] in libshell32.so) (ebp=405c600c) 8 0x4067850e (ShellView_WndProc+0x18e(hWnd=0x30034, uMessage=0x4e, wParam=0xffffff4f, lParam=0x405c626c) [shlview.c:1405] in libshell32.so) (ebp=405c602c) 9 0x408947a3 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405c6050) 10 0x4089483d (WINPROC_CallWndProc+0x8d(proc=0x40678380, hwnd=0x30034, msg=0x4e, wParam=0xffffff4f, lParam=0x405c626c) [winproc.c:167] in libuser32.so) (ebp=405c6080) 11 0x4089a46a (WINPROC_CallProc32WTo32A+0x8a(func=0x40678380, hwnd=0x30034, msg=0x4e, wParam=0xffffff4f, lParam=0x405c626c) [winproc.c:2439] in libuser32.so) (ebp=405c60a8) 12 0x4089aa32 (CallWindowProcW+0xb2(func=0x40b606d2, hwnd=0x30034, msg=0x4e, wParam=0xffffff4f, lParam=0x405c626c) [winproc.c:2646] in libuser32.so) (ebp=405c60dc) 13 0x40830727 (call_window_proc+0xd7(hwnd=0x30034, msg=0x4e, wparam=0xffffff4f, lparam=0x405c626c, unicode=0x1) [message.c:1351] in libuser32.so) (ebp=405c6138) 14 0x40831301 (SendMessageTimeoutW+0xe1(hwnd=0x30034, msg=0x4e, wparam=0xffffff4f, lparam=0x405c626c, flags=0x0, timeout=0xffffffff, res_ptr=0x405c61bc) [message.c:1721] in libuser32.so) (ebp=405c6198) 15 0x40831587 (SendMessageW+0x37(hwnd=0x30034, msg=0x4e, wparam=0xffffff4f, lparam=0x405c626c) [message.c:1801] in libuser32.so) (ebp=405c61cc) 16 0x4096b033 (dispinfo_notifyT+0x1d3(self=0x30035, code=0xffffff4f, pdi=0x405c626c, isW=0x1) [listview.c:330] in libcomctl32.so) (ebp=405c6234) 17 0x40971f9e (LISTVIEW_GetItemT+0x34e(hwnd=0x30035, lpLVItem=0x405c630c, internal=0x1, isW=0x1) [listview.c:5040] in libcomctl32.so) (ebp=405c62b8) 18 0x4096ed6d (LISTVIEW_DrawItem+0xed(hwnd=0x30035, hdc=0x860, nItem=0x1, rcItem=0x0, FullSelect=0x0, SuggestedFocus=0x405c67b8) [listview.c:354] in libcomctl32.so) (ebp=405c6748) 19 0x4096ffd5 (LISTVIEW_RefreshList+0x175(hwnd=0x30035, hdc=0x860, cdmode=0x0) [listview.c:3552] in libcomctl32.so) (ebp=405c67e4) 20 0x4097036f (LISTVIEW_Refresh+0xbf(hwnd=0x30035, hdc=0x860) [listview.c:3677] in libcomctl32.so) (ebp=405c6824) 21 0x4097633e (LISTVIEW_Paint+0x5e(hwnd=0x30035, hdc=0x0) [listview.c:8170] in libcomctl32.so) (ebp=405c6880) 22 0x40977a70 (LISTVIEW_WindowProc+0xdc0(hwnd=0x30035, uMsg=0xf, wParam=0x0, lParam=0x0) [listview.c:8922] in libcomctl32.so) (ebp=405c689c) 23 0x408947a3 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405c68c0) 24 0x4089483d (WINPROC_CallWndProc+0x8d(proc=0x40976cb0, hwnd=0x30035, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:167] in libuser32.so) (ebp=405c68f0) 25 0x4089aa4e (CallWindowProcW+0xce(func=0x40b604b4, hwnd=0x30035, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2650] in libuser32.so) (ebp=405c6924) 26 0x4087c494 (DispatchMessageW+0x134(msg=0x405c69a0) [message.c:1126] in libuser32.so) (ebp=405c6968) 27 0x40870b26 (IsDialogMessageW+0xb6(hwndDlg=0x20023, msg=0x405c69a0) [dialog.c:1533] in libuser32.so) (ebp=405c698c) 28 0x4086fe10 (DIALOG_DoDialogBox+0xa0(hwnd=0x20023, owner=0x10021) [dialog.c:1040] in libuser32.so) (ebp=405c69cc) 29 0x408701af (DialogBoxIndirectParamA+0x2f(hInstance=0x405e5000, template=0x40622a60, owner=0x10021, dlgProc=0x405ee730, param=0x403b7798) [dialog.c:1163] in libuser32.so) (ebp=405c69e0) 30 0x405ed76c (GetFileName95+0x10c(fodInfos=0x403b7798) [filedlg95.c:249] in libcomdlg32.so) (ebp=405c6a08) 31 0x405edc02 (GetFileDialog95W+0x352(ofn=0x1008c40, iDlgType=0x2) [filedlg95.c:467] in libcomdlg32.so) (ebp=405c6a6c) 32 0x405ed580 (GetOpenFileNameW+0x40(ofn=0x1008c40) [filedlg.c:1606] in libcomdlg32.so) (ebp=405c6a88) 33 0x01001dc1 (notepad.exe..text+0xdc1 in C:\winnt\notepad.exe) (ebp=405c6ce8) 34 0x010028bd (notepad.exe..text+0x18bd in C:\winnt\notepad.exe) (ebp=405c6d08) 35 0x408947a3 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=405c6d2c) 36 0x4089483d (WINPROC_CallWndProc+0x8d(proc=0x100248f, hwnd=0x10021, msg=0x111, wParam=0xa, lParam=0x0) [winproc.c:167] in libuser32.so) (ebp=405c6d5c) 37 0x4089aa4e (CallWindowProcW+0xce(func=0x40b60640, hwnd=0x10021, msg=0x111, wParam=0xa, lParam=0x0) [winproc.c:2650] in libuser32.so) (ebp=405c6d90) 38 0x4087c494 (DispatchMessageW+0x134(msg=0x405c6dec) [message.c:1126] in libuser32.so) (ebp=405c6dd4) 39 0x01002a64 (notepad.exe..text+0x1a64 in C:\winnt\notepad.exe) (ebp=405c6e08) 40 0x01006576 (notepad.exe.EntryPoint+0x156 in C:\winnt\notepad.exe) (ebp=405c6ea4) 41 0x400d3b18 (start_process+0x1f8 [process.c:397] in libntdll.so) (ebp=405c6f38) 42 0x400d7307 (call_on_thread_stack+0x27(func=0x400d3920) [sysdeps.c:91] in libntdll.so) (ebp=405c6ff4) 43 0x400d74c0 (SYSDEPS_CallOnStack+0x14 in libntdll.so) (ebp=00000000) 0x4082ba06 (ICO_ExtractIconExW+0x386 [exticon.c:325] in libuser32.so): movl %eax,0x0(%ecx,%edx,4) 320 for( i = nIconIndex; i < nIconIndex + nIcons; i++ )

2 1

Newbie Trying To Get Ghost Recon To Install
by Joel Miller 17 Feb '02

17 Feb '02

Hello, I'm new to using WINE (and to these lists), so I apologize if this has been asked and answered already: Has anyone been able to get Ghost Recon to at least install? The autorun program came up just fine, but when I click the button to install, it promptly quits. I tried running the setup.exe program directly, and it gets as far as trying to setup and install shield wizard, and then gives me an error mesage box stating that it cannot load a certain dll. I do not recall the name of the dll, and I do not have immediate access to the GR installer -- I borrowed my friend's discs and manuals to see if it would work under WINE. When I found out last week that it wouldn't install, I returned them =-(. I might be able to borrow them again, though. I am running the latest WINE on this box: * SuSE Linux 7.1 * 1Ghz Athlon * SiS Mainboard * 256MB RAM * GeForce 2-MX (not using nVidia's drivers, just the ones that come with SuSE) * 60GB HD I am trying to set up an MS-Free game machine, so using an existing WhineDoze install just isn't gonna happen. =-) Any help offered will be greatly appreciated. Joel Miller

2 1

Re: ldconfig : ..... .so is not a symbolic link
by lawson_whitney＠juno.com 17 Feb '02

17 Feb '02

On Fri, 15 Feb 2002, Sylvain Petreolle wrote: > > ldconfig -v produces : > /usr/local/lib: libopengl32.so -> libopengl32.so libglu32.so -> libglu32.so libmsvcrt20.so -> libmsvcrt20.so libsane.so.1 -> libsane.so.1.0.7 ldconfig: /usr/local/lib/libwine_unicode.so is not a symbolic link libwine_unicode.so -> libwine_unicode.so.1.0 ldconfig: /usr/local/lib/libwine_tsx11.so is not a symbolic link libwine_tsx11.so -> libwine_tsx11.so.1.0 .... Not only that, but make uninstall make install is broken. I thought that would fix it, but I had to install the wine binary by hand, and the result is exactly the same. Where there were symbolic links before are now copies. Besides wasting file space, though, I don't see it does any harm. You get this mail by the latest Wine, ldconfig warnings and all. Lawson First shoot the arrow. Then draw the bulls-eye. - J. A. Soucy

4 5

RE: BSD, Gav, LGPL, Jeremy, and business
by Roger Fujii 17 Feb '02

17 Feb '02

> > if you have to give out an unlimited, royalty free license to your > > work, I think it's not unfair to say that you have given up your > > copyright protection. As the copyright holder, it's true that you > > can relicense it to suit other licenses, but it's not clear to me > > that you can clearly make a copyright infringment case if there is > > an LGPLed copy in the public. > Well if somebody uses my work in a way either not permitted by LGPL > or explicitly permited by me through some other license I can't see > why I can't sue. But the point I'm trying to make is that I can be in violation of your RELICENSE. I can make a claim that YOUR work is covered by the *GPL, so that your RElicense to me doesn't apply. If this holds, then my original statement that you gave up your copyright protection holds. -r

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 16 Feb '02

16 Feb '02

> > The *GPL extends the circumstances where I can take somebodies work. > > but isn't this notion rather frightening? Frightning? Have you been effected with Brett fear mongering? :-) I don't consider it frightning. Copyleft is a trade where someone was allowed distribute my work and did and as companation I can take his related work. Of course this is not always good as I have been arguing in countless mail, but that is another thing. Sometimes this is good idea sometimes it is not. > > > nor does it force you to give up your copyright (effectively). > > > > Neither does the LGPL you can still license the code to others > > under any license. You just have to give it back under the > > LGPL as well. > > if you have to give out an unlimited, royalty free license to your > work, I think it's not unfair to say that you have given up your > copyright protection. As the copyright holder, it's true that you > can relicense it to suit other licenses, but it's not clear to me > that you can clearly make a copyright infringment case if there is > an LGPLed copy in the public. Well if somebody uses my work in a way either not permitted by LGPL or explicitly permited by me through some other license I can't see why I can't sue. At least not unless you claim that Open Source == Public Domain, but that is something else entirely.

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Roger Fujii 16 Feb '02

16 Feb '02

> > while this is one *small* aspect of copyleft, the *GPL extends > > well beyond that. "fair use" does not allow you to redistribute > > work, > > Yes, it does, that it what fair use is: > The right to distribute somebody elses work or > part of work without a license under some > circumstances. you're right. I was just thinking in terms of backups and work as a whole. Good reading: http://www-sul.stanford.edu/cpyright.html > The *GPL extends the circumstances where I can take somebodies work. but isn't this notion rather frightening? > > nor does it force you to give up your copyright (effectively). > > Neither does the LGPL you can still license the code to others > under any license. You just have to give it back under the > LGPL as well. if you have to give out an unlimited, royalty free license to your work, I think it's not unfair to say that you have given up your copyright protection. As the copyright holder, it's true that you can relicense it to suit other licenses, but it's not clear to me that you can clearly make a copyright infringment case if there is an LGPLed copy in the public. -r

1 0

Re: Clarification on my call for license change
by Roger Fujii 16 Feb '02

16 Feb '02

Aric Stewart <aric(a)codeweavers.com> wrote: > The simple of it is.. you, Patrik, would not buy a Wine distribution > form us. Why would you? You are a developer, and a wine developer on top of that. What seems to be the most commercially successful mode on top of opensource is to have an opensource base and have a value-add component - but I have yet to see a successful mode that has no propriatary component. > It is these sorts of people and companies that we want to target. And > financially Patrik's money for his license or even the money form all > the wine developers would be nearly insignificant compared to a 100+ > seat site license. uh, how can you sell a N-seat site license with something that is covered by *GPL (since this would be a violation of the license)? If your model is to sell by seat, I would like you see the reasoning between the difference of a 10 seat license and a 100 seat license with the *GPL. > As a developer who has worked on far too many proprietary Wine trees and > seen all the fights the Jeremy has gone through. I want to be assured that > i can give my code back to the wine community. As I said before, if a copyleft is all that is needed, choose a copyleft that makes SENSE. LGPL may be convienient, but I have seen no rational argument in having the *GPL's brand of copyleft (other than it's widely used). I think the mozilla project would be a good place to look... -r

2 1

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 16 Feb '02

16 Feb '02

> Patrik Stridvall wrote: > > > No. If anything, it seems to be using licencing rules > > > to negate copyrights. It really wants to make a copyright > > > into "a right to copy it". Even taking what you say, if you > > > extend what is "fair" use, you obviously must be making it > > > less fair somewhere else.... > > > > As I said, very simplified. > > > > What I meant is that the mechanism that forces release of > > the extension of the LGPL (read: copyleft) is similar to the > > case where fair use is extended so I take legally take > > the work instead. > > while this is one *small* aspect of copyleft, the *GPL extends > well beyond that. "fair use" does not allow you to redistribute > work, Yes, it does, that it what fair use is: The right to distribute somebody elses work or part of work without a license under some circumstances. The *GPL extends the circumstances where I can take somebodies work. > nor does it force you to give up your copyright (effectively). Neither does the LGPL you can still license the code to others under any license. You just have to give it back under the LGPL as well. > > The copyleft mechanism forces "push" of the source code > > which is better in the case of software. > > > I by this wanted to illustrate that copyleft is not something > > inherantly "evil" as Brett Glass are apparently crusading against. > > I'll let Brett speak for himself (not like I can stop him :) ), but > I didn't see an argument that 'copyleft' was bad. It was the *GPL is > bad. Just as rms think proprietary programs are evil, Brett > and others > think that the loss of copyright protections are just as bad or worse. Perhaps. But as you said, let Brett speak for himself. > I'm not quite as concerned as Brett, as I think the viral > nature of the > *GPL will eventually be thrown out in US court. Yes, I think that too.

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 16 Feb '02

16 Feb '02

> At 02:38 AM 2/16/2002, Patrik Stridvall wrote: > > >I'm sorry if I sound a little angry but it seems that some > >of people have found me guilty by association with you > > Patrik, don't you see? We're both guilty of the same sin: > saying that everything does not revolve around the Earth. > While we have different views of how things DO work, > there's exceedingly strong evidence for what we say. Perhaps. But I think you seem to focus on worst case scenarios, many of them are IMHO unlikely to happend, which impacts negatively on your credebillity. > But because it's contrary to some people's "religious" > beliefs they would rather excommunicate us, suppress > what we have to say, or burn us at the stake than listen. I don't think it is quite that easy. I don't think most of them have an "religious" belief in the LGPL. I think they simple see it as a way to both eat the cake and have it while trivialize the price they have to pay in the order to acceive this. Note, however, that sometimes, but only sometimes, this price is actually worth paying, see below. > >What you are doing IMHO is pure fear mongering, > > No, it's not. I am making predictions based on what > has happened to other businesses in the recent past, > as well as sound economic principles. I'm not advocating > or attempting to induce fear. I do not believe that you try to induce fear, but by focusing on unlikely to happend scenarios you cause fear regarless. > But if the outcome does not > look rosy, it's because WINE really would head down a > very destructive path if it were (L)GPLed. Wine will survive regardless. However I very much fear that it might impact negatively on the willingless of companies to invest in the Wine market and thus reducing the speed which Wine develops with. Note that when Wine fully works (close to 100% of all Windows applications run) it will not matter what license we have, there will be no money in anything except support anyway and the LGPL will not hurt that. It is the way there that worries me. Note that we can always choose LGPL later, but after we have choosen it we can't go back. > >I firmly believe that the GPL and the LGPL has > >a place in the world. > > Their place, and purpose, has been stated by Stallman. > (Not in the licenses themselves, which are designed > to be deceptive, but in Stallman's words in his more > candid moments.) It is to turn publicly available > software into a weapon in his lifelong, personal > vendetta. Again, he has stated this explicitly > himself, and it is also well documented by third parties > such as Levy. Please, now you are fear mongering again. I care not whether I support Stallman or not. I care ONLY about what is good for Wine. > WINE should rise above this agenda and not become an > agent of it. What agenda? The GPL/LGPL works in ways that are almost the dual to fair use. Very simplified: It uses copyright to extend fair use. Fair use have an obvious place in the world. However trying to extend fair use to legalize (or rather rationalize) for example Napster like sharing of music clearly takes things too far. GPL/LGPL have an obvious place in the world. However it has close to the same price as fair use, it discourages investment in new works using classical business models and new business models need to be found. This is obvously not so easy, neither in music business nor in the software business. Possible, yes. Easy, no. Don't try to stretch my analogy to far. The point is this and only this: The GPL/LGPL have a place in the world for almost the same reasons that fair use have a place in the world. However if trying to extend fair use too far is not good, neither is trying it extend GPL/LGPL too far. While fair use is nessesary an author can't live of it. The same with GPL/LGPL.

3 2

RE: Clarification on my call for license change
by Patrik Stridvall 16 Feb '02

16 Feb '02

> Patrik Stridvall wrote: > > > The point is: > > - The 100+ seat company gains. (They get support). > > - Red Hat gains. (They get money). > > - I gain. (I get money). > > - But CodeWeavers, that did a lot of work on Wine, > > doesn't gain anything and they are becaused of the LGPL > > been forced to release all of their work. > > > > Sure they might gain back a few bug fixes if I had to > > do in order to fix a few small flaws, but then Red Hat > > probably would have let me release it anyway. > > A few bug fixes? If it is important enough that such a big > customer pays > Red Hat for developing something then I guess that it is not > only a few > bug fixes we are talking about here. Well, if they just want a support contract the applications they use probably works fine in usual case thanks to the works of others that I have download for free thanks to the LGPL and made a RPM for them. But OK there will probably more that a few bugfixes but somehow I think that most of the time will be spent telling ignorant users the obvious, that is what support usually is. The support money will also pay for me making new RPMs for them from time to time get even more stuff for free thanks to LGPL. Beside a simple support contract are not likely to allow for advanced fixes without extra money being paid. The point is that CodeWeavers will not get any money at all. > And that is to the advantage of > CodeWeaver then because they gain also fucntionallity they might have > needed to develop themself. Yea sure, but don't have too much hopes that it will be that much. Support means support not development. Beside Red Hat would probably have let me release the fixes back even if they didn't have too since the license was still BSD. If their applications works under Wine, there is no reason for me to implement any new functions.

1 0

RE: Clarification on my call for license change
by Patrik Stridvall 16 Feb '02

16 Feb '02

> > of it is not possible. If just somebody in the world realizes > > the flaw he can contact the companies in question and > > point this out to them and for a fee do the work of recompiling > > their application for them. > > You are assuming here, that any given customer will sit and > wait until a > suitable patch is released. That may be true for many and > that's what I > wrote about my earlier job in my previous mail. But if this is an > important feature than he will pay for it because he needs to. If this > is released for others this is no problem because for others > apparently > it may not be that vital otherwise they would have paid for it in the > first place. If you can get the fully cost from the first customer, yes. But often you can't. So you develop it for say 50% of the cost and hope that the rest of your customers will pay the rest. Usually this will work out fine. However with the GPL this is impossible. You almost must have the full cost upfront which means that you have to spend more time negotiating to get the whole cost covered. Worse sometimes you miscalculate how must something costs, but that it not that bad if the code is proprietary. Now when you know the cost you know what to charge the rest of your customers. > Another implicit assumption here is that customers pay for a > given piece > of code. In my opinion they are often not doing that. Instead they pay > for a service. They pay for the service that they have > someone whom they > can contact and who will code if neccessary. That is absolutely correct. However using the GPL would force me to charge everybody that calls the full cost for each improvement. Often the cost will not outweigh the benefit for them so no deal unless I can reduce the price somehow. With the GPL this is impossible. > So even if they use an OS > code that doesn't imply that they never again will pay for any service > based on the assumption that any given functionality they > will need will > turn up sooner or later. Of course not, but some smaller customer might not have so much money so they often hope somebody else will have the same problem and pay for it. > Most larger customers (and I think that's the > one who are intersting for business models) are not willing > to bet their > business on the fancy of some developers. They want to have plans they > can follow so they in turn can tell their customers when and > how a given > problem will be solved. That's why xGPL also works for companies. The problem is not whether it works or not the problem is the drawbacks. As I have said before sometimes this is worth it, sometimes it is not. > I was once arguing with collegues because they maintained that if MS > gave their code for Word to OS then nobody would buy Word anymore and > they couldn't make any money from it. I stil say, and that is > the point > here as well, that this is not true. Private indivudals won't pay > anymore, but usually they are not the money anyway. Really large > companies, with their own development staff might also choose > to develop > and maintain themself, and there may be some loss. But the majority of > smaller companies would still pay for the service of maintainence and > for adding features they need and I bet that even bigger companies who > could afford their own development wouldn't choose to do that. Why > should they? It's more sensible to let somebody develop that who know > about it. The code is there as an insurance should the > developer ever go > down, but not for developing by everybody else. Yes, sometimes this will work out fine, but as I said it comes with a cost and the GPL limits want and how you can offer things to market quite severly. The problem with things like Word processors is that few users use or need new features so the market for enhancements will be quite limited.

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Patrik Stridvall 16 Feb '02

16 Feb '02

> Patrik Stridvall <ps(a)leissner.se> wrote: > > > > WINE should rise above this agenda and not become an > > > agent of it. > > What agenda? > > > > The GPL/LGPL works in ways that are almost the dual to fair use. > > Very simplified: It uses copyright to extend fair use. > > No. If anything, it seems to be using licencing rules > to negate copyrights. It really wants to make a copyright > into "a right to copy it". Even taking what you say, if you > extend what is "fair" use, you obviously must be making it > less fair somewhere else.... As I said, very simplified. What I meant is that the mechanism that forces release of the extension of the LGPL (read: copyleft) is similar to the case where fair use is extended so I take legally take the work instead. Of course fair use requires the use of "pull" which my be of less use if the work is compiled into a binary. The copyleft mechanism forces "push" of the source code which is better in the case of software. I observed that there are some theoretical similarites between fair use and copyleft. So seeing copyleft as some sort of contracted or licensed fair use makes sense. This suggest that a too broad fair use have similar problem that a too broad application of copyleft. And indeed both have the freeloader problem for example. I by this wanted to illustrate that copyleft is not something inherantly "evil" as Brett Glass are apparently crusading against. Like the case for fair use a little copyleft is good as long as you don't get to much.

2 1

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