Orange Israel (Partner Communications) is not distributing source code of a modified version of OpenRG

This is the product (router) which is known as Smartbox: 
http://www.orange.co.il/Catalog/Accessories/Modem2/pages/Novatel2/smartbox/

Orange & Partner Communications
https://secure.wikimedia.org/wikipedia/en/wiki/Orange_%28telecommunications%29
https://secure.wikimedia.org/wikipedia/en/wiki/Partner_Communications_Company

OpenRG: http://www.jungo.com/openrg/pr_openrg.html

Here is an HTML code from the top of the page of this address: 
http://smartbox/index.cgi?active_page=page_about

This product includes modules based on BSD, GPL and LGPL source code. 
Click <a href="http://orange.net.il/isp/opensource";
target="_blank">here</a> to receive the GPL and LGPL source code, and
to view the BSD credits.

The link <http://orange.net.il/isp/opensource>, as of now, redirect to: 
http://www.orange.co.il/he-il/internet_and_phone/

I have made a few phone calls to the support department and either 
the employees are lying by saying that they don't understand the
question (perhaps it is an instruction that was given by a higher level
in the company) or they really do not understand anything about this
issue. Some of the employees are even changing the subject.

It is also seem that they have eliminated a feature to connect a
printer to the router (i.e. Network Printer). Some of the employees say
that it is not possible to use a printre with this router and others
say that it is possible but connecting a printer to the router will

How i can use MySQL connector/J with GPL compliance?

Re: How i can use MySQL connector/J with GPL compliance?

tor 2011-10-20 klockan 16:58 +0900 skrev Jou Sung-Shik:

> I think it is possible,
> If my source code has no compile time dependency with MySQL
> connector/J,
> end-user can change their DBMS without modification of source code.

Dynamic linking of proprietary components in an GPL program is not OK.
But license do not stop end-users from doing so if they want (not even
static linking at source level). The rules of GPL applies on
distribution only.

> But I don't know certainly..
> How can I satisfy GPL compliance with using MySQL connector/j?

Do not bundle proprieary components with your application.

Do not require proprietary components for your application to run.

Regards
Henrik

Re: How i can use MySQL connector/J with GPL compliance?

[+list]

2011/10/20 Henrik Nordström <henrik <at> henriknordstrom.net>:
> tor 2011-10-20 klockan 16:58 +0900 skrev Jou Sung-Shik:
>
>
>> I think it is possible,
>> If my source code has no compile time dependency with MySQL
>> connector/J,
>> end-user can change their DBMS without modification of source code.
>
> Dynamic linking of proprietary components in an GPL program is not OK.
> But license do not stop end-users from doing so if they want (not even
> static linking at source level). The rules of GPL applies on
> distribution only.

Can you name a source for your opinion that dynamic linking of GPL
code into a proprietary program is not okay, and then preferably one
that discusses the JVM's particular way of dynamic linking? I am
asking this because Wikipedia says that the status of dynamic linking
is still unclear:

http://en.wikipedia.org/wiki/GNU_General_Public_License#Point_of_view:_static_linking_violates_GPL_but_unclear_as_of_dynamic_linking

>> But I don't know certainly..
>> How can I satisfy GPL compliance with using MySQL connector/j?
>
> Do not bundle proprietary components with your application.
> Do not require proprietary components for your application to run.

I think these advices are too generic. It depends completely on the
way the proprietary and the GPL components interact.

The situation described by the original sender reminds me a bit of
dynamically linking proprietary modules into the Linux kernel,
although it is exactly the other way round there (proprietary driver
into a GPL'ed program instead of the other way round).

Jos

--
Sometimes you're the car, sometimes you're the tram...

Re: How i can use MySQL connector/J with GPL compliance?

Misread your message slightly earlier, thinking you wanted to link a
proprietary module into a GPL licensed program. Here is a new attempt to
answer.

tor 2011-10-20 klockan 16:58 +0900 skrev Jou Sung-Shik:

> I think it is possible,
> If my source code has no compile time dependency with MySQL
> connector/J,
> end-user can change their DBMS without modification of source code.

End user is obviously free to change their DBMS or other sytems
componends with no legal impact on your proprietary license. But it's
important that you license & distribute your software in such manner
that it is obvious your proprietary program is not derived from or
requiring the mentioned GPL component to run.

Dynamic linking of GPL components into proprietary programs is not OK,
but there is nothing in the GPL license that stops end-users from doing
so at runtime (GPL license only restricts redistribution). And if the
GPL component is a plugin to a framework you are using then it's a
cleaner separation than normal dynamic linking of libraries even if
there is still (dynamic) linking taking place.

> But I don't know certainly..

No body does. It is a grey area.

And since it's a grey area you need to include the perceived intentions
of the software authors in your risk calculation and a nuber of other
unknown factors.

Regards
Henrik

Re: How i can use MySQL connector/J with GPL compliance?

tor 2011-10-20 klockan 22:23 +0200 skrev Jos Visser (OSP):

> Can you name a source for your opinion that dynamic linking of GPL
> code into a proprietary program is not okay, and then preferably one
> that discusses the JVM's particular way of dynamic linking?

There is many points of view here obviously.

I have no experience of how the JVMs dynamic linking differ from other
dynamic linking methods and can't really comment on if that makes any
difference. I think not.

As references look up the opinions of RMS & Linus regarding runtime
linking and GPL. The GNU GPL FAQ is also good reading.

http://fsfe.org/projects/gplv3/torino-rms-transcript.en.html#q2-linking
http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html
http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF
http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF

Most people agrees that the question really centers around what is a
derivate work and not the specific method of linking. Now the method of
linking obviously have a bit of impact when it comes to distribution if
using static linking, but fact is that dynamic linking alone is not a
barrier.

> The situation described by the original sender reminds me a bit of
> dynamically linking proprietary modules into the Linux kernel,
> although it is exactly the other way round there (proprietary driver
> into a GPL'ed program instead of the other way round).

The rules are pretty much the same in both cases. It does not matter
which of the application or dynamically loaded entity is GPL and which
one is GPL-incompatible. They only differ in rules derived from what
happens at compile time.

Proprietary kernel modules is cleary a much greyer item than the
discussed GPL:ed mysql driver. But neither is black or white. Hence
dynamic linking of GPL components into proprietary programs is NOT OK
even if there technically is nothing in the GPL which explicitly denies
it given that it happens at runtime and not distribution and GPL
explicitly do not regulate runtime actions.

Regards
Henrik

Re: How i can use MySQL connector/J with GPL compliance?

Thanks for your answer and the references. Some more thoughts around this topic:

I like the viewpoint that in the end of the day it is not the actual
mechanics of the linking process which defines whether there is a
"derivative work", but rather the intention of the author(s). In RMS'
words: "If there are two modules that are designed to be run linked
together and it's clear from the design from one or the other that
they are meant to be linked together then we say they are treated as
one program."

In this view the actual mechanics of the linking might be an
indication of whether there is a derived work, as the GPL FAQ
(http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF) says: "If
the program uses fork and exec to invoke plug-ins, then the plug-ins
are separate programs, so the license for the main program makes no
requirements for them. So you can use the GPL for a plug-in, and there
are no special requirements." I think that this statement is too
general because I can easily envision a situation where a non-free
program starts a plug-in through fork/exec but then communicate so
intimately over the process barrier (using pipes, shared memory or
whatever) that they are essentially part of one program.

In the next entry the FAQ says: "If the program dynamically links
plug-ins, and they make function calls to each other and share data
structures, we believe they form a single program, which must be
treated as an extension of both the main program and the plug-ins. In
order to use the GPL-covered plug-ins, the main program must be
released under the GPL or a GPL-compatible free software license, and
that the terms of the GPL must be followed when the main program is
distributed for use with these plug-ins."

Applying this to the original question (the MySQL Connector/J plug-in)
leads to an interesting situation. That plug-in is a Java Database
Connector to access the MySQL database. JDBC (the Java Database
Connectivity standard) provides a standard API to let Java programs
connect to and access databases. It needs drivers (implemented as
plug-ins) to actually do this so it provides an external API (to the
Java programs) and an internal API (to the plug-ins) to hook all of
this up. A lot of drivers provide extra features (on top of the JDBC
standard), but it is possible to develop Java programs in a way that
they work with all standard JDBC plug-ins. In that latter case a user
can easily use another plug-in to talk to another database (Postgres,
Oracle, whatever).

I would venture that if a Java program is written in such a way that
it is completely independent of the actual JDBC plug-in used that then
means that it is possible to use a GPL'ed plug-in with the Java
program without requiring the Java program to be under the GPL too.
The reasoning behind this opinion is because in that case it is not
clear from the design that these two programs are meant to be working
together since the non-free program could work with any other plug-in
as well. The non-free Java program could be distributed without any
plug-in and with instructions for the user to download the GPL plug-in
separately and to combine the two (though a configuration file and a
JVM flag for instance). If the author of the non-free program chooses
to do the latter there is definitely no breach of the GPL I would say
(because the GPL hooks into the distribution of the software).

If on the other hand the non-free Java program is written in such a
way that it *requires* the Connector/J plug-in (e.g. because it uses
features from that plug-in which are not exposed through the standard
APIs) then there is a potential GPL violation. It would be interesting
to know whether the separate distribution "trick" referred to in the
previous paragraph could be used to circumvent the violation.

Jos

--

-- 
Memory and regret are, when taken together, the set of necessary and
sufficient elements required to produce a time machine.

Re: How i can use MySQL connector/J with GPL compliance?

lör 2011-10-22 klockan 11:37 +0800 skrev Jos Visser (OSP):

> program starts a plug-in through fork/exec but then communicate so
> intimately over the process barrier (using pipes, shared memory or
> whatever) that they are essentially part of one program.

Maybe. No one knows. So we can only speculate, reason about it and make
"risk" calculations.

> but it is possible to develop Java programs in a way that
> they work with all standard JDBC plug-ins. In that latter case a user
> can easily use another plug-in to talk to another database (Postgres,
> Oracle, whatever).

Yes.

> I would venture that if a Java program is written in such a way that
> it is completely independent of the actual JDBC plug-in used that then
> means that it is possible to use a GPL'ed plug-in with the Java
> program without requiring the Java program to be under the GPL too.

It depends.. and again there is many viewpoints.

> The reasoning behind this opinion is because in that case it is not
> clear from the design that these two programs are meant to be working
> together since the non-free program could work with any other plug-in
> as well.

The reverse is also true, it may not be clear that they are not. It all
depends..

but as mentioned the GPL is about distribution, and if the program is
designed in a generic way, obviously fully usable with alternative
drivers and not bundled with the GPL driver then there is no risk of
"contamination".

>  The non-free Java program could be distributed without any
> plug-in and with instructions for the user to download the GPL plug-in
> separately and to combine the two (though a configuration file and a
> JVM flag for instance). If the author of the non-free program chooses
> to do the latter there is definitely no breach of the GPL I would say
> (because the GPL hooks into the distribution of the software).

Yes, and what I said earlier. Do not bundle them together and do not
require them to be used together.

> If on the other hand the non-free Java program is written in such a
> way that it *requires* the Connector/J plug-in (e.g. because it uses
> features from that plug-in which are not exposed through the standard
> APIs) then there is a potential GPL violation. It would be interesting
> to know whether the separate distribution "trick" referred to in the
> previous paragraph could be used to circumvent the violation.

I would not bet on it. And when there is doubt always select the safer
choice of not doing it.

Regards
Henirk

Re: How i can use MySQL connector/J with GPL compliance?

On 22 Oct 2011, at 04:37, Jos Visser (OSP) wrote:

Jos, Hendrik et al

> the actual mechanics of the linking might be an
> indication of whether there is a derived work

If you have not already seen it, you might find the document here of interest:

https://wiki.fsfe.org/EuropeanLegalNetwork/LinkingDocument

We (that is, the unnamed authors) certainly do not claim that it is authoritative, as the decision is one for
local courts to make, and the answer may well be different in different jurisdictions, but it might
provide some interesting food for thought.

Kind regards,

Neil

__________

Neil Brown
neil <at> neilzone.co.uk | http://neilzone.co.uk

Re: How i can use MySQL connector/J with GPL compliance?

lör 2011-10-22 klockan 09:54 +0100 skrev Neil Brown:

> If you have not already seen it, you might find the document here of interest:
> 
> https://wiki.fsfe.org/EuropeanLegalNetwork/LinkingDocument

Thanks. Pretty extensive document on the subject and very good reading.

Just a small correction:

inline functions exists and is used quite a lot in C as well, not only C
++, usually pulled in from library header files. Resulting in a form of
statically linked functions carrying their license requirements into the
compiled program. This is mentioned in the macros section, but section
on shared libraries implies that this is not an issue in C.

What is true is that the inline mechanism is used a lot more in C++ than
C. But is still something you need to look out for when mixing
code/libraries with different licenses in C.

Regards
Henrik