Licensing question

[Mark James]

On 03/02/10 06:36, Chris Travers wrote:

>> 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.
>
> I found a bug in Windows Server 2003 (not found in Server 2000)
> environment variable handling that Microsoft plainly said they
> wouldn't fix.  (The issue had to do with Unicode handling, empty, null
> terminated strings, and set but empty environment variables.)  It
> wasn't a problem everyone would run into but it kept some versions of
> Websphere from installing without setting a bunch of environment
> variables first.
>
> Also, there are issues regarding prioritizing fixes.  I wouldn't
> expect Microsoft or anyone else to fix every bug reported by anybody.

Software warranties are never absolute. But you have more rights with
most commercial licences than an absolutely-no-warrranty FOSS licence.


> I am just saying where my time would be better spent.  YMMV.
> Personally I would be happier if my customers sent me bug fixes
> instead of paying me to do it simply because that allows me to focus
> more on paid development work focused on new features.  But whatever
> the customer wants....

...and can afford.

Licence fees fund developers to fix bugs for free; and free licences
and revenue shares offers give users an incentive to upstream high
quality fixes and features.



> Also, this dual licensing of BSD and EULA works very well for [PostgreSQL] but
> only because they are a multi-vendor project with a rapid pace of
> development.  This is something worth emulating for many projects, but
> certainly not where you are going with your project, right?

I don't want to dual-licence my plugin projects because it creates two tiers
of users, and allows more of them to freeload.

>
>>   - Corporate users whose work is supported by other closed software or
>>    products?
>
> Not sure what you mean here.

People employed to work on FOSS projects are usually being supported by
some other closed and proprietary product. I want to make it feasible to
make an independent living from selling open software.


> It takes very little sales effort to have customers aware of the
> benefits of submitting the enhancements upsteam.

If the patches are small, the maintenance burden of keeping it private
is also likely to be small. When patches are large or competitively
important, there is an incentive to maintain a fork. In between, there's
a good case.


>> 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.
>
> Sure.  But it's not really comparable to FOSS.

Very comparable! It's the only feasible way of which I know to bring the
major benefits of FOSS to commercial software. The net effect is something
closer to FOSS than to closed and proprietary software.


> Email lists depend on the willingness of the developer to help out and
> encourage a community of folks to do so.

Email support should be an obligation if the software has been purchased.

However some big companies selling cheaper software scrimp on this,
inducing secondary markets and frustrated users to fill the gap. Niche
commercial software should however have the resources to do it.


> I think that if any of us had not considered the pro's and cons of
> license fees, we wouldn't be on this list.

Have you considered licence fees in combination with open development?


> Call it what you want, but it is well outside the expectations of what
> users expect from "Open Source" these days.

Change isn't easy:

   First they ignore you, then they laugh at you, then they fight you,
   then you win. -- Mahatma Gandhi



> Folks on this list probably are aware of my harsh feelings for folks
> who think that everything MUST be open source.  I think PostgreSQL is
> a great counter-example, and shows what can be accomplished with the
> BSD license if you have a vibrant community.  However, you aren't
> going to generally entice FOSS developers over to the world of license
> fees unless there is a real open source basis on which this can rest.

How would you define "a real open source basis"?

There should be a continuum between FOSS and proprietary licences, not
a two-armed-camps view of the world.


>> 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.
>
> Right, but they are closed because the community doesn't want them.
> Nobody wants Pg to treat empty strings as NULLs like Oracle, for
> example, except those migrating from Oracle.  What this means is that
> EnterpriseDB offers everything outside this narrow area back to the
> PostgreSQL community.

Some do want those features. And some would like to tinker with them, and
possibly release them, but they can't.


> I wouldn't necessarily call [FOSS licences] restrictive.  I don't see the BSD
> license as restrictive.  However, some software shouldn't be OSS and
> on that I would agree.  Consumer software, for example, lacks any
> business model where one can really monetize the software outside of
> panhandling.

FOSS licences significantly limit the ways in which one can successfully
charge for software to fund its development.

I agree that consumer software is the hardest type to enforce licence fees,
particularly if the software is open, and so easier to bypass any trial limits.

But I wish more developers would actually ask for a fixed fee from continuing
users, like in the shareware days, rather than the nebulous relationship
of the donation button. (Developers like them because they owe their donors
nothing, and users like them because they can ignore it).


>> I just want to restore openness by providing a
>> licence that relaxes the OSS model at appropriate points.
>
> No complaints there.  Just not sure it is comparable to OSS.

In practical rather than ideological terms, I think it is.


>> Will you open-source the turn-key build?
>
> Absolutely.

You're making something that requires less support from most users, undermining
your services business (though gaining some additional customization work).

Consider a mandatory charge for production use, which comes with a degree of
free support. Keep the build entirely open, but work with any distributors
and forkers to fairly share the income.


> Understand I am not independent of some of those projects.  I have
> committed roughly half the changes in LedgerSMB since the fork, for
> example.  I am independent of most of the other contributors though.

LedgerSMB is a really nice project. I know some people who are using it.
If it supported Australia's Goods & Services Tax, I'd like to use it myself


> 80-90% get distributed either in the standard package or into addons
> in the same svn tree.

That's good. I suppose customizations for an accounting package would
mainly be applicable to all businesses, and not strategically important,
or would be applicable only to that company or industry, making upstreaming
respectively useless or competitively damaging.


> We are moving towards more addons and a smaller standard package for
> LedgerSMB though.

It's addons where I see the Rails Wheels licence being most applicable.


>> 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.
>
> I offer discounts to address some of this.

But still cost-plus?


>>> Honestly, I get more money out of a donation of code than a small
>>> project of cash.
>>
>> Could you explain this more please.
>
> Either it fixes a problem for me with less overhead on my part, or it
> provides new functionality that lets me sell to a larger market.
> Either way it does so much faster than if I am paid to do it myself.

OK, thanks.

It's in your interests to make it as attractive as possible for people
to contribute.


>> 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.
>
> Consider LedgerSMB. (http://www.ledgersmb.org)
>
> Distribution would be smaller, sourceforge would not be available to
> host the downloads (meaning hosting expenses wold go up), and I would
> lose out on the compelling perspectives of other contributors.  It is
> great to jointly develop software with folks like Josh Drake, Chris
> Murtagh, and Seneca Cunningham who can not only contribute code but
> provide much needed perspectives in building quality software.

Yes, there's a lot of free infrastructure that cuts out as soon as you
charge 1c for your software, even though it's available for projects that
agressively seek donations, deliberately limit their free documentation
and components to drive sales of charged and closed material and services,
or make their money from advertising (hello Mozilla!).

LedgerSMB would definitely have fewer users if non-trial users were required
to pay a licence fee. But I don't think you'd see as dramatic a fall-off as
you'd see with consumer software. For more niche software, that has affordable
licence fees and email support for paying users, I think most users would pay
rather than pirate or forgo.

And charging for software shouldn't mean a fall-off in the community of
contributors, particularly if they can now earn part of their living from their
open patch work. That's one aspect of Rails Wheels.


> However, why I make money is because I know the code very well.
> Nobody can out-produce me in this area.  So my time is worth more than
> many other developers' time.

You could be making a lot more if you were paid by a greater fraction
of people who are benefiting from your work.


> I am also the go-to person in the community so when people need work
> done I am one of the first folks they come to.

Top-dog always survives. But a different ecosystem could support a larger
and healthier population of developers, and consequently, a better package.


> Again, these are business decisions.

A valid choice. I'm just looking to make some alternate business models
for open software more feasible.


> The key issue between OSS and your license IMO is that your license,
> not being really open source or free software by expected standards is
> that you have a tradeoff.  On one hand, you cannot leverage the open
> source community as well, but on the other, you can demand licensing
> fees.  That is a tradeoff that your business has to decide on.

Tradeoff yes. Dilemma no. Workable hybrid? We'll see.

The software is open, and so definitely leverages a community.

Mark
-- 
Mark James
Advanced Machine Controls
Email: mrj at advancedcontrols.com.au
Phone: +61 2 9983 0294