Re: OT: Two ways Microsoft sabotages Linux desktop adoption



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!

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list



Relevant Pages

  • Re: GPL encumbrance problems
    ... then the licenses seem to claim that the program produced is some sort of derived work. ... And they were of the opinion that the tool used to do the linking was also irrelevant. ... 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. ... In the case of dynamic linking, it does NOT follow that, as you claim, "LGPL forceany *other* libraries I might link with to be distributed in a form which can be reverse engineered and repaired by the end user.". ...
    (Fedora)
  • Re: GPL encumbrance problems (jdow)
    ... The company lawyers saw no problem with us building and selling a closed source product that included calls to a variety of GPLed and LGPLed libraries. ... The only way the GPL kicks in is if you actually modify executable GPLed code for your product. ... you would then need to make only these changes to the GPLed code available as source ... LGPL states flatly that you must provide all the parts necessary ...
    (Fedora)
  • Re: license question?
    ... >> suspicion. ... Linking is one of the oldest and best defined concepts in computer ... if not then you have to take a very fine reading of the LGPL to ... LPGP-ed Smalltalk libraries. ...
    (comp.lang.java.programmer)
  • Re: license question?
    ... >> suspicion. ... Linking is one of the oldest and best defined concepts in computer ... if not then you have to take a very fine reading of the LGPL to ... LPGP-ed Smalltalk libraries. ...
    (comp.os.linux.misc)
  • Re: GPL [Was: CarrierIQ Software and Forth]
    ... to non-FOSS code (such as system libraries from Apple), ... it would be impossible to use the GPL on Windows ... LGPL is always touted as the solution to these issues. ... license term which nullifies it's premise entirely. ...
    (comp.lang.forth)