Re: Again: list of advantages of the xGPL

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.

>My point is that it's not necessarily inherently advantageous to use the
>GPL, but that it's context-dependent.  While the GPL may appear to be a
>strategic advantage to company A, it might be a disaster for company B.
>
>At best, then, you could cite "possible" advantages in such a situation...

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

> > 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.

> > One advantage I see is, that because ALL the code is released back to the
> > community the PAYING Customer will benefit from all improvements and
> > BUG-FIXES made to that code.
>
>If, and only if, someone else does some extra work on the code.  What if
>the paying customer paid a lot of money to get ALL the features they wanted
>(so improvements might not matter) and received mostly bug-free code?  What
>if that code works so well that it doesn't really need much more investment
>in improvements or bugfixes?
>
>What if that code provides a strategic business advantage over the paying
>customer's competitors?
>
>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.

> > 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.

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.

>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$.

> > Like any incentive to fund new software development. When there is a big
> > enough need for it.
>
>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

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.

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.

>However, my question was about incentives to FUND new xGPL development.
>
> > And honestly I don't believe that we will ever reach the point where there
> > is no need for further software development. I see it here at the company.
> > Mostly I develop software for trivial tasks like reading a text file and
> > sending the data to a database. There will always be need for specific
> > software that solves very specific problems.
>
>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.

> > > > Yes, like TG releasing D3D code in five years or so...
> > >
> > > That's better than never getting it.  And you're free to write it first
> > > and not wait on them...
> >
> > Yes, and I'm free also to put that code under the LGPL :)
>
>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.

>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...

Roland