Re: Again: list of advantages of the xGPL

On Mon, 15 Jul 2002, Roland wrote:

> At 11:24 AM 7/15/02 -0400, Deven T. Corzine wrote:
> 
> >Stagnant, inactive projects are different -- they don't have much inherent
> >advantage for contributing back to the open project, if it's not really
> >moving much at all.  Such projects may need the added protection of the GPL
> >or another "copyleft" license to prevent abuse.
> 
> Exactly, I think WINE fits in this category.

Are you sure?  Wine seems pretty vital and active.  Freshmeat ranks it with 
a "vitality" score of 32.08% right now.  Sure, the Linux kernel ranks at 
81.50%, but Apache only ranks at 2.44%.  No, I don't think Wine needs the 
protections of the GPL as much as many less active projects do...

> Right. I never wanted to say that the GPL is ALWAYS THE best license. But 
> it might be a good choice in some cases.

I've never denied that.  I just don't want to see it become the only choice 
that's reasonable to make...

> > > If I understood correctly, under the LGPL they would HAVE TO release 
> > > their improvements.
> >
> >Then you understand incorrectly.  Neither the LGPL nor the full GPL demands
> >that you release your modifications.  It only requires that the source be
> >available to those to whom you distribute a binary.  As I said above, this
> >would mean that Transgaming would have been unable to release ANY code (in
> >source OR binary form) until meeting their threshold.
> 
> AFAIK the TG threshold was the userbase of 20,000 subscribers. How do you 
> achieve such a userbase without releasing any binaries? Would you tell your 
> customers: pay now, but you will only receive the program when 20,000 have 
> subscribed.

You'd pretty much have to, or that 20,000 number would be meaningless.

Obviously, this would suck for the subscribers who pay and don't get any 
benefit until that threshold is reached -- if it ever is!  Yes, it would 
invite criticism eventually that their code is vaporware.  But withholding 
the code entirely would be the only way to possibly implement the "Street 
Performer Protocol" using the GPL or LGPL.  (And no, I'm not convinced that 
they could do it successfully, unless they could generate so much interest 
so fast that the 20,000 number is reached in short order...)

> >What business justification would there be for using the GPL in this case?
> 
> The question is, how much would the company have to invest in order to make 
> the program from scratch, without the available GPL codebase. If this cost 
> is too high, it might well choose to use the GPL codebase, inspite of the 
> advantages for its competitors.

Yeah, that's the monopoly advantage, basically.  If the GPL codebase can 
overwhelm the cost of redevelopment, it effectively becomes impossible to 
compete with.  That's the goal of the GPL, and if it succeeds, it will take 
away all freedom from developers who don't want to use the GPL (because not 
using the GPL is no longer a viable business option when it becomes too 
difficult to compete against that GPL codebase).

This still ignores the question of why someone should release that code 
under the GPL in the first place.  Sure, if you have a huge project like 
Linux already under the GPL, it will make more business sense to improve it 
than to redevelop a proprietary version.  But if you're developing some new 
software, that gives you a competitive advantage, and existing GPL code is 
not a significant factor in the development time it will take, the original 
question still applies -- why should a business release such code?

> > > Another advantage is for other companies in the same business (potential
> > > paying customers). They could use that solution without having to pay
> > > anything. So I see a lot of companies profiting.
> >
> >This is exactly what would be likely to bother the paying customer -- that
> >his rivals can get the fruits of his fully-funded efforts, for free.  That
> >can turn a strategic advantage (code whose benefit your competitors don't
> >have) into a strategic disadvantage (equal benefits with one-sided costs).
> >
> >Clearly the competitors can profit from this situation.  That wasn't in
> >question -- my question was whether the PAYING customer should consent to
> >the release of the code they've paid for.  In many cases, the appropriate
> >business decision will be NO.
> 
> Exactly. And that's where the GPL has a major advantage over the BSDL. If 
> the program is BSDL, then the company probably won't release any code. If 
> it is GPL the company will have two choices: reimplement everything at a 
> huge cost. OR extend the existing code and submit back the changes. I bet 
> that in many cases they will choose the second option.

You're still assuming that the company is just extending some existing code 
in a relatively minor way.  I'm talking about the case where a company is 
NOT depending on existing code in any significant way, where their new code 
dwarfs any existing code they might build upon.

And the question remains.  If a company pays for a lot of new development, 
not just a little extra work on a large existing codebase, but to CREATE a 
large NEW codebase, what business reason do they have to GPL that code?

> Please also keep in mind, that in the case the company does use the 
> software only for internal use, it doesn't have to give the source, since 
> it is not distributing any binaries.

That's not clear.  The GPL doesn't address whether internal use within an 
organization is "distribution" or not.  It could be argued that giving the 
code to another person in your organization gives that person the right to 
release it to the world...

> >I don't want the GPL to be the only game in town.  We should have choices.
> >If the "amount of xGPLed software [is] as big as possible", then ultimately
> >we won't have real choices anymore, because the non-GPL choices will be so
> >pathetic by comparison that only a fool or a zealot would choose them...
> >
> >THAT is the danger.
> 
> Although that danger is quite hipothetical. If we look at our world today I 
> see far more danger coming from private companies like M$.

Today, that's very true.  But the GPL's creeping dominance is inexorable.  
Even Microsoft could make a business mistake and go out of business, but 
the GPL codebase will just keep growing, even if it leaves a trail of 
broken companies behind it.

Yes, the GPL danger is currently hypothetical.  But it's not irrational or 
implausible.  It's a potential danger, but not a foregone conclusion.

> > A large enough specific need can drive development, but what about a 
> > large but diffuse need?  What if lots of individual users would like a 
> > feature but it is of no interest to a company?  No single individual is 
> > likely to fund development.  At best, you can cross your fingers and 
> > hope a single developer will just decide to implement the feature.
> 
> If there is a large userbase probably one of those users will finally 
> implement the feature himself. Its all statistics. In a large userbase 
> there will probably be
> a) several programmers
> b) of whom at least one will be willing to implement that feature

That's a convenient theory, but a flawed one.  The history of free software 
has shown little interest by the programmers to apply the ease-of-use sort 
of polish that unsophisticated end users crave -- and that's not surprising 
since the programmers don't find the unpolished version difficult to use.

Since the few programmers among the users are far more sophisticated than 
the average user, it's incredibly naive to assume that one of those more 
sophisticated programmers will decide to expend the effort to polish the 
code for the benefit of those "lusers" without being paid to do it...

> Also in quite some open source projects developers eventually listen to 
> users and if the need for a feature is big enough it will be implemented 
> sooner or later.

Again, wishful thinking.  Yes, it may happen, but there's certainly no 
guarantee that it will.  Paying money to someone to have something written 
is a far more certain path to implementation.  Coming up with that money is 
a more difficult question, if only end users care.

> Btw, the same problem applies to closed source. We use one of those 
> softwares in this company. On a newer version they took away a feature we 
> need here. We can't switch back to the old version because it's an online 
> software, the old version won't work. I phoned the company and asked why 
> they took away that feature. They replied: Oh, there wasn't enough need for 
> it. It will "eventually" be there again, if more customers NEED/WANT it. 
> So...happy waiting, we are just a small company, can't afford to pay them 
> for reimplementing it.
> We now have quite some extra work here to do because of this missing feature.

Yes, that sucks, but having that product under the GPL would only help you 
if you have the skills and time to code that feature, if you don't have the 
money to pay for it.  My question was how to come up with money if people 
lack the skills, time or motivation to do it themselves, so as to pay for 
someone to write the code...

> >However, my question was about incentives to FUND new xGPL development.

Funny, you didn't bother to answer this one.  You just turned a blind eye 
to the core question here.

> >This is true.  The problem is that hiring developers to do this work isn't
> >cheap, because the necessary skills aren't so easily acquired.  That why we
> >have far more users in the world than programmers.
> 
> Ohhh you just said that programmers will always have good job opportunities.

I believe it will be a very long time before there's no need at all for 
programmers.  However, our profession could still be devalued greatly by 
the GPL, should it become a monopoly influence.  There may always be a need 
for programmers, but what if the need is much less because of the GPL, and 
the few remaining programming jobs become low-paid, but still hard work?

> >Certainly.  Of course, don't be surprised when another company looks at
> >what happened with Transgaming and decides that the "Street Performer
> >Protocol" is unworkable -- and sticks with closed software instead...
> 
> And thats also what happened to the WINE project. People realized that 
> the BSDL didnt work as expected, and they decided to switch to the LGPL.

It's true that the BSDL didn't force TG to release their code.  But the 
"harm" suffered thereby seems somewhat hypothetical in nature.  Maybe it 
truly exists, or maybe it was an illusion that was perceived as reality.  
How can we be certain either way?

> >Apache is under a very fre BSD-like license, and they're getting a LOT of
> >development -- would the GPL really help Apache?  I doubt it...
> 
> True, but would it hurt Apache? I doubt it...

It might discourage companies from contributing, even if there's no real 
effective difference, because many of them are hostile to the GPL...

Deven