I have been trying to show folks over at the JCD-A a way to, without any admission of GPL violation, redesign the way their proprietary code works with Joomla!. It hasn't been received very well, but I hope that someone can find this useful.

Per the FSF, under the GPL, if a process calls another process, independently and no functions or classes are shared, the two are separate and distinct works. To illustrate how this might be done in Joomla!, I put together a simple example, that I called com_gplexample and hello.php.

Here's the breakdown. gplexample.php, being the main file for the Joomla! component, acts as the abstracting bridge between Joomla! and a BSD licensed script, hello.php. gplexample.php includes task.inc.phps which simply holds my $task related functions, so look there for the actual interfacing. The significance here is that the BSD license is not compatible with the GPL, yet through this implementation, I keep the two as separate, distinct works.

The way it works is the component provides the UI for input and output. It takes user input and puts it into a CURL HTTP request for hello.php. hello.php is accessed by passing it arguments like if you were to call a program from within another one. Obviously, they are two distinct entities. The BSD licensed script takes the information and does with it what I've told it to and passes it back as an HTTP response. The output is received by the component code and formatted for output. In this case, I ask for the user's name, it goes to hello.php to say "Hello there, $name" and sent back to be formatted inside a div. Simple, but I think it illustrates the point. You could adapt this to use Ajax or embed the non-GPL code's functionality inside an iframe.

As long as you aren't reaching into Joomla! proper to directly use it's functions or classes, you have not created a derivative. Also, the data Joomla! uses is stored in a database. To my understanding, there's nothing wrong with you connecting to that same database to grab data. If you need a user's session data, pass it as an argument for the non-GPL code. There are all kinds of possibilities to meeting the requirements of Joomla! and writing closed, proprietary code.

The biggest advantage here is that you no longer depend on Joomla! exclusively. You could take this generic code and create bridges for other CMS's. This would broaden the customer base for the product and allow you the opportunity to expand a potentially very limited niche market. After all, most CMS's provide similar functionality and chances are, if there is a demand under Joomla!, there will be demand under XOOPS, CMS Made Simple, e107, Typo3, and on and on and on.

If you would like to try the whole thing out, I have an installable package of it here. Note that you will need CURL support in PHP for the component to work properly. I welcome any and all thoughts on this.

Regards,
Daniel J. Givens
Jamandall Endeavors, Inc.

DISCLAIMER: The comments made here are strictly mine and do not represent the position of any other organization I may be affiliated with.

Welcome to our forums. 

I am sure I am not the only one here who appreciates that some are proposing solutions to the issue instead of threats.

As I am no coder or lawyer, I am eagerly waiting for a reply to your proposal.

Thank you for the warm welcome.

I feel I can see both sides of this as a relatively disinterested party. I'm new to Joomla!, having only been working with it for a couple of months while I do some custom component work for a client. I am, however, a long time proponent of free software, but also understand that people have to make a living. I would personally rather see all code released under an open source license, but I'm not going to say "poo poo" to a developer that decides on a different route.

Joomla! and OSM have every right to place whatever restrictions on the use of their code as they like, just like other developers have the same rights over their code. Rather than complain about it, I think it would be better for everyone to focus on coping with the situation at hand and trying to make the most of it. Sometimes a little push is what is needed to spark innovation. Am I an optimist? Sometimes I am, but I try to work situations to my favor, even when they don't seem like they could be at first.

Let me clarify further how this method can be used. CURL, Ajax, IFrames are all options that are easy, using HTTP as the means of communications between the separate applications. One could just as easily be done by executing the non-GPL script by using one of the Program Execution Functions and passing the information through argv, as if you were executing the script on the command line.

Also, I think people are having a hard time with the idea with one concept. If you reach into one application to use its API directly, such as to access a variable, execute a function, extend a class, instantiate or use or access information stored in an object, you have done enough to be considered a derivative work, according to the FSF's interpretation of the GPL. The Joomla! folks may have another interpretation, though, and I won't speak for them, but I can reference the source of the GPL.

Since you aren't using Joomla!'s library style functions, variables, or classes directly from the non-GPL compatible work and the GPL compliant component isn't using the API to the non-GPL compatible work, you don't run into this issue. While it certainly flies in the face of the spirit of the GPL and the philosophy of the FSF, the 3PD have said plenty of times that they don't care about those things since they are overly optimistic and completely unrealistic. Seems to have worked for Linux (the kernel) and the businesses that would have otherwise not been without the kernel.

Anyway, I must say once again, I speak for myself and no one else. I just wanted to present information as stated by the FSF to further backup my solution and why it makes sense. Is it ideal? Nope, but everyone has to play by the rules they are given. If someone chooses to distribute non-free, or non-GPL compatibly licensed software to work on a GPL platform, they have to figure out ways to do it without violating the terms by which the platform is distributed. Even if they don't agree with the position of Joomla!, they (and their customers if they are 3PD) would be better suited to work with the situation and do their best to make forward progress.