*BSD News Article 87742


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!news.wildstar.net!serv.hinet.net!spring.edu.tw!news-peer.gsl.net!news.gsl.net!news.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.sprintlink.net!news-peer.sprintlink.net!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 04:39:04 GMT
Organization: Georgia Institute of Technology - College of Computing
Lines: 164
Message-ID: <5cmk98$3tp@solaria.cc.gatech.edu>
References: <32DFFEAB.7704@usa.net> <5clvmp$jjs@pulp.ucs.ualberta.ca> <32EE8E40.167EB0E7@freebsd.org> <5cmcpb$d0a@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:154955 comp.os.linux.networking:66529 comp.os.linux.setup:94462 comp.unix.bsd.bsdi.misc:5785 comp.unix.bsd.misc:2104 comp.os.ms-windows.nt.advocacy:51300 comp.os.os2.advocacy:264181

In article <5cmcpb$d0a@pulp.ucs.ualberta.ca>,
J Gunthorpe <jgg@gpu3.srv.ualberta.ca> wrote:
>John S. Dyson (dyson@freebsd.org) wrote:
>: J Gunthorpe wrote:
>: > 
>: 
>: > 
>: > Hm, that does sound pretty bad, and does limit the usefullness of the
>: > GLP'd code.
>: >
>: I agree, except...
>: >
>: > However I have a question, if you take a GPL'd code base and
>: > make it into a library (shared or otherwise) and then link to that library
>: > is it required to distribute the code of the new executable?
>: >
>: GPL, you will likely have to redistribute the source.  There is a
>: modified
>: GPL, called LGPL that would allow you to keep some control over your IP.
>
>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.

Of course if you dynamically link even that is unnecessary.

As for the first point if you integrate GPL code with your code, then
your code has to be GPL'd too.

Bottom line is that the whole point of the GPL is not to hide code.

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

>
>Has anyone carefully looked at the licenses included with the various
>shared libraries/tasks/packages etc to determine how widespread a cascade
>effect like this might be?

I haven't.

>
>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 don't see how that can help anyone.. How far does this go? 
>If I make a program that spawns a
>GPL'd program and uses it's output does this require my program to be
>GPL'd too (And how is this different from making a library)? 

No (but used to be the case for flex and bison but their outputs were
transferred to LPGL licenses I believe).

The difference is that a library creates a single integrated program whereas 
the other is two separated programs.

Again what's the point? The [L]GPL is crystal clear: if you integrate GPL
code to yours you must release yours, if you link statically to LGPL
code you must make the objects available, otherwise you're fine.


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

>
>: > If this is so, then how can anyone make any money in linux? I assume stuff
>: > like the X-Windows libraries, shared C libraries, Sockets libs etc etc are
>: > all GPL'd? (In which case wouldn't NetScape, ID and others be violating
>: > the GPL by releasing ported code that runs on linux without source?)
>: > 
>: The LIBC in Linux is LGPLed (I think), and the OS allows you to write
>: any
>: (reasonable) program that doesn't use any proprietary interfaces and
>: continue
>: control of your IP.  Linus has made an exception to allow for certain
>: relief
>: from GPL on the kernel module interface (the kernel is NOT LGPLed, but
>: GPLed)
>: -- but that would only apply to code that he wrote or owns.
>
>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.

>
>: My position about GPLed kernels is that many times you need to modify
>: the kernel in order to incorporate the kernel into product.  Those
>: modifications may or may not include significant amounts of research
>: 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.

> Which means only by special
>permission of Linus can any new kernal entity be created which is usably
>commercialy (ie no source give outs).

Unless it's a module. The kernel is GPL'd.

>
>Tis a strange world we live in.

Not strange at all. Without this protection some company will immediately
snap up all this hard work, modify it, not release the modifications, and
sell the results without anyone who produced the base getting any
compensation for their work. The GPL protects them.

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.

But check out the benefits. Thousands of potential developers, millions
of beta testers and clients. 
And folks will buy conveniece, manuals, support, and
whatnot. Just check out Linux CDROM and book sales. More work and
profit than any one company can handle.

I'm starting to find out that folks only use free software for the most
part. They either get freeware or shareware, or simply "borrow/trade"
programs with other folks. Quite illegal.

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.

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