Re: wine-license digest, Vol 1 #106 - 9 msgs

On 3 Jun 2002, Marco Pietrobono wrote:

>   well, I don't like feeding the trolls, but sometimes they are really
> asking for it...

I'm not a troll, thank you very much.  Nor do I have an axe to grind, but 
it seems like many people do, on both sides.  I honestly don't know if it's 
a good thing or a bad thing for Wine to use the LGPL.  I can see potential 
benefits, but I can also see some potential pitfalls.  I don't know where 
the balance lies.

I am only an outside observer, seeking to supply some perspective untainted 
by the history between the parties who seem to have long-running arguments 
back and forth.  Now, because of the perspective I have, I'm necessarily 
also naive about certain aspects of the debate -- that's intrinsic to being 
an outsider to it all.  If I weren't naive to those aspects, I'd probably 
have a predetermined opinion on the outcome and look to rationalize it -- 
that's a normal human tendency, and the main reason why an unbiased outside 
perspective is occasionally useful.

> > If Wine clobbers ReWind, on the other hand, that doesn't tell you whether 
> > or not the LGPL license is superior, since Wine can be expected to "win" 
> > due to community support alone.  Wine ought to win by default -- so, if 
> > Wine does win, that doesn't prove that the LGPL made it happen.  Prevailing 
> > against the odds is far more meaningful than winning by default.
> 
>   Nice reasoning... So there is still another one who tries the old
> theme "If I win, I win, if you win it's not a win". And I was thinking
> that only a really young boy would have used such a scheme...

Hey, feel free to reverse it.  Get the Wine community to switch back to the 
X11 fork, and have only the hardcore LGPL advocates worry about the LGPL 
fork.  Then, if the LGPL wins, I would consider it evidence of the LGPL's
superiority for prevailing against the odds.

I'm not making this argument because I have a predetermined notion of which 
camp I'd like to see win.  I'm saying that the Wine community is of utmost 
importance, and the license is largely immaterial.  I think whichever fork 
has the attention and support of the community will win, it's as simple as 
that.  Since that is now the LGPL fork, I expect that one to win.  Arguing 
later that it left ReWind in the dust because the LGPL is better than the 
X11 license won't be convincing at all, because I fully expect it to win 
due to the community support, not because of a different license.

If you want to prove the LGPL is better, prove that the community doesn't 
matter and that the license is more important.  I haven't seen anyone even 
make the argument that the choice of license is more important -- on the 
contrary, it seems much of the community cares so little about the choice 
of license that they're allowing X11/LGPL dual licensing.  That just tends 
to confirm my belief that the community is the dominant force here, not the 
license.  Do you have any arguments to refute that?

>   BTW, I don't think it should be considered a race. They are two
> projects on a diverging path. It is not so immediate that there aren't
> enough resources to allow both to prosper. I think in the long they can
> both survive, even if at different speed. But if you really have such a
> compelling love for both of them, why don't you try to contribute to at
> least one of them, instead of bickering around like you are doing now?

I'd be happy to see both succeed, though I think it would be preferable for 
the community not to be split between the X11 and LGPL camps.  A larger 
community with a single codebase is stronger than a divided community, each 
with its own fork of the codebase.  If most of the base code were released 
under dual licensing (or even many, like X11 + MPL/GPL/LGPL a la Mozilla), 
and only certain selected DLLs were LGPL-only, it would probably benefit 
both sides.

However, it seems likely that this divide will remain, which seems rather 
sad.  Such is life.  It doesn't look like the Emacs vs. XEmacs divide will 
end soon either.  Then again, the GCC vs. EGCS divide was resolved...

I'd be happy to contribute to either or both projects, if I had the time 
and energy to do so.  However, Wine is a very large and complex project, 
and thus not one well-suited to casual involvement.  It would require a 
significant time investment on my part to become sufficiently familiar with 
the code to be of any true help, and I just don't have the time.

I already face the same hurdle with Mozilla, which I'm even more interested 
in helping out with.  At least Mozilla is finally approaching a final 1.0 
release, and the APIs will finally be frozen.  I'm hoping I may be able to 
finally participate more with Mozilla after 1.0 when I won't have to worry 
about trying to hit a moving target.

Much as I'd like to contribute to Wine, it's nowhere near a 1.0 release and 
I don't have the time to track a moving target as complex as this.  There 
are too many other projects that are calling to me, including ones for my 
own interest that don't exist yet.

The only relevant project is that I'm interested in writing an operating 
system, even if it's destined to serve as little more than a learning 
experience for me.  I don't delude myself into thinking that I'll make the 
next Linux to take the world by storm, and I'm not even convinced I'll ever 
bother to write anything usable.  I don't doubt my ability to, but I doubt 
my motivation and commitment to put that much work into it.  There's a good 
chance I'll walk away if and when it becomes merely hard work and no longer 
a rewarding learning experience -- especially since I strongly doubt anyone 
but me is likely to use an operating system I write from scratch.  (Sure, 
Linus Torvalds thought much the same at the start, but it's better to just 
assume nobody else will use it then to set yourself up for disappointment.)

Anyway, supposing I ever write an OS of my own, I might find it interesting 
to see if it's possible to integrate Wine code to run Windows applications 
more "natively" than may be possible under Linux.  (What would it take, not 
to need a "wineserver" process around, for example?)  And I suppose that 
such an effort might have to rely on the X11 fork if the LGPL codebase 
turns out to be incompatible with the license I may choose.  That doesn't 
mean that I'm rooting for the X11 fork -- it's a long shot that I would 
ever try to integrate the code, given that I may never develop the OS.  
Even if I do, the LGPL may well be compatible, even if the GPL wouldn't be.  

At this point, I'm not worried about it.  Although I am curious just what 
support Wine needs from the native OS, and whether it would be feasible to 
integrate Wine into a native OS (into Linux, for the sake of argument) to 
run Windows applications more "natively".  Does anyone know offhand?

> > If the patches they're asking for are truly to enforce proper boundaries 
> > between DLLs, might that not constitute a special case?  If the intent of 
> > using the LGPL (instead of the GPL) was to allow DLLs to be mixed between 
> > LGPL'd and proprietary DLLs, shouldn't you release any patches that are 
> > indispensible to making this possible?  (If in fact that's what these are!)
> 
>   have you read what Alexandre said? I don't think so.

Certainly not everything.  I said I was an outsider -- I follow this list 
only sporadically and I'm not even on the wine-devel list.  Anything I've 
responded to directly, I've read.  Anything else, I may or may not have -- 
as an outsider, odds are that I haven't in many cases.

>   He said that if they really want, they can adapt their models and they
> can write their code within the LGPL wine codebase without being forced
> to release their versions of their proprietary DLLs.

Why should that require adapting their models?  The question is whether 
they can already mix in proprietary DLLs with the LGPL codebase, without 
changing their (evidently despised) business model -- or are these "DLL 
separation" patches they're requesting a prerequisite for doing so?

>   This is possible thanks to the DLL separation patches. And he has
> released such patches. They are in the wine repository. Have you checked
> them? Perhaps they are not complete, there is still work to do, but they
> are here and they are useable, so I don't see your point.

No, I haven't looked at the code, and don't intend to.  I'm not familiar 
enough with the Wine codebase to make sense of them, nor do I have any 
experience with Windows APIs for that matter.  It would be pointless for me 
to spend my time analyzing that code without the background for it.

Anyway, if the patches are in the Wine repository, but only usable under 
the LGPL, how does that help Transgaming?  They seemed to be asking for 
those patches to be rereleased under the X11 license so they would be able 
to mix and match proprietary DLLs with LGPL'd ones.  This doesn't seem like 
an unreasonable request, if that's what they're asking for.  In fact, it 
might encourage them to do work on selected DLLs under the LGPL, and that 
would be good to encourage, wouldn't it?

>   But they want the DLL separation patches in Rewind so they will be
> able to continue to use Rewind, not Wine. They don't want to
> "contribute", they want to "trade". You know, there is a difference
> between these two terms, even in english...

Yes, and the proposed trade can be evaluated on its merits.

If the DLL separation patches are necessary to mix-and-match proprietary 
DLLs with LGPL'd ones, which is what people seem to be indicating, then it 
seems cricitally important to have that code in both Rewind and Wine -- the 
only reason to refuse is to deliberately cripple Rewind and further isolate 
(shun, really) the developers who want to rely on that codebase.

Those same developers may not want to adopt the entire LGPL codebase, 
especially if it conflicts with their business model, but they might well 
choose to contribute (under the LGPL) changes to some LGPL'd DLLs, that 
they otherwise wouldn't contribute to, if they couldn't use those DLLs 
under Rewind.  Wouldn't it be better not to preclude such collaboration, 
even if it might be limited only to some DLLs?

> > Your contention is that Transgaming is hurting Wine by developing code like 
> > DirectX that discourages Wine contributors from working on similar code?
> 
>   His contention is that Transgaming HAS HURTED wine not by developing
> the code, but by promising an opening of that code that has never
> occurred.

I had not been aware of this promise before.  This may well be a compelling 
reason not to want to cooperate with Transgaming, if they betrayed the Wine 
community's trust, but that's not a reason to reject the very notion that 
trading patches (in general) could benefit both parties.  (People usually 
engage in trade precisely because BOTH parties benefit from it.)

>   This is what has stopped the developing of DirectX in Wine. Because
> none that aims to call himself a "programmer" would write code if that
> code is going to be discarded "real soon now".

Sounds like an empty promise with much of the effect of Microsoft vaporware 
announcements that kill competing products before Microsoft is anywhere 
near release.  If they're making empty promises, then don't trust them.  
Isn't that self-evident?

>   This is the reason why, even if I like the LGPL, I'll release the alsa
> driver I'm working on under the X11 license, because from when I've
> stepped up to this task, both Eric and David have stopped working on the
> driver to avoid wasting time on a duplication of effort. And since I
> respect the work they had done up to when I started my work, I think
> it's right to give them back all my work on that driver.

Glad to hear it.  I always think it's preferable to respect the wishes of 
the primary developers of any code, even if it's not your preference.  Even 
Richard Stallman encourages GPL developers to retain dual licenses (as Perl 
and Mozilla have) rather than releasing their changes only under the GPL...

>   it was not for the competition, it was because at the time that was
> not "competition" but "cooperation". And while there is cooperation
> there is the will and the implicit agreement to not step on each other's
> toes.

Then it would make sense to pressure Transgaming to follow through on their 
promises or admit that they've reneged.  After that, or when the community 
decides that they're not going to respond, forget about them and work on 
the code, if it doesn't appear that a release is forthcoming.  If they ever 
do release their code, try to merge the best of both, I guess...

>   but one day there was no cooperation anymore, and all the promises
> suddenly disappeared, leaving the Wine project without both the code
> promised by Transgaming and the old developers that were working on
> DirectX.

I wasn't aware of this aspect of the history with Transgaming.  I was only 
aware that there was clearly a large segment of the Wine community holding 
a grudge against Transgaming for whatever reason.  This animosity may or 
may not be deserved, but it certainly isn't conducive to cooperation.  Even 
if Transgaming can't be trusted to cooperate nicely with others, it doesn't 
mean that other proprietary companies should necessarily be tarred and 
feathered because Transgaming wouldn't behave.

> > No, I really don't see how Transgaming's existence or business model has 
> > really hurt the Wine project.  As far as I can see, it's only shattered the 
> > illusion that these gamers were committed Wine developers.  Clearly, those 
> > developers would have ceased to contribute eventually even without the help 
> > of Transgaming, as they would have finished the coding they needed and gone 
> > back to playing the games they love so much.
> 
>   So you are saying that Marcus was working on Wine just to play few
> games... Why don't you try to ask to himself? He is still working on
> Wine, and it seems to me that his contribution are still abundant and
> important. Like the COM code he has written lately.

I'm not saying that at all.  By the descriptions I've heard, it sounds like 
Marcus is a committed Wine developer, and an asset to the project.  Maybe 
he's lost interest in DirectX, but he hasn't walked away from Wine.  If he 
were working on DirectX now, this other work he's doing wouldn't have been 
done -- how can you say it's a loss that he's no longer working on DirectX, 
then?  No matter what code you work on, it's an opportunity cost, because 
there was other code that you could have been working on instead.  I don't 
see how DirectX is more important than COM.  COM sounds more important to 
me, actually.  It may not be as sexy as DirectX, but it sounds important.

>   It seems to me that you are desperately trying to make a point without
> any real data backing it, just to yell something.

I was offering a hypothesis.  I didn't claim to have incontrovertible facts 
supporting the case.  I don't know if ANY developers were in the category 
that I hypothesized about.  It certainly sounds like Marcus wasn't, in any 
case -- if he was, he would have walked away from Wine entirely, and THAT 
would have been a tangible loss to the project.  However, you say that he 
redirected his efforts from DirectX to COM support -- that hardly sounds 
like a loss to the project as a whole, just a shift in focus.

>   I've been lurking on this list for at least three years, I can say I
> have seen what's happened from the very start. I don't know if you can
> say the same. But if not, I don't think you can say you really know what
> you are saying.

Well, I know the "wine-license" list was created this year, so that's not 
strictly true.  I'm assuming you mean you've been lurking on wine-devel for 
three years and wine-license since its creation.  And no, I haven't.  I've 
paid a little attention here and there; I haven't followed the lists.  So, 
I'm not claiming to know what I'm talking about here.  I'm only offering an 
OUTSIDE perspective.  Yours would be more of an INSIDE perspective.  Both 
are useful perspectives, I think.

>   And BTW nor I nor you can say we really know what's happened and why.
> Alexandre can.

Indeed.  I don't have much knowledge of the actual facts of the situation.  
However, as an outsider, I don't have any risk of "losing the forest for 
the trees".  All I can see is the forest, not the trees.  Being cognizant 
of all the facts can make it harder to look at the overall picture -- you 
know too much.  It's like handing off code or prose to someone else to 
proofread -- you might miss something that should be obvious because you're 
too intimately familiar with the details already.  Sometimes an outsider's 
perspective can help.  Not always, but sometimes.

>   nice. So you have such a great knowledge of the inner works of the
> wine community... nice indeed...

Nope, don't know much at all about the inner workings.  I do know that the 
estimates of how far away Wine 1.0 is haven't changed in 5 years or more, 
always seeming to be just a year or two away.  Even from the outside, it's 
been clear that a lot of emphasis has been placed on games in the last few 
years.  It's not such a leap to conclude that maybe that last year or two's 
worth of work was put off (at least somewhat) to focus on games instead.

Of course, it's quite possible (even probable) that the estimates were just 
overly optimistic, but Windows has been less of a moving target than it 
used to be, simple because Microsoft has had to keep supporting Windows 95 
much longer than they ever wanted to.

It seems like nobody has wanted to do the unsexy work of finishing at least 
Windows 95 compatibility.  And why should they?  No doubt it's tedious, 
thankless work.  Not fun at all.  It's hard to blame developers for working 
on games -- that's fun, at least.  But the project would probably be better 
off today if everyone had been willing to sit down and do the unfun, unsexy 
work that nobody wanted to do.

It's not surprising.  Unpaid developers deserve to at least pick the work 
they want to do.  If they're going to do the work nobody wants to do, they 
ought to be paid for it.  Unfortunately, it's the dilemma of open-source 
development -- there's a lot of unsexy and downright tedious work that 
needs to be done, but nobody wants to do it for free.  Nor should they have 
to, for that matter.  It's NOT fair to expect that of volunteers.

If one could "take up a collection" from the millions of Linux users who 
would benefit from Wine having 100% compatibility, there'd be plenty of 
money to pay for the work nobody wants to do for free.  Unfortunately, 
that's easier said than done.  Nobody thinks their few bucks will matter 
(and individually, it won't), and everyone obtains the benefits when it's 
done.  Might as well wait for someone else to pay for it or for someone to 
feel like doing the work for free.  Too bad it can be quite a wait...

>   so you are saying that both Marcus Meissner and Lionel Ulmer, those
> who have worked so much on the directx stuff before the Transgaming era,
> have gone away and now are not anymore part of the wine project...
> strange... I seem to remember to have seen them around just last
> friday...

I never cited any individuals.  And the fact that you choose to cite those 
names strongly suggest that those individuals are NOT in the category I was 
hypothesizing about.  They would be committed Wine developers who happened 
to have an interest in gaming, so they worked on DirectX.  If they haven't 
walked away, that means they're working on something now that they wouldn't 
be working on if DirectX was still taking up their attention.  That's not a 
loss to the project, only developers that walk away entirely are.

>   have you ever tried to back up your thesis with few facts? Or are you
> just wasting your and our time just for the love of the discussion?

As an outsider, I have relatively few facts at my disposal.  But the ones 
you've thrown out didn't refute my hypothesis either.  I don't know if the 
hypothesis is true or not.  But it certainly seems plausible that some of 
the hardcore gamers out there may have "joined" the Wine project solely in 
pursuit of their gaming interests, without any interest in Wine for itself.

>   Since it is Alexandre to say so, I would have used just a little more
> of my time to think and understand what he was saying before writing
> something like your reply.

What is this, argument by authority?  Yes, Alexandre is a respected leader 
of the Wine project.  I respect him too, and admire his willingness to stay 
with the Wine project for so many years.  I can only assume burnout is a 
real danger to anyone who has worked as hard as he has on any given project 
for years on end.

However much I may respect his leadership and coding ability, I'm still not 
sure if his refusal to trade patches with Transgaming is more personal (due 
to Transgaming's empty promises, for example) or if he's right in believing 
that the act of trading patches inherently endangers the whole project.  

That seems like an extreme position, so I offered an outside perspective 
and some alternative hypotheses that might explain the damage he described.  
The gamer-as-uncommitted-Wine-developer hypothesis was entirely in response 
to his arguments about how Transgaming has damaged the Wine project and the 
Wine community.  I don't know if it's true, but it's possible.  Meanwhile, 
any committed developers (e.g. Marcus) may have given up on DirectX, but 
remain to work on other things -- those things wouldn't be getting their 
attention if they remained focused on DirectX, so it's not clear that it's 
really fair to call it "damage" to the project that they've changed focus.

>   If there is one who can say that the damage is real it is only him,
> not you or any other whiner who has just discovered the LGPL switch. He
> knows every single contributions and every single developer in the wine
> community. Who other can say so? You?

It's clear that he has perceived damage.  It's possible that that damage is 
illusion, however real it may seem.  Yes, Transgaming may have done heavy 
damage to Wine's DirectX support.  However, Wine is about more than just 
DirectX -- does that damage to that one area constitute overall damage, or 
just trigger refocusing of developer efforts so that OTHER gains are made 
that otherwise wouldn't have occurred?  If the Wine project has improved, 
just no longer in the area of DirectX, I'm not sure that damage is real...

>   Are you sure you are not Brett Glass under cover?

Hardly.  I've followed enough of this list to know that Brett Glass is 
often reviled and he seems to be quickly dismissed by many on the list.  
However, as an outsider, I have to point out that Brett Glass does make 
some good points here and there, though he seems as quick to dismiss the 
good points of his opponents as they are to dismiss his.  But I'm not Brett 
Glass in disguise, nor do I agree with everything he says.  I only point 
out that SOME of what he says (that gets dismissed out of hand) is worth 
more serious consideration than it seems to get.

Deven