- wine-devel - winehq.org

Re: Dr. Seuss, licensing, and WINE
by David Elliott 09 Feb '02

09 Feb '02

On 2002.02.09 05:32 Plato wrote: > On Sat, Feb 09, 2002 at 03:50:09AM -0500, David Elliott wrote: > > On 2002.02.08 15:03 Brett Glass wrote: > > [...] > > >taxes: It will act in its own interest, not yours. The FSF's > > >sole goal is to destroy commercial software developers, and > [...] > > Give me a break dude. Yes, the FSF wants all software to be free and > > wants to rid the world of commercial software altogether. > [...] > > I think it is worth pointing out the the Free Software Foundation does > *not* > want to rid the world of commercial software. > > Stallman has, however, stated that he would like to rid the world of > *proprietary* software. > Whoops, sorry, you are correct about that. However to the person I was replying to commercial==proprietary. Red Hat Linux is a commercial product, but not proprietary (to give an example). Though I think Red Hat does have a few proprietary products they work on. > There is an incredibly important difference. Please do not use the terms > interchangably. See > > http://www.gnu.org/philosophy/words-to-avoid.html#Commercial > http://www.gnu.org/philosophy/software-libre-commercial-viability.html > Been there long ago.. just kinda forgot. -Dave

1 0

RE: Wine, enthusiasts, businesses and the agony of the license
by vinn 09 Feb '02

09 Feb '02

IANAL, yada, yada [nor can my involvement with Wine be considered anything more than minor] Patrik wrote: > Companies in this group have several choices: > 1. Don't use new improvement in the main Wine tree, only resync > then a new major version of the application should be released. > 2. Maintain a tree by themselves, continually resyncing in order > to make even minor version take advantage of new improvements > in the new Wine tree. I just want to throw a couple of ideas out about using an LGPL license. There's a lot of people with a heck of lot more at stake than me, and ultimately they deserve to have their opinions weighed more heavily than mine. Ultimately these ideas stem from the practice of licensing software rather than the theory (which is where this thread was headed). First, the LGPL doesn't really ever give a time frame for modifications to be released back. We can safely assume that it means "in a timely manner", since in practice this is how it works. I think we could collectively agree that a company such as Transgaming could be allowed a grace period in order to submit their modifications back. Whether this is a week or a year can be debated. If for no other reason than to ensure clean code. Now you may argue that a year is too long, but keep in mind that the modifications do have to be released, and if it takes them a year the amount of work required for a resync may impact other operations. Second, the LGPL doesn't state how the modifications have to be released. In practice this is done electronically via patch files or access to a modified tree. But there's no reason why the modifications couldn't be released on handwritten post-it notes available by request only. In this manner there is a non-trivial amount of work required to integrate the changes. ------ Brian Vincent vinn(a)theshell.com

3 2

something to do
by Jason Phillips 09 Feb '02

09 Feb '02

Hello everyone, I'm interested in doing some work on the wine project. There's quite a few bugs in the bug list are any in particular that someone would recommend as a good place to start? I might need to document for my own good also. Any guidelines on what/how that should be so it can be contributed? Jason Phillips

3 2

RE: Wine, enthusiasts, businesses and the agony of the license
by Patrik Stridvall 09 Feb '02

09 Feb '02

> On Sat, Feb 09, 2002 at 11:40:54AM +0100, Fredrik Ohrn wrote: > > Another observation is that companies in group 1 are in > direct competition > > with each other, so they want closed source. If TransGaming > released their > > DirectX work BSD style, Lindows would quickly be there to > appropriate it. > > You miss one case here: Companies in group 1 that also want > to make money > with group 2s business model. They could do that easily and > it would give > them a distinct competitive advantage over the group 2 only > type enterprises. > Result: The group 2 only companies *can't* release their > sources any more > if they want to stay in business. I'm not sure that I follow you. Groups 2 companies (like Corel) have one or more Windows application that are likely to be their primary source of income. How can group 1 (like CodeWeavers and Transgaming) companies compete with that? Sure they can compete other group 1 companies to get contract with the group 2 company. If the application was DirectX based I can imagine that Transgaming are likely to give a better bid. But I don't see how they compete with the group 2 company. And in the example above I'm sure that Gavriel according to his promises will release any non-DirectX related stuff he had to do in order to fulfill the contract and if group 2 company is nice perhaps they might even require him to release some of the DirectX related code.

1 0

RE: Dr. Seuss, licensing, and WINE
by Patrik Stridvall 09 Feb '02

09 Feb '02

> If people don't understand that some people are decent and > contribute back > regardless of whether they are forced to or not, but others > are not and > require a feedback loop to force this behavior, then they > don't understand > how the world works and we're just wasting time. That is not one of the problem, as far as I'm concerned I fully agree that there will be companies that will be, how should I put it, less honourable. There ALWAYS are in ALL markets. As I sidenote I would like to say that I believe that the LGPL for reasons stated in last debate will not be enough to stop less honourable companies from doing less honourable thing. You might believe me or you might not, as all people arguing against me last time. Be that as it may, that discussing is dead and I will in the future concentrate on "If the LGPL means what you say it does, we don't want the LGPL". > I think it's more of an issue of people thinking too much in > black/white > terms and people that lean strong towards one side or the other. Yes. Perhaps they are not nessarily thinking in black and white but their arguments are often presented that way. I'm not entirely blameless on that point either, I will try to do better in the future. > Look no further than the US political system for a good > example. You have > the Republicans and the Democrats. Generally they take every > issue to > opposite ends of the extreme such that 99% of congress is at > one extreme > or the other, but 99% of the population wants neither extreme. Exactly, but that is because: 1. They want votes so they can do that they feel is right. 2. The ignorant masses are not likely to understand subtle differences in opionion. When the voters give any of them support, the problem is that they didn't really support the extreme views they presented, but they are forced to do it anyway in order of not being accussed of betraying the will of the voter. In the cases of Wine. I hope that the people working with the Wine project are not among the ignorant masses and thus really are able to understand the subtle differences between different positions. > Essentially we could go on forver about X11/BSD vs. GPL. It's been > discussed to death already folks. What we need are reasonable > compromises. Of course you need to have people willing to > compromise to > do that. I suspect most developers are with the exception of > the view > vocal BSD people and the few vocal LGPL all the way people. > I myself am > certainly not at either extreme. Even if perhaps some people won't believe me. I not really an extremist. I try to take a pragmatic view of the world. I believe that GPL has its place, LGPL has it place and the BSD license has its place. However my analysis of the issues at hand makes me believe that LGPL would be really bad in the particular case of Wine, for reasons that I have tried to explain. I suggest that people try to think about scenarios of circumstances where possible extensions to Wine might be made. This might be business models like Transgaming or Lindows.com or just something Joe Hacker or Joe Ex-Windows-Shareware-Writer or Joe I'm-Conspiring -With-A-Proprietary-Library-Company-But-You-Can't-Prove-It are doing. Just like the examples in the my last mail. Then ask the questions: 1. Do you consider his or her behavior morally or ethically defendable? 2. Does it violate the letter of the LGPL? 3. Does it violate the spirit of the LGPL? 4. Does it violate the letter of copyright law? 5. Does it violate the spirit of copyright law? 6. Do you think any reasonable Judge/Jury would find him or her guilty? With the spirit of copyright law I roughly mean: Is it what congress intended and/or is it constitutional? Notice the and/or: It is possible for act of congress to be constitutional without being the intention of the congress.

2 1

Re: Dr. Seuss, licensing, and WINE
by Roger Fujii 09 Feb '02

09 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > Jeremy White, the man who posted the request for feedback that spawned > this discussion, the developer who is encouraging the Wine community to > adopt the LGPL, works for a company whose principal software product > (though not their only source of revenue) is a bundled package of a piece > of proprietary glue code and Wine functionality. > > Let me repeat. The person recommending the LGPL to us sells a proprietary > program built on top of Wine as part of the business model for his > company. if you are going to follow this line of reasoning, you have to ask jeremy whether or not the crossover plugin would have been written IN THE FIRST PLACE if wine was LGPLed at the time. I really think that LGPL would have at least *some* impact on the decision, which is why there is opposition - it impacts future contributers. > Now, do the people arguing that the LGPL would destroy all chance for > people to make a profit believe that Jeremy is stupid, or out to get you? I'll agree that the Brett overstated the case by saying "impossible". But it does make it very difficult and the thrust of the argument is sound. Even though I'm not too sure if codeweaver's business model is too sound (no flames please), but the request for LGPL makes sense because an LGPLed wine now would deny future competitors (even if they contribute) the advantage that they had. -r

1 0

Wine License change: Open question to Jeremy White
by Roland 08 Feb '02

08 Feb '02

Quote from Jeremy White: "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." Obviously you, Jeremy started this discussion. I don't want to sound curious, but I have the feeling that our discussion will be in vain if we don't know about those "events" you can't disclose. I mean suppose that the list reaches a consensus to stay at the BSD license. This wouldn't make a difference would it? You would simply say, sorry: but I have my reasons which I can't disclose and will start a xGPL fork of WINE now... So I think to consider all interests involved we must obviously first KNOW what they are specifically...otherwise we will just be wasting time without touching the really important points(your specific concerns among others...). Best regards, Roland

2 1

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

08 Feb '02

> I think that this message as well as many other bring up some > very good > points as to the needs of licensing within the wine project. > Many other > messages have been clearly in the realm of bsd-gpl feudalism. > I think that trying to find a license to fit the needs of the project > without first having a good understanding of the needs of the > project is a > serious error. Yes, that is what I have tried to say in my reply to Jeramy. We must define what we want to license to protect, but more importantly we must define what the we DON'T want the license to protect. Because "What doesn't the license protect?", more popularly known as "What can we get away with?" is the first question ALL new business models will ask. If the answer of that question is "Not Much" it might be very bad for most business module, but even worse if the answer to the question is "I don't know, it depends on your intent" or "I have no idea, the jury is still out" it will be very bad. >From my discussion with Alexandre last time he seems to believe that whether or it was allowed to implement a few function in some DLL in a LGPL Wine by linking to a proprietary library depended on my intent. I reject this absurd idea most violently. However consider for a moment: What if he is right? This means that with a LGPL:ed Wine: If somebody that had some proprietary library and thought hey with this library it should be quite easy to implement these functions in Wine that prevented these cool application to work. Some programming later... Great it works... Now I call Lindows, Red Hat, SuSE (whomever that distribute Wine) and tell them that I can license this library for $5 per end user to you. Some time later... Great at least some them accepted and the money keeps streaming in. Life is good. Questions: Is his intent bad? Would you sue him for violating the LGPL? If he publish his proprietary library function wrappers under the LGPL. If he didn't? What about the Linux distributor? Under what circumstances would you sue it? Another scenario: Joe Hacker has bought a proprietary library to use with his non Wine related hobby. One day he realizes that the one of his hobby related also proprietary Windows application he dual boots to since it never worked under Wine could be made to work by implementing the missing Wine functions with that library. He does so, it takes a weekend. It works. He puts out the patch to Wine under LGPL on a hobby related website for other that also owns the application and the library. He is happy since dual booting is but a memory. Life is good. Questions: Is his intent bad? Will you sue him? If some months or so later the maker of the protrietary library finds the patch and contacts the Linux distribution like in the case above. Will you sue the him, the proprietary library company or the Linux distribution? All this begs the questions: 1. Isn't it so, that as I claimed that the LGPL really doesn't protected this. 2. Or alternatively, if it really does make what some of the people above do illegal, do we REALLY want to use it? > It's pretty obvious that neither the a gpl > license nor a bsd > license are optimal. It only take the observation of the lack > on consensus > to see it. Quite. > All that I can really offer is this suggestion: end feuding > and start a > process to > 1. Gather the requirements to the licensing of the wine project > 2. Determine if any combination of existing licenses can meet the > requirements > 3. If no combination of existing licenses will suffice, write > a license > that does. Fully agree. > Additionally, I advise that everyone abandon there preconceptions of > licensing. There is no mandate that I know of to license the > whole project > under the same license, only use one license for any part of > the project, > only use existing licenses, license any part of the project > to different > groups under the same license. Quite true. However, take care with viral licenses, they might spill over to the other parts all the same.

1 0

Licensing
by Joe Tennies 08 Feb '02

08 Feb '02

I have personally always been a huge fan of the BSD license. It has always seemed to me to be more about standards. I know you guys are angered about TransGaming making their WineX version, but get over it. TransGaming is more than willing to place code back into the community. They are just making sure they can cover their own asses too. With the current state of open-sourced companies and internet companies in general, I think they have a decent plan. Also, switching to the LGPL will not make it impossible for TransGaming to make WineX. This has been discussed on the SDL list lately. All you need to do to make a closed source version of a LGPL library is have the LGPL library make calls into a closed source library. The theory behind the LGPL is fairly simple. Make sure that the LGPLed library can be recompiled if one of its dependancies either stops being made or changes dramatically. Basically, it's there to make sure things link 5 years from now. This will probably be my last message to this list as I am dropping it and going to the Mono project. Have fun!

1 0

Re: Wine license change
by g.russell＠ieee.org 08 Feb '02

08 Feb '02

I think that this message as well as many other bring up some very good points as to the needs of licensing within the wine project. Many other messages have been clearly in the realm of bsd-gpl feudalism. I think that trying to find a license to fit the needs of the project without first having a good understanding of the needs of the project is a serious error. It's pretty obvious that neither the a gpl license nor a bsd license are optimal. It only take the observation of the lack on consensus to see it. All that I can really offer is this suggestion: end feuding and start a process to 1. Gather the requirements to the licensing of the wine project 2. Determine if any combination of existing licenses can meet the requirements 3. If no combination of existing licenses will suffice, write a license that does. Additionally, I advise that everyone abandon there preconceptions of licensing. There is no mandate that I know of to license the whole project under the same license, only use one license for any part of the project, only use existing licenses, license any part of the project to different groups under the same license. Thanks for you ear - Gabriel Russell g.russell(a)ieee.org >Look at the copy protection stuff that transgaming have added to their >tree: they licensed it and thus quite likely can't publish the source >for this - but I still want to see this in the binary only releases >they make :-) Other scenarios I can imagine: drivers for hardware - >think of a company that wants to port their software to Linux via wine >but continue using a dongle or something like that: the dongle code >is quite likely to go into the kernel itself (and may need some support >for that by the wineserver). > Ciao > Jörg

2 1

Undocumented functions: a digest
by Jeremy White 08 Feb '02

08 Feb '02

Thanks to everyone who sent me examples of undocumented information; I have passed that along; I think it will be very helpful. I was hoping to edit it, and make it a bit more definitive, but I seem to have run out of time. So, I thought I'd just post the raw replies here so it didn't vanish into the bit bucket. Cheers, Jeremy

1 0

RE: Dr. Seuss, licensing, and WINE
by Medland, Bill 08 Feb '02

08 Feb '02

> -----Original Message----- > From: Dimitrie O. Paun [mailto:dimi@cs.toronto.edu] > Sent: Friday, February 08, 2002 6:35 AM > To: Brett Glass > Cc: wine-devel(a)winehq.com > Subject: Re: Dr. Seuss, licensing, and WINE > > > On Thu, 7 Feb 2002, Brett Glass wrote: > > > --Brett Glass (Who hasn't happened to contribute to WINE > yet, but may do so if > > it remains open source) > > Could you have finished wiht a more dumb line? LGPL _is_ open > source my > friend, go read about it first. > > I don't know about other people, but I'm so tired of these > arguments where > LGPL is 'fascist', 'proprietary', 'not open source', etc. > Once again, we > don't discuss what is important, but we keep arguing about mostly > irrelevant things, just like last time... :( Especially as the OP seems to be in favour of contributing to an "open source" set of code that is used for the basis of a "commercial closed source" product. Bill

1 0

License change: patenting for one year?
by Roland 08 Feb '02

08 Feb '02

Hello, someone here already had the idea of making a patenting scheme. Maybe this would be a good idea. A company can take the code, improve it and doesn't have to give modifications back until one year has passed. That would give them a competitive edge. Users would pay that company to be able to use always the newest versions. After one year, the code has to be contributed and is placed under the xGPL. The disadvantage of this would be that it would slow down the WINE progress or lead to code duplication. Free developers who don't want to wait a year would start duplicating the code that the company already has but doesn't want to give back yet... Maybe it would really be a good idea to open a web-site with a forum for this discussion, or how about another mailing list? I think the problem with this discussion is that we seem to have at least 2 distinctive groups: 1. People who want to make money selling WINE or derivatives == Anti xGPL 2. People who have no financial interest(individual developers) or companies who have another business model than the above == Pro xGPL Of course there are also people from group 2 that are against the xGPL for one reason or another. Ok, how do we solve this conflict? Maybe there is no solution other than splitting up WINE? That means we would have two code bases corresponding to the two conflicting interest groups. I think that the xGPL group will win on the long run because group one would consist of many people who have only a limited interest in sharing back! That means that the codebase wouldn't evolve much over the long run, and we would have more companies like Lindows who simply build their own version of WINE and improve it, without giving back. Of course there probably will be a group of people involved like on FreeBSD but I wonder if the xGPL group wouldn't have more members.... The problem with the actual license is that it has created exactly this kind of situation: Companies don't share back at all or only if certain requirements(incoming profit) have been fulfilled. This effectively created a situation that is similar to the proposed patenting scheme. So basically I see two options A. We make that patenting scheme official, which basically would correspond to the way things are NOW. B. We split WINE in two projects. B is my current prediction of what will happen. In fact CodeWeavers has already announced that this will happen(they will base their code on xGPL no matter what), so it is very obvious. The only alternative is if someone finds an ingenious solution but I doubt it is possible since the involved interests are so antagonistic. We simply cannot sit in the same boat if one group wants to go north, the other south. Roland

2 1

Re: Wine license change
by Roger Fujii 08 Feb '02

08 Feb '02

Marcus Meissner <marcus(a)jet.franken.de> wrote: > Hi, hello.... > On Thu, Feb 07, 2002 at 05:45:36PM -0500, Roger Fujii wrote: > > If you are using marketing speak for "contribute". GPL requires 1) > > for you to show your work 2) You effectively license your software to > > the FSF. It doesn't say it has to be in any useful form to be worked > > back into the originating project (if any). > License is not equal Copyright. > You don't automatically sign away your Copyright when switching to the GPL. ??? but I didn't mention copyright. I used the word "license" for this very reason. The copyright holder can later change the licensing policies (though the FSF says this is "ethically tainted"). But there still can be a *GPLed copy after the change.... > > Freedom means allowing people to do things, even things that you don't > > agree with. BSD = Free. GPL is not. Call a spade a spade.... > > Quoting: > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do ^^^^^^^^^^^^^^^^^^^^^^^^ > these things. I didn't mention cost for the same reason. It seems like a trivial academic exercise to show that something that has LESS restrictions is more "free" than something with more. Hence it is riduculous to say GPL is more "free" than X11/BSD (which is why I wrote that to begin with). Just because something claims it's 'free' doesn't mean it is, just as the "Democractic People's Republic or Korea" isn't democratic by most people's definition of democracy. GPLed programs are certainly infinitely more "free" than propriatary ones, but then, propriatory programs don't try to claim that they're "free" either. > The problem is not other people doing things with my stuff, the problem > is restricting ME as a developer. but that is PRECISELY the issue here, unless you consider someone not contributing is a restriction on a developer. The *GPL clearly restricts how something can be distributed: "rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program" The topic was opened again because there are concerns about how other people are using the source code. Yes, this is a problem, but the tendency is for *GPL advocates to claim that there will be no negative impact which is not the case. -r

2 1

more on wineconf 2002
by Michael Robertson 08 Feb '02

08 Feb '02

I've fielded a few questions from people who are interested in wineconf 2002. http://net2.com/lindows/hotels.htm For a list of hotels. The best on the cheap/close scale would probably probably be Homestead which are really nice suites (have a little kitchen I believe). Sorry about the short notice (by Feb 14th). That's of course not the cutoff to attend, but just the cutoff for those of you to attend that want Lindows.com to pick up the airfare. We don't intend on advertising it to the general public so we keep a high caliber of attendee. The only place the notification has gone is wine-devel list. We currently have about 15 people signed up. Alexandre told me to tell you he's coming if that will help get more people here. Please continue to send in your ideas about topics and speakers. This will help make the conference as informative and rewarding as possible. We'll also have a fun event planned for one of the evenings on Lindows.com so we'll try to make it a good social event as well as technical. -- MR Lindows.com michael(a)lindows.com 858-410-5941 Bring choice to computers: Become a Lindows.com Insider http://www.lindows.com/signup

4 3

Re: Wine license change
by Roger Fujii 08 Feb '02

08 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > Under the LGPL, everyone /will/ contribute back, because that's what the > LGPL requires. If you are using marketing speak for "contribute". GPL requires 1) for you to show your work 2) You effectively license your software to the FSF. It doesn't say it has to be in any useful form to be worked back into the originating project (if any). > Under the LGPL, it's not for them (or for you) to decide > whether they have anything to contribute back; if they make modifications, > they must be shared openly. And you're right that some people don't want > to contribute back. That's precisely WHY we would consider relicensing > under the LGPL. If everyone shared of their own free will, why would we > need a license that said they had to share? The question at hand is > whether or not we want to allow others to benefit from Wine without > sharing their changes. Here we go again.... If this is *all* it did, LGPL is far less objectionable. The problem with *GPL is that it also regulates the UNMODIFIED use of the software. > I make no bones about the fact that I'm a staunch believer in copyleft. > If Free Software has value, then there's also value in keeping it Free. Freedom means allowing people to do things, even things that you don't agree with. BSD = Free. GPL is not. Call a spade a spade.... > > As for commercial interest, I see that Apache+modssl has done quite well > > against any closed-source versions. > I would argue that this is a different ballgame. In the web serving > field, There's More Than One Way To Do It, there shouldn't be... http and ssl are 'well' defined protocols. > and trying to avoid forks leads to infrastructure issues as you need more > and more management to make decisions and guide the project. this is a project SIZE issue and has very little to do with the license. > In Wine, most of the decisions have already been made by Microsoft for us, > it's simply a question of implementation; and most of that implementation > is parallelizable to a high degree. and what gives you this impression about wine? Seems that many of the subsystems are interconnected (look at the recent thread on dll mapping). Can't imagine that DX support wouldn't impact anything else. > Having a license that allows commercial offshoots of a > webserver lets companies come up with innovative new designs that > wouldn't have been incorporated into the main tree. Having a license that > allows commercial offshoots of Wine potentially leads to a bunch of > different Windows emulators, each of which is 98% complete and none of > which works with half the software people want it to. If it works 100% with the 1-3 pieces of software a user needs it for, the user certainly wouldn't care. The question is whether the alternative would be better or not..... > I'm sure that under a BSD-style license, Wine could continue to outcompete > any commercial offshoots. The question is, which license model gives us > the best chance of competing with *Microsoft*, who already has the lead? If this is the goal (it certainly is mine), then *GPL is not a good choice, because it would interfere with deployment (*GPL wouldn't allow being bundled with the playstation2 or other HW platforms as an example). If acceptance is the goal and you care about wine in a non-linux context, stay with BSD/X11. If you don't care about expanding the pie, go *GPL.... -r

4 3

Re: wine license change - look at how ghostscript is licensed
by dschwarz＠bellatlantic.net 08 Feb '02

08 Feb '02

As a non-coder but longtime interested observer of the WINE project, here are my ideas: Consider doing what ghostscript does (http://www.ghostscript.com/). New versions are released under the AFPL license (more restrictive than GPL). Old versions are re-released under GPL when they are about 1 year out of date. This may be applicable to Wine. Like Wine, ghostscript tracks an evolving API. Older versions are useful but may not have all the latest bells and whistles. Those that need to be on the cutting edge have to use the more restrictive license. How this could be applied to Wine: Going forward, all builds are released under LGPL. They are then re-released one year later under an X11 style license. Regards, Daniel Schwarz http://www.winecentric.com/ coming soon... the wine wiki! test it at http://www.winecentric.com/test

2 1

Re: Wine license change
by Andreas Mohr 08 Feb '02

08 Feb '02

Seems Slashdot is fast today ;-) They already have a thread about the proposed license change running. One guy made an interesting suggestion: a "dual license" scheme (like MySQL uses) where you switch to (L)GPL, but certain companies are allowed to take code without contributing everything and their arms and legs back... -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

10 14

Re: Wine license change: it's about time!
by Roger Fujii 08 Feb '02

08 Feb '02

Gavriel State <gav(a)transgaming.com> wrote: > Quite the opposite: It is not 'competitive advantage' that concerns us, > or others using our code without contributing their own code. It is > simply that we could not and cannot afford to do our development without > monetary compensation. If the OLE DLLs had been LGPLed, we could not > have been able to afford to do any DCOM work, since we would have had > no prospect of getting paid for it. > > Under the LGPL, the only possible business model is this: > a) Find someone who might need some piece of code > b) Sell them on: "We can do this for you, and release it under > the LGPL for $x dollars. We're really good at what we do, > honest" > c) Do the work, and hope to actually get paid. well, a)+b) is really the same, and you left out d) sell support on the changes, but yes, there are only 3 choices. I really think that *GPL will have problems in the long term because there is no real economic way to sustain it, but it's going to take VAlinux/SUSE/RedHat to finally go down in flames for people to take a long, hard look at the issue. Think the patent model (with a much shorter protection period) is a good place to start. > The LGPL simply slams the door shut on that whole model, saying in effect > "It's my way or the highway". It also slams the door shut to non-development areas too. -r

1 0

Re: wine-devel digest, Vol 1 #714 - 13 msgs
by Roger Fujii 08 Feb '02

08 Feb '02

dschwarz(a)bellatlantic.net wrote: > Consider doing what ghostscript does (http://www.ghostscript.com/). New > versions are released under the AFPL license (more restrictive than GPL). > Old versions are re-released under GPL when they are about 1 year out of > date. This is fine for the "owners" of the project. It gives them a grace period and makes sure that changes gets worked back in. However, if you are on the outside, it blows, since you must IMMEDIATELY make your changes available (because of the GPL). > How this could be applied to Wine: Going forward, all builds are released > under LGPL. They are then re-released one year later under an X11 style > license. This won't work very well since all that this is really requiring is that changes to the changes are LGPLed, but not changes to the base. What might work is this (though this won't be considered "open" by those self-professed 'champions' of open-source. BSD/X11 base with the following LGPLish addition: Modifications to 'derived work' must be made available within 12 (or some reasonable period) months of initial publishing under the same terms. This way, unmodified versions aren't virialized like the GPL, but you will (eventually) have access to any improvements. -r

1 0

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

07 Feb '02

> Patrik Stridvall wrote: > > > 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 any sort of proof. > > It seems like a reasonable analysis to me; contributing code > represents a bigger and bigger gift as Wine comes closer to > completion, > as your competitors will be able to produce useful products with > less and less work. The only likely head to head competitors that I can see are two companies that uses Wine to port their competing applications. As Wine nears completion, the competive advantage fixing Wine at all instead of working around the difference in their respective application becomes quite low so I don't think we will see that many patches from either. LGPL or no LGPL. > Under the LGPL, this is ok, because you'll have > access to the competitor's code as soon as he starts shipping ig. > Under the X license, you're in trouble, and have to hustle to > reproduce > the work the competitor did. In the longer perspective neither company will live or die because the better quality of the Wine port, but rather because of the better quality of their application. So even the company that is nice to Wine is not likely to suffer serious competive disadvantages anyway. In fact it might even make sense to them to make a deal that they should treat Wine as it was LGPL despite being competitors. But this is their choice and we shouldn't force it on them. > > 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. > > Really? Sun doesn't compete head to head with IBM? I some markets, yes. In the Wine market neither of then competes so your example is largerly irrelevant. Anyway, if both would enter the Wine market I would be very suprised if they really competed head to head. I would rather think they did it in some niche of their own. > > > 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. > > It captures the essense of how the two licenses set up incentives, > though. In a simplified enconomic theory: Perhaps. In the real world: Difficult to tell, but I believe not. > I think Patrik and I agree that it's important for the Wine license > to provide economic incentives for companies to contribute to the > Wine project. Yes. > His legal analysis of the LGPL differs so sharply > from mine (or that of most people), as far as I can tell, that > just about nobody agrees with his point of view on it. Perhaps it is because I'm bad on explaining what I mean. Anyway, I would rather be alone and right than not alone and wrong. :-)

1 0

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@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

RE: Wine compile on MSVC?
by Patrik Stridvall 07 Feb '02

07 Feb '02

> Is this correct that tests are made to compile Wine on MSVC? Only on a small scale, nothing really serious yet. > What good > is this for? I thought Wine should be an emulation of windows > code on a > Unix platform, what good is it to run Windows on Windows? > > Just being curious. :) Well. I qoute myself: "It would be quite nice to have all non core DLL compiling and working and with winetest ported. Then you could just run winetest through the debugger and be able to set breakpoint and step through the code in Visual Studio in order to get all to tests to run properly. :-)" Also note that this would make it possible to debug each dll in an enviroment where all other DLLs except the DLL tested were real Windows DLLs.

2 1

Wine compile on MSVC?
by Gerhard W. Gruber 07 Feb '02

07 Feb '02

Is this correct that tests are made to compile Wine on MSVC? What good is this for? I thought Wine should be an emulation of windows code on a Unix platform, what good is it to run Windows on Windows? Just being curious. :)

1 0

RE: Header files not present on Windows
by Patrik Stridvall 07 Feb '02

07 Feb '02

> >Eventually I guess that the non-core DLL:s never should call any > >non Windows functions at all and the core DLL:s are not really useful > >to compile and run under Windows anyway. > > Well I have only played with the shell32.dll and in any file > in there except > "shelllink.c" removing "unistd.h" entirely had no negative > effect whatsoever. > This means to me that it is not needed at all. The use of > fork(), execvp(), and > waitpid() in "shelllink.c" however seems to require the > "unistd.h" header. > > I'm not sure if shell32 should be considered a core DLL. It > seems to me > rather not. shell32 is not really a core DLL eventhough it is a borderline case since some functionallity might want to intergrate with the desktop. However, it definitly should compile under Windows at least with limited functionallity. > The desired operation could be possibly achieved > with the use > of Windows kernel functions as well. Possibly, but it looks a little Wine specific to me. I'm not 100% sure what the code does. Anyway, we could always choose to exclude that code on Windows. It would be useful to run test on the rest of the functionallity in any case.

1 0

(FWD) Announcing wineconf 2002
by Ove Kaaven 07 Feb '02

07 Feb '02

I received this today... it seems Lindows seem to want to host a Wine conference. I noticed that they misspelled Alexandre's name and email address, though they claim to work with him. Since this is supposed to be an open conference anyway, and it's not a secret (most of the mail is just a straight dump of the webpage they link to anyway), I decided to forward it to wine-devel (but without the HTML). ---------- Forwarded message ---------- Date: Tue, 5 Feb 2002 14:21:18 -0800 From: Cheryl Schwarzman <cheryl(a)lindows.com> To: uczekalla(a)codeweavers.com, andi(a)rhlx01.fht-esslingen.de, andrew(a)transgaming.com, aric(a)codeweavers.com, bon(a)elektron.ikp.physik.tu-darmstadt.de, brianv(a)ski-copper.com, dimi(a)cs.toronto.edu, dmitry(a)codeweavers.com, ekohl(a)codeweavers.com, eric.pouech(a)wanadoo.fr, fgouget(a)free.fr, franciosj(a)macadamian.com, galberte(a)neo.lrun.com, gav(a)transgaming.com, gerard.patel(a)asi.fr, hdavies(a)codeweavers.com, james(a)macadamian.com, jasonfilby(a)yahoo.com, jefft(a)xandros.com, juilliard(a)codeweavers.com, jwhite(a)codeweavers.com, lionel.ulmer(a)free.fr, marcus(a)jet.franken.de, mike_mccormack(a)start.com.au, ovek(a)transgaming.com, ps(a)leissner.se, ridgway(a)winehq.com, sanderv(a)xs4all.nl, tephane(a)macadamian.com Subject: Announcing wineconf 2002 Announcing wineconf 2002 We believe 2002 is the year WINE really breaks through to have a major impact on computing. Many of you have had the vision and dedication long before Lindows.com was around. And it's all of you who deserve the credit. As a small token of our gratitude, we want to do our best to host the first conference dedicated to WINE called wineconf. As the host, Lindows.com will pay the cost of putting on the conference including venue, food and other necessary arrangements. The agenda and speakers will be the members of the WINE community. It will be a two day event on Friday and Saturday where new ideas can be shared, new connections made, and you can hear from the best and brightest pushing the WINE initiative forward. We have dubbed the event wineconf and it will be open to all who wish to attend. We don't expect a large crowd given the highly technical focus. Working with lead WINE mind, Alexandre Juilliard, we have come up with a list of people whose historic contributions to WINE deserve extra recognition. To this group, we're making a special offer by picking up their airfare to and from San Diego for this event. This is Lindows.com way of thanking those who have made contributions in the past to get WINE to the level it is at. We will notify you personally, if you are in this list. If you are not on this list, you are still welcome to attend with no registration fee, but you will be responsible for your own transportation. Hotel costs will range from $75-125 per night. The agenda will be sent out several weeks before the conference outlining the topics and speakers. We will be working with attendees and speakers to ensure we touch all the areas of interest. wineconf will be held in San Diego, CA on March 15th-16th, 2002. We selected San Diego for two primary reasons. First, because it's our home town we can keep the costs down on the venue, transportation, computer facilities, etc. Like all startups (that weren't born in 1999!), we have a finite budget we're trying to stretch as far as possible. Secondly, since WINE is a worldwide effort there's no ideally centralized location, so we selected a place that should be nice and warm in March. (San Diego is 25 minutes south of LA by plane or 1.5 hours by car.) The specific agenda will be forthcoming as we work with WINE contributors to get their input and guidance. You can register online by going here: www.lindows.com/wineconf We hope you can make it! Registration Form: First Name: Last Name: Email: Company: Address: City: State: Zip: Country: Phone: Topics You Would Like To See Discussed: Speakers You Would Like To Hear From: ------------------------------------------------------------------------ Optional Part (for those we will be paying for air transportation) Because of your past contributions to WINE, Lindows.com is offering to arrange and pay for airfare from a nearby major metropolitan area to San Diego for you to attend wineconf 2002. This offer is non-transferable. Your flight would depart on Thursday, March 14th and return on Sunday, March 17th. To qualify, by February 13th, 2002, you must: 1. Register online at http://lindows.com/wineconf (enter your name for the "Invitation Code"). 2. Send an email to cheryl(a)lindows.com with the below cancellation payment information. You will need to agree that if you do not attend that you will pay for all costs incurred by Lindows.com related to airfare arrangements. Your credit card will ONLY be billed if you do not attend after saying that you will. Hope to see you in San Diego! ------------------------------------------------------------------------ NOTE: In addition to registering at http://lindows.com/wineconf, we must receive the below information no later than February 13th, 2002 (e-mail this to cheryl(a)lindows.com). After that date, this offer is no longer valid. I agree to attend wineconf 2002 March 14-15th in San Diego and understand that Lindows.com will be paying for my airfare. If I do not attend, I understand that I will have to pay for the costs incurred in the scheduling of this airfare. <"yes I agree." and your name here> Exact name on passport or ID: <put your name here> Nearest Major Airport: <put your city and country here> Credit Card Type: <card type> Credit Card Number: <card number> Credit Card Expiration Date: <exp date> Please remember to travel with picture ID, passport and VISA if required. Further information can be found here http://www.lindows.com/wineconf

7 7

RE: Header files not present on Windows
by Rolf Kalbermatter 07 Feb '02

07 Feb '02

Patrik Stridvall <ps(a)leissner.se> writes: >> Patrik Stridvall <ps(a)leissner.se> writes: >> >> > Hmm. I'm note sure I like making unistd.h >> > an optional header but then few part of >> > Wine should include it anyway so perhaps >> > it doesn't matter. >> >> The question is whether you can build without it. If the needed >> definitions are provided by other includes then it's fine to make it >> optional; but if the code doesn't compile without it then there's no >> point in having a check. > >Yes and in many cases it did work without unistd.h, but maybe that >is because it really wasn't needed at all. > >In some case it might have worked because some of the functions in >unistd.h is defined else where in Windows and in some case we might >get it to work by including needed files. > >Of course in such cases we probably should fix Wine and >include that other header exclusively instead of unistd.h. > >Anyway, I just experimented a little trying to get Wine to compile >under Windows. I'm not really sure exacly what to do. > >Eventually I guess that the non-core DLL:s never should call any >non Windows functions at all and the core DLL:s are not really useful >to compile and run under Windows anyway. Well I have only played with the shell32.dll and in any file in there except "shelllink.c" removing "unistd.h" entirely had no negative effect whatsoever. This means to me that it is not needed at all. The use of fork(), execvp(), and waitpid() in "shelllink.c" however seems to require the "unistd.h" header. I'm not sure if shell32 should be considered a core DLL. It seems to me rather not. The desired operation could be possibly achieved with the use of Windows kernel functions as well. Rolf Kalbermatter CIT Engineering Nederland BV tel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijk http://www.citeng.com Netherlands mailto:rolf.kalbermatter@citeng.com

1 0

Date format
by info2000＠telecable.es 07 Feb '02

07 Feb '02

Hello, IŽm running a windows aplication made on Builder C, and when I execute de program with Wine, I receive an error message, reference to the date format, I get the year correctly, but the rest of date content is ="0", for example 01 January 2002 at 13:20:15 is= 17/20/02 00:00:00 can you help me to fixing this problem? thanks from spain. Jose. --------------------------------------------- Este mensaje fue enviado utilizando el servicio de correo-web de: http://www.telecable.es

2 1

RE: Some more MSVC fixes
by Roger Fujii 07 Feb '02

07 Feb '02

From: Patrik Stridvall <ps(a)leissner.se> wrote: > > Dimitrie O. Paun wrote: > > > On Wed, 6 Feb 2002, Steven Edwards wrote: > > > > > > Any other interesting compilers? Maybe the Solaris one? What about > > > headers? We already have 4 * 4 * 3 = 48 combinations. > > I tried briefly with the Solaris compiler, but there seemed > > to be enough problems that I gave up. I really don't remember what they > > were. > Well, the older versions for one doesn't support __stdcall. > I'm don't know about the newer. well, the current version doesn't seem to run under solx86 even with the gcc. Not certain what changed. Trying to figure it out right now (if only cvs.winehq.org would let me in...) > > It is probably a moot point now, since Sun has announced that there > > will be no Solaris 9 X86. > AFAIK they have only said that Solaris 9 SPARC will be released > before Solaris 9 X86. Of course it is not a good sign if you > read between the lines but still. well, technically, they said that x86 development work has stopped, but they can change their minds. Effectively, they "laid off" solx86, but added "we may ask you back..." Not promising at all.... -r

1 0

RE: Some more MSVC fixes
by Patrik Stridvall 07 Feb '02

07 Feb '02

> Dimitrie O. Paun wrote: > > On Wed, 6 Feb 2002, Steven Edwards wrote: > > > > Any other interesting compilers? Maybe the Solaris one? What about > > headers? We already have 4 * 4 * 3 = 48 combinations. > > I tried briefly with the Solaris compiler, but there seemed > to be enough > problems that I gave up. I really don't remember what they > were. Well, the older versions for one doesn't support __stdcall. I'm don't know about the newer. > It is > probably a moot point now, since Sun has announced that there > will be no > Solaris 9 X86. AFAIK they have only said that Solaris 9 SPARC will be released before Solaris 9 X86. Of course it is not a good sign if you read between the lines but still.

1 0

Re: X connection to :0.0 broken (explicit kill or server shutdown).
by Sylvain Petreolle 07 Feb '02

07 Feb '02

Bonjour, Je rencontre un problème persistant avec wineconsole. Dès qu'il est chargé le système ralentit et wine grandit en mémoire jusqu'à saturation de la mémoire swap.(256M ram physique + 208M swap) Le message "fixme:bitmap:CreateCompatibleBitmap got bad width 1939840 or height 2457900" me fait penser que wineconsole se configure mal. Y a t il un moyen de spécifier une taille de fenêtre ? En regardant le code source (registry.c) jai essayé de mettre la proprété WindowSize à une valeur très petite, mais le lancement en mode debugmsg +reg montre que les valeurs sont ignorées par le programme. Comme vous etes en partie l'auteur de ce programme, je pense trouver un peu de répondant... --- Sylvain Petreolle <spetreolle(a)yahoo.fr> a écrit : > Hi, > > Using wineconsole to try a command line program > like ftp.exe (runs fine whithout wineconsole), > it appears that wineconsole slowdowns the system > and use incredible amounts of memory. > > These are the messages that appear on the wine > command > line : > > fixme:bitmap:CreateCompatibleBitmap got bad width > 1939840 or height 2457900, please look for reason > fixme:console:SetConsoleCtrlHandler (0x1001dc5,1) - > no > error checking or testing yet > fixme:bitmap:CreateCompatibleBitmap got bad width > 1939840 or height 2457900, please look for reason > > then i got the shell prompt, look like the process > had > end up. > (the processes didn't end up of course). > i must kill the processes (the 2 windows desktops > displayed are complete empty and > do not close when asked to close) > > Running it with --debugmsg +relay, I saw that wine > took a long time when running x11drv.SelectObject. > and the last line in the debug text is > X connection to :0.0 broken (explicit kill or server > shutdown). > (this is before I do killall wineconsole wine). > > > > ___________________________________________________________ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et > en français ! > Yahoo! Mail : http://fr.mail.yahoo.fr > ATTACHMENT part 2 application/x-bzip2 name=wineconsole_debug.log.bz2 ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.fr

1 0

Re: Some more MSVC fixes
by Dimitrie O. Paun 07 Feb '02

07 Feb '02

On Tue, 5 Feb 2002, Patrik Stridvall wrote: > I have finally tried to compile Wine with MSVC. > Eventhough I had to do some hack on the whole > it compiled quite well. Great. On a slightly related note, is it possible that we compile Wine with the MS headers? What would it take to do that? If we could, we would have one more degree of freedom: Platform Compilers BinFmt Headers -------- --------- ------ ------- Linux gcc ELF Wine *BSD MSVC PE MS Solaris Borland ReactOS(?) Cygwin Esentially, most of the above possible cobinations should work (except, of course Windows-base compilers and ELF). If we get this level of portability, would be nice to set an automatic compile farm which tries all the possible combinations, and reports problems early, so they get fixed. -- Dimi.

3 3

Favor: I need examples of un or poorly documented APIs
by Jeremy White 06 Feb '02

06 Feb '02

I'm working with someone involved in the Microsoft trial, and they are looking for some information from the Wine team. Specifically, they need clear examples of Windows APIs that are not documented, or cases where the actual working of an API is substantially different from the documented behavior. I've asked around CodeWeavers, and we had a few examples, but we're in a bit of a time crunch (48 hours), and I was hoping to ask a broader audience to pitch in. In an effort to keep this off topic traffic down, please reply just to me; if you like, I can post a summary of the results. Thanks, Jeremy

2 1

flaky regression(?) - patch.py?id=1012510895681951425038278
by lawson_whitney＠juno.com 06 Feb '02

06 Feb '02

Good day! Something in this patch makes my app set This->bigBlockSize of its inbox to zero when it gets a big batch of mail. Of course, the app (and my laola-based mailbox reader) is then unable to read the file. AFAICT, that is the only byte that is damaged, and it can be fixed after, but it is annoying. The app never did this before the patch, and hasn't since I reverted it yesterday. I will work on refining my observations, and I expect I will find and fix the error eventually. I'm just writing this in case it may be some help to anyone. Lawson

3 9

RE: (FWD) Announcing wineconf 2002
by Patrik Stridvall 06 Feb '02

06 Feb '02

> I received this today... it seems Lindows seem to want to host a Wine > conference. I noticed that they misspelled Alexandre's name and email > address, though they claim to work with him. Well, I'm not suprised. I'm not 100% sure how his last name is spelled. I usually cut and paste or more often, only use his first name. :-) > Since this is > supposed to be > an open conference anyway, and it's not a secret (most of the > mail is just > a straight dump of the webpage they link to anyway), I > decided to forward > it to wine-devel (but without the HTML). Hmm. I noticed people on the special invitition list (that get air transportion payed) must register by 13th February, 2002. It is only a week until then, they could have given us some more time to consider it, I think. Anyway, I'm slightly intrested in coming. Providing of course that at least a few of the Wine people will come. I'm not particularly intrested in travelling at least 12 hours by air to only talk to the Lindows.com people. Anybody else interested? PS. Does anybody know if a VISA to the US is required for citizens of the European Union countries (like Sweden)?

6 6

Re: Some more MSVC fixes
by David Laight 06 Feb '02

06 Feb '02

Alexandre Julliard wrote: > > David Laight <david(a)l8s.co.uk> writes: > > > This is the standard behaviour for C includes. It is actually usually > > best to use <> not "" for all header files - unless you explicitely want > > the file included from the current directory. > > The problem is our makedep uses the "" to determine which headers to > include in the dependency list, so this would have to be changed. Sounds like your makedep is broken! It needs to recognise <> and "" and treat them differently! David

1 0

RE: Some more MSVC fixes
by Patrik Stridvall 06 Feb '02

06 Feb '02

> On Wed, 6 Feb 2002, Patrik Stridvall wrote: > > > Well. If you do as I did and just add just create > > a Visual Studio Project (.dsp) for each DLL using the > > MS headers is the default. I had to add "..\..\include" > > to the include path to get it to use the Wine header. > > Sorry Patrik if my questions are sometimes naive, but I don't have a > Windows partition, let alone MSVC. So, here goes the question: > > MSVC must have a command line version of the compiler. Yes, MS Visual Studio always calls the command line version to compile. It is called "cl.exe". > Wouldn't it be > easier to use our Makefile system under cygwin to compile > Wine with MSVC? Possible. However I don't know exactly cygwin works. I try to avoid Windows as much as possible. I know how MSVS project files work though so I tryed with them first. Personally I think that the ultimate solution would be to automatically generate the .dsp files from Makefile.in or otherwise. There is a huge advantage of using the Microsoft format since Visual Studio can read them and you can for example just point and click on the files of each DLL to open them inside Visual Studio. The .dsp format is not very difficult to generate. It is just some sort of glorified Makefile. > > As to how good it works with MS header: > > Well, the problem is that if you don't add the path the > > Wine header files like debugtools.h doesn't > > exists so it doesn't compile very well and if > > you do the Wine headers take priority. > > That's why all our private headers must reside in > include/wine. That needs > to be fixed, eventually. Hmm. Well, I gave the MS headers one more try and discovered a few not so nice things. If you have a Wine specific include like below in a file: #include "heap.h" and this file heap.h in turn has a #include "winbase.h" it will include the Wine version of the file instead of the MS version. This is probably because with "" files in the same directory has priority IIRC. This is solvable by doing #include <winbase.h> but this requires changes in almost all .h files but it is just a simple search and replace. Hmm. I wonder if doing this will cause any bad effect with GNU C or other compilers? > > Of course you could add the MS header for inclusion one > > more time after the Wine headers, but where they > > are under Windows are installation dependent and not > > very portable. :-( > > Yeah, but that could be determined by configure. True. > > Additionally windef.h must be included first. > > > > #include "winbase.h" > > #include "windef.h" > > > > doesn't work. You have to do > > Of course. I was thinking would be nice to have a > > #include "wine/prologue.h" > <whatever includes you have> > #include "wine/epilogue.h" > > > #include "windef.h" > > #include "winbase.h" > > > > This is a minor issue though. > > Which should be fixed, I think. Yes. It will investigate some more. > > I also so got some other strange error with PCONTEXT > > in winnt.h which in didn't understand. > > > > In short it was a terrible mess so I primarily tested > > it with the Wine headers. > > It would be sooo nice if we could compile with other headers > as well. Just > compiling would be great, running the resulting executable would be > fantastic! Yes. :-)

4 3

RE: Some more MSVC fixes
by Patrik Stridvall 06 Feb '02

06 Feb '02

> > Personally I think that the ultimate solution would be to > > automatically generate the .dsp files from Makefile.in or otherwise. > > May not be easy but you are pretty good with perl so if anyone can > pull it off it's you :-) I don't think it is that difficult even for somebody less comfortable with Perl. The problem is getting all the details right and that will take some time, but allmost all details are quite easy, I think. > Once you have all the .dsp files, make a big .dsw file in the > top-level directory that references all the other .dsp files. That way > you can double-click on the .dsw, and then pick which dll you want to > build, build them all at once, etc. I guess you already know > about them > (and they are really simple to generate). Yes, I have it that way right now. But I only have a .dsp for a of few DLLs since doing it manually is quite boring. It would be quite nice to have all non core DLL compiling and working and with winetest ported. Then you could just run winetest through the debugger and be able to set breakpoint and step through the code in Visual Studio in order to get all to tests to run properly. :-) > > Hmm. Well, I gave the MS headers one more try and discovered > > a few not so nice things. > > > > If you have a Wine specific include like below in a file: > > #include "heap.h" > > and this file heap.h in turn has a > > #include "winbase.h" > > it will include the Wine version of the file instead of the > > MS version. This is probably because with "" files in the > > same directory has priority IIRC. > > No, that's because we use '-I .', which is a questionable practice. > Unfortunately I believe there is something that makes it hard to avoid > in Wine's case. I cannot remember what though. No, I don't think so. First of all -I. means current directory that is the directory of the current .c file. I was refering to that the #include "winbase.h" in file heap.h in wine/include perfered the winbase.h in wine/include rather than the MS variant. This is propably because #include "" with MSC always chooses the include from the same dir first rather the Microsoft dir that was EARLIER in the -I path (or rather the MSC equivalent). In the .c file #include "winbase.h" correctly included the MS variant. I haven't tested if GNU C have the same behavior but it might. > > > > Of course you could add the MS header for inclusion one > > > > more time after the Wine headers, but where they > > > > are under Windows are installation dependent and not > > > > very portable. :-( > > > > > > Yeah, but that could be determined by configure. > > > > True. > > But you would have to run configure on Windows, no? Since configure > is a shell script this means you need something like cygwin to compile > the source :-/ Or did you mean to run configure on Unix to > generate just > the right Makefiles for use on Windows? I didn't nessisarily mean configure but rather a Perl script that generates the .dsp files. Just install Perl and double click on configure.pl and all the .dsp was generated. Then double click on wine.dsw and you are ready to go.

1 0

compiling .obj with wine
by Ricardo 06 Feb '02

06 Feb '02

hi, Is it possible to compile/linkedit .obj, not the source, with wine libs? thanks Ricardo.

2 1

RE: Some more MSVC fixes
by Patrik Stridvall 06 Feb '02

06 Feb '02

> On Wed, 6 Feb 2002, Patrik Stridvall wrote: > [...] > > I also so got some other strange error with PCONTEXT > > in winnt.h which in didn't understand. > > You must define _X86_ before including 'winnt.h'. > Otherwise it won't > known on which architecture it's being compile and it won't define > CONTEXT. Yes, I realized that slighty after sending the mail. _M_IX86 is defined by the complier but _X86_ is defined by windows.h iif _M_IX86 is defined. > And you must also include 'windef.h'. Otherwise CONST is > not getting > defined and again, errors ensue. > > #define _X86_ > #include <windef.h> > #include <winnt.h> > > > Defining _X86_ is done in 'windows.h' which means that it is > virtually impossible to use these headers without including the big > beast itself. Yes. I have noticed that. However it is not that bad. #include "windef.h" #include "winnt.h" #include "stdarg.h" #include "winbase.h" Seems to do the trick. Another thing. It seems that all files will need to include "config.h" anyway because of issues like MSC doesn't support inline only __inline so a #define inline __inline is needed for anything reasonable to work anyway. Adding #include "config.h" at the top of each .c files is not that bad and things like #define _X86_ from windows.h could be there as well.

1 0

RE: Some more MSVC fixes
by Patrik Stridvall 06 Feb '02

06 Feb '02

> On Tue, 5 Feb 2002, Patrik Stridvall wrote: > > > I have finally tried to compile Wine with MSVC. > > Eventhough I had to do some hack on the whole > > it compiled quite well. > > Great. On a slightly related note, is it possible that we compile Wine > with the MS headers? What would it take to do that? Well. If you do as I did and just add just create a Visual Studio Project (.dsp) for each DLL using the MS headers is the default. I had to add "..\..\include" to the include path to get it to use the Wine header. As to how good it works with MS header: Well, the problem is that if you don't add the path the Wine header files like debugtools.h doesn't exists so it doesn't compile very well and if you do the Wine headers take priority. Of course you could add the MS header for inclusion one more time after the Wine headers, but where they are under Windows are installation dependent and not very portable. :-( Additionally windef.h must be included first. #include "winbase.h" #include "windef.h" doesn't work. You have to do #include "windef.h" #include "winbase.h" This is a minor issue though. I also so got some other strange error with PCONTEXT in winnt.h which in didn't understand. In short it was a terrible mess so I primarily tested it with the Wine headers. I have only tested a few DLL since doing .dsp files for each them was some work. I might do a script to automatically generate .dsp files for MSVC some day. > If we > could, we would > have one more degree of freedom: > > Platform Compilers BinFmt Headers > -------- --------- ------ ------- > Linux gcc ELF Wine > *BSD MSVC PE MS > Solaris Borland ReactOS(?) > Cygwin > > Esentially, most of the above possible cobinations should > work (except, of > course Windows-base compilers and ELF). Well. I think GNU C chokes on the MS headers so that won't work either. > If we get this level of portability, would be nice to set an automatic > compile farm which tries all the possible combinations, and reports > problems early, so they get fixed. Yes, that would probably be a good idea.

3 2

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