Installshield 6 (inter-proc) patches

[Geoff Thorpe]

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