wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: mt locks, fix _sopen for msvcrt
by Alexandre Julliard 20 Feb '02

20 Feb '02

"Peter Hunnisett" <peter(a)transgaming.com> writes: > * dlls/msvcrt/Makefile.in, dlls/msvcrt/console.c, dlls/msvcrt/exit.c, > dlls/msvcrt/file.c, dlls/msvcrt/heap.c, dlls/msvcrt/locale.c, > dlls/msvcrt/main.c, dlls/msvcrt/msvcrt.h, dlls/msvcrt/msvcrt.spec, > [new]dlls/msvcrt/lock.c, include/Makefile.in, [new]include/msvcrt/mtdll.h > Peter Hunnisett <peter(a)transgaming.com> > Add _lock,_unlock and header file for them. > Convert all msvcrt locks over to use _lock and _unlock > Explictly make msvcrt compile with multithreaded option > Fix flag handling in _sopen. Add W->A call for new _swopen Isn't mtdll.h supposed to be an internal header? If so, it should be in dlls/msvcrt, not in include/msvcrt. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Small changes to notepad
by Andriy Palamarchuk 20 Feb '02

20 Feb '02

This patch, submitted on Feb 15 was not applied, but other patch - "Notepad2. Command line processing" was. These two patches are independent from each other. If the patch was not understood as duplication and was not applied for some other reason I'd like to know why. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com

2 2

Concerning the boot procedure for renaming/deleting files
by Gerhard W. Gruber 20 Feb '02

20 Feb '02

Something not to do with licencing, I hope that poeple have time for this as well. :) I've submitted a patch that is the preliminary for processing the files that are installed with a setup in order to be deleted/renamed when windows boots. The files are now entered into the registry as I have seen how it is done on NT4.0. I have now some questions regarding this. 1.) When I verified this with a testprogram on NT I noticed that the MoveFileEx code enters the names like this \??\D:\test.exe[0] !\??\D:\Test_renamed.exe[0] [0] Does anybody know what the \??\ stands for and wether the '1' for the renaming entry has some function? I coudn't find anything regarding this and I hardcoded this as to now. 2.) I've looked into the program winebootup from Andreas Morh and I could finish this (at least regarding the boot processing for now). BUt I don't see the advantage of having a seperate program that does some stuff that should be done when a wine process starts up. When I check if there is something to process this takes a trivially small time, so performance can't be the issue. I don't really like the idea of having a seperate program for this because in my opinion it belongs into the wine startup code to do this sort of work. Also I think that this will lead to additional questions because people will install programms and then wonder why it doesn't work after successfull installation, so they will ask whats wrong (and I gues this will happen again and again). Furthermore I bet that most people may forget about this secondary program that is needed to run because setup is not done that often once a system is set up properly so people might tend to forget about it. The other thing could be that this secondary program will substitute the startupe program in which case there is no need for a second program in the first place. Any opinions on how to best integrate the boot processing?

3 5

Re: License change vote results
by Roger Fujii 20 Feb '02

20 Feb '02

> CodeWeavers as a single entity did receive one vote.) If we had stuffed > the ballot box as Brett suggested, the votes would have > been more lopsided, believe me. So, you're saying that it WAS possible that it could have been stuffed. Remember that the criteria was not given out when the results were posted (which is why I asked in the first place), so there was no way of knowing what the numbers meant. As it is, I think the criteria is flawed in the sense that it discounts major contributers (codeweavers and transgaming) and enhances the votes of minor ones - the ones who are least effected by a license switch (and, IMHO, the ones that understand the issues/mechanisms of licenses the least). As the argument for X11/BSD is a philosophical/commercial one, it's not unfair to say that if you discount commerical entities, you will have the effect of discounting the X11/BSD count. > I think Dimi and others have been remarkably patient, all > things considered. Being on the other side of the issue, I can say that Dimi is not a saint on the matter either - at least Brett sometimes will substantiate what he says. -r

2 1

Re: Notepad2. Command line processing
by lawson_whitney＠juno.com 20 Feb '02

20 Feb '02

On Fri, 15 Feb 2002, Andriy Palamarchuk wrote: > I *think* this patch does not depend on my previous > patch. > > Changelog: > - implemented parsing of file name, passed in command > line, loading new file on startup. This fixes bug 407 > Did you notice in testing this patch that notepad can not save a file? Never mind bug 407, that is the Real Bug that renders notepad unusable. :-). I guess this is not an urgent bug, I can use joe, jed, vi (elvis, vim) or emacs if I need to change a file. Lawson Illigitimati non carborundum.

4 3

Re: License change vote results
by Roger Fujii 20 Feb '02

20 Feb '02

Alexandre Julliard <julliard(a)winehq.com> wrote: > 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. 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. As a curiosity, what % of the voters are affiliated with codeweavers? I realize that they are a significant contributer, but as you are using the word "community", it's fair to ask a) how big that number is in total b) if there are large components in that number, they should be at least quantified. -r

8 7

MIDL replacement?
by Phillip Schmitz 20 Feb '02

20 Feb '02

Some time ago there was talk of using an (msrpc/com) idl compiler and idl files to replace some of the complexity of the current COM implementation details (I imagine the main advantage would be that winelib programs might be able to use COM stuff without having to generate stubs etc using MIDL). Rather than starting from scratch people recommended finding an existing (corba) idl compiler and hacking that. Has anyone taken up the challenge? I had a look at the freedce idl compiler but I can't get it to compile. Not that I want to invite another round of "my license is better than your license" but should this be distributed independently of wine so as to avoid license problems or what could one base it on if distributed with wine (if wine was rewritten to depend on its availability this would make things tricky... ) Also, while on the topic of MIDL it seems that the emitted code contains marshaling hints/info in special strings - does wine currently understand these? (undocumented of course but not that messy - people writing their own custom DCOM-over-other-transports stuff managed to work them out quite quickly - I'm sure working with people from Microsoft Research helped though :) Would it need to be a drop-in replacement for MIDL? I suppose not but I'm not sure how much easier that would be (I know com-idl is a moving target with COM+ and new attributes etc but plain COM should be sufficient for most). Anyway - this is the result of a few days research and may all be in vain - those with more experience with COM and its implementation in wine should (if required) shoot me down now before I continue wasting my time. Phillip Trainee wine-devel lurker who marvels at the endurance of people using/implementing COM in C. PS I don't know if it is worthwhile starting a separate effort to make a "free" MIDL replacement regardless - what do people writing windows code with mingw etc do if they want to use COM?

2 1

cd programs && make install
by lawson_whitney＠juno.com 20 Feb '02

20 Feb '02

Good day! Maybe this is a local misconfiguration (only I doubt it) or maybe I am going about it wrong,...maybe I deleted winetest.pm myself and can't remember... cd `dirname winetest/__install__` && make install make[1]: Entering directory `/oof/Wine-20020122/programs/winetest' [ -d /usr/local/bin ] || mkdir -p /usr/local/bin /usr/bin/install -c winetest.so /usr/local/bin/winetest.so cd /usr/local/bin && rm -f winetest && ln -s wine winetest [ -d /usr/local/lib ] || mkdir -p /usr/local/lib /usr/bin/install -c -m 644 wine.pm /usr/local/lib/wine.pm /usr/bin/install: wine.pm: No such file or directory make[1]: *** [install] Error 1 make[1]: Leaving directory `/oof/Wine-20020122/programs/winetest' make: *** [winetest/__install__] Error 2 Lawson "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.

2 1

RMS, Univerial Themes, Slashdot, and Wine
by Tim R. 20 Feb '02

20 Feb '02

Hi, This post, http://mail.gnome.org/archives/foundation-list/2002-February/msg00015.html to some GNOME mailing list got /.ed recently. Quoting from the post: >It might also be useful to organize a specific joint project, >something that would improve the coherence of a GNU/Linux system >which uses parts of both GNOME and KDE. The idea that occurred to me >was to work on unifying theme definitions, so that a user can define >a theme just once and have it work with both GNOME and KDE. Perhaps >others will have a better suggestion. I would love to see something like this happen. However, IMHO, I think something like this should be more than just KDE and GNOME. I would like to see something like that as a more or less Linux (and BSD, etc), or X11 standard. It seems to me that Wine could benifit from something like this. Basicly, Wine is just a Unix/X11 toolkit that happens to have the same API as MS Windows and includes a binary loader right? Or am I completely off base here? Anyway, GNOME programs tend to look and feel like GNOME programs, KDE programs tend to look and feel like KDE programs, and Wine programs tend to look and feel like Windows programs. So could something like this work for Wine? Could Wine programs inherit their look and feel from some kind of universal theme? That would surely help the Windows programs integrate into the X desktop. So I guess I'm asking, would this work for Wine, and if so, is anyone interested in doing it? If the first answer is yes but the second is no, could anyone provide me with some pointers for getting involved with doing some a project myself? (Both the work on Wine, and on GNOME/Gtk/KDE/Qt/etc.) Also some of the replies to RMS's post suggested this was an itch none of the GNOME people felt like scratching, because none of them used KDE programs. I thought perhaps the Wine people would feel more like scratching this itch, because most of you probably use Wine programs along side of atleast either KDE or GNOME applications, if not both. Sorry if this has been a bit off topic, or if I don't really know what I'm talking about. --Tim Ringenbach

1 0

Bye
by Gerard Patel 20 Feb '02

20 Feb '02

Ring down the curtains, the farce is over ;-) I will unsubscribe from wine lists in a few days. If anyone of the contributors has a problem with the few lines of code I wrote for Wine, they should not hesitate to send me a mail in my personal inbox, I'll try to understand what I was trying to do and if I succeed I'll explain :-) And if among the seven who voted against the changes there are enough people aventurous (I did not participate to the 'vote'), I'd be interested to hear from them and discuss a contribution to a new project under a x11 like license. As wine-license seems to be a continuation of the gpl/bsd flamewar :-//, I'd prefer to talk about a x11 project elsewhere... Thanks to all on this list who helped me. Good luck to the Wine guys for their 1.0 version. Gerard PS : And ah, well, as a parting note for Alexandre Julliard : there is a problem with your patch made on Revision 1.22 / (download) - [select for diffs] , Fri Sep 14 00:24:40 2001 UTC (5 months ago) by julliard Branch: MAIN Changes since 1.21: +8 -13 lines Diff to previous 1.21 Make sure that HWND comparisons are always done with full 32-bit handles. You included this (hardly related) change in dlls/x11drv/window.c, line 524: while (prev && !(GetWindowLongW( prev, GWL_STYLE ) & WS_VISIBLE)) prev = GetWindow( prev, GW_HWNDPREV ); This is triggering a regression in one of my test apps, webferret (www.webferret.com). The option window has its tabs covering each other. I can work around with this patch : --- winpos.c.orig Tue Dec 18 02:27:43 2001 +++ winpos.c Thu Jan 10 18:08:16 2002 @@ -880,7 +880,7 @@ if (get_whole_window(wndPtr)) /* don't do anything if X window not created yet */ { Display *display = thread_display(); - + int zorder = !(winpos->flags & SWP_NOZORDER); if (!(winpos->flags & SWP_SHOWWINDOW) && (winpos->flags & SWP_HIDEWINDOW)) { /* clear the update region */ @@ -895,10 +895,11 @@ TRACE( "unmapping zero size win %x\n", winpos->hwnd ); TSXUnmapWindow( display, get_whole_window(wndPtr) ); } + else if (winpos->flags & SWP_SHOWWINDOW) zorder = TRUE; wine_tsx11_lock(); if (bChangePos) - X11DRV_sync_whole_window_position( display, wndPtr, !(winpos->flags & SWP_NOZORDER) ); + X11DRV_sync_whole_window_position( display, wndPtr, zorder); else { struct x11drv_win_data *data = wndPtr->pDriverData;ü as far as I can understand your code and what the app is doing, your new code updates the ordering of the X window but there is a case missing when child windows are shown using for instance ShowWindow. But of course you'll have a better patch :-)

4 3

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel