what does constitute "linking"?

[Hardy, Allan]

First, you have to consider who owns the rights to the work.  The
copyrights holder can interpret the GPL terms as they see fit.  
As example the Linux Kernel team does not take the same interpretation
as the FSF/Gnu folks do.

Other GPL holders may look to the FSF (free software foundation) for
assistance, so overall, figuring out what the FSF's position is on this
issue is probably the most conservative way to go.

That said, your question isn't really about linking, its about what
constitutes a derived work, in short when would your work which uses the
GPL work be subject to the GPL requirement for reciprocity, when does
your work need to be licensed under GPL

This is a very old question and it's been discussed I'm sure thousands
of times. You are in an area where there is no case law, no judges
rulings to go by, for the most part.  You will in the end be making a
risk assessment.  The GPL/FSF pushes copyright law and definitions to
extremes, especially in definition of a derived work, and simply no one
knows what will ever hold up in court.

So you will in the end be deciding on the risk factors of FSF/Copyright
holder taking issue with you, and the risk factors if a Court Judge
rules if your form of use is a derived work, etc.   Measure into your
risk factors that Open source licenses, as of last Dec 08, are covered
under copyright law, per supreme court.  So you have statutory damages
of up to I think $150k per incident. So 10 users could be $1.5M in
damages. (These are just illustrations), also consider the non financial
aspects, bad publicity, etc.  

Now with that background in mind, the next point is that the Technical
form of the integration doesn't matter as much as you would like it to.
FSF Looks at the whole picture, they look at not just the technical
form, but even the 'semantics' of how well these two applications know
each other, how intimate they are.  Here is a general rule of thumb:

If your applications depends 100% on the GPL application - you have a
derived work in FSF's view.

Makes sense in some way. If your applications cannot function without
the GPL application, that's a derived work and FSF expects you to
reciprocate the benefits of open source and make your application open
source. Note: Regardless of the technical form of the integration.  

So if my application sits on a server in New Zealand and my MySQL (GPL)
database is in France, it wouldn't matter. My application is 100%
dependent on that GPL database and I am vulnerable to MySQL-Sun/FSF not
being happy with me.

As another illustration, a  recent example we had to deal with involved
a a Jabber Server, opensource GPL, and a client application my guys had
written and wanted to distribute.  The client used a standard protocol
and could technically talk to any server, commercial or open source,
that used that protocol.  Where we 'dependent' on the GPL server?  Hard
to say, there is strong technical case of no we were not dependent
because of use of a standard protocol.  However we had only tested
against the GPL server, we only offered support for that server, we
directed the customer to acquire and use that server, etc.  So we made
them test/document against at least 2 other servers.  We had the
documentation/marketing materials go agnostic so to speak, we made sure
to slant the server choice as a customers choice, etc.  All of this was
to get us away from any appearance of dependency, and it made our
product/marketing a bit more robust as well.

So this is the kind of issues and considerations you need to make when
making your risk assessment. Without court cases and rulings, you, like
all of us will be guessing.  In the end, you won't get black and white
answers, just data to make a more informed risk assessment by.

In my analysis your Proprietary Application B is a derived work of the
GPL Work A.  It uses it and seems to depend on it.  I could care less if
its sockets, dlls, static compiling, etc.  Your adding of a sockets
wrapper is moot.

However, you may find that the original copyright holder doesn't care,
perhaps they like and want to encourage your approach because it gets
more people using their product. Who knows.  Ask them.  Look for any
other examples where they have allowed, not taken action against, or
even encouraged this form of integration.  Ask them if they would
release an LGPL version.  I've had a good amount of success just asking
he copyright holder for their view in different usage scenarios.


You are evil.  


Just kidding

Allan

Oh, PS
GPL cannot be revoked once released
The author/copy right holder can offer the same product under as many
licenses as they desire, dual, triple, licensing
The author can decide to stop offering the GPL version whenever they
please, they are free to choose their licensing approach, they just
cannot revoke backwards.




-----Original Message-----
From: legal-bounces at lists.gpl-violations.org
[mailto:legal-bounces at lists.gpl-violations.org] On Behalf Of Janez Pers
Sent: Thursday, June 18, 2009 10:56 AM
To: legal at lists.gpl-violations.org
Subject: what does constitute "linking"?

Dear All,

I have a bit unortodox question. I cannot find any better
place to get an answer, if there is, please point me in
that direction.

The main question seems silly: does connecting the
proprietary application with the GPLed one constitutes
"linking" in terms of GPL license?

The straightforward answer would probably be no, right?

But, consider a following scenario:

1. I take the GPLed/LGPLed library "A" and "socketize" it -
meaning, I write the interface to the library that
provides its funcionality via TCP sockets.

2. I publish the source code to this interface as required
per GPL, as the new improved library clearly constitutes
derived work.

3. I write my (proprietary) application "B" in a way that uses
library A's services through TCP sockets, and do not publish
this source. I sell the binaries of B and bundle them with
binaries of socketized version of A. I even put it on
sourceforge - no hidden tricks here.

I can even reasonably argue, that I added valuable new
functionality to the library - now it can work over the
network.

But, this way I circumvented the protection of the GPL which
perhaps author assumed when he choose GPL license. By letter
of GPL, I did nothing wrong, right? But it is a clear violation
of the intent of the GPL, I guess.

Now, a related question. Can the copyright holder of A revoke
the GPL licensing of the existing library? Or is his only option
to either continue new GPLed versions, or scrap it alltogether?
Can I provide the downloadable sources of his previous GPLed
library, regardless of his wishes?

BTW, the original idea is not as evil, as it may sound here -
my original intent was to provide way in which a large number
of low powered, low cost networked devices could use advanced signal 
processing/computational libraries. Then I figured that actually
I could use GPLed libraries this way as well.

Am I correct? Am I evil? (Please answer separately, if possible).

Janez.