Licensing question

[Chris Travers]

On Tue, Mar 16, 2010 at 3:45 AM, Mark James <mrj at advancedcontrols.com.au> wrote:
> 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.

Sure, it's a needed motivator, and we sell that service.
>
> Combining community and money is a strength of
> non-gratis open software.

Sure.  But that is also non-open source and carries with it a set of tradeoffs.

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

It would also reduce distribution and increase distribution costs.

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

Maybe.  It's not the only option.

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

I don't oppose non-FOSS plugins for FOSS apps.  However, there is no
way the FOSS project could distribute them.  Generally, the cost
reduction here is well worth releasing the work under a FOSS license.
Again, if you do something as a non-FOSS plugin, provided that certain
rules are adhered to, that's your business.  However, we don't promote
the plugin as part of our free, community work.

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

The other tradeoff is that most FOSS distribution media won't carry
the work......


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

It would also alienate the community of existing users.  We aren't going there.

I could see moving parts of the framework to a BSD-type license though.
>
>
>> 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.

We will absolutely NOT change to the AGPL, or even the GPL v3 (simply
because it suddenly makes exception for AGPL components).

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

But what would be gained for us if someone writes their quality book
and adds, in a separate section, the entirity of our manual with
proper attribution and license information, and publishes that
compiled work?  The GPL doesn't come into play there.

Best Wishes,
Chris Travers