OT: Two ways Microsoft sabotages Linux desktop adoption

Mike McCarty mike.mccarty at sbcglobal.net
Thu Feb 16 19:07:38 UTC 2006


Bob Taylor wrote:
> On Wed, 2006-02-15 at 17:14 +0100, Ralf Corsepius wrote:
> 
>>On Tue, 2006-02-14 at 23:08 -0800, Bob Taylor wrote:
> 
> 
> [snip]
> 
> 
>>>Please show us *where* in the GPL/LGPL are the words "static linking"
>>>and "Dynamic linking" used? 
>>
>>Nowhere, but it's how the FSF interprets the LGPL/GPL and how courts
>>have interpreted it, when sentencing SW vendors trying to use GPL'ed SW
>>in closed source projects.

What I say here is based in part on a several day (like three or so)
brain-busting argument session I and few other engineers had
with four (or so) lawyers over the use of GPL and LGPL libraries
in code we wanted to produce for a commercial telephony product.

IANAL.

Here is section 6... (from http://www.gnu.org/copyleft/lesser.html)

6. As an exception to the Sections above, you may also combine or link a 
"work that uses the Library" with the Library to produce a work 
containing portions of the Library, and distribute that work under terms 
of your choice, provided that the terms permit modification of the work 
for the customer's own use and reverse engineering for debugging such 
modifications.

[READ that last sentence carefully. It makes no distinction between
the "library" portion of "the work" and the "non-free" portion of
"the work". The work, in it's entirety, must be reverse-engineerable,
and modifiable for the customer's own use.]

You must give prominent notice with each copy of the work that the 
Library is used in it and that the Library and its use are covered by 
this License. You must supply a copy of this License. If the work during 
execution displays copyright notices, you must include the copyright 
notice for the Library among them, as well as a reference directing the 
user to the copy of this License. Also, you must do one of these things:

     * a) Accompany the work with the complete corresponding 
machine-readable source code for the Library including whatever changes 
were used in the work (which must be distributed under Sections 1 and 2 
above); and, if the work is an executable linked with the Library, with 
the complete machine-readable "work that uses the Library", as object 
code and/or source code, so that the user can modify the Library and 
then relink to produce a modified executable containing the modified 
Library. (It is understood that the user who changes the contents of 
definitions files in the Library will not necessarily be able to 
recompile the application to use the modified definitions.)
     * b) Use a suitable shared library mechanism for linking with the

[RIGHT HERE is where DYNAMIC LINKING is referred to, just not by name]

Library. A suitable mechanism is one that (1) uses at run time a copy of 
the library already present on the user's computer system, rather than 
copying library functions into the executable, and (2) will operate 
properly with a modified version of the library, if the user installs 
one, as long as the modified version is interface-compatible with the 
version that the work was made with.
     * c) Accompany the work with a written offer, valid for at least 
three years, to give the same user the materials specified in Subsection 
6a, above, for a charge no more than the cost of performing this 
distribution.
     * d) If distribution of the work is made by offering access to copy 
from a designated place, offer equivalent access to copy the above 
specified materials from the same place.
     * e) Verify that the user has already received a copy of these 
materials or that you have already sent this user a copy.

[END QUOTED MATERIAL]


>>
>>
>>> I have to agree with many others here.
>>>Linux/GNU, as currently licensed is dead in the water for any commercial
>>>development use.
>>
>>You are plain wrong.
> 
> 
> I don't think so.
> 
> 
>>Linking commercial/closed source works against LGPL'ed libraries doesn't
>>violate the LGPL, linking them against GPL'ed binaries does.
> 
> 
> I will have to see a *written, signed by Stallman* letter to that
> effect. Until then, the words of the license stands.

I have already posted here some messages which purport to be
interviews or statements by Richard Stallman that the GPL and
LGPL were carefully written not to mention exactly what kind
of linking was done, because they realize that technology
changes, and they want the licenses to have effect no matter
how or in what manner the linking takes place. He also stated
that if the header file is included, then the work is derivative,
even if no link has been done.

Linking non-free object with LGPL is intended not to violate
the LGPL. But sections 5 and 6 still apply, and the non-free
software must be supplied in a form which can be reverse
engineered and modified for the customer's own use.

 From the perspective of the commercial developer, the main
difference between LGPL and GPL in code being linked in,
is that GPL is a complete virus, and infects all code it touches,
forcing one to use a license very like GPL for all code linked with it.
Linking to something which is LGPL, OTOH, does not require one to allow
redistribution, only modification for the customer's own use. But in
effect, the source must still be provided to the customer, just
the customer can't pass it along. With GPL, the customer
can redistribute modified versions. With LGPL, the customer
only can modify for his own use, and can't redistribute
at all (unless you just let him).

So, if I write a proprietary program, and link with a GPL
library, I can't distribute. I can use it for myself, but
I can't even give it away. AIUI, today, this means that no
proprietary device drivers can be distributed for Linux,
since they have to link against the kernel, which is GPL.

If I write a proprietary program, and link with an LGPL
library, I *can* distribute, but I must supply the customer
with enough information that he can modify, for his own
use, the entire program. This pretty much means I have to
allow customers to get the source, but for their own use,
not for redistribution.

Of course, there are also effects on the libraries themselves,
but the FSF documentation covers that in great detail,
telling you what it means to use one or the other of LGPL and
GPL for your libraries, so I won't go into that.

Now, what this means for companies is pretty plain. Proprietary
software generally contains what is known as "trade secrets".
These are protected under law. I've participated in a lawsuit
or two over these matters, where industrial espionage was
involved. But once *ANYONE* else knows the trade secret, except
under NDA, then there is ABSOLUTELY NO MORE PROTECTION OF THE
SECRET. So, in effect, linking with LGPL code implies that
companies would have to sell their software, along with access
to the source, with an included NDA which would have to be
agreed to BEFORE THE DISTRIBUTION TOOK PLACE, i.e, before the
software left the plant. And this is the problem with LGPL.

All this presupposes that the FSF is correct in asserting that
linking creates a "derived work" and that the entire executable
is a "derived work" and so forth, which AFAIK, has not been
teted in court. And no corporation wants to spend time, money,
effort, and risk its trade secrets to find out.

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