wine-devel December 2001

wine-devel@winehq.org

86 participants
179 discussions

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > I'm against the fact that the GPL or to a smaller extent LGPL > > tries use the doctrine of derived work as a weapon to achieve > > their goals. It is a very dangerous weapon, since if the courts > > or the policitians decide that a strong doctrine of derived work > > is good it might be disasterous for society as a whole. > > This is a very good point which in fact _promotes_ the LGPL. Not really. See below. > Let me > explain. > > There are two possibilities for copyright law: > > 1. The copyright law becomes stronger. > 2. The copyright law becomes weaker. It is much more complicated than that, but fair enough, lets assume this for the sake of argument. > I will assume, for the purpose of this discussion, that: > > A. Wine contributors wish for 2. I, for one, am very worried about the > direction of law these days (see: software patents, DCMA, > SSSCA, etc.) and > I fully agree with Gerard that it's an unfortunate situation > B. There doesn't seem to be any negative feedback loop that > will prevent 2 > from happening. That is, it is very probable that 2 _will_ > happen sooner > rather than later. I agree. > Now, let's just go through the possibilities: > > Let's look at copyright law. If our dreams come true and 2. > will become > reality, then Wine will be in no worse situation than it is > now in. The > LGPL will effectively become BSD, i./ii. become irrelevant, > and we're all > happy. This scenario is possible, but (unfortunately) not probable. Yes, but in the mean time it is likely that we scare away potential good companies and regardless of the LGPL be effected negativly by bad companies using the lopeholes in the LGPL. > On the other hand, if society moves towards 1., then the LGPL is the > perfect tool because it turns the stronger copyright law > against itself. > In this case, it is the only moral/ethical thing to do: to > turn an evil > instrument against itself, thus provides the > _negative_feedback_loop_ that > is missing at the moment. > > Moreover, if you are worried about the fact that open source > software is > so influential that it can influence the debate over the doctrine of > derived work, then even more so should we opt for the LGPL > because in that > case we would contribute to a negative feedback that will deter > politicians from making the copyright law arbitrarily stronger. So you want Wine to be the catastrofic failure, that was used to change copyright law. You can't seriously want this.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > > Note that I said "_small_ improvements" because of the > > > modular nature of Wine. If the improvements are big, the DLL > > > separation would allow them to keep those changes proprietary. > > > > I don't think small improvements is a problem anyway and > > beginning an implementation of say DCOM is probaly not a > > small improvement and DirectX certainly isn't. > > But if it's not, it's within a small constant factor to > replace the rest > with prorietary code and not release anything. See, if the > DLL is mostly > implemented, the changes are not that big, so they should be > contributed > back. If the DLL is mostly stubs, just rewrite the entire > thing, you're > not wasting that much effort in the first place, and you can choose > whatever licence you want. DirectX and DCOM fall in this cathegory. I have use the Crypto API as an example several times that to illustrate that the DLL:s isn't a relevant protection boundary for the LGPL, even Alexandre seems to accept this. In any case if the DLL is mostly implemented there is very little reason for a company to try to enter the market, it is simply to dangerous, so I don't see the problem. > > > I fail to see _any_ moral/ethical/philosophical problem with > > > this. Do you? > > > > Perhaps you have been more enlightend now. > > Focusing on obscure issues only is anything but enlightening. :) Well, the concrete issues like do we scare potential companies that wants to help way quite hard to argue about in a objective way and I do not really like subjective arguments. I leave them to for example Gavriels that IMHO has done a good good job at that. I have been trying to approach the problem from the other side, that the LGPL doesn't provide much protection at all.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On Tue, 18 Dec 2001, Patrik Stridvall wrote: > > > You forget that some "independent"(*) parts like the Crypto API are > > parts of other DLL:s (like ADVAPI32.DLL) for no particular reason. > > This is ridiculous: it is one of the few exceptions, it is > simply silly to > bring the Crypto API into this discussion. If this the Crypto > API is the > only problem, we can fix it in multiple ways. It is not the only problem it is just a symptom of the gaping hole in LGPL. > > > At this point, I would like to know if people agree up to > > > this point. > > > > I don't. > > That's informative. WHAT don't you agree with? In fact, if we > can agree on > WHAT we disagree, I think it would be a great step forward. "I don't" primarily refered to the previous argument concerning "independent"(*) parts. > > > 0. Isn't Wine's best interest to evolve and develop as fast > > > as it can? > > > > Yes. > > This is a fundamental point. A project like Wine is just like > a living, > breathing creature. And being need to be selfish to survive. Not too > selfish, but it is essential that they have a certain level of > selfishness. Your analogy is flawed, Wine is not living in the meaning that it, if it is to unselfish can die. The mechinisms are entirely different compared to normal life. > In Wine's case, that has to be: 'the licence > should be such > that it would maximize Wine's development'. Yes, but I don't believe that LGPL does, that I have being trying to explain in I forgot how many mails. > > > 1. If so, isn't the LGPL _spirit_ in Wine's best interest? > > > > No, not nessararily. See different mail. > > 1 follows from 0. Period. You can not agree with 0 and > disagree with 1, no > matter what you write in other emails! :) Again, THE SPIRIT > of LGPL, not > the letter. Again, the spirit is: 'if you improve Wine in minor ways, > please contribute back your improvements'. Yes, and the key is minor ways and I believe that is a absolute non-issue as I have explained before. There is no profit in holding minor improvements. > > > 2. If so, why shouldn't we formalize it in the license? > > > > But it isn't nessarily so. > > And why is that? Quite the contrary, because: > > -- For people that contribute back, would chnage nothing > -- For people that don't contribute their changes, it's no > good to us, so > we don't care (which follows by point 0). > > Tertium non datur. That is, there's no other case. QED. OK, since you bring mathematics in to it, I will try to explain in mathematical terms: "The set of people is not invariant over a license change." In fact the set of people are likely to be considerly less. While I have no strict mathematical proof of that, I especially point to Gavriels' reply concerning Corel and Transgaming.

1 0

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On 2001.12.18 05:09 Patrik Stridvall wrote: > [snip] > > Dimitrie O. Paun wrote: > > > Stop for a movement and tell me: are you against the letter > > > or the spirit > > > of the LGPL. > > > > Asking that question is like asking whether I support the spirit of > > Communism: > > "From each according to his abilities - to each according > to his needs." > > > > Well, it sound nice doesn't it? However doing a little > deeper analysis > > I realize that the price for being able to do this is not > worth paying. > > > > Note however that I'm not equating GPL or LGPL with Communism. > > It was just an example from real life, that you get more that > > you wish for. See below. > > > [snip] > > That's a piss poor example. The statement that something > would be from > each according to his abilities and to each according to his > needs sounds > to me at first glance like it would suck. And you don't have > to dig too > deeply to figure out why that would suck. But maybe that's > because I am > an American capitalist though and through and that blatantly > conflicts > with my core values that everyone should do for themselves. Perhaps. However, I think that if you move to Europe, especially northern Europe you will find that people have different opinions. While most people there certainly do not believe in Communism and to various degrees understand why is doesn't work, people are more inclined to be believe in this principle. Actually I think the reason for this is more Protestant Christianity than Communism, but why is not really that important. > And to get > off topic, why is that? Because that's what everybody will > do anyway, > might as well work with that rather than pretend that it is otherwise. So there is no such thing as morality? > This has lead me to another thought. We cannot pretend that > people are > going to release code back to Wine under the X11 license. > However we can > realize the obviousness of the truth that given the chance > people will > take whatever they can and give back nothing in return. Some > folks will > give back because it may make more sense to do so than to > not. But some > folks will be more than happy to take the whole codebase for > their own > good and provide nothing in return. > > We need to stop living in the dream world that everyone who > uses Wine will > contribute back. I have no illusions that everybody will. However there is no need to scare away potentially good companies by using a hard to understand license. > Yes, it is true that Corel, Codeweavers, > TransGaming, > etc. have given a lot to Wine. None of them was or is > required to give > anything. And yet they did. That is kind of shocking for an American Capitalist, isn't it? :-) > If the goal is to let people know that if they want to use > Wine then they > need to contribute back, then the only choice is to put that into the > license. By "use" I am obviously not referring to simply porting an > application using Winelib. I am referring to incorporating > source code > from wine into their own products. > > This is exactly what the LGPL was meant to address. And if they borrow some obscure functions, they might even supply some bugfixes in hope that at a later stage there will be more bugfixes waiting for them when they borrow again (resync) a year later. And if they don't, who has been hurt? If Wine was LGPL:ed they certainly wouldn't have borrowed at all, so no chance at all of getting any bugfixes back at all. > I recall Uwe's usual .sig which is: > Free Software: if you contribute nothing, expect nothing. Indeed and what is your hypotetical sig? "LGPL:ed Software: if you contributed something, use the law as a tool to force others to contribute as well." > Maybe we should have one for wine: > Wine: If you contribute nothing, well, there isn't shit we > can do about it > since we are X11 licensed. I don't think that one came out the way you hoped. Try again.

1 0

Installshield 6 (inter-proc) patches
by J.Brown (Ender/Amigo) 19 Dec '01

19 Dec '01

Any idea when Oves interprocess patches will be put into the main Wine CVS tree? The code currently in WineX isn't really that ugly at all, and it is a very important part of Wine to have working IS6 support. Regards, | Any significantly advanced technology is indistinguishable from | a perl script. Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org]

5 9

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> On Mon, 17 Dec 2001, Patrik Stridvall wrote: > > > > This has been my argument against Patrick exactly. Some > > > protection is better than none at all. > > > > As a general rule, yes. > > > > However this time the protection comes with a price. > > And what might that price be? You fear that we are going to > alienate the > commercial ventures developed around Wine? Yes. > > The problem is not whether LGPL is well written or not the > > problem it is the doctrine of derived work. That is very > > unclear because of lack of good case law. > > Oh, come on, for crying out loud! The LGPL is the best thing > we have -- we > can't wait for a good case law to adopt a license. Yes, there may be > problems, but that's life. We take our best shot -- this is what we're > doing with Wine in the first place! The main problem is that using the LGPL introduces uncertainty to what is allowed and that advantages is not good enough IMHO to outweight the disadvantages. > Patrik, your entire arguments are based on such obscure > assumptions that's > scary! I must tell you, both the GPL and LGPL have received careful > scrutiny from FSF's legal council (and a bunch of other law > professors, > I'm sure). The problem is the doctrine of derived works. Nothing else. Even if their understand of other parts of law are perfect it matters not. IIRC their arguments always seen to assume that the doctrine of derived works is unproblematic if applied to source code. > It's the best we can hope for now. You come along > with a bunch > of 'it is possible' type of scenarios (doh, everything is > possible!), and > say that 'well, everything's in vain, we're doomed, there's > no point in > doing anything, actually...'. In all honesty, it just looks > stinks. Badly. To connect again to the example of the spirit of Communism: I am sure it was very popular to dismiss to fear of the opponents by saying what you have been saying. Trivialising the problems and clinging to clean, pure and uncomplicated spirit of it.

2 1

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> Patrik, > > The more I read your posts, the less I understand what you > are trying to > say. You argued over many hundreds of lines over weird > technical details > and various dubious assumptions about what courts will do in > the future. The main point is that what is legal allow is very unclear. I'm not primarily trying to explain what is legal allowed or not, just pointing out some difficulities in understand what the law really means. > Stop for a movement and tell me: are you against the letter > or the spirit > of the LGPL. Asking that question is like asking whether I support the spirit of Communism: "From each according to his abilities - to each according to his needs." Well, it sound nice doesn't it? However doing a little deeper analysis I realize that the price for being able to do this is not worth paying. Note however that I'm not equating GPL or LGPL with Communism. It was just an example from real life, that you get more that you wish for. See below. > The spirit is simple: > > Here is this thing, we give it to you for free, use it for your own > benefit however you see fit. But it's a labor of love, and > many people put > thousands and thousand of hours in it, together with their hearts and > souls. As such, they hold it dear, and they want it to survive, and > thrive. All we ask is: if you've made _small_ improvements to > it, to make > it useful to your purpose, please contribute those back such > that our baby > can grow and develop together with your business. I'm against the fact that the GPL or to a smaller extent LGPL tries use the doctrine of derived work as a weapon to achieve their goals. It is a very dangerous weapon, since if the courts or the policitians decide that a strong doctrine of derived work is good it might be disasterous for society as a whole. Various commerical intrest might (read: will) for example try to use this to stop 3rd party additions to their works and I don't want that to happend. In short: Be careful what you wish for: "The road to hell is paved with good intentions" > Note that I said "_small_ improvements" because of the > modular nature of > Wine. If the improvements are big, the DLL separation would > allow them to > keep those changes proprietary. I don't think small improvements is a problem anyway and beginning an implementation of say DCOM is probaly not a small improvement and DirectX certainly isn't. > I fail to see _any_ moral/ethical/philosophical problem with > this. Do you? Perhaps you have been more enlightend now.

5 5

RE: Installshield 6 (inter-proc) patches
by Patrik Stridvall 19 Dec '01

19 Dec '01

> Technicalities aside, the LGPL spirit seems to be accepted by most > people. We've heard no end of discussion of what represents > the code, and > so on, but in reality (please Patrik :)), Wine is a > _well_defined_ piece > of software. In fact, it's defined by Microsoft, and well > accepted by the > world at large. > > Now, that being said, there seems to be two camps: > -- the BSD camp, which maintains that BSD is good enough, and that > people will in fact do what the LGPL wants. > > -- the LGPL camp, which says 'well, if that's the case, why > not have it > formalized in the license'? No, I think you misunderstand. I'm not in the BSD camp as you define it. I do not nessarily believe that everybody will follow what the LGPL wants or at least that they will do things that they are certain would have been allowed if it was LGPL. And that is an important part of my objection: It makes it less clear what is allowed. > Before I go any further, I would like to stress a very important > point: Wine is in fact a collection of independent projects. > These are the > DLLs, and they nicely (and unequivocally) partition Wine into lovely > little, independent components. And this means that the LGPL is > independently contained to each and every DLL. It is the _perfect_ > position to be LGPLed. You forget that some "independent"(*) parts like the Crypto API are parts of other DLL:s (like ADVAPI32.DLL) for no particular reason. Actually large parts of the Windows API are "independent"(*). They are just helper function wrappers around other functions. (*) By "independent" mean that they just use other parts of the Windows API like normal applications do and claiming derived work for this would be absurd, just like claiming it for normal applications would be absurd. > At this point, I would like to know if people agree up to > this point. I don't. > The > discussion has been going all over the place, so I would like > to keep this > email short and to the point: > 0. Isn't Wine's best interest to evolve and develop as fast > as it can? Yes. > 1. If so, isn't the LGPL _spirit_ in Wine's best interest? No, not nessararily. See different mail. > 2. If so, why shouldn't we formalize it in the license? But it isn't nessarily so. > When answering these questions, let's try to leave the > commercial aspect > out of it for a second. That is a separate discussion. You > see, the reason > we care about the commercial aspect is that we hope (from > Wine's selfish > point of view -- as it should be!), that the commercial world will > actually _help_ in the development of Wine (that is, having a > commercial > universe around Wine would be in Wine's best interest). Now, > I claim that > the LGPL is _way_better_ for the commercial interests in the > long term, > but I will leave that to a future email (if people care to > discuss it). Claiming that it is better for Wine as a whole is one thing, but claiming that limiting commercial intrests choices is good even for them, requires a explaination.

2 1

implementation of ImageList_*Drag*
by Michael Stefaniuc 19 Dec '01

19 Dec '01

Hello, the attached patch (it's my first wine gui patch, that's why wine-devel is CC'ed) implements the dragging part of the ImageList functions. It works quite well with FreeSolitaire besides the dragged image isn't drawn semitransparent. But how do I draw a semitransparent image? IMO this isn't possible with the BitBlt functions. The ImageList_*Drag* functions shouldn't produce flickering as per the MSDN documentation, but ImageList_SetDragCursorImage (at least in Win9x) produces a short flickering when called. I implemented this function to match the behavior of the native comctl32.dll, but it would be very easy to stop the flickering. Should I change it or keep the Win9x behaviour? bye michael Changelog: Michael Stefaniuc <mstefani(a)redhat.com> fixed/implemented the ImageList_*Drag* functions -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

does mingw include share.h
by Bill Medland 18 Dec '01

18 Dec '01

I'm just off home now so I haven't time to learn sourceforge and download 100M. I need a share.h to go into the msvcrt (for two lousy symbols). I see that much of the msvcrt is based on mingw. Does it include share.h? TIA Bill

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
18
Older →

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 December 2001