11
Mithrandir
Re: Closed source modules?

Yes, Herko's explanation is good.

One should also keep in mind that the GNU/GPL is a license to protect the USER of a program/application - It does not say that you everyone should have access to it, but those, who DO get access to it, should also have FULL access to it (including source code, that is).

12
intel352
Re: Closed source modules?
  • 2004/6/21 18:09

  • intel352

  • Module Developer

  • Posts: 824

  • Since: 2003/11/23


if you had your module talk to the closed-source xml-rpc app, you would likely have to package the closed source app with the module, correct? and if that happened, it would need to become gpl, according to what you guys are saying.

am i right?

13
Mithrandir
Re: Closed source modules?

Yeah. The big problem here is that the code is not really DISTRIBUTED and as the GNU/GPL license says:
Quote:

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope


It is a question between you and the maker of the xml-rpc app if you are allowed by THEM to make it into a module (because you are basically modifying their work)

If you are giving this to a client, I would also say that you ARE distributing it - because you will not be 100% in control of what happens to the product afterwards and when you supply your client with a GNU/GPL program you cannot restrict its use and distribution performed by the client. As Herko stated, modules for XOOPS must be GNU/GPL licensed.

If the client is in-house, I guess it can be argued that you are not distributing it, but if the client is external, you are under the GNU/GPL license not allowed to restrict what they can or cannot do with the product. If this is the case, I think that you cannot make the app into a XOOPS module without licensing it with the GPL - which will most likely break the original license of the xml-rpc app.

I think it is a matter of definitions. Definition of the product you make and a definition of the customer.

Sorry if this contradicts what I said earlier, but that was based on me thinking it was a completely internal project.

14
WickedLogic
Re: Closed source modules?

I would not have thought so, because xml-rpc is nothing more than an http call to an api (more or less). Just the xml-rpc interface and the code it talked to the xml-rpc server in the module would have to be gpl'd. Other xml-rpc clients not in modules of XOOPS would not affect the xml-rpc server code, why would xoops.

Sorta like how seperate programs using fork or exec do not have to be gpl'd, with the grey area being the level of intimacy of the data structures passed back and forth.

Because the xml-rpc server could be on the same machine or a dedicated machine on the net somewhere, I might not even be able to packaged it.

Quote:
What is the difference between "mere aggregation" and "combining two modules into one program"?
Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.

Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL--if you can't, or won't, do that, you may not combine them.

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. http://www.gnu.org/licenses/gpl-faq.html


I'm not really bothered either way as long as I know where to draw the line, and I would rather be over cautious. XOOPS looks like a great project and I will use it for other stuff that I can open source and gpl.

15
Herko
Re: Closed source modules?
  • 2004/6/21 18:28

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


With keeping it 'private' I meant that you do not redistribute the code. So having only one site, or only sites owned by your client, would be doing that. Then you don't have to make the source code available, because it stays with the original owner of the code.

As for having a closed-source app working with XOOPS, if you have the app write to the XOOPS tables, and have a page that brings XOOPS core variable values (isuser, iud, etc. etc.) to the application, then they wouldn't share processes, as the app could function independantly of the core. You can do this using XML-RPC, or whatever. But then it is possible.

To bd_csmc, the GPL doesn't have much to do with 'packaging', if you want to add the closed source app to the package, you're free to do so. As long as the apps processes don't mix too much. At least nothing essential.

Herko

16
intel352
Re: Closed source modules?
  • 2004/6/21 18:29

  • intel352

  • Module Developer

  • Posts: 824

  • Since: 2003/11/23


to support PostNuke's argument, couldn't it be said that XOOPS is (arguably) more complex than a *Nuke CMS? and so, comparing the XOOPS process against the postnuke process, is it possible that a module created under XOOPS (and thus licensed GPL) could be similarly created under postnuke or phpnuke and not be licensed GPL, due to the simpler processes?


this is just a question for sake of curiosity, lol, in the spirit of discussion. i've worked with both phpnuke and xoops, and that's why i suggest phpnuke is possibly simpler, in that you just include a few files to gain access to functions, but in XOOPS it seems that including files changes much of how a module acts


lol, maybe i'm just talking out my *ss, it's just a possibility that i was considering



17
intel352
Re: Closed source modules?
  • 2004/6/21 18:32

  • intel352

  • Module Developer

  • Posts: 824

  • Since: 2003/11/23


@herko - good to know

18
WickedLogic
Re: Closed source modules?

To Herko, the deffinition of redistribute here is a little fuzzy for me. I would not be giving away the code or be selling it as a product (open or otherwise), but selling access to the application. Either way, the fact that it compiles as a single application on each request using gpl'd functions/libraries I think is the real sticking point.

If that is ok, then the issue is what is meant by distribution.

This seems to be a question on a lot of people's minds and not just related to xoop.

19
intel352
Re: Closed source modules?
  • 2004/6/21 18:44

  • intel352

  • Module Developer

  • Posts: 824

  • Since: 2003/11/23


ah, so you'll be creating a XOOPS module (for sale), that allows the clients to connect to your server (where the xml-rpc app is stored)?


sounds good to me

20
Herko
Re: Closed source modules?
  • 2004/6/21 18:48

  • Herko

  • XOOPS is my life!

  • Posts: 4238

  • Since: 2002/2/4 1


Selling access to the application is a service, one that has nothing to do with the code itself. You sell code execution, bandwidth, storage. You can do that with apps under any license. The redistribution of code is only when you dicede to use the module for somene else then the original (owner).

Herko

Login

Who's Online

234 user(s) are online (139 user(s) are browsing Support Forums)


Members: 0


Guests: 234


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: May 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits