February 2002 - Wine-devel - list.winehq.org

RE: Wine license change: it's about time!
by Patrik Stridvall 07 Feb '02

07 Feb '02

> On Thu, 7 Feb 2002, Dan Kegel wrote: > > > It's about time. Putting Wine under the xGPL is the best way > > I can think of to ensure its future. The xGPL makes it possible > > for competitors to cooperate for their common good - which > is pretty amazing. > > This is a fundamental point which we haven't had a chance of > discussing > last time as we argued over silly future (unlikely) possible > changes in > copyright law. I think you missunderstood what I was saying I said that I believe that the courts eventually will interpret the CURRENT law as I suggested since it the way that IMHO makes the most logical sense. For the law to perform as you wish will require very complex and possible self countradictory or unconstitutional interpretations. Anyway, there is no reason to restart that discussion. I and Alexandre have in private mail agreed that we disagree and the discussion is ended. Lets for the sake or argument assumes that the LGPL can do what you believe it can. I will try to in this and latter mails explain why this is not a good idea for a project like Wine that is not an ordinary library like the LGPL is designed for. > One important argument was that building a thriving economic > environment > around Wine is essential for its success. > > Everybody agreed on this premise, IIRC. Yes. > The argument followed that BSD license is better for creating such an > environment, and hence better for Wine, since more business will > contribute more code back. Yes. > This, I'm afraid, is entirely false. > > I argue that in fact, the BSD license is a STRONG DETERANT > for businesses > to contribute code back, while the LGPL provides an INCENTIVE. For normal libraries this might have some (but only some) truth in it . However Wine is not a normal library as in vain tried to explain last time. Trying to claim that LGPL is good for Wine because (and only because) it is good for normal libraries is pure nonense. There are fundamental differences among them: In the normal LGPL:ed library world, an application that demands some extra functionallity in some LGPL:ed library can do that by implementing that functionallity is the application itself or possibly if the extra functionallity is extensive in a new library. No need to extend the LGPL:ed library. Here LGPL doesn't hurt at all. The application or for that matter the new library can be of any license. You would be hard pressed to claim derivation even if the new library calls your LGPL:ed library. Claiming derivation for the application is clearly absurd. Another difference: In the normal LGPL library world, the application will need the extra functionallity for the NEXT version. In the Wine world, the application will need the extra functionallity for the CURRENT version since it already work on Windows. > Note that I do not care, for the purpose of this discussion, about > businesses which don't intend to contribute code back. They > are of no help > to Wine, and thus irrelevant (if not a little harmful, for reasons so > eloquently explained by Alexandre). Just because they initialy decide not to contribute back doesn't mean that they won't do it in the future then they for example see the work of keeping a seperate tree. Or like in the case of Transgaming when they feel their income is secure. You can't just dismiss such businesses as irrelevant. Irrelevant now, perhaps. Irrelevant tomorrow, maybe, maybe not. > A BSD license is a STRONG DETERANT for a business to contribute code > back. The reason for this is that they have no guarantee that another > business will not improve a little the code, and thus get a > competitive > advantage. Or that other companies will not use that code on > top of the > code they wrote but not released, and thus again, get that > edge. What competitive advantage? I don't believe that you will see many business model that will make sense in the Wine world will compete head to head with some other business model, including the main tree. They will select a niche and try and live there. Some will succed some will not. However there is no reason to make survivial harder. > This is a > fantastic _deterant_ for releasing code back. In fact, Gav validated > exactly this point when he tried to argue for the BSD license > last time: > > <talking about the DCOM work> > But there are companies out there who will benefit significantly > from commercial use of this code, and who can afford to sponsor a > portion of the development cost. Until such a sponsorship happens, > we cannot apply the WineHQ license to that code. > > In other words, they needed that code. They invested some money do get > it. They are happy with the results. Why not release the > code? They have > what they needed in the first place? The reason is clear -- > it cost them > to get there, they can not aford to bring everybody there for > free. I can > 100% understand that. But if the code was under the LGPL, it would not > matter, because even if they brought everybody there, other companies > could not step ahead of them, since if they did, they themselves could > have used that code. > > In other words, TG could have kept Direct3D proprietary, released > everything else back under LGPL, and they could have _known_ > they still > have the competitive edge in the D3D work! This is why the > LGPL is in fact > an _incentive_ for such colaboration. Read Gavriels reply. Need I say more? > Bottom line is clear: as the project matures and becomes more > useful, the > deterant of contributing code back from a business > perspective is going to > greatly increase, while at the same time, the incentive under the LGPL > would have also increased. This is a just claim without an sort of proof. For head to head competitors it has some (but only some) relevance. However this is not the kind of business models we are likely to see IMHO. > In economic terms, for Wine, one spells death, the other, life. Another grandiose claim without any substance. The world is not that simple. Both approaches has their pros and cons but neither is life not death.

2 1

Re: Favor: I need examples of un or poorly documented APIs
by Fredrik Ohrn 07 Feb '02

07 Feb '02

One little gem I found once is "GetInputDesktop", exported from user32.dll in Windows NT and friends. It belongs to the "Window Station and Desktop Functions" topic in MDSN but isn't mentioned anywhere at all. The function can for example be used to detect if a screen saver is running or if the Login/SAK-screen is active. I don't know if it is used by Microsoft in anything that isn't part of the core OS. Regards, Fredrik Ohrn -- "It is easy to be blinded to the essential uselessness of computers by the sense of accomplishment you get from getting them to work at all." - Douglas Adams Fredrik Öhrn Chalmers University of Technology ohrn(a)chl.chalmers.se Sweden

1 0

Re: Wine license change
by David Wheeler 07 Feb '02

07 Feb '02

YES. I think switching changing the Wine license to the LGPL is a VERY good idea. If the license isn't changed, Wine is going to continue to suffer from code forks. The current license encourages companies to take Wine, make a proprietary fix, and keep the result proprietary, which means that no one else gets the benefit and the work is fragmented. This is already happening, as Steve Langasek noted: >One thing to bear in mind is that others already ARE forking the Wine >code... Other companies are forking >with no intention to contribute back (see Lindows.com) still others >(Transgaming) have made reintegration of their work contingent >on turning a[n] profit. As Wine becomes more capable, there will be more companies who do this, taking but never contibuting. I agree with Dan Kegel, who said: >It's about time. Putting Wine under the xGPL is the best way >I can think of to ensure its future. The xGPL makes it possible >for competitors to cooperate for their common good - >which is pretty amazing. As Bob Young said .. >"There's been a fundamental problem of getting industry consortium >to work together... But we don't have a single corporate lawyer >in the room. We haven't signed a single licence among any of us... >With the GPL, we have eliminated the need for trust." In my opinion, the LGPL more accurately reflects how most Wine developers _actually_ work. I think many contibutors expect that anyone who improves Wine itself will give those contributions back to the community, while still allowing proprietary programs to use Wine as a library or infrastructure. The LGPL merely changes this expectation into an enforceable requirement. #include <standard_disclaimer.h> --- David A. Wheeler dwheeler(a)ida.org

3 2

RE: Example of ODBC and wine
by Medland, Bill 07 Feb '02

07 Feb '02

Yes unixODBC and DB2 It's easy enough for that. Bill > -----Original Message----- > From: Ricardo [mailto:r00tzz(a)yahoo.co.uk] > Sent: Thursday, February 07, 2002 9:19 AM > To: wine-devel(a)winehq.com > Subject: Example of ODBC and wine > > > has anyone used wine with a program that conects to an ODBC > database? How > have you set this? I was thinking about FreeTDS but i > configured it and > doesn't know what to do nexe. Any help? > Thanks > Ricardo > > > > >

1 0

RE: Wine license change
by Patrik Stridvall 07 Feb '02

07 Feb '02

[Oh, no here we go again] > Some recent events have occurred that have made me change my opinion > about a Wine license change. I see. > During my involvement in the Wine project, I have always striven to > make sure that I, and my company, did what was best for the Wine > project. Before I critize you to much. I would like to point out for the record that I do believe that you and Codeweavers as far reasonable possible have done what you claim and that you have my gratitude and respect for that. However remember that: "The road the hell is paved with good intentions." > I believe Wine's success will help to make the world a > better place. Partly agreed. I believe that people moving from Windows to Unix is a good thing and that Wine (or Wine like projects) are among the nessary tools to acceive this. It is not the only tools though. > To that end, often through difficult personal > negotiations, I have always insured that all of my contracts require > that all code changes be returned to Wine. This, in effect, treats > Wine as an LGPL product. You have my respect for that as explain above. However I'm not entirely convince that this always is a good thing. It is a probably a good strategy by average but do not believe it is always the right thing. In military terms: A strategic retreat is often good, eventhough retreat as a strategy is not. > You can argue that the flexibility granted by the Wine license has > meant that I received some business I would not otherwise have had. > Gav, for example, has pointed out that Corel would never have worked > on Wine if not for its license. There are two ironies there - first, > Corel has always been a great Wine citizen, IMO, never 'abusing' the > license. Second, while we did work with Corel to help them with Wine, > we never signed a contract with them. Their lawyers and I were never > able to agree on a contract that we thought would sufficiently protect > Wine. Fortunately for me, we were able to work with Corel without a > contract, but this issue to this day creates unnecessary friction > between my company and Corel. Read that Gavriel have written again. Surely you must realize that there is a difference between: 1. Specificing a goal in the beginning and be legally forced to stick to it until the end no matter what. 2. Specificing a goal in the beginning and be legally able to retarget when reallity didn't turn out as you expect. There is a difference between striving to do good and being forced to do good because of an earlier promise despite the fact that reality has changed. > However, with some recent events I cannot disclose, it is clear to me > that the opportunity for Wine to be used in a proprietary product is > too tempting and has caused some harm to the Wine project. Based on > experience, I feel strongly that the potential for harm is great > enough that CodeWeavers needs to take two actions. First, we would > like to release all new code we develop under an LGPL style license. > Second, I would like to open another call for a license change and > thereby strongly add my voice to Alexandre's. Luckily for you your credibillity is pretty high. Normally I immediately raise the red flag of warning then I heard claims made referring to undisclosed information. I understand that you are worried about the future but don't let your fears drive you onto the wrong path. > Thus, I would like to call for a change in the Wine license. I think > we all agreed that the LGPL formed the basis for a good 'alternate' > license strategy. Eben Moglen, the counsel for the FSF, has kindly > offered to help review licensing strategies for Wine. The goal is to > attempt to secure some form of Copyleft protection for Wine while > still permitting proprietary software to link and bind with Wine. I > think it it is great that we have, in Eben, not only the leading legal > scholar on free software licensing, but a great hacker to boot. I > think he will clarify exactly what is possible and what is not > possible with GPL style licenses and insure that the license we choose > will meet our goals. Talking to Eben can only help. However we need to very careful to specify not only what we want to acceive but also and MUCH more importantly what we want to _avoid_ the license from accidently preventing. So what do you want this new license to acceive? And the much more important question what do you want to avoid the license from accidently preventing? > When Alexandre last brought up this issue, he was very disappointed. > He felt that there was not enough support from the 'silent majority' > of Wine developers for a license change. His overriding lament to me > was 'No one cares'. I care. > He further felt that since a small number of > major Wine contributors objected, that it was not appropriate to > change the license. > > I would like to ask for a more formal process. I would like each and > every contributor to Wine to send Alexandre a private email with an > 'Agree' or 'Disagree' opinion, so that he can more truly assess what > the contributors to Wine really want. The specific question I wish to > pose is as follows: > > Should the Wine project switch to a license which has as > its goal to attempt to secure some form of Copyleft > protection for Wine while still permitting proprietary > software to link and bind with Wine? > > Please privately let Alexandre (julliard(a)winehq.com) know what you > think, and then publicly respond to this thread as you feel > appropriate. Done. > Finally, in closing, I wanted to summarize our position. We plan to > release our future work under an xGPL style license, and we would like > the rest of the Wine community to join us. If the bulk of the > community wants to stick with the current license, then we will > probably end up making a separate CVS development tree. Anyone would > be free to use our work from that tree, under the xGPL-style license > terms the FSF's lawyers recommend. Is that a threat or what? Hmm. I think I will intrepret is as symptom of your fears and advise you to try and avoid acting in a hastely manner. By all means start a dialog the FSF lawyers, but don't do anything you might later regret.

1 0

Conferences
by Keith Matthews 07 Feb '02

07 Feb '02

Speaking of conferences, is anyone planning on going to FOSDEM (16th & 17th Feb, Brussels) ? -- Keith Matthews Frequentous Consultants - Linux Services, Oracle development & database administration

2 1

Example of ODBC and wine
by Ricardo 07 Feb '02

07 Feb '02

has anyone used wine with a program that conects to an ODBC database? How have you set this? I was thinking about FreeTDS but i configured it and doesn't know what to do nexe. Any help? Thanks Ricardo

2 1

Re: Wine license change
by Dave Jones 07 Feb '02

07 Feb '02

I like the LGPL and all, but I think converting to this license will hurt greatly the current projects such as Lindows and Transgaming and, in proxy, hurt wine. Mindshare is important, and to see Wine in succesful projects helps people to realize it as a viable product. I don't think anybody is turned off from developing wine with its current license, but the change would turn away many I'm sure. Some people get thier paychecks working on Wine (Transgaming). I think TG has done great things for Wine, and I wouldn't have supported them had they not promised to release thier changes back to the main wine tree. Lindows, however, can eat it. By not intending release thier changes and to sieze the Wine code to make it thiers for profit, I cannot, and will not support them. What I would like to see is a new licence that sees that all forks move back into the main wine tree at regular intervals, say, after 6 months or a year while still allowing companies to do what they will with the code. We aren't looking to stifle innovation here, I like the TG subscription model, and I would probably contribute in that kind of fashion to many projects, but there must be an incentive to do so (like TG's DirectX work) I am against a change to LGPL, but I realize the current license is allowing lindows to stand on the shoulders of giants and wearing a long overcoat to cover it up, and that is just wrong. Dave Jones - dajones(a)purdue.edu

1 0

Re: Wine license change
by Robert Boucher 07 Feb '02

07 Feb '02

Just a quick question that I haven't seen addressed: If the license is changed to LGPL, who will own the copywrite? The contributors, or the Wine Project? -Rob

2 1

Wine license change
by Jeremy White 07 Feb '02

07 Feb '02

Folks, Some recent events have occurred that have made me change my opinion about a Wine license change. During my involvement in the Wine project, I have always striven to make sure that I, and my company, did what was best for the Wine project. I believe Wine's success will help to make the world a better place. To that end, often through difficult personal negotiations, I have always insured that all of my contracts require that all code changes be returned to Wine. This, in effect, treats Wine as an LGPL product. You can argue that the flexibility granted by the Wine license has meant that I received some business I would not otherwise have had. Gav, for example, has pointed out that Corel would never have worked on Wine if not for its license. There are two ironies there - first, Corel has always been a great Wine citizen, IMO, never 'abusing' the license. Second, while we did work with Corel to help them with Wine, we never signed a contract with them. Their lawyers and I were never able to agree on a contract that we thought would sufficiently protect Wine. Fortunately for me, we were able to work with Corel without a contract, but this issue to this day creates unnecessary friction between my company and Corel. However, with some recent events I cannot disclose, it is clear to me that the opportunity for Wine to be used in a proprietary product is too tempting and has caused some harm to the Wine project. Based on experience, I feel strongly that the potential for harm is great enough that CodeWeavers needs to take two actions. First, we would like to release all new code we develop under an LGPL style license. Second, I would like to open another call for a license change and thereby strongly add my voice to Alexandre's. Thus, I would like to call for a change in the Wine license. I think we all agreed that the LGPL formed the basis for a good 'alternate' license strategy. Eben Moglen, the counsel for the FSF, has kindly offered to help review licensing strategies for Wine. The goal is to attempt to secure some form of Copyleft protection for Wine while still permitting proprietary software to link and bind with Wine. I think it it is great that we have, in Eben, not only the leading legal scholar on free software licensing, but a great hacker to boot. I think he will clarify exactly what is possible and what is not possible with GPL style licenses and insure that the license we choose will meet our goals. When Alexandre last brought up this issue, he was very disappointed. He felt that there was not enough support from the 'silent majority' of Wine developers for a license change. His overriding lament to me was 'No one cares'. He further felt that since a small number of major Wine contributors objected, that it was not appropriate to change the license. I would like to ask for a more formal process. I would like each and every contributor to Wine to send Alexandre a private email with an 'Agree' or 'Disagree' opinion, so that he can more truly assess what the contributors to Wine really want. The specific question I wish to pose is as follows: Should the Wine project switch to a license which has as its goal to attempt to secure some form of Copyleft protection for Wine while still permitting proprietary software to link and bind with Wine? Please privately let Alexandre (julliard(a)winehq.com) know what you think, and then publicly respond to this thread as you feel appropriate. Finally, in closing, I wanted to summarize our position. We plan to release our future work under an xGPL style license, and we would like the rest of the Wine community to join us. If the bulk of the community wants to stick with the current license, then we will probably end up making a separate CVS development tree. Anyone would be free to use our work from that tree, under the xGPL-style license terms the FSF's lawyers recommend. Thanks, Jeremy

13 21