I'm looking to use XOOPS as the cms side for our site, but need to include access to a closed source php application. I'd like to code it as a module, but am not sure if this is an option as I cannot open source the application.

Does anyone current develope closed source modules, or know if it is even an option. Obviously changes to the XOOPS code must be submitted because of the gpl, but can I write closed source modules?

These modules would be purely for the application, and would be of little/no use to the cms functionality in general.

The alternative, is that I map the user stuff over afterwards, but that seems to defeat the reasoning of extending the cms.

thoughts?

Not entirely an expert, but have picked up bits here and there.

I would think that as long as you do not release/distribute/sell your solution, you can do with the code what you want.

Including closed source applications is not a problem with the XOOPS license, but may be with the application's license - but I cannot know that.
Noone forces you to release the code, you do, unless you distribute it or make it available for download in which case the core and all modules you distribute must be open source - but if you use it yourself, I don't think there is a limitation to what you may or may not do.

Well, the idea I had for the project is that we use a cms for the community side of things. XOOPS looks like a great project, and would allow me to contribute to it while also doing my day job.

We would be selling subscriptions which allow our users access to the application (hopefully as a module).

We would not be re-/distributing XOOPS in any part or sense, just using it for our site where we also have the application hosted.

I was concerned that the gpl requirements would extend to modules used by the cms, even if I write my application module from scratch.

Quote:
It does.

BUT only if you distribute it.
Meaning that if you put the application/module up for downloads or sell it, you MUST give the source code for it as well as you cannot restrict what you customer/the downloader does with it.

It sounds like this will go against the license of the application, so just don't distribute it and you should be safe (I am NOT a lawyer, though, so do NOT take my word for more than that)

Thank you very much for your reply. I'll check around with others who might be doing this and also with a lawyer.

here are a couple of viewpoints that i've seen others voice:

1. any and all code developed to work with the XOOPS framework *must* be licensed as GNU/GPL (viewpoint was based off the GNU/GPL Faq)

2. claims that code not actively distributed with the cms is not necessarily gnu/gpl, and can then be licensed however needed (viewpoint makes the assumption that the GNU/GPL faq is just a person's opinion, viewpoint's opinion is that the gnu/gpl should be read to be understood, ignore other people's opinions, even in the faq)


personally, i lean towards #2 because i had gotten the same impression as #2, until i read the faq. but as #2 points out, the faq is an interpretation, it's not what the license says explicitly.

if you speak to a lawyer, please post his interpretation

After doing some googling and reading through the gnu gpl terms over lunch, here are the thoughts I have come to.

Some of the postnuke people seem to think that modules can be closed sourced and do not fall under the gpl liscence as long as you don't distribute the module with the core as a single product.
example #1

However technically, modules do get executed via php as a single program, even though they are required/included files and are re-executed on every request. To me that seems to suggest that it fits the deffinition of single product, not in distribution, but execution only. Either way, it certainly does not fit the private use clause.

In my case the other option is to find a BSD* style cms, or open up the api via documentation to the application, and use xml-rpc or some other method to make calls to it. That would protect my clients application, and just expose the interface. Of course I can write a cms from scratch but then no-one else would benefit from any changes I would make to the core cms and I be reinventing the wheel. I'm off to go do more googling and reading, but wanted to do a follow up post.

As for a lawyer, although legally it makes the most sense, most lawyers I know would not understand this, because the terms are very tech specific and the gpl was written from a "compiled-only influenced standpoint" (i think). but, without case law, it is all up in the air anyway.

i agree with the postnuke dev's diagnosis. from what i've seen, gnu/gpl states that when using code from a gpl licensed product, *then* your product is gpl, same if you package your product with a gpl product.


so, their argument makes sense. and not the first time that i've heard it.

I have said this before, but I am glad to say this again here:

The PostNuke guys are wrong No, seriously, they take the GNU GPL's definition of 'part of the application' too literal. Module fall under the same license as XOOPS does when the module makes extensive use of processes that are GPL licensed (whether they are modules or core, doesn't really matter). Processes like this are the permission system, user authentication, database connection thru XOOPS' core code classes. If your module uses that code, it's considered part of the whole application, and is then patented under the same license as XOOPS.

In other words: the code is GNU GPL if it uses the XOOPS processes, even if it is NOT released. And under releasing a module we do not count the developer giving it to the one who commissioned it.
Because the code is GPL, there are some rights and limitations that apply to the availability of the source. These apply by default, even if the module is not released. But, this is just a fictual situation, because most limitations apply to releasing the code (meaning that they are only appliccable when the client decides to resell the code, or when you do). So, you can't restrict your clients use of the code in any other way then what the GPL allows you to. You can't release the code under a different license. But you can keep the module 'private', thus in effect keeping the source closed.

I hope this makes it a little bit more clear.

Herko

After rereading the gnu gpl a few times, I am mostly in agreement with Herko's opinion. The only way I would be able to have the application with XOOPS is to have it not be a module or to have an xml-rpc like module-client as the gpl'd module and have it make calls to our closed source app. Either way, if anything was done to extended user management or to adjust anything else in the cms it would have to be gpl'd. (again, I was planning on that part).

Keeping it private really means for yourself, and not for a group of users via a website, although in that sense if no-one knows, no-one asks... not a risk I can take with this particular project, but one that wouldn't matter with others. I'd love to hire a lawyer, or here something official on this. grin, maybe I should go have a word with RMS, he's only a few towns away.