wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

LGPL, and real World
by Hetz Ben-Hamo 16 Feb '02

16 Feb '02

Gentlemen, I do not wish to interrupt the nice email party going on here, but I wish to bring an example in real life which might let people re-think their decision.... I'll try to be a simple as I can. The following case is totally fiction. For the sake of this email, lets say I'm a lead developer in a company caled qwerty-wine, and one of my customers want me to develop a software for his palm top tun Visio XP on it, for the field engineers. For the sake of this example, lets say I'm checking out wine cvs today. Now - lets say that now is May, Codeweavers had decided to switch to LGPL and lets say that I am their competitor and I just had become aware of a DLL which is not implemented, but it is (according to a co- developer) implemented in Wine under the LGPL tree, so it means I'm 2 "cvs" commands from getting their implementation... Now - what if my product is totally a closed source one and my client doesn't want to reveal a single source code line? then I have 2 choices regarding this DLL: 1. I can Ignore the DLL in the Wine tree and re-implement it from where it was before the license has been changed and I keep the changes since it already implemented in Wine tree (and my customer doesn't want to reveal code). 2. I can "steal" this code from the new LGPL wine tree, and saving myself 90% of headache how to implement it, and invest 10% of the time to change the code cosmetically to look different, so if CodeWeaver's wine DLL looked like: 1+2+3+4=10 Then my code will look like: 5+5=10 So the code is different, but it does same thing, and I still keep my code closed... Who's loosing here? CodeWeavers. I used their code and no one got nothing out of this. Nada. Zilch. Zero. All their investment on that DLL implementation went down, they'll have hard time to re-cap this investment. Lets say that CodeWeavers could drag me to court and I'll be happy to show the code to the Judge or any 3rd party mediator - what he'll see? he'll see completly 2 different implementations which give same results. I win the case and I can collect damages from CodeWeavers. I repeat again - all the above is a FICTION. I'm not a developer (I'm unemployed at the moment) and the whole case - I made it up (although I heard some people were interested to see Wine on Embedded). But you wouldn't know if your competitor will use this trick with your code, will you? TransGaming probably won't do it, but others? So yes, CodeWeaver have their full right to move their code to LGPL or whatever. Is it a smart move for the Wine development move? yes. Is it a smart move business wide? IMHO - no, but CodeWeavers is a private company, and it's Jeremy full right to decide what to do with their code. I support CodeWeavers (bought their crossover even if I used it for 2 days), Transgaming (I subscribed, even if their code doesn't make my games work yet), and Lindows (I'll keep my Redhat and multi user approach, thank you!) and I plan to continue to do so - but will CodeWeaver exists due to this move? for a long term - I'm not sure, although I surely hope to be wrong here.. Just food for thought... Hetz Ben Hamo

3 2

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

16 Feb '02

> Patrik Stridvall wrote: > > > They turn to their respective distributor say Red Hat and > say that they > > are prepared to pay $XXX per year for a better supported Wine. > > Red Hat in turn hires me (or some other on this list) to do > this and I do: > > > > cvs update ; ./configure ; make install > > > > That is your problem. > > I fail to see why this should be a problem. Once the code is > written is > (basically) free to use by the one who wrote it (or ordered it, > depending on the agreements). Red Hat got his money in that > case because > it agreed to create that code. I was talking about the 100+ seat support contract CodeWeavers wanted. > You got your money because you > were hired > by Red Hat. If Red Hat chooses now to release the code it > still has the > money and you still have your money. The only problem would be if it > didn't release the code and some other customer would come along and > asks for the same thing to be developed. In that case it > might be worse > (but for Red Hat) because it can now get paid a second time, while it > won't get paid if the code is released. But that is a general > problem of > GPLed code and not specifically to Wine. I think that > companies working > with GPL code are well aware of that fact and their busines model must > accomodate that fact. 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.

2 1

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

16 Feb '02

> Roland wrote: > > > 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? > > The same way many companies work also with their properiteary > code. You > know your code needs a feature but you don't have the time for > implementation because you have no customer who says he > really needs it. > Of course many customers may be gald to have it, but none is > willing to > pay for it. The someday a customer turns up who says he needs > that stuff > badly and he wants to know how much you charge for it. Then you > implement that feature, you might have implemented anyway > some day, and > once it is available you can give it to all your customers, or you can > charge a price that others are willing to pay even though > they wouldn't > have paid the develeopment price. I worked for a company that worked > exactly that same way Actually I work for a company that works this way as well for some of our products. > and this works also for GPL code as well. No, it won't. There is nothing save ignorance that would make the other customers pay for it when can have it for free. Granted most customers are ignorant (as far as software development is concerned). But building a viable business model 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.

2 1

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

16 Feb '02

> At 10:47 AM 2/16/2002, Patrik Stridvall wrote: > > >> If users are fully informed about what a Trojan horse REALLY does, > >> they may think twice about "running" it. > > > >Obviously everybody should be carefully before using a tool > >and study and understand for yourself what it really does > >an not rely on what other people say about it. > > > >But that doesn't mean that the tool inherits any > >"evil" purpose that the creator of it had in the > >process of creation. > > I disagree. A Trojan horse that, for example, trashes hard > disks or creates zombies for DoS attacks is fundamentally > bad. This is why it's called "malware." Compare the trojan to a weapon. It is the person that uses the weapon that does something illegal (or evil), regardless of whether the weaponed manufacturer had "evil intent. However regardless of whether the user or the manufacturer or both had "evil" intent the weapon is not "evil". A trojan for example might be used to make havoc in the enemys computer system. This is an act of war and is neither illegal nor "evil". > >I think the difference is that I don't consider Stallmans > >agenda unethical, only unrealistic. > > > >Forcing people to releasing small bug fixes is one thing > > It's a start down a slippery slope -- toward appropriating > any or all of their code at will. Well, if you are worried about the license of the C library that close to all Linux application links, you don't have to use it. I think it is entirely reasonable if a find a bug in the C library and fix it that I publish the fix as thanks for having privilage of using it for free. > >Yes, because the motor ways that can transport troups > >can also transport trade goods or people visiting > >other countries in friendship. The more trade the > >more interdepence and the less risk for war. > > Ah, but the government's terms won't let commercial > vehicles on the road. And why should they do that? And what is the analogy with either Nazi Germany or the GPL. > >> Yes, it can. You can forfeit your fair use rights via > >> a contract. And the FSF licenses are profferred contracts. > > > >That remains to be decided in court. > > Actually, no. Fair use rights can be signed away. > Non-disclosure agreements, for example, prevent people > from doing things that might otherwise be allowed > as fair use. Yes, but that have nothing to do with copyright or fair use for that matter. If you get hold of some work in trust you must of course keep that trust, but this have nothing to do with copyright at all. But claiming that some freely available work that I happend to download from site on the Internet that have a file with a license contains some obscure paragraph means that I have been entrusted that work is quite absurd and only in the US would a court even consider such absurd charges. Same if I would have bought the work in a shop. > >> >I don't think they will have much luck though, > >> >they have already tried to stretch the boundaries > >> >of copyright law with the GPL, > >> > >> This is another reason why the GPL is likely to be > >> ruled invalid. An attempt to use copyright law to > >> do anything beyond the purposes stated in the US > >> Constitution can be invalidated as "copyright abuse." > >> (This argument has been made in the Napster litigation > >> and Judge Patel has taken it quite seriously.) Certainly, > >> "turning copyright on its head" (these are Stallman's own > >> words for what a "copyleft" license does) would qualify > >> as copyright abuse. Hence, all "copyleft" licenses are > >> probably invalid and unenforceable. > > > >I think saying that the GPL is copyright abuse it taking > >it little far. > > Not at all. Read the case law. Type "copyright abuse" into > any search engine. I'm not particulary intrested. If you wish to invalidate the GPL fine, for me it is enough that Wine doesn't choose LGPL.

1 0

RE: BSD, Gav, LGPL, Jeremy, and business
by Roger Fujii 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.... -r

1 0

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

16 Feb '02

> At 03:50 AM 2/16/2002, Patrik Stridvall wrote: > > >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. > > WINE is not likely to work more than 90% ever, due to > the facts that Windows is a moving target True, but useful application have little reason to use new Windows API unless it gives them something substantial so I don't imagine this will be a large problem once we are close to completion. As the Windows application market slow moves to Linux with the help of Wine, the Windows application writers are likely to avoid using new Windows API because of portabillity reasons. > and that > Microsoft is likely to patent defensively. That is an orthogonal problem to licenses. Of course with the LGPL various companies can't even make a deal with Microsoft, but then Microsoft are not likely to make any deals anyway. > >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. > > This is a concern. Indeed. > >> 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. > > No, I am stating historical fact. A tool is a tool. As every tool it can be use for good or evil. The purpose of the creator is irrelevant in the real world. Only in fairy tales like the Lord of the Rings can tools be inherently evil. Like the One Ring that answers to his master Sauron alone and corrupts everybody else to evil. Therefore I have a half serious question to you: Do you believe that the GPL is like the One Ring that answers to his master Stallman alone, and corrupt everybody else to evil? "One License to rule them all, One License to find them. One License to bring them all and in darkness bind them" You don't seriously believe this do you? > >I care not whether I support Stallman or not. > >I care ONLY about what is good for Wine. > > Ethics, consumer choice, and the future of programming > as a profession all matter as well. It is not ethical > to focus only on the interests of one project. Ah, perhaps I shouldn't have formulated myself better. What I meant was that just because somebody is "evil" supporting _some_ of the things they support doesn't make you "evil" or unethical. Hitler supported building new autobahns (motor ways). I support build new autobahns (motor ways). However this doesn't make me "evil". > >The GPL/LGPL works in ways that are almost the dual to fair use. > >Very simplified: It uses copyright to extend fair use. > > The opposite is true. It attempts to deny fair use by programmers. No license can deny fair use. I think even in people in the LGPL camp agrees with me in this. > And GPL V3 will attempt to deny fair use by ASPs. I'm not sure that "fair use" is the correct term. First of all I personally make a difference between non-infringing use and fair use. At lot of people call both things fair use. What they are trying to do is to make some use that is tradionally considered non-infringing use to be infriging use. I don't think they will have much luck though, they have already tried to stretch the boundaries of copyright law with the GPL, so I predict that they will fail, it is not no much a question on how they formulate the license, it is more question on where the boundaries of copyright really is.

3 3

wine and debian - what's up?
by Dan Kegel 16 Feb '02

16 Feb '02

http://lwn.net/daily/woody-release.php3 says > From: Anthony Towns <aj(a)azure.humbug.org.au> > To: debian-devel-announce(a)lists.debian.org > Subject: [2002-02-16] Release Status Update > Date: Sat, 16 Feb 2002 12:23:18 +1000 > > Hi guys, > > The good news, and the bad news. > > The good news is that base is back in good shape. glibc, base-passwd and > rsync have all had their RC bugs fixed which is very pleasing. ... > > The bad news is that this means we're probably releasing soon, and that of > the hundreds of less important packages with RC bugs (eg, bugzilla, craft, > crossfire-{client,server}, epic4, fvwm95, gmc, gnome-admin, intuitively, > kdepim, moon-lander, tkdesk, wine, and xosview) will be getting randomly > ripped out of testing (in the case where bugs apply to the version in > testing, anyway). What this means, is that if packages you're interested > in have accumulated RC bugs (ie serious, grave or critical) you've almost > run out of time to get them fixed if you want them released. What bugs are they talking about with wine? I only saw one marked as grave: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=133540&repeatmerged=yes but this one looks worth responding to, too: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=98661&repeatmerged=yes It might be good for wine developers who like debian to have a look at the debian bug tracking system. The main problem appears to be being addressed, but a little overkill never hurt. - Dan

3 2

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

16 Feb '02

> >A tool is a tool. As every tool it can be use for good or evil. > >The purpose of the creator is irrelevant in the real world. > > Not so. When one is reverse-engineering a virus or Trojan horse, > for example, it helps a great deal to know what the creator > intended. > > And the GPL is, in many ways, a Trojan horse. (It's viral, too, > but that's another issue.) > > Programmers see the rhetoric at the top claiming that the license > will promote "freedom," and place it upon their code -- whereupon > its terms and conditions promote Stallman's agenda instead. > > If users are fully informed about what a Trojan horse REALLY does, > they may think twice about "running" it. Obviously everybody should be carefully before using a tool and study and understand for yourself what it really does an not rely on what other people say about it. But that doesn't mean that the tool inherits any "evil" purpose that the creator of it had in the process of creation. Sure there are trojan horses in the world intend or not intended and you should be careful what you use, that goes without saying. > >Therefore I have a half serious question to you: > >Do you believe that the GPL is like the One Ring that > >answers to his master Stallman alone, and corrupt > >everybody else to evil? > > You're being overly dramatic (and a bit silly) here. It was meant to be. I was just testing you. If you had answered yes, I would have known that further discussion was meaningless. > >> >I care not whether I support Stallman or not. > >> >I care ONLY about what is good for Wine. > >> > >> Ethics, consumer choice, and the future of programming > >> as a profession all matter as well. It is not ethical > >> to focus only on the interests of one project. > > > >Ah, perhaps I shouldn't have formulated myself better. > > > >What I meant was that just because somebody is "evil" > >supporting _some_ of the things they support doesn't > >make you "evil" or unethical. > > Alas, by using Stallman's licenses -- which are designed > to further his agenda to some extent no matter WHERE > they are used -- one is promoting something unethical. > One may not be doing so intentionally (just as one is > not being unethical if one votes for a corrupt politician > whom one does not know to be corrupt). But if you know > that you're supporting unethical activities and continue > to do so, then you are yourself not acting ethically. I think the difference is that I don't consider Stallmans agenda unethical, only unrealistic. Forcing people to releasing small bug fixes is one thing but forcing people to contribute considerably more will soon find that the willingless to contribute will decrease unless some external factor exists. > >Hitler supported building new autobahns (motor ways). > >I support build new autobahns (motor ways). > > > >However this doesn't make me "evil". > > I could invoke Godwin's Law here, but I won't. ;-) > > In the analogy above, suppose you find out that the > autobahns in question won't actually go anywhere that > citizens (including you!) want to go, but are designed > to support military invasions of other countries in > which many innocent people will be needlessly hurt > or killed. Do you still support them? Yes, because the motor ways that can transport troups can also transport trade goods or people visiting other countries in friendship. The more trade the more interdepence and the less risk for war. You can't have the good without the bad. > >No license can deny fair use. > > Yes, it can. You can forfeit your fair use rights via > a contract. And the FSF licenses are profferred contracts. That remains to be decided in court. Anyway such considerations are close to meaningless a license can only binding to anybody buying or downloading a work. IIRC a judge suggested that if somebody found a piece of work lying on the street he could do whatever he pleased with it. I can for example have my friend do it and access the work over the network on his computer or however. As far as fair use is concerned it will not consider how you got hold of whatever you claim fair use on. > >I don't think they will have much luck though, > >they have already tried to stretch the boundaries > >of copyright law with the GPL, > > This is another reason why the GPL is likely to be > ruled invalid. An attempt to use copyright law to > do anything beyond the purposes stated in the US > Constitution can be invalidated as "copyright abuse." > (This argument has been made in the Napster litigation > and Judge Patel has taken it quite seriously.) Certainly, > "turning copyright on its head" (these are Stallman's own > words for what a "copyleft" license does) would qualify > as copyright abuse. Hence, all "copyleft" licenses are > probably invalid and unenforceable. I think saying that the GPL is copyright abuse it taking it little far. As far as the viral aspects of it maybe, but not as a whole.

2 1

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

16 Feb '02

> My only issue is that both you and Patrik have made your > views more than > known, and it's obvious you hate the GPL and GPL-style licenses with a > vengance.. for whatever reason (which, as someone who has worked on > commercial projects involving the GPL, are not - in my experiance and > opinion - based in any substanciated fact whatsoever).. Please do not find me guilty by association. I'm sorry to say it but I don't think Brett Glass have helped my case at all, rather the opposite, because it seems obvious that many people seem to have a hard time seperating the various anti-LGPL view. I personally do not hate the GPL nor GPL-style licenses, I think they have a place in the world, but that place is not nessarily in the Wine project. I have tried to explain why throught countless mails so I will not do it again, just say that I'm not in the I-hate-the-GPL-club rather in the I-don't-think-your-understand-the-price-you-have-to-pay-club or the I-don't-wish-to-pay-the-price-club if you prefer. > 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. However _I_ do not agree.

3 3

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

16 Feb '02

> On Fri, 15 Feb 2002, Daniel Walker wrote: > [...] > > Wine is a _re_implementation .. 90% of the code we > write is double > > work, triple work sometimes .. It doesn't bother me that we had to > > rewrite something, since after all that is what we do.. > Wouldn't we have > > it easy is Microsoft would just release their source? The > real question > > is, if Wine was GPL'd would TransGaming have written the > DCOM code in > > the first place? > > No, the real question is whether Transgaming would have written the > DCOM code if CodeWeavers had not released its typelib code in > the first > place. Is typelib code really in the same DLL as DCOM code? Note, I haven't checked, just asking. > Because it seems to me that one of the main arguments of the BSD > proponents is that we are stupid and that we should have kept all the > code for ourselves. Maybe they are right. What I mean is that you, as every other company, must formulate a business stratergy and from this decide what code is strategic and what code is not. If you decide for example to be a pure consulting company, releasing all code might make sense since you get paid anyway and a better Wine means larger potential market and thus potentially more customers for you. If like Transgaming you wish to improve DirectX, it might makes sense to release non-DirectX code since they don't really have a business model that makes it possible to recoup such costs. This I think was made painfully obvious for Gavriel by Marcus reimplementation of what they did. > But which of the > following two > scenarios leads to the more healthy Wine and Wine marketplace? It depends on what the market want and are prepared to pay for. Since the market is unlikely to pay for random bug fixes, except in some circumstances like support contracts, random bug fixes have limited value. However releasing them for free, increases the value of other products in the market, including your own. Not only because some application will work better, but because a more stable "ground" increases the trust in that even seemingly working application really works. > * The one where we released our window-management code, did dll > separation work, added cross-process handle support, added > cross-process > messaging, released our typelib code (essential for InstallShield/COM > support), released our true-type support, improved winelib > and released > countless bug fixes. > > * Or the one where the public Wine has none of the above (unless new > volunters had magically sprung up out of thin air). There is no reason to state the obvious. But note that since it lies in your intrest to increase the quality and public intrest in Wine it might not been a bad choice. > Where would the first scenario, which appears to be what BSD > proponents advocate, leave the Wine community? I have said that you, like any other company, must consider what is strategic and what non-strategic code for you. It seems to me that Jermemy thinks that by using the LGPL he can both eat the cake and have it and I have tried to explain that this is not the case. By using the LGPL you will force yourself in the future to release code for the benefit of Linux distributions like Red Hat, SuSE, Caldera and Mandrake that are likely to will sign support contract for Wine with 100+ seat companies by strength of already having one for non-Wine stuff. Face it you will not have a chance against them. Even Lindows will have a hard time I predict. Sure you can still live by contracting and selling your proprietary products like CrossOver, but then you can do that even with the current Wine license. > Which one do > Transgaming > and Lindows prefer? Why don't you concentrate on your own situation without worrying about others. > Do they really prefer not to benefit from > any of our > code in the future? There is no reason to ask questions with obvious answers. > The Wine competitive landscape has changed a lot in the past year, > and I believe that it is unpractical for us to continue releasing all > our code under the current license. That may be, but from that doesn't follow that the LGPL is the answer. > We could definitely turn our Wine proprietary but as the above > scenario illustrates this would be bad for the Wine > community, including > for our competitors; even if they don't realise it. And I believe that > all Wine companies need a thriving open-source Wine. Agreed. > That's why I think it is important for us (Wine community + > CodeWeavers + Transgaming + Lindows) to find a better solution. Yes, but the LGPL is not the answer. In his initial question Jeremy was talking about CopyLeft, not nessesarily LGPL. Why not continue the discussion from that point?

1 0

Re: a small patch to wineshelllink
by Michael Cardenas 16 Feb '02

16 Feb '02

forgot this: Changelog - Added a check for file type to wineshelllink. If the file is an executable, add "Type=application" to the kde entry. ----- Original Message ----- From: "Michael Cardenas" <michaelc(a)lindows.com> To: <wine-patches(a)winehq.com> Sent: Thursday, February 14, 2002 3:24 PM Subject: a small patch to wineshelllink > I put this patch together, but once I did the diff against the current > cvs, I see that somebody has already fixed it. Here's a patch that is a > little more correct. > > It checks when an application is creating a desktop link and adds the > "Type=application" line if the link points to an executable. > ---------------------------------------------------------------------------- ---- > --- wineshelllink Mon Jan 14 10:32:12 2002 > +++ /home/michael/wineshelllink Thu Feb 14 11:42:29 2002 > @@ -70,9 +70,11 @@ > [KDE Desktop Entry] > Name=$xname > Exec=wine "$path" -- $args > -Type=Application > Comment=$descr > EOF > + > +(file "$path" | grep -q 'MS-DOS executable (EXE)') && echo 'Type=Application' > + > [ -z "$workdir" ] || echo "Path=\"$workdir\"" > [ -z "$xpmicon" ] || echo "Icon=$xpmicon" > } > @@ -187,3 +189,4 @@ > fi > > exit 0 > + >

1 0

out of memory?
by David Laight 16 Feb '02

16 Feb '02

After a few games of freecell, I get the following message output repeatedly on the terminal I ran wine from. err:local:LOCAL_GetBlock not enough space in GDI heap 01c7 for 136 bytes This is running Wine-20020122.tar.gz under NetBSD. I don't think any of the wine processes have hit any unix limits. Any thoughts ? David

2 1

Wineconf attendance
by Gavriel State 16 Feb '02

16 Feb '02

Since various people have been saying "I'll go if you go", I just want to let people know that Ove and I will both be going to the Wineconf. Maybe I'll bring my fencing equipment and we can settle the licensing debate properly with a duel. 8-) http://www.fencing.net/pages/clubs/ccg/images/sn_ath.jpg -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

4 3

Wine's path VS host path
by David D. Hagood 16 Feb '02

16 Feb '02

Due to circumstances beyond my control, I have an embedded system that I am developing that uses Windows based compilers. Unfortunately, WinNT bluescreens too much for me to be able to work, so I have ported the project to using Gnu Make, with the compilers being executed via Wine. The problem is that the compilers search the path for their sub-components (just like GCC does - the driver calls the preprocessor, compiler, assembler, etc.). Now, the location of the project within the filesystem is not fixed - it depends upon where the developer checks it out. The project has the compilers stored along with the code, so the project is "self-contained". The project has a shell script that sets several environment variables describing the location of the project, and adds the needed directories to the Unix path. However, Wine (wisely) does not make that path available to the Windows program, so when the compiler driver looks for the preprocessor, it bombs. As a work-around, I've stated the the developers must install the tools into a fixed directory, and add that directory to the Windows path as defined in ~/.wine/config. However, it would be nice if the setup shell script could add the tools directory within the project automatically to the Wine path. Has any thought been given to honoring a WINEPATH (or similar) environment variable, which would be added to the Wine path at runtime? On a related note: would it be possible to have a means to tell the wineserver process to "hang around" for a few seconds after the last wine process using it has terminated? Again, in this make process you get lots of "start wine, start compiler, compile, exit. Start wine, start compiler, compile, exit" operations - if the wineserver stuck around for 2 seconds after the last wine process terminated, this would aviod starting and stopping the wineserver process.

5 9

Re: a small patch to wineshelllink
by Alexandre Julliard 16 Feb '02

16 Feb '02

"Michael Cardenas" <michaelc(a)lindows.com> writes: > - Added a check for file type to wineshelllink. If the file is an > executable, add "Type=application" to the kde entry. You can't do it that way, there is no guarantee that 'file' will return the same description on all machines. -- Alexandre Julliard julliard(a)winehq.com

2 1

brett glass
by Shane Shields 15 Feb '02

15 Feb '02

>The words of a man who has no intention, interest or desire to compromise. >"There is no need to compromise because my way is the right way." Brett, no >one >on this list that has read your posts fails to see your point. Some of them >disagree, some of them agree, but a) you have no formal say in the decision >(of >course, you're free to do as you've done and bemoan the issue) and b) you >have >shown no willingness to look at the points of view of the other members of >this >list who don't think the same way you do. >I think it's time you, to use a phrase, either put up or shut up. If you >want >people to listen to you more than you've listened to them, then write some >code. > Then, people might be more interested in what you have to say. Saying >"Well, >I *might* contribute, so long as you don't change the license" and presuming >that your vapourware-work is any sort of argument for people to listen to >you >and do what you want, is ridiculous, childish and egotistical. >We've heard your arguments and attacks on the FSF and RMS. Fine, you've >stated >your case and made your point. Now let the people that can actually make >the >decision make it. hear hear im glad that you said it. cause if you wasnt going to i was. some people like arguing for arguments sake but it takes two (or more) people to have an argument. if no-one was to reply to an unwanted solicitation then that outlet of expression will die a limp death. for people who enjoy vendettas and slander the best medicine is to deny them the satisfaction of knowing that they have produced a response. in other words dont respond to useless verbatribe and it will dissapear like butter on a hot plate. this is the only mail that you will see from me about this subject (no need to regurgitate useless code) best regards Shane Shields -- To drink the WINE of success you must first seek the sayings of source _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

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

15 Feb '02

> > 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. > > > I have been avoiding this debate although reading it closely. > However i > thought i would step up to the plate on this one, as someone whose > salary depends on Jeremy's vision. > > 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. If your critical app crashes you can just hack on > the code and > make it work. In fact we dont really expect anyone on this > list to buy a > Wine distribution from us. Yes, that is pretty obvious. > However if a company unfamiliar > with Wine, or > even linux wants to get a critical app working on Linux using > Wine they > have to choose. The could hire a developer and have that person figure > out wine and do the work, or buy a distribution of Wine supported by > proven Wine developers. > > 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. The problem is not that I or the other Wine developers don't pay. The problem is that the company needing a 100+ seat license runs Red Hat, SuSE or Mandrake or some other Linux distribution. They turn to their respective distributor say Red Hat and say that they are prepared to pay $XXX per year for a better supported Wine. Red Hat in turn hires me (or some other on this list) to do this and I do: cvs update ; ./configure ; make install That is your problem. Sure Red Hat might write a contract with you instead but then perhaps they consider you a competitor and hire me instead or perhaps they believe I'm better or whatever. > 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. Assurance about some things can be given but everything has a price. Will you pay it? Will it really do what you expect it does?

2 1

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

15 Feb '02

> On Fri, 15 Feb 2002, Patrik Stridvall wrote: > > > Still think that after reading my reply to Jeremy? > > Yes, I do. > > Listen Patrik, in the past you seemed to be a reasonable > person. Now you > are indistingushible from a troll. Really. It seems that whatever is > argued, you have a psychotic tendency to invent a counter-argument, no > matter how silly it is. Yes, I'm quite aware that some people consider my tendency of almost never giving up irritating. :-) But what do you expect me to do when I have a feeling that going to LGPL is a terrible mistake? If you don't understand it if I explain it one way, perhaps you will if I explain it another way, of course often I hope invain... > Now, that fun sometimes, but it has > gone too long, > too often in this bitter thread. For this very reason I have > avoided to > argue with you, but I will make this one exception, since the > thread has > progressed past useful long time ago. If you have made up your mind you have, but I'm arguing for people that haven't. > > Very true and this significantly weakens any "protection" > > that the LGPL offers. > > Which is a feature, and which should silence all reasonable BSD > supporters. BSD has the same feature so when comparing pros and cons this certainly doesn't weight in favour LGPL. > The ones that are left, simply ignore this very > important FACT > (It's emphesised since I don't want to argue it, let's assume > it for the > purpose of this discussion). Their is nothing to argue, BSD has the same feature. Obviously we should concerntrate on the relative pros and cons. > > Perhaps, but at a terrible price. Read my reply to Jeremy. > > Crap. What terrible price, WTF are you guys smoking, 'cause I > want some of > it! Once again: Wine is isomorphous to a Linux distribution. They are > growing MUCH faster than Wine ever did. They have a lot of commercial > backers. No Wine is not isomorphous to a Linux distribution. Wine will be an essential part of EXISTING Linux distribution. Sure there might be a market for new specialized ones like Lindows but don't have to large hopes. I'm sure there will be Linux distributions willing to offer proprietary extension to Wine if some company offers it. There is nothing strange about that, some distributions already bundle proprietary applications. > Stop this stupid, idiotic, "LGPL will kill all > business" argument. I have never said, that LGPL will kill all business models, now you are claiming things I never said. There are some people, none named, none forgotten in the BSD camp that he made similar claims, but please don't make me guilty by association. I have said that it will limit the possible business models severly. For example read Gavriels first reply or for that matter read my last reply to Jeremy again. Since the LGPL removes the work protection that the work have from copyright, it is almost essential that you get assurances that you get paid before doing the work. This is in most markets called contracting. > > 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. > > Patrick, you are incorrigible. Yes, our purpose in choosing a > license is > not to support as many business models as possible. No. It is > to find a > licence that _overall_ is best for Wine. My point is that since the Microsoft DLL in general have no clear design the LGPL will articially for no good reason prevent some business models that you otherwise have been possible. This means that Microsoft arbitrary choices will prevent many otherwise possible business models. Is that good? Of course this requires that Alexandres analysis of the LGPL is correct, if he is not, you will lose most of the rest of the protection that the LGPL might provides. In that case you will have Wine under a close to meaningless license that will potentially scare away people not wishing to try their luck in court. > Now, we all agree that some > commercial involvment is good. The question is, how much? All possible > one? Like everything is life, the answer must lie in the > middle, not at > axtreme. Obviously. I have never claimed anything else. > So we must sacrifice a few business models to > benefit Wine. It's > just fare. An LGPL licence will keep most of them still > viable (such as > TransGaming, for example). WTF is your problem with it? My biggest problem is that because of way Microsoft have designed the Windows the sacrifice will be complete arbitrary. I'm not entirely against some sort of "copyleft", that is why I in my debate with David Elliot proposed that we could possibly have a license that makes it clear that linking to proprietry libraries are allowed. Possible we could add some paragraph about that the functionality must be a seperate part of DLL in some way. I don't really like it, but you were speaking about compromises....

1 0

Question concerning internal string usage
by Gerhard Gruber 15 Feb '02

15 Feb '02

Some functions are duplicated with their only difference being that one of them is wide character (W) and the other is ASCII (A). Of course it makes sense to convert one of them into the other and reuse the existing code. What I was wondering about, though is that, at least in the exmaple of files/profile.c the W functions are converting to A instead the other way around. Shouldn't we expect some problems with systems using wide characters or is this handled such that these characters are represented as more then one characters in ASCII? In Windows I'm pretty sure that A is always converted to W for such functions.

3 2

Re: BSD, Gav, LGPL, Jeremy, and business
by Roger Fujii 15 Feb '02

15 Feb '02

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote: > Can't you see that most Linux distributions _are_ made mostly of > xGPLed code, and that hasn't stoped a lot of proprietary companies such as > Oracle, SAP, IBM, etc. to release and develop code on this platform? This is an apples to oranges comparison. Things that CALL LGPLed libraries are safe. The problem is that things that work WITHIN a library is not. You can *say* that it stops at the DLL boundaries, but the license does not back what you say. The LGPL has a "work as a whole" clause that can easily be argued that it applies to anything within wine. So, while an installer for wine won't be affect by LGPL, any DLL that wine uses can arguably be considered a part of wine (unless you go through the pains of making sure that your DLL was added AFTER wine, and that the new wine works without your dll. If you want a LINUX analogy, look at device drivers. The *GPLness of the kernel means that no propriatary driver can be shipped as a part of any distribution. Steve Langasek wrote: > Since Jeremy has stated his intention to release future code changes only > under Copyleft, the decision for Wine contributors to make is a simple > one: do you believe that the benefits of potential additional corporate, > closed-source adopters of Wine outweigh the certain loss of code > contributions from Codeweavers, a known active contributor? ok... finally, a reasonable place to start, as it's finally an admission that the choices are exclusionary to some respects. re jeremy's posting: It's pretty obvious that there's animosity between transgaming and codeweavers. Peronally, I think the main problem here has very little to do with licensing, but rather that the commerical pie for wine is really only large enough to support 1.3 companies. So, let's just go over some of the points: > 1. The current license encourages forks. a) the forks already exists - do you think changing the license will fold in any of the forks? b) the forks are also signs of (new) development. Presumably, no one would fork something just for having a fork. > 2. The current license discourages competitors > from releasing their code. s/discourages/does not encourage/ > 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. So, are you saying that Gav is an insignificant contributer to wine? and that all the code inside with is 100% written by codeweavers? > You know, the concept of making money on Free software is crazy > enough without enabling your competitors into the mix. Think the problem here is that you guys are competing in the first place. If you were in different markets, one would think you could "trade" components into open source, thus reducing redundancy without having to risk your business. Also, I don't think it's unreasonable to ask (as a switch to LGPL might discourage Transgaming from ever releasing the dcom code - gav, will this affect your decision?) what exactly is codeweavers going to release LGPLed in the short term and why the urgency? > 3. The current license is harmful to the growth > of Wine, because it creates a murky, uncertain ground. > Well, a Copyleft license provides potential > corporate citiziens with written rules. LGPL is not the only license that's a copyleft. Just from cursory reading, MPL seems more reasonable that LGPL since section 3.7 makes a distiction between "covered code" and "larger work". Personally, if a simple "requirements" list is made, some choice can be made that isn't disagreeable to too many people (unless you have philosophical restrictions like "it can/can't be GPL compatible"). If copyleft and commercial viability is the only requirement, MPL would be a reasonable compromise. -r

2 1

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

15 Feb '02

Brett, Thanks for the email. I've read your argument, many times over on the wine-devel list. I don't buy it. Regards, Daniel Schwarz dschwarz(a)bellatlantic.net

1 0

BSD, Gav, LGPL, Jeremy, and business
by Dimitrie O. Paun 15 Feb '02

15 Feb '02

People, I am sorry I have to fuel the flames, but I have to say what I have to say. 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. And there's reason for that -- the LGPL make a lot more sense for Wine. 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. 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. 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. 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! I'll say this: if Alexandre will start maintaining a LGPL tree, I will submit my code only as LGPL. Everybody who believes even _a_little_ in an LGPL solution should do the same. -- Dimi.

2 3

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

15 Feb '02

> Since Jeremy has stated his intention to release future code > changes only > under Copyleft, the decision for Wine contributors to make is > a simple > one: do you believe that the benefits of potential additional > corporate, > closed-source adopters of Wine outweigh the certain loss of code > contributions from Codeweavers, a known active contributor? Even so, since the LGPL is a one way street, remember that it might not always be so in the future. If we choose LGPL there is no turning back. Remember that always.

1 0

RE: Jeremy makes a persuasive argument for LGPL
by Patrik Stridvall 15 Feb '02

15 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. Read my reply the Jeremy. Do you are really think the price is worth paying? > 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. I don't think such paragraph are worth the paper they are written on and as long as the Microsoft trial is going on thet wouldn't dare even try. > 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. Will it? You don't think most of the market will be eaten up by the traditional Linux distributions (Debian, Red Hat, SuSE, Mandrake etc) and possible Lindows? > Meanwhile, LGPL ensures that core code improvements will flow back to > benefit all, not just those individuals and companies that have an > altruistic bent. Yes, but at a terrible price.

1 0

Re: Scrollbar Fix
by Alexandre Julliard 15 Feb '02

15 Feb '02

Phillip Ezolt <ezolt(a)perf.zko.dec.com> writes: > It converts the intermediate variables to floats instead of > int, which guarantees that multiplication of large values of don't > overflow. (with a small sacrifice of accuracy) You should probably use MulDiv() instead of floats. -- Alexandre Julliard julliard(a)winehq.com

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