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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. =C2=A0The 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. =C2=A0One = 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. =C2=A0It 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. > =C2=A0It's an interesting question as to how "hard line" you get about th= is: 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 jo= bs > 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. =C2=A0In as much= as we > can provide accurate while less potentially inflamatory descriptions, I > think that's a useful thing to do. =C2=A0Possibly 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 broa= dly > relevant. =C2=A0I'd like it very much if we had KDTRACE_HOOKS compiled in= to > 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 :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOfDtXMDVs1hGajMzzXAk8pA%2Bb8zV=wuFD1PaG6J43DZ2Wf3zw>