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

On Mon, 3 Jun 2002, Tony Lambregts wrote:

> Sometimes an outside perspective is helpful.  However  they need have 
> all the facts or at least enough of them to make make informed 
> judgements. Saying that lack of knowledge is helpfull is in my opinion 
> an error in argument.

I said that I had an outside perspective.  I never claimed a complete one.  
I welcome any knowledge and information that pertains to the question at 
hand, and try to refine my thinking in light of it.  The allegation that 
Transgaming made promises to release code and never kept such promises -- 
that was news to me.  (I can only call it an allegation, since I never 
witnessed it, nor have I seen TG admit to such empty promises.)

> >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.
> >
> This whole line of argument is BS. someone could say that  LGPL "Won" 
> when it got supported over an encubent license,  X11, and got the 
> support of Alexandre Julliard, CodeWeavers, Lindows, Macadamia and (not 
> all) the other independent developers.  But this is not about winning. 
> its about what is best for Wine.

Indeed.  I think the line of reasoning was that if the LGPL fork thrived, 
it would be credited to the switch to the LGPL.  My assertion was that the 
community-supported fork is most likely to thrive, regardless of the 
license used for that fork.

> Community DOES matter.  Some people are dual licensing. For the most 
> part I would say they doing so because they are license agnostic. They 
> are also influenced by Ove Kaaven's Support for X11, Alexandre Julliard 
> obviously Supports LGPL , is strong leader of the wine community. and is 
> a major contributor of code to wine. It is also his code that is being 
> discussed If he says that he does not want to trade and then thats his 
> choice. You choose not to listen to his arguments.

Oh, I listened to his arguments; they just didn't make sense to me.  His 
assertions are plausible, but not the only plausible explanation for his 
observations.  I'm curious how he's so certain when several explanations 
seem plausible, that all.

> [snip all the reasons for not contributing...]

I'm not saying I'll never contribute.  I'm just being realistic -- I don't 
have much time that I could devote to it, and I don't see how I could do 
anything useful in a couple hours here or there.  Maybe there's some small 
area that doesn't require learning the whole project -- if so, maybe I'll 
help out in a smaller area sometime.  I sure don't have time to familiarize 
myself with the entire project, that's for sure.

> >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.
> >
> Hum... Maybe you should read what he said to you again?

I read what he said.  He seems quite convinced that Transgaming has harmed 
the Wine project.  For all I know, he may be right.  Then again, there are 
other possible explanations for the effects he described, and there are 
other possible outcomes than the disaster he predicts.  How can they all be 
ruled out?  If they can be ruled out, his decision would indeed make sense 
to me, but it doesn't make sense to me in light of the other possibilities.

> It's not  their business model thats disliked but the fact that they 
> said that would release code and then. kept putting off the release of 
> the code.  It was the business model that they used as a reason/excuss 
> for not releasing code.  If it's broke... 

That detail was only added to this conversation recently.  If they've made 
promises and failed to deliver, hold them accountable.  That doesn't mean 
that anyone else with a proprietary business model is *necessarily* the 
enemy here.  Still, I'd agree that proprietary models should at least be 
viewed with some skepticism.

> If Alexandre Julliard wanted his patches to be released X11 he would 
> have done so in the first place.  The reason for the license change was 
> not just TG but TG+Lindows.  Lindows was convinced to give up thier 
> proprietory code base in favor of LGPL but TG wants to keep thiers.  In 
> order for them to keep it they propose this trade. I do not see any 
> advantage for wine in the long run to encourage proprietory codebases.

I'm happy to hear that Lindows will switch to the LGPL codebase.  That will 
surely be a wonderful thing for their company AND for the Wine project.  If 
Transgaming would switch too, I'm sure they'd find significant benefits 
from doing so, hopefully enough to offset the loss to their business model.
If they refuse, then I guess they'll just have to maintain their own fork.

> >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?
> >
> Again. I do not see any advantage for wine in the long run to encourage 
> proprietory codebases.

There's a difference between encouraging and allowing proprietary coding.  
I wouldn't encourage proprietary codebases, but I wouldn't deliberately try 
to block them either.  One could argue that Mac OS X leeched off the BSD 
Unix folks to make their new Darwin kernel, and their Carbon GUI is quite 
proprietary, but there's no question that Darwin has received a lot of free 
help from Apple because it benefits them, and the BSD community has been 
able to benefit indirectly from Apple's proprietary code.  Maybe it's not 
all bad, after all.  If Mac OS X were not based on BSD code, it would still 
exist, but the BSD community would have gotten nothing from it.

If these DLL separation patches are indispensible to mixing proprietary 
DLLs with LGPL'd ones (a question I've not heard answered yet), then 
refusing to allow them under the X11 license implies that nobody using the 
X11 codebase could ever adopt one of the LGPL'd DLLs from the Wine project.

Now, this might be seen as desirable, forcing them to go all-LGPL to use 
anything from the project.  At the same time, it may be counter-productive, 
since it would force them to duplicate the effort, assuming some of the
proprietary developers are unwilling to switch to the LGPL codebase.  (And 
it sounds like Transgaming is steadfastly refusing.)

If they won't switch entirely, how does it help to block them from using 
LGPL'd DLLs?  It raises the bar and incentive to switch, perhaps, but if 
that's not incentive enough, how does it help?  At least they'd have to 
contribute back ALL of their changes for any LGPL'd DLLs they adopt, so 
they should be encouraged to adopt as many as possible to get the most 
benefit flowing back to the LGPL codebase as possible.  If they were to 
adopt many LGPL'd DLLs, they might find themselves close enough to using 
the entire LGPL codebase that they just might take the plunge and switch 
entirely.  Even if they don't, the more LGPL'd DLLs they adopt, the more of 
their work would tend to flow back to the Wine project.  If they're forced 
to maintain forks of every DLL, it seems less likely they'll contribute 
back much at all.

Wouldn't it be best, then, to encourage them to adopt as much LGPL'd code 
as possible?  The more LGPL code they adopt, even if on a DLL-by-DLL basis, 
the fewer areas in which they can hide their work as proprietary under 
their business model.  It seems the more LGPL code they use, the better...

> I think that the idea of setting a precedent is important.  If they want 
> to contribute fine, but again I do not see trade as any real advantage 
> for wine.

It's hard to know.  Who has really tried it?  If it hasn't been tried, it's 
a theoretical answer to say we know what will happen.  And practice often 
doesn't match theory.  There seems to be potential for benefit, and also 
potential for harm.  It might be most pragmatic to try it for a while to 
see which potential really pans out.  It's not a permanent commitment if 
one or two trades occur -- if it doesn't work out, it's easy enough to say 
so and refuse further trading...

> >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?
> >
> There you go...

Choosing not to trust them may be appropriate.  Citing the idea of trading 
patches as inherently flawed seems like a mischaracterization, if the real 
issue is that they can't be trusted to live up to their promises.

> >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...
> 
> Brett would never say this... you can't be him.

No, I'm not.  Out of curiosity, what do you suppose he would say instead?

> [big big snip]
> 
> Brett Glass you are not.  He was never so verbose.  Anyway to be short 
> about it  read again what Alexendre said...

Well, I never claimed NOT to be verbose. ;-)

Deven