[License-discuss] we need a new license for earning money

Chris Travers chris at metatrontech.com
Wed Sep 25 02:45:26 UTC 2013

A few thoughts, assuming you are open to open source perspectives by asking
here ;-)

On Thu, Sep 19, 2013 at 10:17 AM, Pirmin Braun <pb at intars.de> wrote:

> currently our "IntarS" ERP Software is released under GPL. But we want to
> be able obtain license fees from bigger commercial users.
> That's not possible with GPL or any other OSI approved license since it is
> a restriction to free use.

It is also not possible under the Open Source Definition.  There are ways
around this business-wise I will discuss below (disclaimer, I compete in
the ERP space too).

> Since we neither want to dual license nor Open Core we've created a draft
> expressing our thoughts of a new sort of license.
> We think it adresses a common issue and differs effectively very little
> from an OSI compliant license.
> So I'd like to share our thoughts: Maybe it is possible to add such an
> extension to the OSI Open Source Definition? Or create a new class of
> approved liceneses? Or at least coin a name for this sort of license?

What's wrong with the term "shareware?"   I realize what you are doing goes
a bit beyond what shareware usually does.

> Here's the draft:
> //  IntarS 7 ERP Framework
> //  Author 1996-2013  Pirmin Braun
> //  all Rights granted to and reserved by IntarS Unternehmenssoftware GmbH
> //  Am Hofbrauhaus 1 - 96450 Coburg - GERMANY
> //  http://www.intars.de info at intars.de
> //  licensed under IntarS Open Source Commercial License
> --- IntarS Open Source Commercial License (IOSCL) ---
> Preamble
> ========
> Short Version: you can think of the IOSCL as the LGPL (tm) with license
> fees for bigger companies.
> It gives you all the freedoms, the GPL (tm) is meant for:
> - the freedom to use the software for any purpose,
> - the freedom to change the software to suit your needs,
> - the freedom to share the software with your friends and neighbors, and
> - the freedom to share the changes you make.
> But additionally it gives you and us the freedom to earn money based on
> heavy usage.
> As professional services are accepted to pay for, framework development is
> not.

Well, I put a significant amount of unpaid time into LedgerSMB framework
development.  I am sympathetic to this concern.  I also think there are
better ways around this, and if you take license fees, you end up killing
the same community that open source tends to cultivate.  So I would urge
you not to do this.

The first thing is, you need to differentiate those portions of the
framework that can be developed through professional services and those
parts that cannot.  Those that can you do for paying customers.  Those that
can't you pay for through your development services.

The way I have always seen it is that open source is paid up front for new
features while software licenses mean paid in arrears.  With software
license fees, you bear the risk that you won't make the money back on your

The Open Source idea of community development didn't work for the IntarS
> ERP framework.
> Framework development had to happen in spare time and at night and we had
> to hire professional
> programmers.

I don't think that is the only model.  You can:

1.  Charge customers to develop new features and

2.  Charge customers enough for professional services you can subsidize
framework development.

In essence I would suggest instead going a sponsored development (and
offering to publicly thank sponsors), and making sure you can still
subsidize some development off your professional services.  I am sure there
are other models too.  Now, there are some things where the above open
source business models really don't work (I am thinking in particular of
regulatory compliance matters) and so you can have professional services
which offer subscriptions for these areas.

> While the license fees will be low enough not to hurt bigger companies,
> they will help paying further framework development. Also the certified
> IntarS Partners
> and other creators of derived work will benefit as they now may create
> their own price list
> for usage of their branch solutions.

With LedgerSMB we went the opposite direction.  What we did was build into
the system deep integration points.  These are likely to eventually raise
questions regarding what constitutes derivation under the GPL but we have
adopted a line of "use our API, choose your license, but use our code, and
use our license."  We have in essence two separate components, a
database-level object model and an application-space object model.  These
communicate over a db bridge inspired by web services.  Over time the
application model will rely more on the db model than it does.

Our approach has been to license db bridges in other languages (and soon in
the language we use too) under the PostgreSQL or 2-clause BSD licenses.
This is specifically intended to allow proprietary add-ons written in any
number of licenses outside our licensing control.  In part we hope that the
db bridges will be useful for other application designers unrelated to our
work but it also creates an explicit path for people to write proprietary
addons to the software in whatever language they want.

What this means is that people can (and sometimes do) offer proprietary
addons for LedgerSMB.  We could too.  We have other ways of making it
happen though.  We are looking at a large launch of new services starting
in 1.4, but I don't want to talk specifics at this time.

My point in bringing this up is that it is possible to go with community
development, freemium, and open source (under the OSD together) if you look
at this as an engineering challenge rather than a licensing one.  This can
help cultivate community as well.

It sounds to me like part of what you are trying to do here is cultivate a
community of partners and resellers.  I think the question you need to ask
yourself is what role there is for commons between resellers or if you are
just claiming to control those commons.

Whether or not you agree with it you may also find this to be an
interesting read:


> Your Rights
> ===========
> IntarS Unternehmenssoftware GmbH grants you the right to
> use, redistribute, modify IntarS, create and/or distribute a derived work
> based on IntarS
> under these
> Conditions
> ==========
> Redistributions of source code of IntarS or a derived work must retain the
> above copyright
> notice and this License.
> Redistributions in binary form of IntarS or a derived work must reproduce
> the above copyright
> notice and this License in a convenient manner.
> A derived work must provide the information, that it is based on IntarS
> and that the contained
> IntarS is licensed under this license.
> Usage of IntarS is free for private users, educational and non commercial
> organisations.
> For commercial organisations usage is free for the first 5 concurrent
> named users.
> Continued usage by exceeding concurrent named users needs to be licensed
> in a seperate, written
> license agreement with IntarS Unternehmenssoftware GmbH.
> This applies also to the IntarS contained in a derived work.
> Commercial organisations must immediately send a mail to info at intars.deto buy required licenses.

As a reseller, I would never modify your work under such terms because
there is no provision for me to require downstream licenses too.

If you fix that though then you make end users buy licenses from umpteen
different partners.  I think you are going to have a mess on your hands
trying to make that community-friendly.

> Termination
> ===========
> Failing to conform to a condition will automatically terminate your rights
> under this License
> and constitute a claim for compensation.
> Clarification
> =============
> You don't have to redistribute your derived work. If you do, you don't
> have to distribute source with your derived work.
> You are free how to license your derived work.

That conflicts with above.  You might want to say that you are free to add
licensing requirements to your derived work.

> For the IntarS contained in the derived work of certified IntarS Partners,
> IntarS Unternehmenssoftware GmbH takes
> only 30% of the regular license fee rate from the commercial end users.

Not sure what you mean by that.  Does that mean they take 30% of
collected?  Or 30% of what they charge directly?

Moreover if you write this into the license, it is very much out of your

If I may, if you really want to go with this approach my recommendation is
you treat it as proprietary and have transfer pricing agreements with
resellers which are individually negotiated and contractually based, and
offer your shareware source license on the source code itself.  I would
suggest changing it to say further that derivative works can be licensed
under the same terms, or transfer pricing agreements are available from you.

Hope this helps,
Chris Travers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20130924/2756e079/attachment.html>

More information about the License-discuss mailing list