Just to set the record straight.

Lindows.com has had a partner company producing the majority of our WINE code. The vast majority of the code that came from that partnership is in the public tree already.

Lindows.com has contributed code to open source projects. We have hired open source companies (spending over 500K) to help us reach our goals with the majority of the code going back to open source. Lindows.com has given financial support to several open source initiatives (such as KDE). Lindows.com has made significant investments in linux companies. All told, we've spent about 2 million in the 5 months that we've been a company.

Linux (and all the other pieces) does 95% of what people want to do today, but only has 1% market share. Our belief is that the code is largely not the limiting factor for adoption now. It's all the pieces that go around the code. It's education, it's marketing, it's lobbying, it's business development, etc. These are big tasks which are critical to success, even more so than the code itself (think AOL). I know this won't be a popular thing to stay on a mailing list with "devel" in the title, but it's where we believe linux is and what we believe needs to happen to get to the next level. This doesn't mean the code isn't important, it is but there are other critical elements.

We need Lindows.com and 10 more thriving companies to help with the expense of educating, lobbying, marketing, etc. desktop solutions. It's expensive to do those things and a burden that needs to be shared by several companies because the job is so enormous and the competitor so strong. The Linux community, especially the desktop community needs healthy ongoing companies to put in capital, organization, and other support. If we can put a few million more people running Linux on the desktop, then magical things will happen. Drivers for linux will be available, higher quality linux software will emerge, more OEMs will offer linux as an option, devices will have linux interfaces, governments will view linux differently, etc.

There are some small, but meaningful for-profit companies out there today in linux (such as codeweavers and transgaming). The more companies in the linux desktop space there are, the more companies that will be able to pay their rates on an ongoing basis and hire them to code great products. There's tremendous opportunity and the more companies out there the better.

As for our marketing message, it's designed for my Grandma. Anytime there's a word on the website she doesn't understand she calls me up. Try explaining a recursive acronym to your Grandma. Yikes. Our goal with Lindows.com is to bring Linux to the segment of the world who thinks linux is spelled with a 'y' and is a small bobcat.

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?

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.

OK, when the last discussion was going on, I started out with the opinion that the change would be good and changed it to not so good, because if proprietary stuff that *is* part of the windows kernel (or drivers) needs to be implemented, this can't be done with an LGPLed wine. My final idea (which I never mailed) was, that maybe a X11-licensed kernel (including wineserver and driver emulation) and LGPLed dlls for the rest would be the best solution.

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.

One important argument was that building a thriving economic environment around Wine is essential for its success.

Everybody agreed on this premise, IIRC.

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.

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.

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).

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

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.

While I do want to contribute further to this debate, I need some time to gather my thoughts. In the meantime though, I want to address Dimitrie's quote - and fundamental misunderstanding - of me below.

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:

1. Find someone who might need some piece of code
2. 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"
3. Do the work, and hope to actually get paid.

The current license, by contrast, allows many other alternate models that are worth trying. In the case of the DCOM code, there was something that we had a need for with our current subscriber base, but we could not afford to do the work just for that base, since it is not yet large enough. Instead, we have this business model:

1. Do the work up front, proving that it works, covering a small portion of the cost from our current subscribers.
2. Talk to potential sponsors who need the work
3. If they agree on a price, release the code under the Wine license.

The TransGaming subscription model is simply this writ large, trying to get the individual users to act collectively as sponsors of the work.

The LGPL simply slams the door shut on that whole model, saying in effect "It's my way or the highway".

At the same time, I believe that I understand the main concern of the LGPL proponents: the current license allows the possibility of benefiting from the project without any contribution. Where I differ from them is that someone else's code is not enough to keep my employees eating. What I need as a contribution is not code, but cash.

Anyhow, I'm going to go and put my thinking cap on, and try to see if I can think of some arrangement that might work better for everyone.

As I mentioned, I have been considering the license issue for the last several days. It is a matter very near to my heart, as I believe that it affects not only TransGaming, but really the entire software industry. This posting is somewhat lengthy, but please bear with me.

Open Source software has made enormous strides in the last several years, and incredible amounts of great code have been produced. At the same time, it has been unable to compete effectively with proprietary software vendors like Microsoft, except in those areas where sufficient well financed companies have been able to direct full-time developer resources to the problem.

With the wellspring of dot com VC funding going dry, the question arises: where will the money come from to pay full-time Open Source developers? Just imagine where Wine would be without the code contributed by the half-dozen or so companies that have been involved. Imagine where Linux would be without the efforts of the companies paying for dozens of full-time Kernel hackers.

And imagine where we could be if just one or two percent of Microsoft's annual $25 Billion in revenue were being directed at Open Source projects.

The business models capable of supporting traditional Open Source projects are really rather limited: consulting services, technical support, and selling ancilary products with the software. None of these come close to delivering the levels of revenue that traditional mass-market shrinkwrap software can. So far, it is unclear whether they can support much profit at all for their proponents: RedHat, VA, and others bear witness to that.

TransGaming, for one, is working with some new ideas on how to do things differently, and profitably. There are a number of interesting possible approaches out there, and it is important to the entire world that we find models that work. Otherwise we are going to be stuck with the kind of information police states envisioned by the RIAAs, MPAAs, and Microsoft's of this world.

Now we are all here because we think that there are better ways to do software than the wholly proprietary approach. We want to be able to look at the code, tear it apart, fix the bugs, and make it cooler. And we want others to have the freedom to do the same.

Ultimately, the questions that need answering are these:

• What freedoms are important to the community?
• Can those freedoms be achieved without sacrificing other goals?
• What is the best mechanism for ensuring those freedoms, and ensuring the continued development of the code?

The Wine X11-style license essentially allows the code to be used anywhere, in any way. Users don't need to pay, Developers can take bits and pieces as they deem appropriate, and corporations can sell the product in whatever way they feel like. But it also has no legal mechanism to try to coerce further development of the project.

Current proponents of an LGPL license switch believe that a legal mechanism is important to protect the project.

Frankly, I am at a loss to understand the reasoning behind such a switch. I don't see any way in which any company could maintain their own fully proprietary fork of Wine without doing periodic merges into the public project. It's hard enough for TransGaming to do it despite the fact that we deal mostly in very specific areas. And even if someone was able to do so, how does it affect the Wine project any more than the existence of Windows or MainWin does? At most, it would affect the userbase, but in the current model that doesn't matter, since that userbase doesn't contribute significantly to the project. Only the developers contribute, and it is not at all clear to me that they would stop.

Marcus Meissner has already shown that the existance of our AFPLed DCOM code didn't stop him from going ahead and doing it himself. On the contrary - it helped him, since he got hints from our design. It's a shame that he had to, since we've been working hard to find a way to contribute that code back, and now we may have no way to recoup our investment. We still have a 2nd pass, more complete DCOM implementation under development, so it is possible that we be able to get a sponsor for that. But regardless, it clearly shows that having code outside the WineHQ tree is no impediment to the community reimplementing it if necessary.

The LGPL would severely limit a number of possible commercial applications of Wine, such as:

• Companies or groups that might want to take a small bit of Wine code here and there without taking the whole thing. IE: Corel's Mac porting work, or projects like MicroWindows or Odin (similar projects like Xine and ReactOS use parts of Wine this way, though they're GPLed, and thus would not be affected).
• Porting Wine to platforms with NDAed APIs. Or commercially oriented ports to other platforms which might not be viable under the LGPL.
• The work that TransGaming has done to support copy protection. Releasing that code all at once - as would be required under the LGPL - might violate the DCMA, since it reveals something of how the copy protection systems work.
• New business models like TransGaming's, with conditional-future- release of code.

While I am open to considering license changes that have the potential to benefit the project, I am very very concerned about the LGPL. Going that route is a one-way street with no turning back.

I've been thinking about these problems for a long time. As much as for any other reason, I started TransGaming with the desire to try to find good long-term solutions to the problem of how to fund Open Source development through the people who are actually using the code.

I have the germ of an idea that might be useful to address some of the concerns that the LGPL-license-change camp has had, while at the same time leaving the doors open for a much wider variety of different commercial activities. I have been trying to flesh it out while at the same time working to some very tight deadlines, and I have not had time to really think through some of the the possibilities that it entails. I am posting it to the list now anyway so that it's out there for people to think about.

Here's the quick and dirty version:

• A new non-profit company is created: WineCorp
• Developers contribute their work to WineCorp - possibly assigning copyright, or at least giving WineCorp the rights to do with the code whatever it pleases.
• WineCorp distributes the code under an AFPL-like license - no commercial redistribution allowed.
• WineCorp has a set of standing licenses allowing for commercial redistribution. A company can redistribute commercially if it does one of the following things:
  • Releases source modifications to WineCorp immediately.
  • Releases source modifications within a preset timeframe (maybe one year).
  • Releases source modifications with some appropriate prearranged condition (ie: the TransGaming subscriber limit).
  • Pays WineCorp a pre-set royalty, which WineCorp can then use to sponsor other Wine development
• For cases that don't fall into the above conditions, the WineCorp board of directors can vote to allow some other licensing arrangements. This helps prevent the kind of one-way ticket we have with the LGPL.
• WineCorp could also serve as a way for the userbase to direct funding and attention to different parts of Wine. To my mind, this is one of the biggest problem Open Source projects have. The end users get everything, but many don't contribute: no code, no money, no bug reports, nothing. The more they can be encouraged to contribute, the better off everyone is. WineCorp could solicit donations from users who can't contribute otherwise and possibly institute a subscription/voting system similar to TransGaming's.

One hard question the above idea creates is how does money gets split fairly amongst different developers working on particular parts of the code? I am sure that there are other problems as well. That said, I think that the importance of new models like this go far beyond the Wine project. Ideally, I hope that methods like these can be profitable enough to make proprietary software companies begin to consider opening up their code in a similar fashion.

Just imagine the day that Microsoft makes their first contribution to Wine, openly and without coersion by the government, because they recognize that doing so is in their own best interests.

Food for thought, anyway.

Based on what an ODBC driver actually does, and assuming a technically sound model, I see no reason that you shouldn't be able to use an existing Win32 ODBC driver under Wine to talk to a SQL server.

In practice, the issue may be far more hairy than that. :)

If the Win32 ODBC doesn't work for you, maybe the next thing to look at would be compiling FreeTDS's ODBC driver using libwine...

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.

Company Presentations

Transgaming, Success To Date [Transgaming/State]
ReactOS - Where it's at, where it's going [ReactOS/Filby]
Corel, A Look Back [Xandros/Tranter]
Crossover Strategy [Codeweavers/JW]
Macadamian - Making It As A Software House [Macadamian/???]

Business

WINE's "Most Wanted": Features To Make WINE Great [???]
Developer Funding, Who Pays The Rent [???]
Future of WINE licensing [CW/White]

Technical

Development Model [CW/AJ]
NORM - The secret weapon [Codeweavers/???]
Making Fonts Not Look Like Crap [CW/Timoshkov/Davies]
Multimedia And WINE [eric.pouech@wanadoo.fr]
Regression Testing [???]
How To Improve The Debugger [Meissner/marcus@jet.franken.de]
Maximizing performance of WINE [???]
Package streamlining of WINE [???]
WinNT APIs (Odin, ReactOS, winNT wine, WINE) [???]
DirectX [Transgaming/Kaaven]
WINE as a porting tool [Macadamian/Jacques]
Native user.dll [Dr. Ulrich Weigand]
API Standardization [???]

Hello everyone. My name is Michael Cardenas and I'm working on Wine for Lindows.com. I'd like to start a lot more communication with all of you and I have a couple of questions.

I'm working on an app that uses a custom dll which requires msvcp60.dll to be loaded at launch time and won't launch without it.

Currently there's no implementation of msvcp60.dll in wine. Is that just because no one has needed it yet? Or has someone looked into this and seen that it's too large to do? Or is it just not needed and there's some substitute dll? Doing some research, I see that on a fresh install of Windows98, the dll is present, so it seems to be a common windows dll. MSDN mentions the dll in this article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/sidexsidewinxp.asp

"A good example of this is the Microsoft Visual C++ Runtime assembly, which includes atl.dll, mfc42.dll, mfc42u.dll, and msvcp60.dll."

Also, there's been basically no discussion of this dll on this mailing list. So, to proceed, I'm going to create a stub dll and hope the app will launch and not need many functions from that dll. I'd like to know if there's a good way to make a complete stub for the dll. Right now, I just made a stub dll with one function.

Well, you might want to create an export table with the *real* function names...

Use pedump for that.

Also, it contains some common functions like mbrtowc() and such, so maybe it should be based on msvcrt. Most functions have mangled names and appear to be different, though. There was a way to demangle these function names. (I think winedbg includes demangling support)

Just found this on http://www.osnews.com/:

Direct 3D 8.0 Wrapper for OpenGL Open Sourced http://www.osnews.com/story.php?news_id=613

Not sure what is the license, but maybe it could be incorporated to wine as an alternative to the transgaming's version.

Well, you're welcome to try, but their 'library' seems to consist mostly of stubs and Microsoft's own code. There is very very little there. The prospect is certainly not keeping me up at nights. 8-)

It might be better to help find us more subscribers so that we can release our real, working code to the WineHQ tree.

Oops, 5760 is physically possible with a custom divisor of 20, I think. 5726 is not. You set the speed of a UART by loading an integer valus into the divisor regisgter. The UART then divides its maximum speed by that number. If the divisor is 2, it runs at 57600. There is no integer you can divide 115200 by to get 5726. There is also no provision in Wine to use a custom divisor, I think, but combined with linux system commands, there is. Set the app to use 38400. Beforstarting the app, do

setserial /dev/ttyS<n> spd_cust divisor 20

when the app asks for 38400, it should actually get 5760. If it doesn't work, show me the output of:

setserial -a /dev/ttyS<n>

<n> is the number of the comm port -1, unless you have ~/.wine/config set oddly. You can make "Com1" = "/any/damn/thing" but it might not work, or "Com1" = "/dev/ttyS3" (if the serial port you mean to use is on com4, that will work, but it will confuse me unless I see your .wine/config)) and

wine --debugmsg +file,+comm blah.exe 2>&1 |tee ~/logfile

(a copy of the debug messages will be in ~/logfile) gzip it before putting it in the mail, please.

If you have access to Google, search for the following Usenet posting, for example: UnHy6.600095$JT5.16435354@news20.bellglobal.com

If you can't use Google, you could see that this is a common request under Windows. quite a few programmers need to access devices with non-standard crystals, or even non 8251 chips with specific drivers. In this post, you could see that SetCommState accepts any baud rate up to 9600 bauds, and that over 9600 bauds the idea is that the Windows driver should accept values that are inside a +-1% interval of the 'correct' value (although the poster says that the calculation is bugged and works only for negative differences).

The Windows code for the 8251 family is probably always rounding to the next integer value under 9600, and if the wanted rate falls to +-1% of the 'normal' value over 9600. As I understand it, the 1% tolerance is explained because such a small difference don't matter for asynchronous serial communication.