RFC: MK_BLOBS build option

[Robert Millan]

El 24 de gener de 2012 9:44, Robert Watson <rwatson at freebsd.org> ha escrit:
> 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.

Hi Robert,

Thanks for your explanation. I understand why such license tracking
system would be useful.  I've to admit, though, that I completely lack
the time to implement it.

The remaining question would be if for the time being it is acceptable
to use MK_* build options for manually disabling sourceless code.
There's a similar precedent (MK_BSD_GREP) so I would guess that it is.
 But if you (or anyone else) has a reason why this would be a bad
thing, then please explain it :-)