[ On Thu, December 10, 1998 at 18:09:04 (-0500), Todd Vierling wrote: ]
> Subject: Re: sendmail licensing again
>
> The gnu/ build procedure is actually very simple; it looks just like the
> rest of the system.  

Well, parts of it are, or maybe even most of it is, but no matter which
way you look at it, it is very inelegant.

There are some very clear differences in the way the build in gnu/
works, esp. when you look at places like gnu/usr.bin/sdiff, or
gnu/usr.bin/ld.new.

There's also the most inelegant and annoying duplication in gnu/dist.
If the *real* intent of segregation were only to provide a single
sub-tree where all GNU licensed software could be bundled from for
redistribution, then /usr/src/gnu/dist should be more than sufficient.
Everything could simply be rolled into the right place with simple
gnu-*2netbsd scripts, just as is done for any other "contributed"
software.

> tar cf gnusrc.tar src/gnu
> 
> Going through hoops of maintaining a list and telling people how to use that
> list to pluck the appropriate software violates KISS.

Oh, come now!  What's so hard about using 'grep' or similar to maintain
a list of files using a given copyright and then handing that list to
the archiver of your choice to bundle all the referenced files up????

Any vendor building a product from NetBSD who cannot figure out how to
take a list of files and copy them into a separate distribution bundle
shouldn't be playing with computers.

The list should even be maintained by NetBSD folks, so that it is known
to be canonical before a release ships to someone who might want to do
this.

You can probably count the number of people who have to make this
separate bundle on the fingers of one hand (and at most on all your
fingers and toes).  Segregating software that's otherwise tightly
integrated just for a few vendors is just plain silly, esp. when the
ownus is on them to obey the GNU copyright license (NetBSD shouldn't go
too far out of its way to cater to them, unless it means going to the
extent of replacing GNU software, though I personally think that's also
a silly thing to try and do for this reason alone, esp. when it's a
never ending task, such as when new releases of packages become GPL'ed,
or effectively so as with sendmail).

We've already got different copyright licenses spread all throughout the
code base.  The fact that the GNU GPL is somehow special and unique to
us today is one thing, but to take it to the ultimate finish would
require moving a lot of things into their own sub-trees.  Your argument
implies that all non-CSRG software should be dropped into a contrib
directory just like the FreeBSD folks are doing, and I think that's a
totally insane thing to do, esp. when it just trades a one headache for
another, and at the cost of additional "confusion" and mis-direction.

What's really silly is that any degree of segregation goes directly
against the trend NetBSD has had from day one of directly integrating
tools into the source tree hierarchy when those tools are to become a
part of the complete system.  (examples abound, including IP Filter,
though IMO it isn't quite as cleanly integrated as it could be)

The *only* reason for having the segregated area set up the way it is
today (and I'm surprised nobody's mentioned this yet!) is because it
lends itself to maintaining the intent of the GPL, i.e. customers of the
product should be able to re-compile, modify, fix, and upgrade those
tools and portions of system that are built from GNU software.  However
so long as the *2netbsd scripts, makefiles, and such are included in the
list, I would contend that the intent has been met.  We all know that
end-users of such third-party products are extremely unlikely to ever
recompile anything, even GNU code.

Note that the intent of the GPL could easily be violated should an
third-party vendor make the mistake of distributing a static binary
linked with -lgnumalloc, something that might not be obvious to all even
with the "gnu" in the name.

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