Licensing question

Chris Travers chris at metatrontech.com
Sun Mar 7 17:32:36 UTC 2010


On Sun, Mar 7, 2010 at 1:16 AM, Mahesh T. Pai <paivakil at yahoo.co.in> wrote:
> Mark James said on Sun, Mar 07, 2010 at 07:17:31PM +1100,:
>
>  > Yes, no matter how companies try to dodge, due to statutory requirements,
>  > commercial software purchasers usually have a greater guarantee of quality
>  > than FOSS software users.
>  >
>  > But this is not often tested in court. The bottom line is that that one
>  > will usually work harder for one's customers than one's (free) users.
>
> Yes, no matter what we spam the mailing lists with, commercial
> software purchasers will not get protection of statutory provisions
> unless they go to court.

I really wonder what claims one would have, given that typical EULA's
disclaim the major implied warranties (fitness for a particular
purpose, etc).  The decision to offer any sort of warranty or not
rests with the developer.  For example, when I worked at Microsoft,
the "warranty" was something like "installation support plus support
for 90 days after" for consumer software and there was no warranty
support for server software.
>
> But this is of course, not tested by statistics. The bottom line is
> that because I do not have time to handle bugs and complaints and
> carps from my unpaid users, I will tend to provider my users with
> better software.

I don't know that the evidence supports the idea that open source
software is necessarily more buggy than proprietary software.  If we
look at security hole metrics, for example Veracode's recent report,
they seem to be about the same.  The fact is that reliable, secure,
robust software begins in the design stage with solid design
decisions.  Certainly some FOSS programs are buggy, but so are some
commercial apps.  I have even known one FOSS developer to refuse to
fix bugs reported by customers with proper support accounts, but I
suspect this is less common in the FOSS world than at, say, Microsoft
(where bugfix effort is strictly limited to one team and where most
likely making enough noise will get it fixed.... years later.... in
the next release--- see IE7 handling of button elements).

The issue Mark was trying to resolve is a business model issue, which
IMO is entirely orthogonal to the software quality issue.

I am going to offer a different perspective here as well on mass
production.  I personally don't see anything "evil" about charging
license fees, but I think that mass production is highly overrated.
It certainly works very well for some products, but I don't think that
small developers are in much of a position to capitalize on it today.
Trying to make one's money off license fees poses greater risks for
small developers.  Although the maximum rewards are often smaller as
well, I think the risk to reward ratio is higher for a small developer
doing open source work in many cases (not all cases, mind you--- it's
HARD to make money off consumer segments with FOSS so perhaps
consumers are better off with more choices for proprietary software).

Basically when you look at the economics, the way a company like
Microsoft develops software is that they pay a bunch of people to
write it.  They aren't earning money during that time for that
product.  When the product is finished, they try to recoup their
losses and make a profit by requiring that people charge money for
that product.  Not all Microsoft products ever make a profit (Bob, for
example, never did), but Microsoft cross-subsidizes this and produce a
wide variety of software which it hopes to eventually make money on,
directly or indirectly.

Startup businesses which do this either have to rely on savings of the
founders, startup capital or the like during the initial development
phase since they likely do not have other revenue streams during this
phase.  Afterwards, the hope is the same:  find enough customers to
make this money back and support development of the next version.
However, in this case, you are starting in a hole you hope to dig
yourself out of.  The more complex the project, the deeper the hole.
The more competition, the harder it is to dig out of that hole.  In
the early days of the industry, the calculation would probably have
been different, but today, I think it is extremely difficult to make
such money back as a small development shop without cutting all sorts
of corners in the development and QA process.

FOSS does this differently.  A small developer can often charge for
development up front, and then use this work to find more customers.
It's true this doesn't necessarily scale as well, but it in fact
scales in different ways.

I am involved in FOSS not because I see it as fundamentally ethically
superior, and I don't begrudge other developers the attempt to earn
money off their hard work, but rather because I see it as the best way
for the little guy to find a niche that provides a sustainable source
of income.

I think what Mark is trying to do is to sell his library to others who
will then charge money for finished products.  Since he is upstream,
that seems logical, but I make finished apps.  LedgerSMB isn't going
to compete head-to-head with Quickbooks if folks want to buy a
commercial solution.  Instead, we can offer something Quickbooks
cannot offer, which is an open source, customizable, etc. which allows
businesses to spend some money optimizing their own operations
(building the software workflows around their processes, not building
their processes around the software workflows).  Many of these
customizations are small ($300 range).  A few are large ($50000 or
more).  When 2.0 comes out, it will be suited for both the low end and
mid-range.

Best Wishes,
Chris Travers



More information about the License-discuss mailing list