Hi there,
I have been watching this thread quietly for some time now but I feel I should probably put my opinion forward ... now or never. Warning - it's longish and covers a few things that might be considered a little bit "left field".
I have worked at more than one company in the capacity of an "open source programmer", however you choose to read that. My primary open source involvement has been with the OpenSSL project, but I've ventured forth bits and pieces to other projects too.
The following note struck a chord with me;
If you believe all are greedy bas*ards and will just steal the code, then you shouldn't care. If you think that people can make a 'good faith' judgment on what's a bug fix and what is their stuff and will contribute the former, then you should care. Let's say company A implements DSOUND, and contributes X bug fixes that fix acm stuff, but keeps its DSOUND implementation. I would say that you are STILL better off, as you got the acm fixes. If company A would not have done the work because it couldn't keep what it did, then you are NOT better off by using LGPL.
I think the essence here is pretty spot on, but I'd like to take it a step further. I have worked on source code in a company that for various reasons (outside it's control I might add) was using essentially a "forked" development tree. The reason is that proprietary code (including external elements they had no permission to open to the wide world) was being used as a supplement to the public code at a certain point in time. During only a short period of time, they did not have adequate resources to pay attention to this problem let alone rectify it. As a result, the open source project had continued forth to the point that not only was the proprietary tree left behind, much of the change in the public tree had in fact conflicted massively with the proprietary code. In this case they hadn't wanted to keep the proprietary code to themselves, but even in cases where the retention of corporate development is by choice - the maintenance curve can easily get steeper than the perceived benefit of doing so.
This is not that uncommon - maintaining proprietary patches to open source projects is always a pain in the ass, and the only positives (when there are any) are commercial. And you should know full well that when commercial considerations have chosen to win out over technical and/or logistical considerations, you can discuss the differences between LGPL/X11/BSD/etc until you are blue in the face and it won't, in all reality, make a shred of difference to what such companies do. As has been adequately demonstrated in many posts already - you can wrap up proprietary code in any number of ways and the practical hurdles of separating that from "public" code are probably minimal (and reasonably constant over time). So the LGPL-vs-BSD differences in that respect are unlikely to amount to much IMHO - especially given the component-oriented nature of wine.
"Forcing" those companies (if one believes the LGPL assertions) that are planning to retain (some of) their wine improvements to at least provide static libs of their proprietary code makes, IMHO, no great difference. The only noticable difference AFAICS is that it improves their users' experience anyway - because they can use the company's product but benefit (perhaps) from improvements in the public code ... but ... if you look at it - helping users of those company's products is hardly doing anything to "deter" the behaviour we all agree should be discouraged, is it? It simply improves the user-experience of these companies and rewards the business model. Again, I doubt the LGPL in reality discourages this behaviour any more than the current license.
I'm not going to "vote" on the wine licensing issue at the end of the day - I'm a casual user and certainly have *not* contributed anything to it - so to my mind, I have no right to do so.
However, if I might wax extreme for a moment, my out-there suggestion would be to stick with a BSD style license but to put an advertising clause *in*. This leaves companies/users/etc basically with their existing freedoms, but provides a P-R feedback loop that might discourage companies who were looking to peddle their wares as "better and other than wine" - it would instantly show them up as being "wine + stuff we didn't contribute back" rather than anything completely independant of the public project. This might also allay fears companies might have about contributing - ie. would Transgaming fear other companies profiting from their work if those other companies also had to 'fess up to using the public wine project themselves? Would not the kudos from sponsoring/contributing/maintaining the D3D work in the public wine project more than offset the fact that other companies would then have the same functionality? I don't think so - especially as the public version would also have it.
Under such a license, what companies contribute back and what they don't is still their choice, but there is a counter-balance to the temptation some might have to withhold their own improvements whilst harnessing the work of others.
The rest of the suggestion I would like to make may seem somewhat surprising; dual license this BSD+adv-clause with the GPL. Not LGPL, but GPL. GPL is an enormous hunk of trouble I know, but under a dual license you're only bound by it if you choose to use it instead of the alternative. The GPL would then exist as an alternative for those who can not work with the BSD (and/or the advertising) clauses - eg. some of those GPL and LGPL projects that have a "no additional restrictions" viral element. If they don't like BSD/adv-clause, they could always go with GPL but would then be stuck with the *ultimate* counter-balance, they have to open up *everything* else they do and stay with the GPL from then on. Given that the most stark conflict with a BSD+adv-clause license is the GPL itself, this would provide a clean fit into GPL projects. Those that can't handle using the GPL option (we shall call this "the sane world") would then have all the freedoms of that BSD-style alternative - with the simple proviso that they have to 'fess up from the get-go that their product is built using wine. In other words; if your commercial product can run win32foo.exe and the public version of wine can not, that means you have supplemented or edited the wine code but didn't contribute it back. Customers can then judge for themselves.
From my experience, I would expect that there are those who would *not* want to use a "mutant" wine just to get paid-up support or an extra feature or two - the simple reason is that you've always got a smoother upgrade path and wider support/info resources available to you if the commercial product hasn't frankensteined the public version. From a Q/A point of view, do you prefer your employees/children/uncle/whoever buying supported products that are known to be forward compatible with a public open source project, or do you prefer them buying products that have no future the moment their subscription lapses or the company goes under?
If you don't know it's based on wine, you probably think you've got no choice. If you know it's based on wine, you're more likely to wait for the public wine itself to catch up (or you will buy your supported product for the support services but will switch to the public version as/when it matures enough to solve your needs).
Anyway ... sorry for the blurt - I realise such a scheme may be off the radar for most people, but thought I should at least mention it. At least it might inject a fresh "something" into this thread (though what that something is remains to be seen ...)
Cheers, Geoff