Licensing question

[Chris Travers]

On Fri, Feb 26, 2010 at 12:25 PM, Mark James
<mrj at advancedcontrols.com.au> wrote:

>> So, that is a typical shareware license.  However with it you lose two
>> major advantages of FOSS:  Multi-vendor support and the ability to
>> fork if necessary.
>>
>
> Chris, Shareware isn't usually source-available, freely
> re-distributable, and non-crippled in trial form.

I have seen a lot of shareware that was any combination of these.
Whether or not it is typical shareware, I think that is still the
correct genre to consider the license under.

<snip>
>
> Some problems with supporting developers solely with support services:
>
> 1. Charging for support reduces the incentive to perfect both the software
>   and its (freely-available) documentation. For most users, the best
>   form of support is polished releases and good free and freely-editable
>   documentation. They don't require customization, or can do it on their
>   own.

Maybe.  I am not so sure.  There are plenty of cases where I do what I
have to because the maintainer is not accepting money for support.  In
general though, I would rather spend $100 paying a developer to go
through and fix a bug that takes him 15 min. to find and fix than I
would to spend an hour or two reviewing the code so I can fix it.

I have contributed bugfixes to a substantial number of Perl modules
simply because I have to.  I would much rather pay the maintainer to
do it so I can do billable work for customers with that time.  The
value to me of 2 hours of my time is $240.  If you charge half that,
and get it done in half an hour, you make twice as much per hour as I
do.

More money doesn't lead to perfect software either.  Just look at
Windows Vista if you don't believe me (so many great ideas poorly
executed).  The only thing that leads to perfection of software is a
small (12 people or less) team of perfectionists who are building the
software.  PostgreSQL is a good example of that :-).

>
> 2. Good support is very expensive, so many poorer customers are likely
>   to be worse off than if they just paid modest licencing fees to fund
>   improvements in the software and documentation for everyone,
>   as well as to get access to a reasonable support infrastructure.

I dunno.  Email lists are always free and provide a nice way for users
who don't want to pay for support in a given instance to avoid it.
Those who do need it can pay.

>   If support work is sent upstream, the wealthier users get a greater
>   say in the direction of the software, and if it isn't, the developer
>   ends up devoting much of their time to closed software.

Sure.  Wealthier customers get a greater say in the direction of the
software.    A smart software engineer will try to set it up so that
less wealthy customers have ways of contributing too.
>
>   OSS encourages a support dichotomy: unless a big payer comes along,
>   developers and users tell each other that they don't owe them shit.
>   Under the dual-licence model, "Community" versions are increasingly
>   becoming the poorer cousins of commercial versions.

I have been a part of software communities where developers and users
tell eachother they don't owe eachother shit.  This, however, is just
bad management of the FOSS project.   Usually it is an indication of
too much greed on both sides.  I avoid such projects.  On other
projects I have been amazed at how much help the main developers are
to the users.  PostgreSQL there is a great example.  I have often been
amazed at how the people who build the software for a living have been
willing to spend an hour or two each day to give helpful advice to
users (here's why your query performance sucks....  this is what the
planner is thinking... we can't really change it because that will
cause worse problems in the following circumstances....)

Well this is honestly one thing I love about the BSD-type licenses for
large, vibrant projects can encourage folks to be able to charge
license fees for their additions and yet economically encourage many
of those additions to make it back into the community version.
Consider PostgreSQL for example.

EnterpriseDB makes a version with increased compatibility with Oracle.
 The PostgreSQL community (for good reason) sees some of these
"features" as problematic and won't accept them back.  EnterpriseDB
can sell those features to customers who want them.

Similarly Green Plum makes a massively parallel version of PostgreSQL
for BI purposes.  THe PostgreSQL community is not interested in a
really good multiparallel database of this sort (for good reason) and
hence Green Plum can sell their additions.

Command Prompt used to make a proprietary version too.  But they open
sourced theirs and not because anyone was telling them to.

However, because the pace of community is high, this means that if
EnterpriseDB and Green Plum want to avoid going bankrupt trying to
continue to keep their enhancements secret, they contribute everything
back to the community except those enhancements which are at the core
of their business clientele. This means that both these companies
contribute a LOT of things back to the community (from bitmap indexes
to WITH RECURSIVE queries) because they can't thrive without doing so.

A dual license model only works if the other license is a BSD license
and you have a multi-vendor product like PostgreSQL.
>
>
> 3. Making it hard for the software writer to directly charge for their
>   software denies them the power of replication (mass production), which
>   supports the income of just about every big company and wealthy
> individual.

Maybe.  I am not convinced.  I am working on replicating my efforts.
Plus there are other ways of replication too  such as selling turn-key
solutions and the like.

>   Customization is hard work, and to fairly reward one's talents one should
>   be able to get away from doing that alone.
>
Like it or not, this is the best way to perfect the software.  It gets
you a first-hand look at what customers actually need in the next
version.  Think of it as charging in advance for development instead
of in arrears for licenses.
>
>
> Do you know what percentage of your users pay for support?

I don't know what you mean by "my users."  If they are "my users" it
is because they are paying me for support.

Others could go to other vendors.

> How many do their own customization and never pay you anything?

If you are asking how many people download the software and never go
to a major vendor, there is probably a fair number.  Again, over half
of the development on the projects are billed up front, so it isn't a
loss for me.  However, we have customizations ranging from a few
hundred dollars to hundreds of thousands.

> How many can't afford you, and must deal with the raw version
> of your software, documentation, and support services?

The glory here is that they can pay what they want to budget and we
can always negotiate what can be delivered for a given budget.  The
more fundamental business question has always been how much free time
to give away to other developers and quasi-competitors.
>
> Perhaps it works in your field, but not I think in most.

I think in line-of-business tools it generally works quite well.  Same
with high-end server software.

Honestly, I get more money out of a donation of code than a small
project of cash.
>
> If you charged for your software according to the recipient's
> ability to pay, you may be able to have a finger on the pulse
> of more of your users.

I would probably have fewer users too.....  I am not the sole author
of any open source project that I have ever made money on.  I am the
principle author of one (making maybe half the code commits), but I
can't take credit for all of it.  Many people, some far smarter than
me have made things a success and no program I work on would be where
it is without them.

Best Wishes,
Chris Travers