RFC: MK_BLOBS build option

[Robert Watson]

On Mon, 23 Jan 2012, Robert Millan wrote:

> I looked in detail at the documentation you pointed.  My impression is that 
> this infrastructure is designed to address a very different problem.  Some 
> notable differences:
>
>  - It concerns about things like license compatibility between ports. If 
> there's a license incompatibility in kernel, it affects the whole tree, it's 
> a lot more manual verification work which is already in place.
>
>  - In src MK_* build options are already stablished practice. Adding new 
> options and using them in Makefiles fits well with the desired goal.
>
>  - src already has a license split (/gnu, /cddl...) and the diversity of 
> license groups is much smaller.  There are already build options concerned 
> with GPL, for example MK_BSD_GREP. When some users have had this need, 
> existing MK_* framework seems to have satisfied them.

There's a related concern to do with "license leakage" into the GENERIC 
kernel.  The policy of the project is that the GENERIC kernel should 
essentially be BSD-licensed -- GPL, CDDL, etc, code needs to be compiled out 
by default, although compiled into modules is considered fine.  One reason 
that KDTRACE_HOOKS is not in GENERIC is that no one has done a careful review 
to ensure that it doesn't lead to CDDL in GENERIC.  It would be nice if we had 
tools to not only perform those checks, but also allow us to induce compile 
failures as part of tinderboxing if something goes wrong.  It's an interesting 
question as to how "hard line" you get about this: how do we want to treat 
uuencoded firmware bits in device drivers that allow unlimited distribution 
but not reverse engineering, for example?

I don't want to get into the politics of this, nor the specific spellings, 
except to say that we (a) can't provide guarantees (and especially not 
indemnification) to our users but (b) we do want to help them do their jobs 
more easily, in which case tools to help them analyse their license 
obligations when using FreeBSD would have benefit.

Count me on in Warner's comment regarding "blob" -- binary-only (or, for that 
matter, obfuscated) content is a contentious issue.  In as much as we can 
provide accurate while less potentially inflamatory descriptions, I think 
that's a useful thing to do.  Possibly we should keep vaguely in mind the IETF 
mantra of being liberal about what we accept (i.e., support components under a 
variety of licenses) and conservative about what we generate (create as much 
code as possible under the BSD license).

However, there is an immediate practical benefit to resolving the DTrace hooks 
situation, and some of the tools used to do that would be more broadly 
relevant.  I'd like it very much if we had KDTRACE_HOOKS compiled into GENERIC 
-- it's one of the reasons why I find myself still using custom kernels in 
many configurations.

Robert