What about the licenses of these modules?
Don't get me wrong here, I think that it's good that you ask for a fee for our modules, but this is a good case study IMHO to see what the consequences are for developing a module for XOOPS.
Bunny wrote this in another thread:
=========================================================
On the GNU.org website you can find a nice FAQ that answeres nearly all question regarding the GPL. (BTW: PHP is not under the GPL, but under a much less restrictive license, the PHP license)
Quote:
Q: If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL?
A: Yes, because the program as it is actually run includes the library.
The XOOPS Core is a library of classes/functions, released under the GPL.
Quote:
Q: If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?
A: When the interpreter just interprets a language, the answer is no. [...]
This would cover the running of proprietary software on PHP, if PHP where GPL'd.
Quote:
Q: If I add a module to a GPL-covered program, do I have to use the GPL as the license for my module?
A: The GPL says that the whole combined program has to be released under the GPL. So your module has to be available for use under the GPL.
But you can give additional permission for the use of your code. [...]
Really says it all, does it?
Quote:
Q: If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?
A: It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, so plug-ins must be treated as extensions to the main program. This means they must be released under the GPL [...]
=================END POST BUNNY=================
So, taking this into account, the main question is: 'do these modules fall under the General Public License?'. The answer to that question lies in the code. Do these modules depend on processes controlled by the XOOPS Core?
Processes like the comments system, for example. Or the user authentication. Or the database management, or the template system.
If these modules depend on this to be executed (meaning they fail to work as intended if they are not using the XOOPS Core classes), then they are considered part of the whole application, and thus are bound by the terms set in the General Public License.
Not having seen the code of these modules, I suspect that they do fall under the terms of the GPL. But I may very well be wrong!
Now, assuming the modules are GPL licensed, what are the consequences of selling your modules? Is this allowed? Yes, it is. There's nothing in the GPL that forbids you to sell your code. Selling the code means you release the code, and under the GPL, you are bound to make the source available to the buyer as well. Since it's uncompiled PHP, that's not an issue here.
However, there is a catch her (there always is). The catch is that the GPL gives the one who paid for the code a lot of freedom. For one, they're allowed to resell the code, or make it available for free. You cannot restrict how other people use your (GPL licensed) code, other then what the GPL sets as boundaries itself.
So, if I pay the $30.00, and look into the code, see it depends on the XOOPS core for it's main functionalities, I can offer the module for free on my website. That would kinda take the sting out of the commercial bee, so to speak.
So, how would you have to go about this then? There are two options.
First, make sure your module doesn't use the XOOPS core classes and can function as a standalone application, thus making it a separate part of the system. But this kinda defeats the purpose of a port, so it's not one I'd recommend.
The second chouce is to ask for a development fee (a small one would be best), when people download it. Also make this a part of the module admin interface, and tell people what they will get for this. I agree that this is a less commercially viable solution, but it's a friendly one too.
You can also ask fees for setup and customisation services, implementation work, and development of course. But these are focussed on services, not code.
This isn't in any way meant to discourage you from walking the path you're waking right now. This post is just meant to make clear for everyone what it means to be developing modules for XOOPS, and the GPL license in that process.
Herko
