Re: Again: list of advantages of the xGPL

On Thu, 13 Jun 2002, Roland wrote:

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

I agree, it contributes to a sense of security.  I just don't think that 
constitutes an "atmosphere of trust" -- you can be secure knowing that you 
have the law (and the force behind it) on your side, without trusting...

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

Ideally, a city that doesn't NEED police in the first place.  (Granted, 
that's not likely to happen.)  If you could truly trust everyone, police 
would be unnecessary.  Since you usually can't, they ARE necessary.

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

Competing code would have to be halted willingly -- if there's no reason to 
expect the code to be released, competitive development should continue...

How is this a flaw in the BSD license, per se?

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

I don't know what you mean by this.

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

That can happen for strategic business reasons, irrespective of the merits 
of the license.

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

So?  Maybe it was a strategic business advantage to them.

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

Would the Transgaming situation have played out much differently under the 
LGPL, though?  If they wanted to follow the "Street Performers Protocol" 
under the LGPL, they'd be unable to release ANY code until meeting their 
threshold.  How would this have really been an improvement?

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

It's easy to see the advantage to the community, IF development happens 
under the xGPL.  That's a big "if", though.  The question is what advantage 
it has for whoever is PAYING for that development, and that's less obvious.

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

Yes, it's an incentive for the GPL community to try to become dominant, 
just like Microsoft's interests are served by trying to become (and remain) 
dominant.  If GPL code can achieve monopoly-style advantages, it will be 
more powerful, obviously.  It will also be more dangerous.

The question is, what are the incentives to fund new xGPL development?  
(The incentives for exploiting previous xGPL developmenbt are obvious.)

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

That's better than never getting it.  And you're free to write it first and 
not wait on them...

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

True, but the natural inefficiencies of maintained forked codebases tends 
to mitigate against this to a certain degree, while the increased profit 
incentive encourages adoption by proprietary interests, who might tend to 
release non-strategic code back to the public project.

Back to the original question: which is better, 100% of a smaller pie or a 
fraction of a much larger pie?

Deven