Re: BSD bad for proprietary development too (was: Re: Vol 1 #154 -10 msgs)

Deven, I'm CC-ing you because you and Sean ask basically the same
question, and I would like to use some of this message as reference
material in the answer.

"Sean C. Farley" wrote:
> 
> On Fri, 14 Jun 2002 12:35, Greg Alexander wrote:
> 
> > [email protected] wrote:
> > > Date: Fri, 14 Jun 2002 07:57:04 -0500 (CDT)
> > > From: "Sean C. Farley" <[email protected]>
> > > To: [email protected]
> > > cc: [email protected]
> > > Subject: Re: wine-license digest, Vol 1 #140 - 9 msgs
> > >
> > > On Thu, 13 Jun 2002 17:03, Greg Alexander wrote:
> > >
> > > > [email protected] wrote:
> > > >
> > > > > THEN DON'T USE GPL CODE IN YOUR SOFTWARE.
> > > > >
> > > > > If the competitive advantages of keeping your code secret outweigh the
> > > > > difference in cost of being able to leverage existing GPL code, then write
> > > > > your program from scratch and keep it proprietary!  If the competitive
> > > > > advantages DON'T outweigh the cost savings of leveraging existing GPL
> > > > > code, then don't whine that the GPL comes with strings attached, because
> > > > > your application wouldn't have gotten written anyway if the GPLed code
> > > > > hadn't been there!
> > > >
> > > > And, BTW, I can potentially make a boatload of money if I can sell you a
> > > > proprietary library that provides enough of the functionality of the GPL
> > > > code at a price that makes it worth your while to write that software,
> > > > since you're probably not the only one faced with this problem.
> > > >
> > > > You see, if the GPL becomes dominant, there becomes a demand for
> > > > proprietary/commercial implementations of GPL code, just like there
> > > > currently is a demand for GPL implementations of proprietary/commercial
> > > > code.  The two markets complement each other nicely.
> > >
> > > Those implementations will have to have all of the developers' copyright
> > > agreements to allow for sale of said code.  Only companies with
> > > exclusive copyright over the code base will be able to sell the code.
> >
> > I think you may have misunderstood the scenario.  I was describing how
> > in a GPL-dominated world there is still work for most software
> > developers, but in a BSD-dominated world there is less work (although it
> > may be distributed in a way more beneficial to society, this is a
> > different issue).  In other words, the BSD-license is just as bad for
> > proprietary software developers as the GPL.
> 
> I did misunderstand what you were trying to say.
> 
> > Scenario A:
> >
> > A group of open source developers G produces a number of software
> > packages, including the software library libG.
> >
> > Company X wants to produce a piece of software SoftX that uses the
> > library LibG.  Company X wants to make SoftX proprietary but they can't,
> > because that library is under the GPL.
> >
> > This is a business opportunity for company Y, which happens to produce a
> > proprietary library LibY, which provides much of the functionality
> > available in LibG, but sells licenses for proprietary software.
> >
> > Company X can now produce and sell their proprietary product SoftX, and
> > company Y sells a LibY license to X.
> >
> > This a business opportunity for both company X and company Y, which sell
> > licenses, and they both can sell product licenses even in a GPL-dominant
> > world.
> 
> Even with Apache and modssl, Stronghold still exists.
> 
> > > > In fact, in the above scenario it would be the BSD/X11 license that is
> > > > interfering with the _library developer's_ ability to make a profit off
> > > > of their code.
> > >
> > > How?  The BSD/X11 license can be integrated with commercial as well as
> > > GPL code.
> >
> > Scenario B:
> >
> > Suppose that there exists another library LibB, which contains most of
> > the functionality of LibG and LibY, only under a BSD license.
> >
> > With libB in existence, company Y will no longer be able to sell copies
> > of LibY, because LibB is effectively a dumping competitor.  Company X
> > will choose LibB over LibY, because the licenses offered for LibY will
> > be substantially more expensive than simply using the code offered for
> > free in LibB.
> 
> This is not necessarily true.  Company Y may still have a better library
> or at the least have better support than an open-source project.

In this case, the company is making money on its value-adds, not on the
library itself.

> In addition, Company Y could enhance libB and sell it, therefore,
> negating any effects of dumping.  OTOH, if it was GPL'd, this dumping
> effect would not be able to be negated.

If the library is GPLed, no dumping actually occurs in the market for
"libraries that can be used in proprietary software."

That was the point of the original message.  If company Y extends libB
and sells it, they are making money on their value-adds, not on the
library itself.  In effect, they are changing their business model to
act as company X in the original transaction.  They are becoming a
consumer of the original library instead of a producer.

In either the GPL or the BSD world there are opportunities for
proprietary consumers of a library, it's just that in the GPL world the
library must be purchased from another proprietary software producer,
resulting in more software jobs overall.  This applies whether the
consumers are end-user application developers or if they are developing
a proprietary library which utilizes the library which they are
consumers of.


The only group I can think of that are hurt by a world with a
significant GPL codebase are proprietary plugin producers.  The more
"viral" restrictions of the GPL view proprietary plugins for GPL
end-user products as "derivative works," when linked with the original
GPL product and thus makes producing and using such plugins illegal. 
With BSD-licensed software proprietary plugins would be legal.  Since
end-users are likely to prefer GPL and/or BSDL products, this is a case
where a market is harmed by the GPL over the BSDL.  The custom for the
GPL is that most software produced under the GPL that is intended to use
plugins includes exceptions for the use of proprietary plugins. 
However, this cannot be assumed to be the case, and thus this IS an
economic disadvantage of the GPL.

> > Company X can still sell SoftX (maybe even at a higher profit), but
> > company Y no longer sells any licenses, and thus there are fewer
> > software jobs overall.
> 
> But more jobs than using the GPL in a similar situation.

How do you come up with that?  If I start out with jobs in company X and
company Y then remove the jobs in company Y, how am I left with more
jobs?

GREG