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

On Mon, 3 Jun 2002, Tony Lambregts wrote:

> >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.)
> >
> No: you said as follows
> 
> <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 you don't know whats going on, find out before you make an opinion. I 
> told you that lack of knowledge is not a good thing. Instead of being 
> helpfull you waste our time explaining... > 

I'm forming an opinion as I go, based on the discussion as it progresses.  
But I'm starting from a place of neutrality.  I'm not starting with any 
initial bias and looking to justify that bias.  It's a trade-off.  The more 
knowledge and information I have, the less neutral I become as I form a new 
bias based on what I've learned.  I'll have a more informed opinion, but it 
will carry a bias towards that opinion that will make it harder to shake.  

This happens to everyone; it's a natural tendency.  The longer you have 
held any given opinion, the harder it is to reverse it.  Even if something 
comes along that "should" reverse your opinion, you'll be suspicious of it, 
or not want to consider it at all.  This happens to me as much as you or 
anyone else.  My point was that an occasional outsider coming along with a 
neutral perspective can be helpful because they join the discussion with no 
preconceived notions.  The downside is that they also begin ill-informed.

I started out questioning the reasoning in just a pair of message; I wasn't 
claiming familiarity with the entire history of events.  That's why I made 
a point of saying that I was an outsider, so people would realize I only 
knew some of the story, not necessarily everything.

> You talk in circles...  the people are where the people are. (Perhaps 
> because of the licence? yes?)

I'm not talking in circles.  I'm saying that I believe that the codebase 
with the strongest community support will thrive the most, irrespective of 
the license chosed for that codebase.  Others have suggested that if the 
LGPL codebase thrives over the X11 codebase, that would represent a victory 
for the LGPL license over the X11 license.  This conclusion does not follow 
because it ignores the influence of the community.  If you want to prove 
that the conclusion is valid, you have to show why the community should be 
ignored in the equation.  Nobody has done so, nor are they likely to.

> His assertions are plausible. because that is the way he sees it. Like I 
> said it's his code he can do what he wants. I would prefer him not to 
> trade it.  

I never said his assertions were implausible.  I pointed out that there 
were alternative interpretations which wouldn't lead to dire conclusions, 
and asked why those alternatives were any less likely.

> That is all I have.  A couple of hours here and there.  "The world is a 
> poorer place if a person does nothing because he can only do a little"

I don't disagree with the notion, but if I only have a few hours to spend, 
doesn't it behoove me to spend them effectively?

[This is a digression from Wine, to illustrate the reason why a few hours 
here and there may not be useful to spend on a large, complex project...]

Let me give you an example regarding the Mozilla project.  There was a bug 
that I reported where an HTML page was being "reflowed" (reformatted) on 
the fly while clicking a link on the mozilla.org homepage itself, one which 
caused the link to move and no longer be under the cursor when the mouse 
button was released, so the link did not get followed.  Now, the second 
time you clicked on the link, it would stay still and work, but this was 
obviously not correct behavior.

I had a few hours available to spend, so I decided to investigate the code 
personally rather than wait for someone else to fix the bug.  I studied the 
reflow code, and fairly quickly determined that it was related to reflowing 
HTML tables, specifically.  Now, I had been told that a reflow was proper 
behavior, in that a button can have images, and the image for a clicked 
button could be of a different size.  (At least I think that was the idea.)  
Nobody would disagree that a simple link (which only changes color while 
being clicked) shouldn't cause anything to move on the page, but checking 
to see if anything should move was evidently not considered an error.

I finally determined that something strange was happening specifically when 
calculating the HTML table column widths the first time, which didn't make 
the same calculation on repeated attempts, causing the different results in 
some fashion.  I was getting down to the point of tracking exactly how each 
number was being calculated and where that number came from, when I ran out 
of time to work on tracking down the bug.

By this time, I had spent at least 10 hours over the course of a week or 
two, and I may have been 80% of the way towards finding the bug, but until 
my investigation was finished, it was of little value.  A few weeks later, 
I was going to try to finish the work, but the effect was no longer seen in 
the latest nightly builds.

Unfortunately, I don't even know if it was fixed correctly.  It may have 
been "fixed" as a side-effect of some other change that masked the effect 
of this bug without necessarily fixing it.  Then again, maybe someone found 
the bug and fixed it properly.  I don't know -- my bug (#7617) got marked 
as a duplicate of a later bug (#28212), which was resolved as WORKSFORME, 
which only means that nobody could reproduce the bug anymore.  This doesn't 
mean that the true source of the bug was necessarily fixed; it could have 
been masked.  (There have been other situations where bugs that seemed to 
be resolved got re-opened later because they were never actually fixed.)

Now, after the 10 hours or so I put in, the only certain information I had 
about the bug was that it occurred somewhere in the cross-platform HTML 
table code for incremental reflow.  Nevertheless, nobody was willing to 
change bug #28212 even to reflect the cross-platform nature of the bug, 
because they empirically assumed it was specific to the PC platform just 
because they didn't happen to have a confirmation of the bug from someone 
on a different platform.  This alone could have caused someone to look at 
the platform-specific code, where the bug would never be found.

Now, I could spend another 5-10 hours to verify whether this "WORKSFORME" 
bug was really fixed, or just seemed to be.  I hate to do it, since it 
seems to be a moot point -- it doesn't seem to be affecting the user now.  
Then again, I may do it for some closure on this investigation -- I don't 
know if it was really fixed, and I hate to close the book on it without 
knowing for certain.  After all, if the bug was masked and not really 
fixed, it could turn up again.  I've already done most of a root cause 
analysis; anyone else would have to repeat work I've already done.  If it's 
truly fixed, I could verify that and satisfy myself that the bug won't 
recur, and maybe get the bug changed to more accurately report the fix.

In practice, I'm reluctant to spend the additional hours chasing down the 
loose ends on this issue, especially since it seems likely that it doesn't 
matter anymore.  I may do it anyway, on general principle, eventually...

My point is this.  I spent at least 10 hours of my time working on a root 
cause analysis of this bug.  Mozilla is a large, complex project, with well 
over a million lines of code.  True, I was able to track down (within an
hour or three) what part of the code was misbehaving (the HTML table code
for incremental reflow), but that still left several thousand lines of code 
to analyze in great detail.  I learned a lot about how that portion of the 
code works, but my goal required more time than I had available.  Before my 
investigation was complete (due to lack of time available on my part), the 
codebase had changed enough that the bug was no longer exhibited.

[End of Mozilla digression, more or less...]

So how effective was the 10 hours I spend chasing this one bug?  The code 
was complex enought that it had a steep learning curve.  Yes, I learned a 
lot about that particular code, but what are the odds that the next bug I'm 
trying to track in Mozilla will be in the HTML table incremental reflow 
code, rather than somewhere else in the millions of lines of source?  That 
10 hours could have been spent much more productively on a smaller project 
more in need of help than Mozilla.  That's a large part of the reason why I 
haven't done much serious work on Mozilla since -- it doesn't seem like a 
good investment of my time if that's all the time I can spend.

For me to spend a few hours here and there on Wine would probably be even 
worse.  It's also a large, complex codebase which is a moving target, but 
it's based on the Windows APIs, and I have NEVER programmed anything to 
those APIs.  (As a matter of policy, I've chosen to avoid programming for 
the Microsoft platform.)  I'd have to deal with a very steep learning curve 
for the complexity of Wine's codebase AND the Windows APIs as well.  Most 
of my time would be spent climbing that learning curve, and little would 
benefit the project.  And without an abundance of time to spend on it, 
what's the point of starting up that learning curve, if I don't have the 
time to get to the top and start making worthwhile contributions?  That's 
not an effective use of my time, so I can't justify spending it that way.

Now, if there's some small area of Wine which doesn't require intricate 
knowledge of the codebase or much of the Windows APIs, maybe I could help 
in such an area.  It would probably have to be extremely low-level, since 
the higher-level code tends to build on the low-level stuff, requiring a 
deeper knowledge of the system.

For example, what's the state of the Windows IPC mechanisms?  I seem to 
remember being told that Windows IPC calls hadn't been implemented -- this 
surprised me, since it seemed like it should have been one of the easier 
things to implement.  If the Windows IPC calls are well-documented (which 
they may or may not be, I know _nothing_ about them), then I imagine it 
shouldn't be hard to implement them in terms of Linux IPC mechanisms that 
are available in the underlying OS.  That's the sort of thing I might be 
able to help with in the time I have available.  I don't know; I'd need 
some help just to learn if it's feasible or not...  (Any volunteers?)

> I said what I said. Look BSD/X11 are valid licences and sometimes things 
> work out to everybodys advanage. If thats the way you want to release 
> your code/patches fine but we went though this before in the original 
> licence debate.  LGPL give's a lot of leeway for proprietary components. 
> This trading however is designed to make the LGPL tree meaningless and 
> the reason for the licence switch was because things were not working out.

At least trading can force them to give back something, instead of just 
taking.  How much would depend on the parameters of the trades.

> But trading makes the LGPL go away...  catch 22...

Trading doesn't make the LGPL go away.  It does place you at a less 
demanding level than strict LGPL compliance does, which in turn places you 
at a less demanding level than strict GPL compliance.  It's all a question 
of degree.  At what point do you "take your ball and go home"?  When it's 
not to your benefit (e.g. LGPL + trading) or whenever someone disagrees 
with your methods at all (e.g. GPL), or somewhere in between (e.g. LGPL)?

> No. This is the time to say no.  "Come on just this once..." Does not 
> work for an argument.

The argument was effectively that making the trade this once would be a 
path to the dark side, and therefore it couldn't be risked.  I find it hard 
to believe that a trade or two could have such a corrupting effect.  Is it 
really so hard to refuse trades in the future, just because you accepted 
some before?  How is that any different, really, than switching to a more 
restrictive license after using a permissive one before?

> Brevity is the soul of...

Yeah, so why did you quote large sections of my message that you weren't 
even replying to?  At least I only quote the parts I'm replying to, for 
the sake of context...

Deven