Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!howland.erols.net!newsxfer3.itd.umich.edu!gatech!smash.gatech.edu!cc.gatech.edu!cc.gatech.edu!byron
From: byron@cc.gatech.edu (Byron A Jeff)
Newsgroups: comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.setup,comp.unix.bsd.bsdi.misc,comp.unix.bsd.misc,comp.os.ms-windows.nt.advocacy,comp.os.os2.advocacy
Subject: Re: Linux vs whatever
Date: 29 Jan 1997 21:50:16 GMT
Organization: Georgia Institute of Technology - College of Computing
Lines: 246
Message-ID: <5cogmo$n97@solaria.cc.gatech.edu>
References: <32DFFEAB.7704@usa.net> <5cmcpb$d0a@pulp.ucs.ualberta.ca> <5cmk98$3tp@solaria.cc.gatech.edu> <5cocvu$122q@pulp.ucs.ualberta.ca>
NNTP-Posting-Host: gemini.cc.gatech.edu
NNTP-Posting-User: byron
Xref: euryale.cc.adfa.oz.au comp.os.linux.misc:152701 comp.os.linux.networking:65163 comp.os.linux.setup:92482 comp.unix.bsd.bsdi.misc:5620 comp.unix.bsd.misc:1931 comp.os.ms-windows.nt.advocacy:50263 comp.os.os2.advocacy:261962
In article <5cocvu$122q@pulp.ucs.ualberta.ca>,
J Gunthorpe <jgg@gpu4.srv.ualberta.ca> wrote:
-Byron A Jeff (byron@cc.gatech.edu) wrote:
-: In article <5cmcpb$d0a@pulp.ucs.ualberta.ca>,
-: J Gunthorpe <jgg@gpu3.srv.ualberta.ca> wrote:
-
-: >Hm, that seems nasty if you ask me. GPL'd libraries then requried all
-: >linked code to be GPL'd and free, even though the new code may only use
-: >a tiny portion of the library. Since you can convert nearly any peice of
-: >code into a usefull library, the gpl seems kinda hairy.
-:
-: With the LGPL if you staticly link the library you must at least release
-: the object code so that the end user can relink against an updated library.
-
-The object code to the modified library? Don't you mean the source code to
-the modified library?
I wasn't talking about a modified library. I was referring to a standard
LGPL'd library. If you modify a LGPL'd library, you must release the
source.
-
-: As for the first point if you integrate GPL code with your code, then
-: your code has to be GPL'd too.
-
-See below...
-
-: >For instance, if you consider the kernal, if it did not have a modified
-: >GPL license LibC would have to be covered under the GPL and no the LGPL.
-: >This would in turn demand that EVERY other peice of software is licensed
-: >by the GPL and must have source availible?
-:
-: Yup but that isn't the case so I guess the point is moot.
-
-I am trying to understand how the GPL effects the licenses of other code,
-I made this example to use an existing situation (slightly changed) to
-present my interpretation of what the GPL means. I assume your Yup means I
-interpreted it correctly? Please note the line 'in turn demand that EVERY
-other peice of software'.
Yes I understand. You are correct. If the library was covered under the GPL
then any program that uses it would have to release its source and be
licensed under the GPL. All programs would be considered a derivative work
of the library no matter how little of it was actually used by the program.
Once again, the library isn't under the GPL so the point (in actualily) is
moot.
-
-: >
-: >Can someone please explain what the benifit of have having the GPL cover
-: >code linked to other code via a library mechanism?
-:
-: Um so you don't have to write your own library? The LPGL is specifically
-: designed to let you use the library without making your code GPL. The only
-: other option is to use another library. That's a big stretch just to
-: prevent releasing source code.
-:
-: Also I'm not sure where you're going with this. See GPL code whether or not
-: it is compiled and/or libraried is still GPL code. The LGPL is the only
-: exception. If you integrate GPL code to your no matter the mechanism
-: you have to release the source.
-
-I am trying to understand the GPL as it applies to linux.. Note your line
-'no matter the mechanism'..
As it applies to the kernel, any additions to the standard Linux kernel must
be under GPL. Modules are not considered a derivative work of the kernel
(as long as the standard module interfaces are used) and therefore are
not bound by the GPL. As for applications, any application that uses the
libc (et. al.) libraries can do so freely as long as the libraries are not
modified. This is because Linux's standard linkage mechanism for libs is
to dynamically link them. If you statically link to a LGPL's library you must
release object code so that the end-user can relink.
So if some commercial venture wanted to release a software product they can
withold the source as long as:
1) The linux kernel is not modified.
2) Only kernel modules are used.
3) The libraries are not modified.
4) The application isn't statically linked to LGPL'ed libraries.
I wonder aloud what percentage of potential commercial apps would have
to violate the above rules.
Note that if any of the rules are violated, then corrective action only
need be taken against that rule. For example if an application requires a
change to the Linux kernel, then only that change needs to be GPL'ed. As long
as the user level application doesn't violate the library rules, it can be
release without source, as can any kernel modules the application uses.
-
-: >When does the
-: >division between 'included source' and 'separate source' occure?
-:
-: My perception (which may be a fantasy) is that both won't get you anywhere.
-
-Again, note this line above..
-
-: >I assume this is fully described in a special kernel license that is not
-: >called the GPL? I wonder how vague the terms are as well?
-:
-: So vague as to be no-existent. There is no Licensing document in the
-: Linux kernel other than the GPL.
-
-Joy.. I wonder if that can cause legal problems?
I'm sure it could. I would consult Linus and my legal staff before sinking
funds into such a venture...
-
-: >: and development. Many companies (read investors) aren't interested
-: >: in being compelled to give away the fruits of that work. Under GPL,
-: >: you can be compelled to do so. There are licensing terms under which
-: >: there is no such encumberance.
-: >
-: >Hm, so if you add any code to the kernal it must be GPL'd code!? Yuk. This
-: >means that if you write something like a sound driver, anything that uses
-: >your sound driver must be GPL'd to -- correct?
-:
-: No on two counts. First you can write a module for the driver which you
-: don't have to release the source, secondly it doesn't affect the status
-: of applications run on top the kernel.
-
-Bang. Here is the statement I do not understand. 'it doesn't effect the
-status of applications run on top the kernal' All of your above statments
-I noted made it clear (to me) that any integration of GPL code with your
-own results in your code being GPL'd too. NO MATTER HOW.
That's true. You're missing the distinction between GPL and LGPL I think.
1) With GPL'd code any derivative work, regardless of mechanism of integration
requires the source release of the new code. So source includes, object
linkages, or libraries doesn't change that fact.
2) With LGPL'd code nothing need be released if dynamicly linked to, object
code must be released if statically linked to, and source must be release
if modified. So you can use a LGPL'd library without releasing anything at
all as long as you don't modify the library itself. And in any case with
LGPL'd libraries, the licensing of the actual application code is not
subject to either the GPL or LGPL AFAIK.
The Linux kernel has a slightly different look license-wise:
3) Same as 1) above as regards to the actual kernel. If you change or add to
the kernel proper, the code must be put under GPL. Applications running
on top the kernel revert to the rules 1) and 2) above.
4) Modules (as long as the standard module mechanism is utilized) is not
subject to any licensing restrictions at all. I would presume that
modifications to the standard module mechanism would be considered part of
the Linux kernel and therefore subject to rule 3) above.
-Technically it is
-easy to argue that when an EXE is loaded it is dynamically linked to the
-kernal.
True. But the licensing document that comes with the kernel specifically
addresses that issue. To quote:
------------------------------------------------------------
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work"...
Linus Torvalds
------------------------------------------------------------
- Or that using <insert favorite interface here> is just a different
-sort of procedure call, so you are again integrating two types of code.
-(From a programers standpoint this is true and very hard to argue
-against.)
I'm with you, that's why there are specific exceptions (LGPL, kernel) that
address those interfaces.
-
-This is why I was asking about the division between included and separate
-code, does the GPL make it ABSOLUTELY clear when this occures? Or does it
-use a general term like 'included within'.
The kernel, module and library interfaces are clearly specified as use, not
derivation. As for the others, err to the side of caution because the intent
of the GPL to make any code that is a derivation GPL code. That's the job
of the copyleft. So the presumption is that any integration or derivation from
GPL'd code that is not specifically exempted GPL's the new code.
Yes that's scary, but I find it quite obvious. I can use the kernel and
libraries all I like as long as I don't change them. Other than that I
presume that using GPL'd source will make my code GPL too.
-I'm no law expert, but it seems
-to me that if someone wanted to (Linus perhaps?) they could go up to
-Netscape or any other company that has released linux code and say they
-have violated the GPL, by the argument that the very fact that the code
-makes use of the Linux kernal it is in fact integrating with it and MUST
-be GPL'd as well! (You say the kernal includes the stock GPL, so would a
-court accept that 'Linus once said...'?)
See Linus' note above. He clearly states that normal usage of the kernel
is not a derivation.
-
-If this is true then Linux is not viable for todays commercial
-applications which require source hiding.
Fortunately it isn't.
-If it is not true, then how can
-the GPL be applied (as it was discussed above) to a dynamic library,
-because it is essentially the same? I think this needs some clarification
-here.
I hope that I did. The LGPL let you use the library without applying
the license to the code using the library.
-
-: In fact the above senario is the only reason to hide code anyway. With the
-: GPL you can 'hide' code in plain sight. Others can see it, modify it,
-: but they can't hide changes from you (in fact are required to send them
-: back to you). Oh they can repackage and sell your code too. That what
-: scares folks.
-
-: So stop spreading FUD and start working on those commercial products.
-: If you generate a solid product, folks will buy it whether or not
-: you send the source or not.
-
-I'm sorry if you see this as FUD. I am only trying to understand the
-license of the software I am running on my computer, and how it will
-effect any code that I may write.
I think I've explained the bottom line. The only concern now is that the
module interface isn't shown with a license in writing.
BAJ
-
-Thanks
-Jason
--
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel - And Using Linux!
Georgia Tech, Atlanta GA 30332 Internet: byron@cc.gatech.edu