- Wine-devel - list.winehq.org

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

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

19 Feb '02

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

4 6

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

18 Feb '02

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

1 0

GetStdHandle problem
by Ignasi Villagrasa 18 Feb '02

18 Feb '02

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

3 2

Re:compiling problem
by Ignasi Villagrasa 18 Feb '02

18 Feb '02

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

2 1

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

18 Feb '02

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

2 1

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

18 Feb '02

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

4 3

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

18 Feb '02

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

1 0

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

18 Feb '02

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

4 3

compiling problem
by Ignasi Villagrasa 18 Feb '02

18 Feb '02

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

2 1