OSCommerce Product Manager

OSCommerce Product Manager for Windows
Tasklist

FS#170 - Licensing issue with included OSCommerce code.

Attached to Project: OSCommerce Product Manager
Opened by Mario A. Valdez-Ramirez (mvaldez) - Monday, 14 February 2005, 11:37 GMT-6
Last edited by Mario A. Valdez-Ramirez (mvaldez) - Thursday, 17 February 2005, 01:25 GMT-6
Task Type Bug Report
Category Backend / Core
Status Closed
Assigned To Mario A. Valdez-Ramirez (mvaldez)
Operating System All
Severity Very Low
Priority Immediate
Reported Version any
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The new server-side script (oscpm1_upload.php) includes the following files: database_tables.php and database.php.

Those files are covered under the GPL license. If we include them we cannot release the debug versions that use the MadExcept.

If we write the supporting DB code (our best approach to avoid licensing clashes), we still have to include the configuration file includes/configuration.php, which includes a GPL clause.

To our knowledge, configuration files are input/output data generated by the software. So, even if the software is GPL the configuration files should not be GPL unless specified in the license (which then it would become a non-GPL license).

From the GPL FAQ (http://www.gnu.org/licenses/gpl-faq.html):
"In what cases is the output of a GPL program covered by the GPL too?
Only when the program copies part of itself into the output."

The problem with PHP configuration files is that the definitions are really PHP code, copied from the install7.php file. This is messy.
This task depends upon

Closed by  Mario A. Valdez-Ramirez (mvaldez)
Thursday, 17 February 2005, 01:25 GMT-6
Reason for closing:  
Comment by Mario A. Valdez-Ramirez (mvaldez) - Monday, 14 February 2005, 11:42 GMT-6

An option is to ignore the ill-designed clause. But then, if the designer of the configuration script was not aware of this, or if did it intentionally, we would be violating the license.

Another option is to create the supporting DB code (which is very easy), and then let the user define the configuration options by hand (which will be harder to them). The advantage of include the configuration file is that the script should only be droped in the OSCommerce directory to work. By forcing the user to set the DB configuration we are eliminating that advantage.

Comment by Mario A. Valdez-Ramirez (mvaldez) - Monday, 14 February 2005, 11:43 GMT-6

Another option is to read and parse the configuration file to extract the data. In that way we use it but we are not linking the PHP script, thus allowing use the debug license.
Comment by Mario A. Valdez-Ramirez (mvaldez) - Monday, 14 February 2005, 11:44 GMT-6
Another option is to avoid MadExcept. It is good. It looks very useful. But we have really never used it in any release. Maybe we can live without it.
Comment by Mario A. Valdez-Ramirez (mvaldez) - Monday, 14 February 2005, 11:56 GMT-6

However, this is not only a practical problem. What if we want to use another license? We won't be able to do so. We have researched and selected best-of-breed components with liberal GPL-compatible licenses that would allow us to take a decision later about using another license.

The reason is not to avoid our social contract with the open-source community, but to be able to do things otherwise not possible with a GPL-only distribution. The use of the freeware MadExcept debug component is one example.

It is very unfortunate that MadExcept is not open-source (as defined by the OSI initiative) because is such an easy-to-use piece of software that provides lot of information when a program crashes. Also, it is unfortunate that we have to use it to debug field-distributed programs. Our main goal is to distribute the best open-source application we can; so we create special non-GPL versions for debugging purposes that allow us to reach that goal (even if in a dirty way).

Maybe Stallman would say "shame on you, that is a lame excuse!". And maybe I would agree.

In any case, this is a blocker. We cannot release until solved.
Comment by Mario A. Valdez-Ramirez (mvaldez) - Monday, 14 February 2005, 12:22 GMT-6


The idea about reading and parsing the OSCommerce configuration file to extract the configuration data sound good. But I'm worried about the overhead of opening, parsing, closing each time we call the script.

Comment by Mario A. Valdez-Ramirez (mvaldez) - Monday, 14 February 2005, 12:34 GMT-6


We can read/parse the config files, then rewrite itself with the found values. So it will only do it the first time.

Comment by Mario A. Valdez-Ramirez (mvaldez) - Monday, 14 February 2005, 12:35 GMT-6

We could provide a client-side helper to create the configuration.
Comment by Mario A. Valdez-Ramirez (mvaldez) - Monday, 14 February 2005, 12:37 GMT-6

Let's keep it simple.

Let's include the DB support files of OSCommerce. We will drop the use of MadExcept.

This is pending issue. It will be closed by now, but we need to reopen this later. Deferred.
Comment by Mario A. Valdez-Ramirez (mvaldez) - Wednesday, 16 February 2005, 09:17 GMT-6

The JclDebug unit from the JEDI project provides also exception stack-trace, however, the license is MPL only. So, again, we are being limited by the silly message in the OSCommerce configuration file.

This sucks.
Comment by Mario A. Valdez-Ramirez (mvaldez) - Wednesday, 16 February 2005, 12:10 GMT-6

We can include an exception in the GPL to link to MadExcept or JclDebug.
Comment by Mario A. Valdez-Ramirez (mvaldez) - Wednesday, 16 February 2005, 12:12 GMT-6

That would apply only to our code. Linking to OSCommerce code would force us to follow pure-GPL (without exception).

We can also distribute separate packages for server-side and client-side. But I hate when people do that... I prefer unified packages.
Comment by Mario A. Valdez-Ramirez (mvaldez) - Thursday, 17 February 2005, 01:20 GMT-6


I have posted a question in the JEDI-JCL newsgroup about any plan to dual-license under MPL and LGPL the JclDebug units. However, I won't hold my breath, because it is uncertain if the several authors involved have the intention to dual-license their work.

Now, we can relicense and distribute the client-side (without the server-side components) with the JclDebug code linked. I think we can reuse the old debug-only license text (freeware kind) like we did when using MadExcept.

Comment by Mario A. Valdez-Ramirez (mvaldez) - Thursday, 17 February 2005, 01:25 GMT-6


I've been thinking that server-side and client-side components can be considered different applications that exchange data. Just like we did with the external-modules interface: we created a non-GPL module because the OSCPMWin application and the module only exchange data (thru a TCP socket).

However, OSCPMWin cannot work (fully) without the script. OSCPMWin and the PHP script not only exchange data but also instructions. Maybe they are not really different applications. At least (on a second thought), I don't think so.

Loading...