[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

Re: Rethinking Licensing (was Re: [ba-ohs-talk] open source +patents = puzzled)


Paul Fernhout wrote:    (01)

> === on micropayments ===
>
> I like your effort towards rethinking. I especially like your question
> at the end regarding the BA value proposition -- that is a good question
> to always revisit periodically for any effort expecting support.
>
> However, sorry, I don't think micropayments are the answer. See:
>   "The Case Against Micropayments"
>   http://www.openp2p.com/pub/a/p2p/2000/12/19/micropayments.html
> The article discusses several reasons, the biggest one is that the user
> cognitive overhead of dealing with micropayments is too high. A
> transaction might cost a fraction of a cent, but it costs you time and
> attention to think about it (even to decide whether to click or not,
> knowing you need to pay), and that makes every micropayment
> fundamentally expensive. The article also suggests several old
> alternatives (Aggregation, Subscription, and Subsidy) to micropayments.    (02)

When micropayments revolve around *use*, I agree that they are
doomed. No way do I ever agree to have something around that is
going to keep charging me forever. The main issue is that I have no
control of my expenses, because I can't keep track of all the little
things that are nailing me all the time.    (03)

But when micropayments consist of revenue-sharing -- so that they
only occur when a purchase decision is made, they have a chance
of succeeding.    (04)

In that case, the end-user never even knows about them. Done right,
the seller can even afford to ignore them, because some fraction of
revenues are diverted as royalties before the income is even seen.    (05)

Assuming that the parameters are acceptable beforehand (for example:
10% of whatever I charge is going to the 10 or 100 developers of the
APIs I use) then I don't particulary need to know or care to know how
those royalties are divided. I just know I'm getting 90% of whatever I
charge, and things are relatively simple.    (06)

That kind of situation turns each of us into a "publisher" who generates
some code on our own while incorporating other code. Any time we
sell something, we pay royalties. If we give it away, then it goes out for
free.    (07)

There is still a lot of room in this equation for problems to arise, though.
For example, developer of Module XYZ may require that:
   a) You can't sell any product that uses it.
   b) You can't give away any product that uses it.
   c) If you sell it, it gets 1% of the revenues, regardless of how
       much you charge.
   d) If you sell it, it gets $10 a pop, regardless of what you charge.
   e) If you sell it, it gets 1% or $10, whichever is greater.
   f) If you sell it, it gets 1% or $10, whichever is less.
   g) You have to charge at least $x for any product which uses it.    (08)

All of these options affect how widely the module will be used, and
how much revenue it may generate. Figuring out the best strategy
for the module developer is something that requires thought.    (09)

By the same token, the integrator needs to figure out their best
strategy, too, based on the availability, functionality, reliability,
and pricing of various modules at their disposal.    (010)

This is basically SW development as it occurs today, only with
automated revenue sharing that is confined to the point of transaction.    (011)

Such micropayments would not only be acceptable, but also highly
conducive to code sharing and reuse. Stuff would basically be free
for use, but anytime you managed to make a buck, people who
developed code you use would get a bit. That would provide
both incentive and the wherewithal to do more.    (012)

If such a marketplace provided the means for making software
available, then a developer could spend less time thinking about
the mechanics of distribution, and more time thinking about their
designs, which would also be to the good. It would help to
promote cottage industries, because it would reduce much of the
staff you need to carry on a business. (Support and marketing
staff would still be needed, but sales and distribution staff could
be largely eliminated.)    (013)