'GPL encumbrance problems'

[Mike McCarty]

Andy Green wrote:
> 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.

Maybe I didn't make myself clear. It doesn't matter *which* of GPL,
LGPL they are. If one links with them, then the licenses seem to
claim that the program produced is some sort of derived work.

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

Eh? You know of VOIP gateways which run Linux?

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

Clause 5 deals with both.

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

You really need to get your prejudices out of the way and listen to
someone who knows his stuff(*), and stop arguing. You obviously know
very little about embedded programming. Dynamic linking and virtual
memory are real no-nos in real-time programming. So is the use
of malloc() in nearly every situation. Static memory maps are the
rule of law in almost all cases. And even if not, the LGPL library
must be present in the image *somewhere*, and some of the lawyers
involved stated that if it is present in the image, then someone
might claim it got "linked" into the image. The LGPL is vague
on just exactly what constitutes "linking" and "executable".

Look, I don't particularly want to argue. In fact, I had more than
enough of that back in 2000 (I guess it was 1998) or so, discussing
this with the lawyers.

I'm just telling you how things work in the real world. You don't
have to like it, but you do have to live with it. If deployment is
important to you, then you need to know that GPL and LGPL deter(**)
deployment. They also deter development of interfaces to proprietary
hardware. And they prevent the use of proprietary libraries. If you
don't care about these things, then that doesn't matter. But if you
*do* care about these things, then you need to know that GPL and LGPL
are carefully crafted to guard GNU and its derivatives from ever having
anything proprietary built into or on top of them. But Solaris doesn't
have this characteristic. (At least the versions I recommended. They may
have put some GPL or LGPL stuff into it since I last looked.)

IMO, if you really want it free, put it into the public domain.

Otherwise, live with the consequences of [L]GPL, or come up
with your own license which is better suited to your purposes.

I've never used either LGPL nor GPL, and likely never will.
The stuff I want to be free, I put into the public domain.
Other stuff I use licenses which seem to fit. GPL and LGPL
do not, and I trow never will, fit my needs.

I've already spent more of my life trying to figure out what
the GPL and LGPL really mean (and I am not sure I know that,
since some of the claims likely would not hold in court [IANAL])
than I really would have liked to.

(*)  in regards to how GPL and LGPL are viewed by american
      corporations and their lawyers, and how embedded code
      works

(**) "deter" and "prevent" do not mean the same thing

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!