*BSD News Article 34040


Return to BSD News archive

Xref: sserve comp.os.386bsd.questions:12191 comp.os.386bsd.misc:3095
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!gatech!news.byu.edu!cwis.isu.edu!u.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (Terry Lambert)
Newsgroups: comp.os.386bsd.questions,comp.os.386bsd.misc
Subject: Re: Whats wrong with Linux networking ???
Date: 10 Aug 1994 06:45:43 GMT
Organization: Weber State University, Ogden, UT
Lines: 77
Message-ID: <329t2n$fgb@u.cc.utah.edu>
References: <Cu8CBr.Fx@calcite.rhyolite.com> <RSANDERS.94Aug9003813@hrothgar.mindspring.com> <CuA6w1.5tF@calcite.rhyolite.com>
NNTP-Posting-Host: cs.weber.edu

In article <CuA6w1.5tF@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes:
] >That cuts both ways, by the way.  Much of the driver support for the
] >two free BSDs has duplicated work already available in Linux.  Why
] >haven't they just ported the Linux drivers?  Or dosemu?  Or the Linux
] >/proc filesystem?  Or the Linux SYSV IPC implementation?  Or the Linux
] >virtual console system?
] 
] That is right.  Dosemu is an obvious case.  The answer is Not-Invented-Here
] syndrome.  Everyone has it.  NIH can be a good thing, since rewrites
] from scratch are sometimes better than the originals.  NIH is bad when
] the result is not strictly and unambiguously better than the original
] in features, licensing and bugs, or when the clone takes to long to
] complete, or when hypocracy or dishonest is involved (e.g.  dishonest
] denials of NIH or theft of code).

I would say the reason for the lack of driver inclusion is NGPLH:
"No GNU Public License Here".  It is pointless to try an argue
religious zealots down from the temples on either side; the fact
remains that it is a matter of public policy that the code produced
by the BSD projects be commercially usable without strings attached,
in the Berkeley/CSRG tradition.

The unfortunate fact is that drivers are GPL'ed as part of an agregate
work; making the drivers available means making all of Linux available,
since they are components of the Linux agregate.

What appears to be needed from the BSD (and commercial) point of view?

1)	Seperately license the drivers instead of as part of the
	agregate.  This makes the drivers individually distributable
	components (which then have to be distributed in accordance
	with GPL).

2)	Distribute the drivers under LGPL, not GPL.  The GPL
	requirements are for entire sources, rather than linkable
	images for things that use the LGPL'ed code and source
	for the things themselves (as with the LGPL).

3)	Clean up the language in LGPL to specifically exclude the
	"glue" required to use the objects covered by LGPL as being
	covered by LGPL.  As it is, a shared library stubs interface
	(or a kernel module loading interface) specifically written
	as a consumer of an LGPL'ed object module qualifies as a
	derivative work.  This was the subject of one of the few
	court cases brought by FSF on the grounds of GPL (dropped
	when acceptable terms were reached).  The LGPL seems to not
	take shared libraries into account very well (or at least
	not explicitly).  As it is, I can't use LGPL'ed shared
	libraries without making my own calling interface public,
	if the sole reason for the code between the calling
	interface and the LGPL'ed shared library is to interface
	to the LGPL'ed library.

Do this, and it would be possible, using a loadable kernel module
interface, to comply with the licensing restrictions without a
need to sacrifice the BSD projects public policy (or a commercial
vender's interests), and use the drivers (and libraries, etc.).

This means BSD hackers working on the drivers themselves to ensure
things like architecture portability, without compromising the source
availability of the drivers -- BSD hacker's changes would be required,
just like everyone else's, to be made source available.

Who knows, do this, and you could very well have UnixWare and other
commercial hackers (professional UNIX kernel programmers with
*decades* of experience) working on your sound drivers, or WINE...


The biggest fear this would cause me if I were a Linux hacker would
be fear of competition... a *good* fear to have around... 8-).


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.