Joomla! Discussion Forums

Here’s how I would decide in the edge cases that I described above:
· The primary indication of whether a new program is a derivative work is
whether the source code of the original program was used, modified, translated
or otherwise changed in any way to create the new program. If not, then I
would argue that there is not a derivative work.
· The meaning of derivative work will not be broadened to include software
created by linking to library programs that were designed and intended to be
used as library programs. When a company releases a scientific subroutine
library, or a library of objects, for example, people who merely use the library,
unmodified, perhaps without even looking at the source code, are not thereby
creating derivative works of the library.
· Derivative works are not going to encompass plug-ins and device drivers that
are designed to be linked from other off-the-shelf, unmodified, programs. If
Linux is designed to accept separately-designed plug-in programs, you don’t
create a derivative work by merely running such a program under Linux, even if
you have to look at the Linux source code to learn how to do so.
· In most cases we shouldn’t care how the linkage between separate programs
was technically done, unless that fact helps to determine whether the creators of
the programs designed them with some apparent common understanding of
what a derivative work would look like. We should consider subtle marketbased
factors as indicators of intent, such as whether the resulting program is
being sold as an “improved” or “enhanced” version of the original , or whether the
original was designed and advertised to be improvable “like a library.”

Please also remember, that the license doesn't apply to an entire work because one section or page of code is derivative.  If you have largely independent code, it can be separated and distributed under a different license from the derivative work.  You'd only need to leave the derivative work GPL-compatible and only offer that portion of the extension as open-source.  Of course I'm also no lawyer and no expert in your particular extensions, but I'm sure if the 3PDevelopers got together to come up with a solution, a good portion of commercial extensions could retain nearly identical business models to what they currently are using.

Topic: A Suggested GPL Compliant Abstraction Process  (Read 82 times)
rugmonster

A Suggested GPL Compliant Abstraction Process
« on: June 23, 2007, 08:05:06 PM »

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.

Under the GPL, the "bridge" has to be GPL and therefore anything it "connects" to.