svn commit: r344487 - in head/sys: conf gnu/gcov

[Shawn Webb]

On Tue, Feb 26, 2019 at 10:18:45AM -0700, Warner Losh wrote:
> On Tue, Feb 26, 2019 at 8:46 AM Shawn Webb <shawn.webb at hardenedbsd.org>
> wrote:
> 
> > On Mon, Feb 25, 2019 at 06:18:42PM -0800, Rodney W. Grimes wrote:
> > > > > The modest increase in activation energy for that task seems worth it
> > > > > for the short-term gains of reduced integration cost (this code will
> > > > > greatly improve our ZFS-on-Linux test coverage.)
> > > > >
> > > > > Rod rightly points out that we haven't accepted SPDX tags alone as
> > > > > license statements.  The standard GPL v2.0 boiler plate should be
> > added
> > > > > to this file along side the tag.
> > > >
> > > > I've copied the full copyright attribution that is in the
> > > > corresponding files on Linux. Is there some reason why FreeBSD
> > > > requires the files to be inflated with the full license text where the
> > > > original lacks it?
> > >
> > > I think for a few reasons, I doubt you copied the whole distribution
> > > that this file came from, as I am sure that distribution included
> > > a LICENSE file.  Second if you actually read the GPL v2 documentation
> > > and follow what it says it says you must do this, just because some
> > > one else does not follow the rules of what the GPL v2 says does not
> > > give us to knowingling not do it.  Third this is a particular dangerious
> > > area for BSD to be mixing a GPL code with its kernel, to my knowlege
> > > we have never had any gpl code in the kernel, no have we ever
> > > allowed it, but thats a seperate argument, that should be made.
> >
> > Would the arm64 DTS/DTB files count as "GPL code in the kernel?"
> >
> 
> No. dts gets compiled into dtb. dtb is a separate work loaded by the boot
> loader. While one can compile it into the kernel, we don't ship like that.
> 
> There's also a question as to whether or not these files are text
> representation of the hardware, and there being only one way to represent
> it (making it not copyrightable under at least US case law since it's a
> database). That question hasn't been litigated. Many hardware companies
> also dual license the dts. Since we're not incorporating it into the
> kernel, but merely using it as a standardized table (there's a separate
> group that controls the dts/dtb spec), I think we're safe from that angle
> as well.
> 
> There's benefit from having it in-tree because the version of the spec
> evolves over time, and having the right version makes it harder to push
> this off into a port. Also, having them in-tree makes the project's
> compliance with GPL a no-op because it's all there in the open in a tagged
> VCS.
> 
> tl;dr: I don't think this is an issue.

Awesome. Thanks for the clarification. I'm now curious if this is
documented outside of random emails in svn-src-all at . I'm 100% sure I'm
not the only one who needed clarification on DTS/DTB licensing,
especially in the context of FreeBSD.

> 
> 
> > I, too, would like less GPL in project, both in userland in kernel.
> > But, I can understand the desire for gcov. Note that I'm not
> > advocating either way that FreeBSD perform an action. ;)
> >
> 
> Given this is for TEST kernels, there's no issue here.  While we'd like to
> be GPL free, let's not cut off our nose to spite our face. Given the
> interactions between different bits, the FreeBSD selling point of "well
> integrated" I think trumps the purity arguments because it's not code
> anybody would ever ship (and if they did, they'd get the proper warnings).

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:    +1 443-546-8752
Tor+XMPP+OTR:        lattera at is.a.hacker.sx
GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20190226/eb32e957/attachment.sig>