<div dir="ltr">A few thoughts, assuming you are open to open source perspectives by asking here ;-)<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 19, 2013 at 10:17 AM, Pirmin Braun <span dir="ltr"><<a href="mailto:pb@intars.de" target="_blank">pb@intars.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">currently our "IntarS" ERP Software is released under GPL. But we want to be able obtain license fees from bigger commercial users.<br>
That's not possible with GPL or any other OSI approved license since it is a restriction to free use.<br></blockquote><div><br></div><div>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).<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Since we neither want to dual license nor Open Core we've created a draft expressing our thoughts of a new sort of license.<br>
We think it adresses a common issue and differs effectively very little from an OSI compliant license.<br>
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?<br></blockquote>
<div><br></div><div>What's wrong with the term "shareware?" I realize what you are doing goes a bit beyond what shareware usually does.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Here's the draft:<br>
<br>
// IntarS 7 ERP Framework<br>
// Author 1996-2013 Pirmin Braun<br>
// all Rights granted to and reserved by IntarS Unternehmenssoftware GmbH<br>
// Am Hofbrauhaus 1 - 96450 Coburg - GERMANY<br>
// <a href="http://www.intars.de" target="_blank">http://www.intars.de</a> <a href="mailto:info@intars.de">info@intars.de</a><br>
// licensed under IntarS Open Source Commercial License<br>
<br>
--- IntarS Open Source Commercial License (IOSCL) ---<br>
<br>
Preamble<br>
========<br>
Short Version: you can think of the IOSCL as the LGPL (tm) with license fees for bigger companies.<br>
It gives you all the freedoms, the GPL (tm) is meant for:<br>
- the freedom to use the software for any purpose,<br>
- the freedom to change the software to suit your needs,<br>
- the freedom to share the software with your friends and neighbors, and<br>
- the freedom to share the changes you make.<br>
<br>
But additionally it gives you and us the freedom to earn money based on heavy usage.<br>
As professional services are accepted to pay for, framework development is not.<br></blockquote><div><br></div><div>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.<br>
<br></div><div>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.<br>
<br>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 development.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The Open Source idea of community development didn't work for the IntarS ERP framework.<br>
Framework development had to happen in spare time and at night and we had to hire professional<br>
programmers.</blockquote><div><br></div><div>I don't think that is the only model. You can:<br><br></div><div>1. Charge customers to develop new features and<br><br></div><div>2. Charge customers enough for professional services you can subsidize framework development.<br>
<br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> While the license fees will be low enough not to hurt bigger companies,<br>
they will help paying further framework development. Also the certified IntarS Partners<br>
and other creators of derived work will benefit as they now may create their own price list<br>
for usage of their branch solutions.<br></blockquote><div><br></div><div>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.<br>
<br></div><div>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.<br>
<br>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.<br>
<br></div><div>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.<br>
<br>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.<br>
<br></div><div>Whether or not you agree with it you may also find this to be an interesting read:<br><br><a href="http://ledgersmbdev.blogspot.com/2013/04/a-distributist-view-on-software-freedom.html">http://ledgersmbdev.blogspot.com/2013/04/a-distributist-view-on-software-freedom.html</a><br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Your Rights<br>
===========<br>
IntarS Unternehmenssoftware GmbH grants you the right to<br>
use, redistribute, modify IntarS, create and/or distribute a derived work based on IntarS<br>
under these<br>
<br>
Conditions<br>
==========<br>
Redistributions of source code of IntarS or a derived work must retain the above copyright<br>
notice and this License.<br>
<br>
Redistributions in binary form of IntarS or a derived work must reproduce the above copyright<br>
notice and this License in a convenient manner.<br>
<br>
A derived work must provide the information, that it is based on IntarS and that the contained<br>
IntarS is licensed under this license.<br>
<br>
Usage of IntarS is free for private users, educational and non commercial organisations.<br>
<br>
For commercial organisations usage is free for the first 5 concurrent named users.<br>
Continued usage by exceeding concurrent named users needs to be licensed in a seperate, written<br>
license agreement with IntarS Unternehmenssoftware GmbH.<br>
This applies also to the IntarS contained in a derived work.<br>
Commercial organisations must immediately send a mail to <a href="mailto:info@intars.de">info@intars.de</a> to buy required licenses.<br></blockquote><div><br></div><div>As a reseller, I would never modify your work under such terms because there is no provision for me to require downstream licenses too.<br>
<br></div><div>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.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Termination<br>
===========<br>
Failing to conform to a condition will automatically terminate your rights under this License<br>
and constitute a claim for compensation.<br>
<br>
Clarification<br>
=============<br>
You don't have to redistribute your derived work. If you do, you don't have to distribute source with your derived work.<br>
You are free how to license your derived work.<br></blockquote><div><br></div><div>That conflicts with above. You might want to say that you are free to add licensing requirements to your derived work.<br></div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For the IntarS contained in the derived work of certified IntarS Partners, IntarS Unternehmenssoftware GmbH takes<br>
only 30% of the regular license fee rate from the commercial end users.<br></blockquote><div><br></div><div>Not sure what you mean by that. Does that mean they take 30% of collected? Or 30% of what they charge directly? <br>
<br></div><div>Moreover if you write this into the license, it is very much out of your hands.<br><br></div><div>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.<br>
<br></div><div>Hope this helps,<br>Chris Travers<br></div></div></div></div>