[ On Mon, December 14, 1998 at 00:59:05 (-0800), Todd Whitesel wrote: ]
> Subject: Re: sendmail licensing again
>
> While I have not actually used FreeBSD myself, I don't understand how it
> could possibly have such an adverse effect on GDB. Enlighten me please?

Sorry, I no longer have access to that environment.  It's possible I was
just doing something very stupid, but I can't say one way or another now
why it wasn't easy to debug things being built with .PATH makefiles.

> Why not? You can tell GDB to debug obj/helloworld easily enough, right?

Except in FreeBSD (and optionaly in NetBSD?) it's not just obj/binary,
but sometimes /export/machine/var/home/boo/obj/usr/src/usr.sbin/thing/thing

(and yes, I know lots of tricks to ease the typing of long pathnames,
including using simple shell variables, but it's still a pain...)

> To me cut&paste of a huge command line after you've re-run the failing make
> command is not too much to ask, although certainly it could be automated more.
> (History editing is your friend.) However, I agree you have a point about
> editor integration. I hope to do something about this soon, by whipping up a
> cheesy Tcl/Tk front-end to GDB that also knows how to do things like fire up
> "xterm -e $EDITOR" using source pathnames supplied by GDB.

If I'd had time to get gdb working properly inside emacs, and then had
time to get used to using it that way, then I probably wouldn't have had
as much of a problem either, but there's still the case where sometimes
you're stuck debugging something on the console without a working emacs....

> True enough, but the other side of this is that every time we bring in a
> new version of some GNU tree, it needs to be "re-integrated" and that is
> a serious pain. I much prefer the physically isolated glue file approach,
> especially if it also means that the src/gnu/dist directory could be
> configured and make'd just like an extracted tarball from prep.

*ANY* integration of any third-party code into a larger system is
sometimes a pain, no matter how you do it.  Even maintaining local
changes to third party packages without integrating such packages into a
larger system can be a bit of pain, even if you use CVS.  I've got
nearly a GB of third party code in my CVS repository, and half of it is
*not* NetBSD (and before that I had several hundred megabytes of third
party code under SCCS), and I can relate all sorts of maintenance horror
stories about my experiences.  I also spent a couple years upgrading a
big BBS-like system which included a lot of GNU and other packages too.
In other words, hopefully without being too boastful, I can show that
I've got a lot of experience maintaining third party code.

Having used both schemes quite extensively (i.e. the "*2netbsd" style
scripts, as well as VPATH'ed/.PATH'ed glue makefiles in separate
directories), I can assure you that the "*2netbsd" scheme of copying
files into their true target locations and then "cvs import"ing is by
far the easiest and most scalable approach (at least with CVS).  (BTW,
the most difficult scheme to manage is the pkgsrc "patch" scheme, but
then it's a mostly manual scheme, even if you use CVS or something
similar in the background to generate the patches.)

You can't simply extract a tarball from ftp.gnu.org (;-) and hope to
re-build the world, *especially* if you don't have access to the patches
in the official NetBSD CVS repository.  Look at how much glue and
re-arranging it takes to get the compiler into place!  Like I said, I've
actually done this for some stuff in /usr/src/gnu and /usr/src/contrib
on FreeBSD, and (a) it was not easy; and (b) I could not have done it
without having access to the full FreeBSD CVS repository.  Even then the
one attempt I made to upgrade a package who's files had changed names
and locations rather radically was too difficult to do in the time I had
available (though I think it would have been possible if I'd been using
"*2bsd" scripts).

Note that even if a vendor only includes a pointer to the original
package release (and provided the vendor also either ensures that the
original tarball will still be available on ftp.gnu.org and/or their own
ftp site for the three years), they've successfully satisfied that part
of the license which requires that they make available the original
code.  You don't have to have the equivalent of /usr/src/gnu/dist --
that's just a waste of space, and I think even RMS would agree with me
on this point.

> Also the little lawyer in mind head very much prefers the physically
> distinct directory structure, because it is much easier to communicate
> to people than the "always put this marker in your source file" mantra
> which is far easier said by you than done by all of the rest of us.

The one time I've actually dealt with lawyers (which is was only that
once, thank goodness!) on a similar issue (integrating GPL code into a
product and ensuring that every source file and enough stub hooks were
present to meet tht intent of the GPL), taking a third-party's word that
the segregated files were wasn't enough -- we were strongly advised to
get written permission (thankfully not directly from the FSF in that
case!) to distribute the code.

So, what I'm getting at is that if your lawyers are at all paranoid then
they'll force you to go through *every* file in the system, no matter
what TNF says about how well they've already segregated the necessary
pieces, and you'll probably have to get explicit permission to
distribute GPLed and similarly copyright licensed code in a binary
product.  Segregation of source and build files into a GPLed-only
directory isn't necessarily going to make anything any easier.

BTW, the suggestion someone made earlier about moving the "glue"
directories into the main tree would make it even less likely that
NetBSD could meet the true intent of the GPL....

However, full integration of the GPL'ed code, so long as it is still
identifiable results in the creation of a "derrivative work", and so
long as all the files used, as well as any new build and integration
framework, is included in the gnusrc.tar bundle, then the true intent of
the GPL can be met.  Given my experience with intellectual property
lawyers I also claim that a half-hearted attempt to keep a list of
necessary files is more than sufficient too.

Given that currently nobody but NetBSD developers can access the full
CVS repository, I will go so far as to claim that it is at the moment
impossible for NetBSD to meet the full intent of the GPL.

I think there are only two ways that an open-source operating system
using GPLed and similarly copyright licensed code can make it possible
for binary vendors to fully meet the true intent of the GPL -- i.e. to
make it possible for their end users to upgrade and change the GPLed
portions of the system on their own.

The first way is to fully integrate the code, as I've suggested, and
include the "*2*bsd" scripts, *AND* include in source distributions the
patches between the vendor branch and the local branch (i.e. the changes
made after the original files are "cvs import"ed) *OR* make available
the (relevant bits of the) CVS repository.

The only other way to do this would be to make all GPLed code be handled
similarly to pkgsrc -- i.e. the build system must un-bundle the original
distribution archive, apply any necessary patches, and then build and
install it.  Only then is the complete control of the code handed all
the way to the end user.  Talk about making things hard to maintain though!

(That said I doubt it's currently possible for any *BSD to meet the true
intent of the GPL for code in the kernel, except perhaps for BSDI, with
some potential for OpenBSD and FreeBSD.)

BTW, the most "interesting" packages to upgrade have always been ones
that perturb both the kernel and user-land, such as IP-Filter.  I'm not
completely happy with the way it's integrated in to NetBSD, but imagine
the implications for binary vendors who wanted to use it if it were
under a copyright similar to Sendmail-9 or the GPL!

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>