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.w...@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@. 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: latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
