'GPL encumbrance problems'

Mike McCarty mike.mccarty at sbcglobal.net
Thu Jan 19 17:56:02 UTC 2006


Andy Green wrote:
> Mike McCarty wrote:
> 
> 
>>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.
> 
> 
> Oh really.  What do you think this means then?
> 
> ''5. A program that contains no derivative of any portion of the
> Library, but is designed to work with the Library by being compiled or
> linked with it, is called a "work that uses the Library". Such a work,
> in isolation, is not a derivative work of the Library, and therefore
> falls outside the scope of this License. ...''
> 
> This is the LGPL dynamically linked case: "outside the scope of this
> License".

Yes, certainly. And one can do whatever one wants with such kinds
of source. But in order for the program actually to be usable,
it must eventually be linked with the library. The lawyers were
of the opinion that if the library is eventually shipped in one
piece with the software, then whether it got hooked up only
when it was executed, or while we were building in our offices
was irrelevant. It was still being linked. And they were of the
opinion that the tool used to do the linking was also irrelevant.
It didn't matter that the linking might be done merely by the
packager. They were of the opinion that a court might decide
that the entire image contained in the ROMs was "an executable".
They were of the opinion that putting everything into one
or more chips might constitute "linking". They were concerned
that distributing the library and then using the loader
to link up proprietary code and LGPL code "after the fact"
could be considered an attempt to evade the provisions of
the license, and might cause a court to view this as devious
behavior.

>>>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?
> 
> 
> Google tells me this seems to exist:
> 
> http://www.myphonecall.co.uk/voip/sip_pbx/epygi/default.aspx

This is not a Gateway, nor is it a Gatekeeper. This is just software
which talks to VOIP. Sorry, I was using a technical term from VOIP,
and didn't make that clear. I wouldn't think there would be any
problem just talking to VOIP. That's easy. Well, not easy. But
the protocol is pretty clear. But a Gateway and a Gatekeeper
need very sophisticated algorithms to track billing and so on,
and do hand-offs when failure occur, and track utilization
and try to balance loads, etc. They are part of the VOIP backbone,
not an end-user kind of thing.

>>From the same place you can buy cards to turn a standard PC into a PABX
> with Asterisk.
> 
> 
>>>>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.
> 
> 
> Section 5 says that dynamically linked apps "fall outside the scope of
> this License", then goes on to define what it considers to make up
> static linking.  Section 6 is where you discover the rules to follow if
> you meet the static linking criteria.

Read what I wrote above about "devious behavior".

>>>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
> 
> 
> Lol... well this will be my last post to you on this subject, since you
> do not seem to be absorbing anything.  Myabe you should email Adobe,
> Macromedia, Xilinx and so on with your theories and see if you can make
> them understand they are breaking your reading of the LGPL.  Good luck.

I guess I haven't made myself clear at all. The issue I'm addressing
is the undeniable fact that there are lawyers who view things the
way that I express them, and that this has an effect on where
Linux gets deployed, and what software gets written for it. This is
not some theory of mine. You may argue all you like whether
lawyers *ought* to be concerned like this, the point is that some
of them *are*.

Personally, I don't give a rat's behind about the whole matter.
I don't care whether Linux lives or dies. But the GPL and the
LGPL contain language which people much more adept at reading
legalese claim are problematic.

The point is, that the lawyers were *unsure* of their footing,
and prudent companies do not spend hundreds of millions of
dollars where the ground is unsure, when for a few bucks they
can get licensing which *is* known to be sure.

As an aside, Adobe does not ship the libraries they use. But embedded
apps do. Also as an aside, there are many many more embedded computers
than there are PCs. (But you already know that, being an embedded
expert and all.)

>>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
> 
> 
> If you want realtime with low latency, do it in kernelspace.  But you
> will find usually only a small region of your full functionality needs
> hard realtime.  The rest of it can be managed without these hard
> constraints in usermode... with dynamic linking to improve memory usage
> and cache locality.

The issues I had in mind deal also with... making sure that there
is sufficient memory to load any given app on demand. You don't want
the cell phone (or whatever) not to be able to load some interface
because memory is full.

> It's good to see though that you are reduced to considering only some
> esoteric 1990s-style should-be-in-kernelspace "realtime" case as
> requiring static linking and having problems with the LGPL.  I guess
> that means we agree that everybody else is going to be using dynamic
> linking and the LGPL is not trying to open their code.

I pointed out that the lawyers I talked to stated that whether
statically or dynamically linked, the language of the LGPL is
vague so that if the library is shipped with the product, then
when the linking takes place is dicey. And, in consonance with
what you write here, the lawyers disagreed with each other about
some of the finer points. But all were agreed that it was risky.

>>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
> 
> 
> I see.. well, thanks for that.
> 
> 
>>I've never used either LGPL nor GPL, and likely never will.
> 
> 
> If you used a copy of linux, of course you used these licenses... or you

Eh? The licenses say things about distribution, not about receiving.

> would not have been able to get the software.  If that's the case, given
> what you say below then you only propose to take from the ?GPL and never
> give.  That's fine... but you should be clear about what your attitude
> actually is.

In what manner have I been less than completely clear? I loaded
Linux onto my machine because I was requested to do so by a client,
not because I wanted it. Now that I have it, I use it. So?

I see nothing reprehensible in taking something someone freely
chooses to offer without expectation of recompense, and giving
no recompense in return. I have done that with some of my software,
by putting it into the public domain. And I haven't ever groused
at not receiving any recompense for software I provided on that
basis.

>>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.
> 
> 
> Well, speaking for people who do contribute to the ?GPL, we will try to
> struggle on without your code somehow.  God knows it will be hard, but
> we'll manage.

I doubt you have authority to speak for anyone but yourself.
Sarcasm is unbecoming.

I couldn't give a rat's behind, as I said. But it is at least
disingenous for you to assume a stance of moral high ground,
when you hamper other people in using your source the way you do.

> Have a nice last word, and then a nice day.

Thanks for the well-wishes. I likewise hope you have a nice day.

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!




More information about the fedora-list mailing list