Subject: Re: New "release" snapshot
To: Bob Nestor <rnestor@augustmail.com>
From: Bill Studenmund <wrstuden@nas.nasa.gov>
List: port-mac68k
Date: 12/19/1999 20:59:06
On Sat, 18 Dec 1999, Bob Nestor wrote:
> Frederick Bruckman (fb@enteract.com) wrote:
>
> >Since last we talked about this, the softdeps code has been imported
> >into the gnu/sys directory. By that precedent, "libhfs" could be
softdeps is a bad example as it's not really GPL'd. It has a restrictive
license, but it's not GPL'd.
> >imported into gnu/sys; it would never be used by the default, official
> >release kernels, but an option in the INSTALL kernel config could pull
> >it in. All sysinst has to do is check errno so it can bow out
> >gracefully, if necessary. I've added a mechanism (to current) to build
> >multiple install kernels using multiple, alternate kernel configs with
> >this scenario in mind.
The problem is that we can't distribute these kernels. :-(
> Isn't everything in the gnu/ path covered by a GPL type license though?
> As I understand it building standalone binaries that can be invoked or
> loaded by a running system isn't a problem since only the code that goes
> into the binary being loaded needs to match the GPL license. Moving that
> code into the kernel, even if it's an Installation Kernel, forces all the
> code in that image to be placed under a GPL license. That would mean
> that even if we didn't put the code in an operational kernel we'd still
> be opening ourselves up to having to put the kernel under GPL license
> because the Installation Kernel would contain GPL code. I'm not a license
> weenie so I could be wrong, but that's the way it was explained to me.
> If this is the case we'll _NEVER_ get any of the current HFS code into
> either kernel. We need a different solution, such as coming up with our
> own HFS code that can be included in either an Installation or
> Operational Kernel.
That's pretty close. The Linux kernel demonstrates that you don't have to
have everything under the GPL :-). The trick is that when you have code
chunk A, which is under the GPL, and you link it against/with chunk B, and
you distribute the resulting objects to others, you have to make sure that
the people you distribute the objects (programs, kernels, etc.) can get at
all of the relevant source under the same terms you got the GPL'd code
under. It doesn't have to exactly be the GPL, but it has to be as free.
The problem is that there are a number of files in the NetBSD kernel which
have more restrictive licenses than in the GPL. Like the advertizing
restriction clauses pionered by Berkeley. Thus to redistribute them as
freely as GPL'd code, we'd have to violate the licenses they have. That's
a no-no. ;-)
Take care,
Bill