Re: WineX and the AFPL

On 30 May 2002, Alexandre Julliard wrote:

> "Deven T. Corzine" <[email protected]> writes:
> 
> > What's past is past.  Why not look to the future and do what's in the best 
> > interest of the Wine project?  Quid pro quo trading of patches doesn't 
> > violate the _spirit_ of sharing enshrined in the LGPL, even if it doesn't 
> > match the letter of the license.  As long as trades are fair and equitable, 
> > how could it be a bad thing, or endanger the future health of the project?
> 
> The trade isn't fair at all. As I tried to explain, the value to the
> project is not in a specific patch, or in a number of lines of
> code. It's in the collaboration that allows everybody to build on each
> other's code. *That* is what makes the open source model so powerful
> to build software, and that is precisely what Transgaming is hurting
> with their release policy.

I agree, but you're treating it as an "all or nothing" situation.  If you 
trade some patches, at least you and everyone else will be able to build on 
THAT code, which leaves you better off than you started.

We'd all love to see full-time programming work be done for free software 
on a voluntary basis, but programmers have to eat.  So most of us have a 
day job.  A few of us may be lucky enough that our employer allows us to 
spend our working hours on free software, but for most programmers, it 
comes out of their free time instead.  Generally, this means part-time 
effort (if any) being spent on free software, due to time constraints.

Should free software projects shun the contributions of part-time hackers 
just because they also write proprietary software during their day jobs?  
Or should they take what they can get and be happy to get something rather 
than nothing?  Should it make a difference if the proprietary software 
written at the day job could benefit the free software project if released?

The LGPL collaboration will happen with or without Transgaming.  At worst, 
they simply won't contribute to it at all.  Obviously fully contributing to 
collaboration would be ideal, but isn't partial collaboration better than 
none at all?  Without trading patches, it looks like "none at all" wins by 
default.  Unfortunately, that "winning" option is a lose-lose scenario.

> The important point about the LGPL is that it ensures that *future*
> versions of the code will be available, which in turn allows anybody
> to work on improving the code, knowing that the work they do will be
> useful.

This will always be true of the LGPL codebase, whether or not you trade 
patches with Transgaming or anyone else.  Choosing to trade patches doesn't 
endanger this assurance.  (It doesn't assure that Transgaming's future work 
will be available, but you don't have that assurance now either.)

> If you look at the code Gav is offering it's just the opposite: he
> offers the current version of the COM code while making it clear that
> Ove is already working on the next version (which of course will
> remain proprietary). So this not only ensures that Wine's version of
> the code is already obsolete, but it also ensures that nobody will
> work on improving it since a better version already exists and will be
> released "real soon now". After DirectX it will be another area of
> Wine where all development is dead.

This is a separate question of whether the specific trade he proposed is 
a fair one.  If you don't think it is, demand something better -- that's 
perfectly reasonable.  You could require (for example) that the current COM 
code be release AND the next version as well.  You could even insist on a 
written commitment from Transgaming to release all future versions of that 
COM code to the LGPL codebase.  Whatever makes it worthwhile and fair (to 
both parties)...

Negotiating is one thing -- refusing to negotiate on principle is something 
else entirely.  You can do it, sure.  But what does that gain you?

> And if we start generalizing this patch trading idea, pretty soon the
> code base will be just a set of private modules, each one jealously
> guarded by someone while waiting to get something else in exchange. It
> will completely break down the free flow of code that is the basis of
> the open source development model.

Especially for individual developers, what's the incentive?  For anyone to 
put such barriers in the way of free collaboration, they'd have to think 
they've got something to gain by doing so.  Many of the developers will 
continue to give freely of their work because they have a generous nature 
to begin with.  For the most part, only companies will have an incentive.

Even for companies, maintaining a separate codebase is a burden.  Why would 
they do it without a compelling reason?  If they've got a business model 
that works with the LGPL codebase, they might as well use it.  If their 
business model depends on proprietary extensions to the X11 codebase, then 
they may be unwilling or unable (from a business perspective) to transition 
to the LGPL codebase anyhow.  Doing so might cause their business to fail, 
after which they obviously wouldn't be able to make any more contributions!

A good disincentive against forking would be to always require trades to be 
substantially more beneficial to the LGPL codebase than to the proprietary 
codebase.  For those companies willing to work with the LGPL codebase, this 
gives them a significant advantage in exchange for their willingness to 
share all their code.

For those companies that depend on proprietary code, this would:

(1) Allow the LGPL codebase to benefit from extra work that would otherwise 
    be completely proprietary.  (Half a loaf is better than none.)

(2) Ensure that the grudging contributions coming from such proprietary 
    companies would be substantial in nature, not trivial.

(3) Probably create at least an echo of the synergy that fully LGPL'd 
    collaboration would.  (If the proprietary companies can't thrive, they 
    can't contribute anything at all to the LGPL codebase.)

Forked codebases are always a possibility.  If they're going to happen 
anyway, the main project might as well have a chance to get some benefit 
from the other codebases.  For those companies that have a business model 
that works with the LGPL codebase, they're going to be better off not 
forking in the first place.  Only those with a great need to keep code 
proprietary will bother, and (1) they'll do it from the X11 codebase, so 
you aren't going to stop those forked trees from existing, and (2) the LGPL 
codebase will never get any benefit from that code if you refuse to ever 
trade patches on principle.

There seems to be a potential benefit for both sides (even if less than 
with full LGPL participation), and the dangers are mostly theoretical at 
this point.  People have often worried about forked codebases with the GPL 
(which clearly allows it), but in practice, forks are quite uncommon.

> This would be badly endangering the future of Wine; and there's no
> amount of code that Transgaming can offer in exchange that would
> compensate that loss. So no, the suggested trade is not a fair deal at
> all.

Yes, the loss you describe is beyond compensation.  That doesn't mean it's 
inevitable or even likely.  This is a path where you can turn back at any 
time.  Make a trade.  If it works out better for both sides than a policy 
of "never the twain shall meet", then great!  At worst, you haven't lost 
any more than you would have if the LGPL license change had been delayed.

If you make a trade or several, and it seems like your worst fears are 
coming to pass, then you can always use that to justify a policy change to 
refuse future trading of patches, or to require even higher standards to 
consider them.

No trades you make now or in the future will irrevocably doom the project 
to the nightmare scenario you describe, so it's really not so dangerous...

> Not to mention that it wouldn't be fair either to the other companies
> who have accepted to work under the LGPL terms. We can't ask others to
> release everything they do while allowing Transgaming to release only
> what they feel like releasing. So we would then have to make LGPL
> exceptions for these other companies too, and start negotiating patch
> trades with them, and pretty soon we will be back to the "everybody
> steps on each other toes" model where nobody releases anything if they
> can avoid it.

It would be fair to the companies working under the LGPL because they would 
get the benefit of ALL the code released into the LGPL tree.  Transgaming 
and similar companies, on the other hand, would get only LIMITED benefit 
from the development on the LGPL side, and they would have to PAY for it by 
offering something substantial in return (possibly something significantly 
more substantial than they're getting, if that's the policy) -- which then 
benefits those LGPL companies for free.  What's unfair about it?

> A fair trade would be for Transgaming to accept a real collaboration,
> where each side can build freely on the other side's code, in exchange
> for receiving all the code the community is writing. But of course
> that is precisely the trade we are offering with the LGPL, and that
> Transgaming has rejected. Fortunately just about everybody else has
> accepted that trade, and the resulting contributions will be much
> larger than anything we could hope to obtain with the patch-by-patch
> trading suggested by Gav.

There's a middle ground possible here.  Transgaming would get the maximum 
benefit from the LGPL codebase and other companies and developers by using 
the LGPL and giving up on their proprietary fork.  If that's not compatible 
with their business model, they'll only get a FRACTION of the benefit of 
full LGPL participation by trading patches, and at least it will be sure to 
be worthwhile to the LGPL participants who have decided to get along.  (Or 
they'll refuse the trade in question.)

Suppose Transgaming switched to the LGPL and went out of business as a 
direct result?  Not only would it ruin their company, but it would also 
discourage others from following their route.  Most importantly, the LGPL 
codebase would not receive any continuing benefit from collaboration if 
there's nobody left at Transgaming to collaborate with.

Suppose they keep their current business model and you allow them to trade 
patches on a basis beneficial to the Wine project?  Transgaming might be 
more successful than they would be without trading, and thereby be in a 
better position to contribute more (via trading) to the LGPL codebase...

Most importantly, while the LGPL codebase would get some benefit from 
Transgaming's proprietary work (which will happen whether or not the LGPL 
codebase benefits), ultimately the LGPL codebase is bound to outstrip any 
proprietary fork based on the old X11 code, due to the cumulative effect of 
all that collaboration.  It will do so even faster via prudent trades with 
proprietary companies.

Eventually, the LGPL codebase will become more and more compelling as it 
grows beyond the level that the X11 codebase is at, even with trading.  
Trading patches would only serve to accelerate this process with no cost.
Ultimately, you may find companies switching to the LGPL codebase (and a 
new business model) because they can't keep up with their proprietary fork 
against the LGPL fork -- and the sooner, the better for everyone.  Limited 
collaboration via patch trading now is likely to accelerate the process, 
not impede it.

You seem to be arguing against it on principle on the basis of unrealized 
fears about the worst that could happen.  I think those predictions are 
overly gloomy, and not likely to come to pass.  Even if they would, you 
could halt the progress towards doomsday at any time by changing policy, so 
allowing some patch trading now doesn't force you to stay on that road 
forever, if it really turns out to be so bad.  But if the road turns out to 
be beneficial, you'll have foreclosed the option to no purpose.

Is this really such a dangerous prospect?  Do you really not see the 
potential for long-term benefit, should things actually work out?

Nope, it still doesn't make sense to me...

Deven