Hi all,
We are busy developing some software (some is web based, others not) and I am having a bit of hard time understanding (or rather, choosing) a license model to work with, We will offer some free software (PHP based scripts, and even Windows based applications) and for this I'm sure the GPL, or even LGPL (for the network side?) will work fine.
But, we also need to suppose these scripts, and will be charging for support (other for installations, customization, or even custom derivations, etc), but at the same time we need to distribute some commercial software to cover developer's salaries, rents, marketing, business growth, etc.
Now, my question(s) is as follows:
Can I sell one script as GPL, but another as AGPL, or even BSD under the same company name? And if these 2 are tied together (i.e. being able to be used together, although seperate programs / script - for example Apache + PHP), how would I license them?
We are writing a series of PHP + MySQL based scripts which can be used on the internet, either stand-alone, or in conjunction with other scripts (API driven), and I want to offer a free, limited edition, as well as commercial edition with more features. We're also writing some software that makes use of MySQL / sqlite / postgresql, and even MSSQL, so I need to take their licenses into consideration.
What would be the best license for this? I know it's broad, but there's just too much to readup on the different licences and I've read a lot already, not knowing where to go. I have a feeling that I may need to go the dual / multi-license route, but even then I don't know which licences to use.
The open source projects wouls also be open for other people to add their own modifications, but I would also like to allow others to write commercial addon's as well.
Any pointers, and even past-experiences?
Am 07.10.2009 um 00:18 schrieb Rudi Ahlers:
Hi all,
We are busy developing some software (some is web based, others not)
Licenses are only about the source-access and how contribution/ deviations are licensed.
You can charge any amount you want for your GPL'ed stuff - but the source must be available for reasonable cost.
So, if one of your licensees redistributes a copy for free, that's perfectly legal (for GPL).
Charging for PHP-stuff has always been very difficult. Some use IONCUBE encoder etc.
I don't know if charging for support actually makes a good business- model. You need a lot of contracts for that.
BSD-licenses carry a lot less burden - but of course you can't just take a GPL'ed piece of code and re-distribute it with a BSD-licence. If your free product is GPL'ed and your commercial product is a derivative of that, it will also be licensed (well, need to be licensed) as GPL - if you give it away to somebody. If you keep it inhouse, nobody cares and nobody has a right to see the derivated source, just because it exists).
You should really enlist the help of a law-professional in this field - the licensing-minefield has gotten more and more difficult to navigate in recent years. This is especially relevant in cases where you want to have "dual- licensed" stuff (as you mentioned).
Rainer
On Wed, Oct 7, 2009 at 1:26 AM, Rainer Duffner rainer@ultra-secure.de wrote:
Am 07.10.2009 um 00:18 schrieb Rudi Ahlers:
Hi all,
We are busy developing some software (some is web based, others not)
Licenses are only about the source-access and how contribution/ deviations are licensed.
You can charge any amount you want for your GPL'ed stuff - but the source must be available for reasonable cost.
So, if one of your licensees redistributes a copy for free, that's perfectly legal (for GPL).
Charging for PHP-stuff has always been very difficult. Some use IONCUBE encoder etc.
I don't know if charging for support actually makes a good business- model. You need a lot of contracts for that.
BSD-licenses carry a lot less burden - but of course you can't just take a GPL'ed piece of code and re-distribute it with a BSD-licence. If your free product is GPL'ed and your commercial product is a derivative of that, it will also be licensed (well, need to be licensed) as GPL - if you give it away to somebody. If you keep it inhouse, nobody cares and nobody has a right to see the derivated source, just because it exists).
You should really enlist the help of a law-professional in this field
- the licensing-minefield has gotten more and more difficult to
navigate in recent years. This is especially relevant in cases where you want to have "dual- licensed" stuff (as you mentioned).
Rainer _______________________________________________
Hi Rainer,
Thanx for your input. My questions aren't really related to what I am going to charge for the software, but rather how I'm going to license it. Most of it was, and still is developed for in-house use, but some clients have requested that they want the same software for their own use.
What I want todo is simple: There will be some scripts (web based) & programs (for desktop use, mostly on Windows, but with Linux server connectivity & management included) that we want to distribute for free. Then we want to sell a commercial version of the same software, but with more features than the free one.
What I don't yet fully understand, is how do we license both versions of the same script, so that if a community member writes an addon for the free one, that other community members can benefit from it as well? And more specific, is it possible to "force" them to redistribute their code via our community network?
I see this a lot, for example with Joomla - which is free and anyone can contribute extra addons, whether free or commercial back into the community.
But they don't have a commercial version of the same project. So I want to know how do I license the commercial scripts with this in mind? i.e. if I license them as GPL, do I need to disclose the source code? Cause we're going to encrypt the additional commercial code of the software.
Support on this will be in the form of: if we need to goto the client and set it up for them, do updates, training, etc.
Zimbra is a good example of what we want to accomplish, but I honestly don't have any experience with licensing, so I can't just "copy another project" in this regard.
On Wed, 07 Oct 2009 10:01:00 +0200 Rudi Ahlers wrote:
But they don't have a commercial version of the same project. So I want to know how do I license the commercial scripts with this in mind? i.e. if I license them as GPL, do I need to disclose the source code? Cause we're going to encrypt the additional commercial code of the software.
It's my understanding that you, as the sole author of the software, can license it in any way that you choose.
So you can have, for example, a GPL version and a proprietary version and those versions can be as similar or different as you wish them to be.
You would have to provide the source code for the GPL version, otherwise what would be the point?
You could have a proprietary version that you release on any terms that you wish; if you don't want to release the source code for that then you would not have to.
If an "outsider" makes a modification to your GPL program then he has two choices: Keep it to himself (within his own company, for example) or release it to the big wide world. If he chooses to release it, then his modification would also be GPL. You could not force a user to give you his modification if he didn't actually release it and kept it in-house exclusively for his own use, though.
If this occurred, then you would have the same rights as everyone else to include his modification in the GPL version of your program. But you wouldn't have the right to include his modification in your proprietary version of the program, even if the proprietary version of the program was 100% identical to the GPL version. If you really wanted to include his modification in your proprietary version of the program you would have to enter into a separate agreement with him to do so. Note that this is a completely different requirement from the automatic "right to include" that comes with the GPL version of the program.
Another factor that you need to be aware of is the licensing requirements of whatever you're using for a "base". For example, it's my understanding that MySQL requires that you license all of your projects as GPL unless you purchase a commercial license from them.
At Wed, 7 Oct 2009 10:01:00 +0200 CentOS mailing list centos@centos.org wrote:
On Wed, Oct 7, 2009 at 1:26 AM, Rainer Duffner rainer@ultra-secure.de wrote:
Am 07.10.2009 um 00:18 schrieb Rudi Ahlers:
Hi all,
We are busy developing some software (some is web based, others not)
Licenses are only about the source-access and how contribution/ deviations are licensed.
You can charge any amount you want for your GPL'ed stuff - but the source must be available for reasonable cost.
So, if one of your licensees redistributes a copy for free, that's perfectly legal (for GPL).
Charging for PHP-stuff has always been very difficult. Some use IONCUBE encoder etc.
I don't know if charging for support actually makes a good business- model. You need a lot of contracts for that.
BSD-licenses carry a lot less burden - but of course you can't just take a GPL'ed piece of code and re-distribute it with a BSD-licence. If your free product is GPL'ed and your commercial product is a derivative of that, it will also be licensed (well, need to be licensed) as GPL - if you give it away to somebody. If you keep it inhouse, nobody cares and nobody has a right to see the derivated source, just because it exists).
You should really enlist the help of a law-professional in this field
- the licensing-minefield has gotten more and more difficult to
navigate in recent years. This is especially relevant in cases where you want to have "dual- licensed" stuff (as you mentioned).
Rainer _______________________________________________
Hi Rainer,
Thanx for your input. My questions aren't really related to what I am going to charge for the software, but rather how I'm going to license it. Most of it was, and still is developed for in-house use, but some clients have requested that they want the same software for their own use.
What I want todo is simple: There will be some scripts (web based) & programs (for desktop use, mostly on Windows, but with Linux server connectivity & management included) that we want to distribute for free. Then we want to sell a commercial version of the same software, but with more features than the free one.
What I don't yet fully understand, is how do we license both versions of the same script, so that if a community member writes an addon for the free one, that other community members can benefit from it as well? And more specific, is it possible to "force" them to redistribute their code via our community network?
If the addon is totally independent and only makes use of some 'public' API, then the writers of the addon can licence it as they see fit.
I see this a lot, for example with Joomla - which is free and anyone can contribute extra addons, whether free or commercial back into the community.
But they don't have a commercial version of the same project. So I want to know how do I license the commercial scripts with this in mind? i.e. if I license them as GPL, do I need to disclose the source code? Cause we're going to encrypt the additional commercial code of the software.
You only need to desclose the source code for the open source part. I'm going to assume that the commercial 'extensions' are basically 'addons' that add to the core (open source) script(s) using a public API. These commercial extensions may expose an additional level of public API.
Support on this will be in the form of: if we need to goto the client and set it up for them, do updates, training, etc.
Right a basic level of support contract. This is much like what RedHat does. The base level code for RHEL is open source. RedHat provides various levels of support and provides some non open source extras with the system. Under the GPL *anyone* is free to snag the open source source code off RHEL site, remove RHEL's trademarks, and re-compile everything and redistribute the system (eg CentOS).
Zimbra is a good example of what we want to accomplish, but I honestly don't have any experience with licensing, so I can't just "copy another project" in this regard.
On Wed, Oct 7, 2009 at 5:01 AM, Rudi Ahlers rudiahlers@gmail.com wrote:
What I don't yet fully understand, is how do we license both versions of the same script, so that if a community member writes an addon for the free one, that other community members can benefit from it as well? And more specific, is it possible to "force" them to redistribute their code via our community network?
Just ask nicely, and they will come --if you run a usable and attractive site or community network able to grow into the best free market for all things 'your product'.
I see this a lot, for example with Joomla - which is free and anyone can contribute extra addons, whether free or commercial back into the community.
But they don't have a commercial version of the same project. So I want to know how do I license the commercial scripts with this in mind? i.e. if I license them as GPL, do I need to disclose the source code? Cause we're going to encrypt the additional commercial code of the software.
I would like to point out that Yes, if you release GPL code you have to disclose the source *to those people you redistribute it to* (see for instance http://www.gnu.org/licenses/quick-guide-gplv3.html, or read the fine print in GPL). You are not compelled to make your sources universally visible or return them to any source code pool or distribution, in the same sense that you are not forced to publish code you develop for inhouse use. If you charge money for your GPL product, your customers may, however, disclose the source to the public --but they may very well not feel like it, as they have already paid for that code!
Consider a business model of having a free, core trunk of code, and separately selling (under any compatible license) custom code to go along with it. This custom code implements some different behaviour which only makes sense to a given customer or a vertical market. Every new code you release under this model (because of licensing compatibility with the core trunk) has to be released with its source. But this means some acquisition cost, and a business advantage, to your customer. He will want to keep it for himself --he won't disclose it. And you can continue with your selling it as if in a closed source model.
-
Eduardo Grosclaude -
Frank Cox -
Rainer Duffner -
Robert Heller -
Rudi Ahlers -
Rudi Ahlers