Re: GPL (was GUI language for beginners)

[Shachar Shemesh]

As it is clear that I have been misunderstood, I'll try to explain again.

Wine is LGPL. As such, it is not covered by this discussion.

Let's then take the wine code, and fork it. We'll call the new program 
"Winw", for "Winw is not Wine". Winw is licensed under the GPL (as the 
GPL is LGPL compatible, this is perfectly ok). Now let's look at the 
email again.

Muli Ben-Yehuda wrote:

Merely linking with a library does not make your software derived work 
of that company! How can that be?
   

What if all your software does is add a "main()" to a 100,000 lines of
code in the library? by the provisions of the GPL, linking your code
with a GPL'd library makes your code a derived work. 

 

You missed my point. The question is not whether it sometimes is. The 
question is whether it is sometimes isn't.

Quoting the GPL FAQ: 

Q: If a library is released under the GPL (not the LGPL), does that
mean that any program which uses it has to be under the GPL?
A: Yes, because the program as it is actually run includes the
library.
 

That establishes, beyond the shadow of a doubt, that the FSF consider it 
derived work. They are not the determining factor, however. The GPL is 
based on the copyright law. Just as you wouldn't want SCO to decide what 
is and what isn't derived work based solely on their whim, you wouldn't 
let the FSF do the same.

The question, therefor, remain. Does merely linking (dynamically) with a 
library make my program a derived work of the library?

Let's take an example. Suppose Wine is distributed under the GPL (It's 
LGPL, but for the sake of discussion). 
   

No no no, that's exactly the difference between the GPL and the LGPL!

 

Then strike "wine" out, and put "winw" in instead.

According to your logic, any 
program that is built to link against Wine is a derivative work of Wine, 
and therefor must be under the GPL. 
   

Correct. 
 

This is patently absured. 
   

Why is it absurd? speaking as a hypothetical WINE developer, if you
want to use my hard work (link against wine) you have to contribute
something in return - make your code GPL. 

 

There is a seprate question here. Just because I may or may not think a 
certain activity just, doesn't make it also legally enforceable.

Effectively, a Windows program that uses the winw libraries to run on 
Linux cannot be considered derived work of winw. Winw did not even exist 
when the program was written and compiled. How can the license for winw, 
or what the copyright holders for winw think, affect the question of 
whether Word is a derived work of it or not?

And furthermore - if Word is not a derived work of winw, why should it 
be covered by winw license?

Most of 
the programs that link with Wine never heard of Wine in their entire 
life. They were built to link with Win32 API, expecting Microsoft's 
version of it. How can a software that never knew about my program be 
considered derivative work of it?
   

Do they require a reompilation to link with wine, or is it dynamic
linking in the dlopen() sense?
Obviously, as winw will run the same programs without touching the 
binary, we are talking about runtime linkage.

In any case, it is obvious that the
program is using my work (as a hypothetical wine programmer) and thus
can be considered a derived work of mine. 

 

Like I tried to claim above - one is not deductable from the other. The 
program is using my work now, that's true, but did not use my work to be 
developed. It can therefor not be considered derived work.

I certainly agree with you that in this case, the onus of making the
code open does not lie with its developers (who have no knowledge of
and have never used WINE), but rather with the user who did use WINE,
which is a thorny mess I have no idea how to solve ;-) 

 

No, this is absured. The user has neither means nor obligation. If the 
developer, who has the sources, cannot be said to have created derived 
work, why should a user, who has no means of changing the software at 
all, be held liable for anything? I'm keeping the relevant GPL clauses 
out of the discussion on purpose. The GPL is irrelevant unless we are 
talking about derived work.

For that reason, I'm not sure that the QT GPL license indeed means what 
some people think it means. I'm pretty sure that's what QT's people 
expected it to mean, but that still does not mean this is, indeed, the 
case. In any case, I think the Wine example clearly shows that the mere 
act of dynamic linking does not yet make a program derived work.
   

The FSF FAQ is one hundred percent clear on this subject. See quote
above.
Clear - yes. Legally binding - I don't know.

It is also as close as you can get to authoriative until a
court rules on what exactly the GPL means. 

 

Cheers, 
Muli 
 

You must also understand something else here. The very fact that there 
are some cases where merely linking is not considered derived work does 
not mean that all cases are like that. I chose winw because it's a clear 
case where derived work cannot possibly be even contemplated (I think).

Now comes the part where I say that I'm not a lawyer. I guess questions 
such as "how much of an original work does the program provide", "how 
specific to the work in question is the API", and many many other 
considerations may come to play here in determining whether a given 
program is a derived work of another library.

            Shachar

--
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/


=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]