Re: Again: list of advantages of the xGPL

At 10:46 PM 6/12/02 -0400, Deven T. Corzine wrote:
>On Wed, 12 Jun 2002, Roland wrote:
>
> > Ok, here is a small list:
> > Advantages of the xGPL in comparison with the BSDL:
> >
> > 1) Create a good atmosphere of trust on projects. Everyone is happy 
> sharing
> > because he knows that all modifications will flow back. No trading takes
> > place which could slow down the project and generate loss of time and 
> trust.
>
>Somehow I have a hard time reconciling this notion that xGPL creates an
>"atmosphere of trust" when it uses legal leverage to require that all
>modifications be returned to the community.  If you truly have an
>atmosphere of trust, shouldn't you be able to trust them to give back
>without any arm-twisting involved?

Let me put it this way. The fact that there is a license regulating the 
exchange of code gives everyone more security. He knows that everyone has 
to return all changes back, so he contributes freely. Think about all the 
code that CodeWeavers released after the LGPL switch. They no longer have 
to fear that another company uses that code without giving anything back.

As an analogy lets think of a city with and without police. Where would you 
like to live?

> > 3) Code development will no longer be halted on the hope for future
> > releases of proprietary code. Think about DirectX.
>
>This is the only example of this nature I've heard.  Is it an isolated
>example or is there a pattern here?  Do you have similar examples to
>establish an actual pattern?  One example may be worrisome, but isn't
>necessarily convincing in and of itself.

The fact that this MIGHT happen under the BSDL is already an argument 
against it. Even if in practice I only know this one example(I don't know 
that many projects on the other hand) it is enough to show this weakness in 
LGPL.

> > 4) With the BSDL people lose interest in coding if some functionality is
> > already implemented by a proprietary fork. Think about Marcus losing
> > interest in game support for Wine. No one wants to reinvent the wheel.
>
>Open-source developers reinvent the wheel all the time.  Almost everything
>done for the GNU project has been with the aim of reinventing Unix.  Why
>generalize about this point when there are many, many counterexamples of
>developers willingly choosing to reinvent the wheel?

The same point I posted above.

> > 5) Increase the amount of available free software. I think some companies
> > will start using/improving xGPL software when the cost of reimplementing
> > it is too high.
>
>This is open to debate.  There is ample evidence that many, many companies
>avoid the GPL like the plague, and therefore the GPL gets back 100% of
>nothing at all, in many situations.  If GPL development is avoided, then

The fact is that many companies contribute to GPL projects, like IBM:
http://news.gnome.org/gnome-news/966964532/index_html

RedHat, etc...
And please don't forget that one of the driving forces of switching WINE to 
LGPL was a company!

>there's nothing to get back.  BSD code, on the other hand, seems to often
>(but not always) get something useful back from proprietary companies, even
>if it's typically an unbalanced exchange in the favor of the proprietary
>company.  Still, a small portion of a larger pie is better than 100% of a
>tiny pie.  The jury's still out on this point.

I'm not saying the BSD has not its advantages, but in the case of WINE it 
seems that many where not happy with what was released by TG, at least 
there was a lot of debate generated around this.


>As such, it's not clear just how often such significant GPL benefits are
>received by the voluntary actions of the preferably-proprietary companies.

Ok, maybe someone has some better up to date examples?

> > 6) In the case of bespoken software: If the developer uses a xGPL code as
> > basis, changes MUST be returned. If the license was X11 the hiring
> > company could demand: Don't release the code back to the public. Ask the
> > guys from CodeWeavers about their experiences in this regard. This will
> > also increase the amount of free software.
>
>I'm not sure exactly what you mean by "bespoken" software.  Requested
>software?  Claimed or hired beforehand?

Yes exactly. I was refering to the case when a company A hires a software 
company B to produce some specific software for company A. If there is a 
xGPL program that already fulfills part of the functionality, B can deliver 
the software at a much lower cost, by just extending that software. With 
the xGPL the community will get back everything. Of course A could decide 
it doesn't want to release everything back, in which case B had to either 
start programming from scratch(at a much higher cost) or try to find an 
equivalent software under BSDL. In this case I see a clear point in favour 
of the xGPL, at least from the viewpoint of the community.

>Anyway, that first "if" is a very big "if".  Since it's common for many
>companies to avoid the GPL, there may be no GPL-based changes to return,
>which means no increase in the amount of free software.
If the company will avoid any xGPLed software the development cost will be 
much higher since it cannot use the large amount of available xGPLed 
software. This is also a reason why it is good to make the amount of xGPLed 
software as big as possible. At least from this viewpoint.

>Still, I won't question that the natural inclination of companies will be
>at first NOT to return any code under the BSD license.  However, over time
>they're likely to realize that the cost of maintaining a code fork for any
>non-strategic code is foolish to bear, and the benefits are such that
>releasing that code is often the best business decision.  It's true that
>strategic code won't be release.  (Although it might eventually become
>non-strategic code and finally be released at that point.)

Yes, like TG releasing D3D code in five years or so...

> > 7) No more reinventing the wheel. With a BSDL you have the possibility of
> > several private forks reimplementing the same functionality because there
> > is no enforcement to return the code.
>
>This can happen in any area.  GPL projects aren't immune from forking.
>(Consider GNU Emacs vs. XEmacs.)  Regardless of the license, forks aren't
>terribly common in practice, because it divides effort and takes more
>effort -- things which are best avoided without a compelling justification.

The difference is, that if an LGPL project forks, the license is usually 
maintained, so every fork can also benefit from the work in other forks. 
With BSDL this is not the case, since some forks can be proprietary.



Roland