Dr. Seuss, licensing, and WINE

[Brett Glass]

Rick Romero (rick at valeoinc.com) writes:

>As long as I'm sending this, I might as well make a comment on the
>license.  We all know money makes the world go round.  If the current
>license makes WINE more enticing to businesses, it should stay with that
>model.  If the LGPL encourages investment (time or money), then WINE
>should move that way.  IMHO, it appears the current license is best in
>the long run.  

I agree.

>The biggest issue I've seen so far is people ego's going
>out of control when they've shared their work with the public, and
>someone else hasn't returned their share (and possibly making money off
>of it).

Perhaps a simple economic analysis would help to assuage those egos.

If WINE is available at no cost to any user, its market value as a product
(defined as what a willing buyer would pay a willing seller for a license
to use it) is zero. No one will pay money for something that's readily
available for free. (They might pay a small amount for the service of pressing 
it onto a plastic disc, but with today's Internet there's no need even to 
do that.) Yes, its intrinsic value is higher, but what matters to users
is market value -- what they have to pay to get it.

Given that the market value of WINE, as distributed at no cost over the
Net by the WINE project, is zero, anyone who hopes to sell a version for 
money must add sufficient value to get users to pay for it. This added 
value must not only be worth the money that customers pay (or word will 
get around and the company will make no sales) -- it must also be enough
to overcome the transaction costs that the user incurs (filling out a Web 
form, paying shipping costs, waiting for delivery, worrying about credit
card fraud, picking up the package at the post office, etc). And the seller 
of the value-added product will have a tough time convincing the user that 
the added value is sufficient to warrant the purchase. Is the no-cost version
"good enough?" As WINE improves, it will be -- for more and more users.

Thus, anyone who hopes to create a value added version of the product has
a tough row to hoe. He or she must add a LOT of value -- and also provide
support services, infrastructure for distribution, a sales staff, marketing,
and much, much more. And he or she must stay ahead of the no-cost version,
which over time will likely duplicate the most important value added 
features of the commerical release.

Finally (and most importantly), if users DO buy the value added product, 
every cent they pay will be not for the original product (whose market value, 
as entioned above, is tautologically zero) but for the value added by the 
vendor. Thus, no developer of WINE can claim that the vendor is "making money
off of" WINE. EVERY CENT will be due not to what the WINE project did, but 
to the value added. If the vendor is able to make money at all (and it's a
long shot), he or she thoroughly deserves it. And every copy sold will 
benefit the WINE project, because the project's reputation will be enhanced 
by the vendor's success and the vendor will become more and more able to 
contribute code back to the project. (The vendor MUST, of course, retain 
some of its code so as to provide unique value; otherwise -- again -- no one 
will pay and everything falls apart. But at the same time, it benefits from 
contributing code with less strategic value, because the project will maintain 
it.)

It may be that the vendor won't be equal to the task of adding sufficient
value to stay in business. But if he or she does, it's a win/win. The
project benefits from an enhanced reputation and from code that's returned
to it because it's in the vendor's interest to do so. It's thus in the 
project's interest to help, not hurt, the vendor.

The (L)GPL destroys this delicately balanced symbiotic relationship by making
it impossible for the vendor to add unique value. As a result, the scenario
described above can't happen, and it's a lose/lose rather than a win/win. The
only entity that wins is the FSF, whose stated purpose is to prevent any 
commercial software vendor from surviving.

--Brett Glass