Date: Wed, 25 Jan 2012 18:44:58 +0000 From: Robert Millan <rmh@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: Kostik Belousov <kostikbel@gmail.com>, Adrian Chadd <adrian@freebsd.org>, tabthorpe@freebsd.org, freebsd-arch@freebsd.org Subject: Re: RFC: MK_BLOBS build option Message-ID: <CAOfDtXMDVs1hGajMzzXAk8pA%2Bb8zV=wuFD1PaG6J43DZ2Wf3zw@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.1201240932580.7739@fledge.watson.org> References: <20120122201814.GA32081@thorin> <20120123193412.GA353@zim.MIT.EDU> <CAOfDtXPeCFknB%2BM2XDNVemEyP2xS6FpQ3O-ta%2BJSqVc=KgNKUA@mail.gmail.com> <alpine.BSF.2.00.1201240932580.7739@fledge.watson.org>
index | next in thread | previous in thread | raw e-mail
El 24 de gener de 2012 9:44, Robert Watson <rwatson@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 :-)home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOfDtXMDVs1hGajMzzXAk8pA%2Bb8zV=wuFD1PaG6J43DZ2Wf3zw>