Hi Mithrandir:

You misread my post. I said that XOOPS modules DO have to have the XOOPS core to run, in much the same way Linux applications have to have the Linux kernel to run.

Quote:And I read the GPL rules such that if a program/module/piece of code is dependant on GPL software, it HAS to be GPL itself. I am not saying that would be the case in a court of law, but that is how I interpret the GPL rules.

Quote:
All my code is GPL - by the above mentioned principle - no matter what the client says or does. Out of respect for the client, I will not release the work unaltered (e.g. you won't see me release AMS behind the back of Brash). However, I reserve the right to use elements developed in one project, when developing another. These elements can be a new XoopsForm element, an object approach or a rating feature.

@Mithrandir: Sorry, for being quick to jump the gun, I follow you now. As you impelement classes and functions, which are released under GPL, your code is requiered to be GPL, and as you rightfully say "no matter what the client says or does". Good business practice, and out of respect for your clients needs, you follow your clients demands, which might be, not to release the code to the public. And as a great negotiator, you try to get the client to release the code at some stage, as this will also benefit the client.

Great thing!

Quote:
wow... you start by assuming that the authority of my experts is of little or no value? And you don't even know them! My experts are not just my own experts, but our national government's lawyers who are dedicated to shedding light on the legal issues associated with working with open source software. They have made extensive and comprehensive studies of open source licenses and how/when to use them, in close collaboration with our nation's top researchers and professors on digital rights. As well as some european and other international collaborations. So disregarding their authority in this is not a good conclusion.

Quote:
No, I am not, and if you had actually read my whole post, you would have understood my points there. I said that the GPL is written for compiled languages, and the terms should be reinterpreted for use with interpreted languages.

Quote:
Ah, reality. Where in the GPL license does it say you should interpret those terms as you suggest? Has this been legally certified by a judge? The answers to those questions is 'it doesn't' and 'it hasn't'. So much for reality...
Quote:
So that's the Mambo Interpretation of the GPL, which is differnt from the XOOPS interpretation, which is different from the PHP Nuke interpretation, etc. etc. etc. We have FAQ and forum posts on this matter as well, do we have less authority on this then Mambo? We've been around longer... Does that give us more authority? I don't think so.

Quote:
In the common interpretation that is not (completely) true. The GPL does not (only) talk about distributions, it talks about code being part of the whole program. The distribution terms of the license are obviously written for compiled languages, as the source code is not readily available to it's users like the code is for interpreted languages like PHP. So the 'packaging' terms of the license are less valuable for XOOPS (and Mambo as well). Untill this has been legally challenged and certified, of course.
The XOOPS project's interpretation of the GPL license focusses on the 'part of the program' terms, as they are subject to interpretation better. And this is the difficult part: for compiled languages the terms for when code is considered to be part of the whole program are well defined in the license and FAQ, but not for interpreted languages.
In our interpretation it is a little too easy to say 'it's not in there so it must be allowed', and in the spirit of the license we make the interpretation as I stated above in my previous post.

Quote:
Agreed there.

Quote:
That's not how we interpret the terms of the license. Again, here's where the 'part of the whole program' terms come to the foreground. These terms are written for compiled languages, and deal with inclusion of libraries and calls to classes etc. That is not exactly the same with PHP applications like XOOPS.
XOOPS is definately not an operating system, it's simply an advanced script interpreted by the PHP parsing engine. That makes the parsing engine the operating system, as that interprets and executes all the commands (operates, hence the term operating system). By your own logic, all PHP scripts would have to be licensed under PHP's license, which of course is not the case. So that hierarchy has been decided long ago already and is not in question here.

XOOPS modules are, because of the way XOOPS's object orientation, by definition extensions to the whole program. The independancy of the modules is not their distribution (as that GPL term is for compiled packages), but their dependancy on code from the XOOPS core in their operations. If they can function without any GPL code, but have an interface with XOOPS to send the results to a XOOPS page, then the dependancy is very small (and thus the licensing as GPL not mandatory). However, XOOPS's architecture is such that most modules will use the core classes extensively and thus rely heavily on the GPL code. Thus, we consider them as part of the whole program (in the spirit of the GPL license), and if released, they should be released under the terms of the GPL license.

Again, this is our interpretation, one which we have checked and tripple checked with the leading experts of the Dutch government, and which we have found to be the most common interpretation. I am not saying that this is the *only* interpretation. If Mambo's interpretation works for them, that's fine with me. Mambo isn't (as) object oriented like XOOPS is. And these interpretations are just guesses untill someone decides to seek certification by a judge. But knowing the international legal system, that is a long and expensive process.

Bottom line is that the GPL is really unfit for use with interpreted languages. We have to make interpretations and leave room for that as well. We have a commonly used interpretation we strongly believe in (and would take to court IF nessecary). We don't begrudge any other scripts their own interpretation tho. Fransisco Burzi added a 'you are not allowed to remove the copyright notice in your pages footer' restriction to PHP Nuke, which has been legally unchallenged for a long time. Does that make it a valid restriction? Even that is legally uncertain untill a court makes it's ruling.

Herko

Herko:

It wasn't my intent to discredit your experts, but just to remind you to always consider the source.

Unfortunately, I can see I'm not getting anywhere with this. You guys are only shooting yourselves in the foot with this interpretation. There are developers out there who would love to develop and sell commercial XOOPS modules, but will not because of how you have interpreted the GPL regarding interpreted languages (I of course read your whole post--3 or 4 times, actually).

I've considered starting up a company to develop and market commercial-grade XOOPS modules to the community at a reasonable price (i.e., $25-$100) and provide (1) ongoing support, (2) maintenance releases that coincide with XOOPS releases, and (3) upgrades with major XOOPS releases. But obviously with this stance, I can't do that.

Xoops is a great security, user, and content management framework on which commercial application developers could develop whole larger-scale applications, but that is not happening right now because of the GPL interpretation for modules.

So, that's all I have to say. Am I alone in my thinking here? Does anyone else agree with me?

I'm only jumping in here to say this whole thing is comic relief. But it isn't funny anymore.

As soon as I see the terms "free software or GPL/LGPL/anyGPL" and "Lawyer" in the same paragraph I'm sure that the "free" part is toast. I'll not understand how the two could ever go together and still have quality free software. Lawyers won't staple papers together without a fee.

I don't understand why someone can't create a commercial model for modules as long as they aren't reselling or forking someone else's work and claiming it as their own. Doesn't matter if the dependent app (xoops) is under GPL. Loads of apps do this all the time.

For my needs (non profit) and budget (limited) I need the existing free Open Source model already in place. But sell all you want. I'll only be able to pay for apps that are low cost (like FlashChat).

No need to reply to my post with excerpts or interpretations of licensing documents. I'm staying far away from that part of the discussion.

DonXoop,

You raise an important and difficult point. How to have both the free development that has made XOOPS (and many other applications) what it is today, and have a commercially viable industry based on that development and platform as well? Some have found solutions for that, and I personally think the solution for XOOPS is not in the code, but in the added value of services. There are many developers out there who create great modules based on their own ideas and ideas and code gathered from the community. IMO it's not this code that they should offer, but the service of creating it. Combined with support services, implementation services, customisation services, hosting, complete site building and implementation, design (all services), you have a very viable commercial enterprise. But, not if you see your market as the XOOPS community. Modules are commissioned, and if the client agrees, released to the public with the added services sold separately. If the client doesn't want to have the code released, then it may only be used by the client and not redistributed (or only under the terms of the GPL).

The XOOPS community thrives on open development, with everyone pitching in and adding his or her bit. So this is where you can find all the code, and the people who are willing to pitch in some free time. The core is based on this principle, and will be based on this principle for as long as we possibly can. ANd that's forever if I can help it.

So we'll have a nice mix of pro's who cater the world with high quality services, and a community who create and support an open and free (as in speech) base and platform for everyone to use.

That's how I see this, just my 2 cts.

Herko

Quote:

I join you in thinking the same. It's a shame XOOPS has taken this stance as it makes it hard to operate commercially in the XOOPS world. I hope also that Mambo's interpretation doesn't drive professional module developers away from XOOPS and towards Mambo.

I run an ASP business based on XOOPS, and develop modules for commercial use that we use to run multiple client sites together. We offer a lot of added value through support and application hosting.

But if an unhappy client want's to take "their" website to another supplier then there is real difficulty as we only have two options:

(a) We hand over all the module code we've developed from scratch for our ASP business with no license restriction (because Herko says it has to be GPL), or

(b) We tell the customer that it's tough and they can't take "their" website to another suppplier (ie. we don't release the code).

Niether option seems particulary fair. In my opinion, a fair solution for both parties would be to say to the client, yes you can take all your XOOPS site somewhere else, but the modules we use to run *our* business can be sold to you (with restrictions on distribution etc).

I'd really value some feedback about this.

Thanks,

Andy

Wow, tis is a blast from the past . I think your somewhere between a rock and a hard place with this Andy as the GPL which XOOPS is released under is quite clear on this. If you are to make a living out of developing for and supporting Xoops, then the only options I can see that protect your interests are;

(a) Never actually release your module code, but instead just allow your customers exclusive access to be able to use it on their website (the same as your option b above). Make sure that you make it very clear for customers which modules are available for use exclusively through your hosting services.

(b) Expand your modules so that they are actually able to run as a stand alone item, and independently of Xoops. This will release you from being tied into the GPL, and will then allow you to release your code under any license you wish.

Option b would be a lot of extra work, and I doubt that what you would gain by doing it would be worth your while. This leaves you with option a, which as you say is not exactly fair, but is the only one that protects your interests as a module developer for a GPL product. There is not a thing you can do to stop people from distributing your code that you depend on for your income once it is released, so the only card you as a developer have left to play is to not release the code at all and allow people the use of it in a controlled hosting environment.

Brash,

Thanks for your reply... which basically confirms my conumdrum!

Andy

PS. Herko, what's stopping you deciding to allow modules to be made under any license? Why do you actually prefer a very strict interpretation of the GPL for Xoops? Is it because you genuinely believe that it's a technical issue (ie. modules use XOOPS core classes) or because you believe tighter commercial licenses for modules are a bad idea?