Re: Static linking under win32

Re: Static linking under win32

[Alexander Terekhov]

> I think the point of conflict is more about what people
> *percieve* LGPL to be about.

BTW, here's rather interesting review of the [L]GPL by OSI's
counsel.

http://www.phptr.com/content/images/0131487876/samplechapter/0131487876_ch06.pdf

"These sections of the LGPL are an impenetrable maze of
 technological babble. They should not be in a general-purpose
 software license. The LGPL even concedes that “the threshold
 for this to be true is not precisely defined by law.” (LGPL
 section 5.) A licensee under these provisions won’t have a
 clue how extensive his or her good faith efforts must be when
 creating a derivative work in accordance with sections 2(d)
 and 5 of the LGPL.
 [...]
 The LGPL, therefore, is an anomaly -- a hybrid license intended
 to address a complex issue about program linking and derivative
 works. It doesn’t solve that problem but merely directs us back
 to the main event, the GPL license itself."

Well, I guess the idea is to simply convert LGPL'ed works to the
"plain" GPL (the LGPL allows this) and stick to the OSI's much
more reasonable (first sale aside for a moment) interprepretation
completely ignoring FSF's politically motivated licensing
smokescreens (I mean their FAQ/quiz/essays/manifestos/etc.)

Now enjoy reading that sample chapter (and consider buying that
book as a whole ;-) ).

regards,
alexander.

Re: Static linking under win32

[Keresztfalvi Laszlo]

On Mon, Dec 06, 2004 at 12:46:24PM -0500, Gili wrote:
> On Mon, 06 Dec 2004 09:34:32 -0800, Phil Frisbie, Jr. wrote:
> [...] 
> >This is what the LGPL is all about.
> >
> >> Regards,
> >> Laszlo
> 
> Laszlo,
> 
> 	I think the point of conflict is more about what people
> *percieve* LGPL to be about. FSF keeps on stating things like "you give

Sorry, I was quoted.. twice.. so it's not my mail :))


I've take a short tour on www.fsf.org and found this link clean and short to
overview :)

About the GPL compatible licenses:
http://www.fsf.org/licenses/license-list.html#GPLCompatibleLicenses

The first two on the list is what we are talking about. It clearly states
for LGPL: "it permits linking with non-free modules". Follow the special
circumstances link where:

"The GNU Project has two principal licenses to use for libraries. One is the
GNU Library GPL; the other is the ordinary GNU GPL. The choice of license
makes a big difference: using the Library GPL permits use of the library in
proprietary programs; using the ordinary GPL for a library makes it
available only for free programs."

I think this clearly explains what you are scared about. Note that LGPL
changed its full name to Lesser GPL to better reflect that it is not only
for libraries but here it was called Library GPL.


Back to Gili:
> users the right to reverse-engineer your final-product" or "you must
> ship the full source-code of the LGPL component with your
> final-product" if you use LGPL code. I've seen explicit mentions

I think you mix the GPL and LGPL at some point. Providing the source of the
used (linked in) LGPL library just means you make available the LGPL'd lib
which you've used and usually available from its author too.. Not your code!

About the reverse engineering I agree with Ross that this is more about
future linking without access to the source. (Usually a quite ugly hack play
with symbols.. chosen only when nothing else possible :)

Regards,
Laszlo

Re: Static linking under win32

[Alexander Terekhov]

> They include a copyright notice and the URL to my website
> so that users can get the full source to the hvdi.dll file.
>
> This is what the LGPL is all about.

Not quite. Go take the FSF's "licensing quiz." ;-)

regards,
alexander.

Re: Static linking under win32

[Gili]

On Mon, 06 Dec 2004 09:34:32 -0800, Phil Frisbie, Jr. wrote:

>Sony Entertainment had no problem including my LGPL library as a DLL in their 
>game PlanetSide. They include a copyright notice and the URL to my website so 
>that users can get the full source to the hvdi.dll file.
>
>This is what the LGPL is all about.
>
>> Regards,
>> Laszlo

Laszlo,

	I think the point of conflict is more about what people
*percieve* LGPL to be about. FSF keeps on stating things like "you give
users the right to reverse-engineer your final-product" or "you must
ship the full source-code of the LGPL component with your
final-product" if you use LGPL code. I've seen explicit mentions
stating that linking to the source-code is not good enough, you *must*
bundle it. I've also seen explicit mentions of static, dynamic link
and/or inheritance (under OOP) from a LGPL library causing your final
product to be considered a "derived work" hence all of the above
restrictions apply to it. It is statements such as these that scare the
bejesus out of me, and coming out of FSF it is something to take
seriously. I take no offence from the actual authors of the LGPL
library because quite often I've found that they did not mean to imply
(or were not aware of) the conditions stipulated by FSF.

Gili

Re: Static linking under win32

[Phil Frisbie, Jr.]

Keresztfalvi Laszlo wrote:

> For the apropo PW32 have just introduced the DLL and API versioning..
> 
> If I develop a commercial application then stability rules and I would use a
> choosen version of pthread (or any other external) library which I link
> against, usually lagging some versions (to be real-life tested). So, even if
> I provide the object files I cannot accept any claims if you link it with
> eg. a newer version of the library either statically or dynamically.
> 
> Moreover, I usually use more than one external library with some licenses so
> then I must provide those too to really enable you to relink..
> 
> I think this would be not a real case if the application is not something
> simple and you provide good support which is generally your business..
> Otherwise ask lawers who play that game ;)

Sony Entertainment had no problem including my LGPL library as a DLL in their 
game PlanetSide. They include a copyright notice and the URL to my website so 
that users can get the full source to the hvdi.dll file.

This is what the LGPL is all about.

> Regards,
> Laszlo


-- 
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

Re: Static linking under win32

[Keresztfalvi Laszlo]

For the apropo PW32 have just introduced the DLL and API versioning..

> If you statically link pthreads-win32 with your application, you will 
> need to provide access to object files such that your users can relink 
> the application with, for example, an updated pthread-win32. That is, 
> you might provide yourapp.obj such that a user could build pthreadVC.obj 
> from source and relink to create yourapp.exe. Both the GPL and the LGPL 

If I develop a commercial application then stability rules and I would use a
choosen version of pthread (or any other external) library which I link
against, usually lagging some versions (to be real-life tested). So, even if
I provide the object files I cannot accept any claims if you link it with
eg. a newer version of the library either statically or dynamically.

Moreover, I usually use more than one external library with some licenses so
then I must provide those too to really enable you to relink..

I think this would be not a real case if the application is not something
simple and you provide good support which is generally your business..
Otherwise ask lawers who play that game ;)

Regards,
Laszlo

Re: Static linking under win32

[Alexander Terekhov]

Opinions below are my own; and, just in case, in no way reflect
official opinion or policy of IBM Corp.

Ross Johnson wrote:
[...]
> >2) I must grant users the right to reverse-engineer my product
> >
> >
> No! Not necessarily IMO.

http://groups.google.de/groups?selm=41AE24CE.C8CB3645%40web.de
http://groups.google.de/groups?selm=41AEFAF3.4753F1A6%40web.de

[...]
> Some time ago there was a proposal to change the license to a
> more liberal Open Source license, ...

For the record, I've proposed to switch to the CPL (reciprocal
share-alike contractual agreement). Even Microsoft apparently has
no problems with it.

http://news.com.com/Microsoft+flexes+more+open-source+muscle/2100-7344_3-5384769.html

If you don't like IBM in the role of the Agreement Steward
and/or looking for something "more liberal", you might want to
take a look at a bunch of CPL derivatives:

- Eclipse Public License (absense of defensive patent
terimination clause);

- Lucent Public License (non-reciprocal "academic" version
of the CPL).

regards,
alexander.

Re: Static linking under win32

[Ross Johnson]

Gili wrote:

>	And here is an ugly question that has to be asked... I recently
>read this:
>http://www.javalobby.org/forums/thread.jspa?threadID=15903&messageID=918
>18939&tstart=0
>
>	The implication seems to be that if my product links against a
>LGPL library (pthreads-win32 is such a library) then it must adhere to
>certain restrictions as set down by the LGPL. Two items I am
>specifically concerned with:
>
>1) The LGPL library source-code must be restributed in full with the
>product
>  
>
No! That's the GPL (and even then not strictly true IMO), not the LGPL.

If you statically link pthreads-win32 with your application, you will 
need to provide access to object files such that your users can relink 
the application with, for example, an updated pthread-win32. That is, 
you might provide yourapp.obj such that a user could build pthreadVC.obj 
from source and relink to create yourapp.exe. Both the GPL and the LGPL 
allow you to recover the cost of providing the extra material by the 
way. You don't have to provide this material on the distribution media, 
although many do because it's administratively easier, but you must tell 
your users that the material is available and provide some form of 
reasonable access to it.

Read the preamble to the LGPL to see what the LGPL is actually trying to 
achieve. The legalese is the technical expression of that, but people 
get wound up in their lay interpretations of the legalese. (And some 
people just like to wind other people up over it too.)

Please note that if you use the pthreads-win32 DLL, you don't have to 
provide anything apart from including the pthreads-win32 copyright along 
with your own copyright.

>2) I must grant users the right to reverse-engineer my product
>  
>
No! Not necessarily IMO.

Without checking the license in detail, I would expect this to be true 
in either case only if you don't provide the material they need to 
rebuild/relink the application. That is, IMO this would be intended to 
provide legal sanction for desperate users if and when you have not 
upheld your side of the bargain. For example, suppose you modify your 
copy of pthreads-win32 somehow in such a way as to make it incompatible 
with the public version and don't provide the necessary information or 
materials to allow relinking.

>	Now, not to start a religious warfare here (since it is not my
>intent), but I'd like to clarify if this your intent as well? If I use
>it in my product, must I do these two things?
>  
>
Some time ago there was a proposal to change the license to a more 
liberal Open Source license, but any change would require the agreement 
of everyone who has contributed significantly to the project, if not 
everyone who has contribributed. I guess if the current IBM-SCO case 
goes badly, then that proposal would be quickly resurrected.

Finally, since I'm not a lawer, you must obtain your own independent 
advice on this, but I believe that what I've
said above is consistent with the generally accepted and working 
interpretation of the LGPL.

Regards.
Ross

>On Mon, 06 Dec 2004 17:22:38 +1100, Ross Johnson wrote:
>
>  
>
>>Gili wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>	I'm sure this is a commonly asked question: how do I build
>>>pthreads-win32 under VC++ (7.1 in my case)? I am surprised you don't
>>>ship a project file with the source-code or discuss this in the FAQ :)
>>> 
>>>
>>>      
>>>
>>Yes, it should be in the FAQ.
>>
>>Pthreads-win32 relies on dynamic linking to provide a seemless interface 
>>to it's POSIX functionality - using dllMain to do some per process and 
>>per thread initialisation and cleanup. Static linking requires your 
>>application to call some non-portable routines (see README.NONPORTABLE: 
>>pthread_win32_process_attach_np etc). That's one reason why static 
>>linking is not really 'officially' encouraged.
>>
>>However, there's a VS Workspace file provided that will build the DLL. 
>>It was contributed by a user and I use it for debugging sometimes. 
>>Perhaps you can modify that one and send me the result.
>>
>>Nor do the makefiles that I use to build and test include targets for 
>>static linking.
>>
>>Regards.
>>Ross
>>
>>
>>    
>>
>
>
>  
>

Re: Static linking under win32

[Gili]

	And here is an ugly question that has to be asked... I recently
read this:
http://www.javalobby.org/forums/thread.jspa?threadID=15903&messageID=918
18939&tstart=0

	The implication seems to be that if my product links against a
LGPL library (pthreads-win32 is such a library) then it must adhere to
certain restrictions as set down by the LGPL. Two items I am
specifically concerned with:

1) The LGPL library source-code must be restributed in full with the
product
2) I must grant users the right to reverse-engineer my product

	Now, not to start a religious warfare here (since it is not my
intent), but I'd like to clarify if this your intent as well? If I use
it in my product, must I do these two things?

Thanks,
Gili

On Mon, 06 Dec 2004 17:22:38 +1100, Ross Johnson wrote:

>Gili wrote:
>
>>Hi,
>>
>>	I'm sure this is a commonly asked question: how do I build
>>pthreads-win32 under VC++ (7.1 in my case)? I am surprised you don't
>>ship a project file with the source-code or discuss this in the FAQ :)
>>  
>>
>Yes, it should be in the FAQ.
>
>Pthreads-win32 relies on dynamic linking to provide a seemless interface 
>to it's POSIX functionality - using dllMain to do some per process and 
>per thread initialisation and cleanup. Static linking requires your 
>application to call some non-portable routines (see README.NONPORTABLE: 
>pthread_win32_process_attach_np etc). That's one reason why static 
>linking is not really 'officially' encouraged.
>
>However, there's a VS Workspace file provided that will build the DLL. 
>It was contributed by a user and I use it for debugging sometimes. 
>Perhaps you can modify that one and send me the result.
>
>Nor do the makefiles that I use to build and test include targets for 
>static linking.
>
>Regards.
>Ross
>
>

Re: Static linking under win32

[Ross Johnson]

Gili wrote:

>Hi,
>
>	I'm sure this is a commonly asked question: how do I build
>pthreads-win32 under VC++ (7.1 in my case)? I am surprised you don't
>ship a project file with the source-code or discuss this in the FAQ :)
>  
>
Yes, it should be in the FAQ.

Pthreads-win32 relies on dynamic linking to provide a seemless interface 
to it's POSIX functionality - using dllMain to do some per process and 
per thread initialisation and cleanup. Static linking requires your 
application to call some non-portable routines (see README.NONPORTABLE: 
pthread_win32_process_attach_np etc). That's one reason why static 
linking is not really 'officially' encouraged.

However, there's a VS Workspace file provided that will build the DLL. 
It was contributed by a user and I use it for debugging sometimes. 
Perhaps you can modify that one and send me the result.

Nor do the makefiles that I use to build and test include targets for 
static linking.

Regards.
Ross

Static linking under win32

[Gili]

Hi,

	I'm sure this is a commonly asked question: how do I build
pthreads-win32 under VC++ (7.1 in my case)? I am surprised you don't
ship a project file with the source-code or discuss this in the FAQ :)

Thanks,
Gili