Licensing question

[Mark James]

On 03/10/10 04:00, Chris Travers wrote:
> I've worked with a lot of software, and most of it is not very well
> polished.  The polish usually comes from resources, but these aren't
> necessarily just money.  Community help, etc. is important.
Polish mostly involves some less-fun tasks where
money can be the needed motivator.

Combining community and money is a strength of
non-gratis open software.


> A lot of the customization I do I carefully divide into two levels:
>
> 1)  What is generally applicable and needs to go into future releases.
>
> 2)  What is customer-specific and needs to be separated from the
> future releases.
>
> We work hard on maximizing the first category and minimizing the
> second.  The benefit for the customer of doing this is that they still
> get competitive advantages of their workflows being protected from
> being further inclusion, but all the base business logic usually gets
> included in future releases.
>
> All of that work is billable and while I also do some non-billable
> development time in things I think will make me money later....
>    

If you were able to sell licences to use your software,
you would capture more of the value you create, and would
not have to sell the benefits of upstreaming.

>    
>> For the common situation where a substantial amount of software is being
>> written for general release, I think you are arguing that FOSS carries a
>> lower risk for developers than proprietary due to (1), community
>> participation,
>> and (2), the marketing power of free. My response to that is the creation of
>> a licence that encourages community participation for open but non-libre [sic: gratis]
>> software, and to apply that licence to certain software niches, along with
>> support services and fair licence-fee schedules, such that most (happy)
>> free-trial users will willingly purchase licenses.
>>      
> No. I am arguing less risk because you can start with a smaller
> release and bill for time making it work for more users.  Yes, you
> have to have some original code (and presumably an application which
> works to some extent), but if you are selling software, you really
> need to start with something that is closer to what is immediately
> needed.  It's the difference between selling the effort of building a
> solution for a customer and selling the solution.
>    

Sure that works for your "better fork" situation, but
not for the more common situation of a person or company
bootstrapping a new OSS-licenced package. In that case the
"exit strategy" is often to get hired or bought-out by a
company with a predominantly proprietary side, closing
or controlling much of the developers' work.

There should be ways other than selling services for
start-ups to form around existing open software. Selling
open plugins for example -- a path I'm seeking to make
more feasible.


> In my experience many users eventually turn to customizations of
> business software (even small businesses with modest incomes) because
> a modest investment in minor customizations may go a long way towards
> bettering a given business's internal processes.
>
> Back in the day, Microsoft commissioned a set of studies called the
> "Get the Facts" campaign.  One of the things that the IDC, Gartner,
> and others concluded in these studies was that FOSS solutions usually
> cost customers more to implement and maintain than proprietary
> solutions.  Microsoft tried to take the position that they were the
> low cost solution and everyone laughed at them.
>
> However, a close look at these studies fit my experience fairly
> closely and suggested to me that the interpretation, rather than the
> data, was what was flawed.  Yes, companies were (and are) spending
> more on FOSS than they would on proprietary software over the life
> cycle of the product, but if you look at where the extra effort comes
> from, it is usually hired consultants.  And in my experience, this
> extra effort is simply a matter of ensuring that the solution
> implemented is optimized for a business.  Businesses are putting more
> money into the solutions because they get more benefits out of doing
> this.  My experience is that businesses which would not otherwise
> purchase services for a commercial solution are often happy to
> purchase services for an open source solution.  Probably a third of my
> customers are in that category.
>    

Much of the need for customization can be covered by
either a full-featured base-package, or a rich selection
of configurable and tweakable add-ons. It's in the latter
arena that open software can shine, because everything is
transparent (source is the ultimate developer's documentation).
The one-off work that is lost can be made up by charging for
the (open) add-ons.

>> But if development is properly funded and managed, open software needn't
>> require users to be sophisticated, and able to handle some rough edges.
>>      
> Depends on the software.  Vim will require users to be sophisticated,
> as it should.  So will LaTeX.  So too will LedgerSMB.  These packages
> are aimed at individuals with specialized needs.  If you don't have
> specialized needs, use GNUCash instead of LedgerSMB, Scribus instead
> of LaTeX, gedit or notepad instead of Vim.......
>
> As far as rough edges, we are working on removing the rough edges. A
> lot of this though has to do with proper design and we forked from
> program that had, and still has, serious fundamental design flaws
> (though I am sure all of us have written a few of those) which have
> tended to get in the way.
>
> There are certain things I pay for.  When we get to 2.0, I expect to
> raise money (one of the few exercises in asking for donations) to try
> to get the software certified by Veracode.  I may pay for a lot of
> that out of pocket.

Even sophisticated and well-resourced users want software
that's reliable, secure, and easy to use. LedgerSMB seems
to have been born with that in mind.

Given LedgerSMB's history, and tangled ownership, you would
have trouble changing to a more commercial open licence,
even though it could greatly accelerate your development cycle,
improve quality, and fund the sort of certifications of which
you speak.


> Some do, some don't.  The application is architected in order to allow
> for multiple points of integration and in 2.0, this will become a
> major feature.  I suspect inheriting our db mappers and base utility
> classes would make the GPL binding.    However a lot of this is fairly
> light-weight automation stuff and could be implemented differently by
> a different programmer.
>    

Someone may also bypass the GPL by writing an extension that
allows them to sell subscriptions to a cloud version. You'd
then have to decide whether to change to the AGPL.

Considering Google's recent announcement about their
Apps Marketplace, this may become the way of the world

http://www.google.com/enterprise/marketplace/home

> Our community documentation is BSD-licensed for a couple important
> reasons (in particular, I was concerned that allowing for aggregation
> but not deep modification would mean that anyone who wanted to publish
> the docs in a different book would simply get around the GPL by
> putting it in a separate part along with a copy of the GPL, and the
> project clearly agreed the GFDL was not free enough for the project).
> The BSD license for the docs here actually is likely to increase our
> ability to use them as a fundraising project because unless you get
> from a trusted source (the project), you don't necessarily know you
> are getting the authoritative version.
>    

Quality usually trumps authoritative. If your app becomes
sufficiently popular, someone will write a book, and I think
you should do your best to make sure it's open.

Mark