Re: GPL vs. sweatshops (was Re: Bias)

On Tue, 18 Jun 2002, Tony Lambregts wrote:

> GPL is accused of being "viral" because the designers of it did not want 
> GPL'd code used in proprietory products period. This aspect of the GPL 
> was designed as a posion pill (as a deterent) and it does the job it was 
> meant to do.  This license has the most protection for the community of 
> volunteers.

It's not the most protection for the community of volunteers who make their 
code freely available -- it's the most protection for the GPL community, 
which isn't the same thing.

The GPL's approach is basically "play the game by my rules or I'm going to 
take my ball and go home!"  This may be legitimate, but ultimatums like 
this are often viewed as immature and antisocial.  If such behavior is 
disdained on the playground, why should it be revered among professionals?

The GPL does a very good job of keeping GPL code from being incorporated 
into closed proprietary products.  It also limits the ability to integrate 
into other open projects, such as MPL-licensed ones.  This is undesirable
collateral damage, and detracts from the nominal goal of the GPL: the free 
and open sharing of code.  However, there's a good argument to be made that 
the nominal goal is secondary, and that the primary goal is actually to 
utterly destroy ALL closed proprietary software...

> X11/BSD has the least restrictions as far as business go but has the 
> least amount of protection for ensureing the community is compensated.

This is true -- it's clearly easy for a closed proprietary vendor to take 
unfair advantage of BSD/X11 code.  On the other hand, this vulnerability is 
exactly the reason why such vendors will be attracted to using the code, 
and if they depend on the sale value of their software, they certainly will 
never use GPL code.  At least if they use the BSD/X11 code, they might give 
back some non-strategic code, though surely not strategic code.  Does the 
competition of a closed product derived from open code outweigh the value 
of these possible non-strategic contributions?  It probably depends on the 
particular situation.

> Mozilla uses MPL and while there was some inital complaints about it not 
> being GPL it seems that things are working out ok for both netscape and 
> the open source community around Mozilla.

The major complaints about the MPL were from GPL zealots who believe that 
everything must be GPL to be "free", and Stallman, who demanded that the 
MPL change to become GPL-compatible -- despite the obvious solution that 
the GPL should be changed to be compatible with licenses (like the MPL) 
which are in the same spirit as the GPL...  (Stallman refuses because it 
would be too difficult to define and he's afraid of opening a loophole.)

> Each of these company's have found a business reason for supporting 
> these projects and the open source communities seem to be satisfied with 
> them.  These are win-win situations because both sides feel they are 
> getting what they want.  Even in the case of Apache it worked because 
> both sides are ok with the situation.

Keep in mind that Mozilla and OpenOffice were commercial products (Netscape 
and StarOffice) that were released freely as a calculated business risk to 
take down Microsoft.  AOL/Netscape and Sun aren't getting a direct return 
proportional to their costs involved, but instead they're betting that if 
they can weaken Microsoft's hold on the market, it will be worth the huge 
loss they've incurred by releasing that commercial code.

Apache is one of the few open projects contributed to by companies for its 
own sake -- and that's because it grew as a grassroots community effort 
among webmasters before management become cognizant of what was happening.  
By the time management realized what value was being added, it was already 
becoming clear that proprietizing their Apache version would be likely to 
cost them a lot because of the very active open project -- so unless their 
additions are extremely valuable, it makes business sense to keep the new 
code as free as the old, so it remains integrated.  (The only case I can 
think of, offhand, where it was compelling to make a proprietary fork was 
for SSL-enabled Apache, which is no longer a strategic advantage...)

> As far as I am concerned Wine could have chosen MPL/SISSL/LGLP/WineOrg 
> and I would have been OK with the result.  

I think any license choice is valid, but it's best to understand all the 
ramifications of the choice, as much as possible...

Deven