'GPL encumbrance problems'

[Andy Green]

Mike McCarty wrote:


>>> Are you saying we should all re-write open(), close() etc?
...
>>> No, not even MicroSoft says that you can't call open() without
>>> making your code theirs. In fact, no one does that except GPL.
>>>
>>> (I'm not claiming that open() is GPL, it might be LGPL, but

>> Your complaints in the parent post do in fact seem to rely on open()
>> being in a GPL'd library: but Standard C library open() is in glibc
>> which is LGPL.

> No, they do not.

This is not what you said in the grandparent post, as shown above.  See
the end of this post for LGPL section 5 and 6.

> In particular, several years ago (2001 or so) I participated in the
> system requirements and system design of some cutting edge telephony
> equipment (VOIP stuff) and we considered whether we could use
> Linux and some GPL and LGPL stuff in our equipment, and after
> spending weeks reading this stuff, and talking with lawyers,
> we concluded that we could not.
> 
> So Linux went by the wayside, and we used Solaris.

And yet Asterisk, Bayonne etc exist and are sold as solutions your
expensive Solaris implementation now has to compete with.  What were the
lawyers actually asked?  Can we use Linux and keep everything proprietary?

> So, on careful reconsideration, yes, I consider that I am
> probably more competent to lecture on this matter than
> you are, since you seem not actually to have read the LGPL.
...
> As I have pointed out, clauses 5 and 6 of even LGPL
> force any *other* libraries I might link with to be distributed in
> a form which can be reverse engineered and repaired by the end
> user.

LGPL section 6 begins: "As an exception to the Sections above, you may
also...".  The reason is that section 5 deals with dynamic linking to an
LGPL'd library, and section 6 deals with static linking.  The reverse
engineering constraint from section 6 therefore only applies to
statically linked executables that actually contain the binary from the
LGPL'd library.  In the (normal, nowadays) case of dynamic linking, it
does NOT follow that, as you claim, "LGPL force[s] any *other* libraries
I might link with to be distributed in a form which can be reverse
engineered and repaired by the end user.".

Here's BSD's summary (you can be sure they cut the [L]GPL no slack):

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/bsdl-gpl/origins-lgpl.html

-Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4492 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20060119/aabb6393/attachment-0001.bin>