*BSD News Article 15688


Return to BSD News archive

Newsgroups: comp.os.386bsd.misc
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!gatech!news.byu.edu!cwis.isu.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: So you say you want an interim release of 386bsd? (What to do?)
Message-ID: <1993May6.014052.17558@fcom.cc.utah.edu>
Keywords: Flame-bait
Sender: news@fcom.cc.utah.edu
Organization: Weber State University  (Ogden, UT)
References: <C5sCvr.3G1@unx.sas.com> <CGD.93Apr20124457@gaia.CS.Berkeley.EDU> <PC123.93May5000713@bootes.cus.cam.ac.uk>
Date: Thu, 6 May 93 01:40:52 GMT
Lines: 90


The issue of "why avoid GPL?" has been discussed on this group before.  To
avoid a flame-fest, if you are arleady a religious zealot on one side or
the other, skip to the next article now.  8-).



In article <PC123.93May5000713@bootes.cus.cam.ac.uk> pc123@cus.cam.ac.uk (Pete Chown) writes:
>In article <CGD.93May4032535@eden.CS.Berkeley.EDU> cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou) writes:
>
>   NetBSD has the same attitude toward GPL'd code as does 386bsd,
>   and perhaps even a stronger one.
>
>   As long as i'm in "control" of NetBSD, there will be:
>	   (1) No GPL'd code in the kernel
>	   (2) No GPL'd code in libc
>	   (3) GPL'd code added to the standard tree only
>		   where no adequate free replacement is presented.
>
>I think this is a shame.  To my mind there is no gain in producing a
>free operating system for other people to make money out of.

Well, we (and the FSF) disagree with you.  The FSF *promotes* sales of
precompiled GPLed code (in the guise of copying fees) and support for
that code.  Cygnus Support has been very successful (and has contributed
greatly to the UNIX community) doing this.

The BSD license lets you do anything you want with the code: sell it,
distribute modifications of it, etc.,  You can do anything you want
with the BSD licensed code that you can do with GPLed code, plus the
things disallowed by the GPL.

Unless there's money in it somewhere, there won't be commercial quality
applications for it (other than development tools, also under GPL).  The
only market for such systems is as part of a vertical market soloution,
and then the beneficiaries tend to be the small consultant.  Even then,
the LGPL on the library requires that object modules be shipped for any
application that wants to link with them, basically publishing every
non-static function, variable, and interface in an application -- this
goes a long way towards reverse engineering it, something that would
be only marginally possible after a *lot* more work if the software
was distributed as a stripped executable.

>1.  The include files seem confused, although the situation has
>improved rather of late.  Particular problems are experienced when you
>try to work with a new version of gcc that has some of its own include
>files - the number of clashes are quite surprising.  But we can't use
>glibc, or the Linux libc, both of which are much better because they
>are under the GPL.

The confusion is in the generically hacked gcc includes that must be
grafted in... unless you are complaining about the lack of ANSIfication,
which protects a programmer from needing (or knowing how to) run lint.

>2.  The DBM library seems most peculiar.  Linking programs to it often
>seems to give link errors due to non-existent routines.

This was an intentional omission, and can be easily remedied by using
appropriate wrapper functions.  In general, you should *not* mix the
old and new syntax; it assumes that the underlying implementation is
shared.

>I don't see what the problem is with the libraries.  All the GNU
>libraries are under the library GPL, so they can't "infect" other
>programs just by them being linked with them.

No, but they can require you to distribute object modules which can
be interpreted as a disclosure of the overall organization of your
program, as well as providing a symbolic organization of each object
module  -- thus disclosing the functional organization as well.  You
can't ship stripped binaries.

>Perhaps I should start assembling a kit of GNU software that you can
>add to your 386BSD implementation...

This would be a nice feature as an add-on "GNU utilities" package, and
would certainly add value to a 386BSD system as far as a consumer is
concerned... Go for it!


					Terry Lambert
					terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------