Licensing question

[Mark James]

On 02/27/10 10:51, Chris Travers wrote:
>> 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.

Chris, unless pan-handling is used as the means of payment, shareware is
incompatible with FOSS licences. And the combination of a standard commercial
licence with standard distribution and payment infrastructure doesn't make
FOSS-like open development feasible. That's why a different system
and licence was needed.


>> 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.

If you've paid for the software, the developer is obligated to fix bugs
for free. There's no problem selling support services on top of this
for greater timeliness, or in the form of feature bounties.

A $100 fix would be impractical for poorer users. And in large companies,
where someone is already being paid to manage the software, they can become
more familiar with it by fixing it internally. Not to mention wanting to avoid
the administrative overhead of the external contract (though this is offset
with the optional burden of up-streaming a patch).

When an external package is both small and part of the same system I'm
already familiar with, such as a framework plug-in,  I find that it's
much quicker and easier to just fix things myself. The Rails Wheels licence
is particularly apt for such smaller packages, rather than huge systems
with many prime developers and contributors.


> 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 :-).

I don't think Vista is buggy, it just had some poor design choices.
I think it's certainly more polished than any Linux distribution.

How do the PostgreSQL developers support their work?

  - EnterpriseDB employees, funded by closed-source extensions, closed
    and restricted documentation, and paid support contracts?

  - Corporate users whose work is supported by other closed software or
    products?

  - People looking for work with one of the above two?

  - Paid bugfixes and enhancements that their customers are willing to
    have committed up-stream? (Private fixes and deployment services
    don't directly help the distribution.)


The Rails Wheels licence is designed to make it easier to be an IOSV
(Independent Open Software Vendor). Everything open, without any corporate
life support system or pot of gold.


>> 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.

Email lists are a crap-draw. No-one's obligated to help. Many questions
don't get a satisfactory resolution, particularly the more complex ones.
That turns off many users.

A developer can provide better email support when they have a large pool
of users who have bought their software, in comparison with making private
communications with purchasers of more expensive support contracts.

> 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.

The prospect of being given a free licence or a revenue share is a good
incentive for all types of users to contribute, without the corporate
appropriation that occurs when uncompensated copyright assignment is
demanded by dual-licenced projects.


>>
>>    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

My particular choice of words was inspired by an utterance in one of
the communities in which I'm active

    http://www.flickr.com/photos/urbanwide/244690884/

Now I don't think the person in question is stingy (indeed, he open-sourced
a Web framework he created on his own), and both the Ruby and Rails communities
are very friendly and helpful. But it boils down to no sense of commitment
on either side.


> 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....)

Again, I'd be interested to know the employment circumstances of these
developers, and to what extent some developers are prevented from
offering such advice so as to not dilute the paid support services their
employers offer.


> 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.

Other than the Command Prompt offering, all the other PostgreSQL add-ons
are closed in some way, which loses all the open advantages we agree on.

Rails Wheels is designed for precisely these circumstances: A large package,
Ruby on Rails, which is MIT-Licenced, and a natural fit for Open Source due
to the large number of contributors, but which can have a number of niche
plug-ins which are each usually maintained by a handful of developers.
Rails Wheels aims to fund development of these plug-ins, while keeping them
completely open.

If some of the PostgreSQL add-ons adopted a Rails Wheels-type licence, they
could, like Command Prompt, open their work while remaining profitable,
without having to focus on support over development.

The restrictive nature of OSS is not suitable for some pieces of software,
and this has driven developers away from the open model, throwing the
baby out with the bathwater. I just want to restore openness by providing a
licence that relaxes the OSS model at appropriate points.


>> 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.

Will you open-source the turn-key build?

>>    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.

Why not do both?

>> 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.

OK, I've now looked at your website. I was looking from the perspective
of the support offered by a prime developer of a smaller package, rather
than a more independent support service for a larger package.


>> 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.

BTW, how many of your customizations get incorporated into the standard
package?

>> 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.

When the customers can't afford cost-plus for the required work, you
must choose between rejection and cross-subsidization. Too much
cross-subsidization always collapses. Charging everyone for using
the software at least limits it.


> Honestly, I get more money out of a donation of code than a small
> project of cash.

Could you explain this more please.


>> 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.

If your offering is compelling, unique, and not easily (clean-room) cloned,
most users will pay modest licence fees, which can be automatically shared
between developers according to an agreed level of contribution.

Thanks Chris for your interesting perspectives.

Mark