Re: what does constitute "linking"? - correction

Janez Pers wrote:

> 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.

Sorry for this mixup - no, I dont put my proprietary source
on sourceforge, just the socketized version of the library A, but I
keep my proprietary software (the client) secret.

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

Re: what does constitute "linking"? - correction

Hubert Figuiere wrote:
> On 06/18/2009 10:57 AM, Janez Pers wrote:
>> Janez Pers wrote:
>>
>>> 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.
>> Sorry for this mixup - no, I dont put my proprietary source
>> on sourceforge, just the socketized version of the library A, but I
>> keep my proprietary software (the client) secret.
> 
> Why don't you juste share it? After all somebody share the library so
> that you can use it, so it would be fair that in exchange you give
> something back.
> 
> Don't you think?

Well, I asked for a legal view. Regarding the spirit of open source, I 
am pretty much sure that it violates it, but the spirit is not
enforceable.

Few side comments:

I did not yet do any of this, I am asking for clarification
to plan my future activities. The reason for this would be for
example that the development would be paid by someone else who does
not want the financed product to be available to everyone, not
my/our greediness. And the initial motivation, as I described, comes

Re: what does constitute "linking"? - correction

On 06/18/2009 10:57 AM, Janez Pers wrote:
> Janez Pers wrote:
> 
>> 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.
> 
> Sorry for this mixup - no, I dont put my proprietary source
> on sourceforge, just the socketized version of the library A, but I
> keep my proprietary software (the client) secret.

Why don't you juste share it? After all somebody share the library so
that you can use it, so it would be fair that in exchange you give
something back.

Don't you think?

Hub

Re: what does constitute "linking"?

Janez Pers wrote:
> 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.

You should throw in a copy of the text of the GPL and (an offer for) the
sources with your binary distribution.

In my opinion you are in a grey area where your intent (to avoid GPL
licensing) can be used against you. OTOH, copyright has inherent limits
and you may find a judge that thinks you are right. I don't know of a
legal precedent for your case.
If you are trying to stretch the limits, be sure to follow the letter of
the GPL to the latest dot. If you slip up, that might be used as an
excuse to settle the legal question at your cost.

> 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?

RE: what does constitute "linking"?

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.  

Re: what does constitute "linking"?

Hardy, Allan wrote:

> 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.

> 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.

Thank you, this is VERY informative answer, and it is exactly what
I was looking for.

Janez.

Question regarding GPL and membership requirements for a standards body

Re: Question regarding GPL and membership requirements for a standards body

Akiba wrote:
> I'm running an open source project to implement the Zigbee Protocol stack.
> The code is currently protected by the GPL, however there's been a challenge
> to the validity of the license. The problem comes from the fact that the
> Zigbee Alliance requires membership in order to use its spec for commercial
> projects. Although my code is license free, it's claimed that the membership
> requirement is a licensing fee.

Only for somebody who wants to read the specification.  As far as I can
tell from the part quoted in your blog post, there is no restriction on
releasing developed code to (commercial) third parties who do not use
the specification document.

On other words, the membership requirement does not affect the _code_.

Best regards,
Clemens

Re: Question regarding GPL and membership requirements for a standards body

On Fri, Jun 19, 2009 at 2:48 AM, Clemens Ladisch<clemens <at> ladisch.de> wrote:
> Akiba wrote:
>> I'm running an open source project to implement the Zigbee Protocol stack.
>> The code is currently protected by the GPL, however there's been a challenge
>> to the validity of the license. The problem comes from the fact that the
>> Zigbee Alliance requires membership in order to use its spec for commercial
>> projects. Although my code is license free, it's claimed that the membership
>> requirement is a licensing fee.
> Only for somebody who wants to read the specification.  As far as I can
> tell from the part quoted in your blog post, there is no restriction on
> releasing developed code to (commercial) third parties who do not use
> the specification document.
>
> On other words, the membership requirement does not affect the _code_.

  The key trick really is, the protocol is covered by IP.  The
document gives you a free license to the IP, if you are a non
commercial entity, or a memory of the alliance.

  The best people to ask is the alliance themselves.  It's their IP.
This isn't a code licensing issue, unless, of course, you release it
under the gpl3.

--

-- 
-- Thomas