Laine Stump <lainestump@rcn.com> writes:

> We should be careful about letting GPL-isms creep into the kernel. Sure, an
> item here and there is no big deal, especially if you're just using the OS
> personally (or internally in a company). But for someone using NetBSD as
> the basis for a product that includes kernel modifications they want to
> keep private (for a while at least), it can create serious problems if 1)
> there gets to be a lot of these GPL'ed modules and/or 2) developers start
> forgetting about this class of user, and add some new GPL-ed module that
> ends up being required for proper operation of the system.

I understand that keeping GPL'd code out of /usr/src is _very_
important, and I agree fully.

But, since the code lives in /usr/src/gnu/sys, this isn't an issue.

I'm talking about what ships with the default install disks.  I think
we should have the most fully-featured kernel possible on those
disks.  They should be competitive with other Unix releases.  To be
told that you need to recompile, run a command like "tunefs -n" to
turn them on, is rather non-user friendly.

> As I understand it, the reason that GPL'ed code has been kept out of the
> kernel (and GPL'ed userland is kept in a separate tree in the source) is to
> make basing products on NetBSD simpler, and it can be one of the deciding
> factors when choosing the OS. If there is a single GPL'ed file in the base
> kernel, then doesn't the entire kernel effectively become GPL'ed? (ie,
> doesn't that mean that any changes you make to existing files in the
> kernel, as well as new files you add, must be made publicly available?) Or
> is my interpretation more strict that reality?

Putting it in "gnu" is really wrong, since it isn't GPL'd.  It has a
modified copyright that (according to my reading) simply requires that
if you link with the code, you MUST release all sources to build the
entire executable.

We do that.

Now, why sys/ufs/ffs/softdep.h is exempt from this curious.  It also
has the same license as the file placed in gnu/sys/ufs/ffs/, after
all.  Doesn't using that header file already taint our kernels?

--Michael