wine-devel

wine-devel@winehq.org

4 participants
84401 discussions

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

Re: BSD, Gav, LGPL, Jeremy, and business
by Brett Glass 15 Feb '02

15 Feb '02

Correction to the message I just sent: "Finally, because the (L)GPL makes product differentiation at best and often infeasible or impossible" Should have been: "Finally, because the (L)GPL makes product differentiation at best difficult and often infeasible or impossible" --Brett

1 0

WINELIB is not defined
by Andriy Palamarchuk 15 Feb '02

15 Feb '02

To check whether an application is compiled under Wine I should use WINELIB macro, right? It seems the macro is not defined if I try to check on it in programs/notepad. Should I define it in the Makefile.in explicitely? I see that other programs, specifically winhelp, wcmd, progman, use conditional compilation blocks, based on the macro, but I did not find it defined in their Make files. Sorry for the newbie question, but I'm not sure how this is supposed to work. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Got something to say? Say it better with Yahoo! Video Mail http://mail.yahoo.com

2 1

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

15 Feb '02

> > >Several people have asked me to clarify my original post. > > I just don't understand one thing: > > How does your company expect to make money once WINE is > xGPLed? If all your > > code has to be contributed back, why should I buy it from > your company? > > Hi, > > Companies will pay because they want certain functionality to > be implemented > that isn't there. For example, let's say you are company > Foo, who wants > their product "FooBar for Windows 2000" to work in Linux using WINE. > It makes use of some COM related functionality not currently in WINE > (like Out-of-proc objects or something) What do you do? > I mean, you can't just post on wine-devl and say "hey guys, > stop making > patches for DirectX, we want you to fix this COM stuff and NOW!" > No way. Do you get your internal staff to do it? Maybe. However, > most likely none of them know anything about WINE, so there is a big > ramp up time. Or do you hire an outside company to help you out, > a WINE developer-for-hire so to speak. That's why companies like > Macadamian and CodeWeavers get hired by clients, to get functionality > into WINE that would otherwise not get done. It allows the > client to focus > the fixes in the areas they need for their particular > application. Congratulations, you have just explained is why specialized consultants can make a living in the Wine market. However since this with a similar explaination is true in almost any market, I can't say I'm impressed. Sorry. That was perhaps a little rude. I was trying to illustrate a principle not insult you. It was not really aimed at you. > Sure, these > changes (optionally for BSD license, "required" for GPL) are > made available to > competitors, but as far back as I remember and for a while > yet I imagine > any moderately complex app will always require some fixes to > WINE to get > it to work perfectly. Yes, but sometimes this is what your client wants, sometimes it is not. Sometimes that client doesn't understand what is good for him and then you have the choice of explaining why or keeping you mouth shut. Your choice, sometimes this is better for you, sometimes it is not. Note however, what is good for you is not nessarily the same thing that is good for your client. Longterm that is. Short term the client pays you for your work regardless.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel