Date: Mon, 25 Feb 2019 18:18:42 -0800 (PST) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: "K. Macy" <kmacy@freebsd.org> Cc: Brooks Davis <brooks@freebsd.org>, Matt Macy <mmacy@freebsd.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers <src-committers@freebsd.org> Subject: Re: svn commit: r344487 - in head/sys: conf gnu/gcov Message-ID: <201902260218.x1Q2Ig4r042692@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <CAHM0Q_NetD%2BbGqtEYEBj0PKEH-G7VuOaTyFH_wdqZHJG5B7FCg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. > > An additional issue is that the a warning tag was not added to > > sys/conf/files. A warning along the lines of: > > > > warning "kernel contains GPLv2 licensed GCOV" > > > > needs to be added. > > Yup. Thanks > > > > This commit needed more through review. > > How would this be achieved:? I had several people on the review and no > one had substantive feedback. I have very seriuos concerns how you can even make that comment now given that ngie@ pointed out during the review that this GPL code and you dismissed it as a non issue. This shows lack of knowlege as to the projects GPL goals, and lack of concern that you might of wanted to ask first, rather than now have to deal with it post commit. When ngie@ pointed out an issue you could of posted to a list with your review asking for more people. Everyone should strive to find reviewers, if the patch doesn't trigger enough herard rules (which we should also work on, but seems the phabricator admins are deaf or non existance as multiple requests go unanswered), it is very easy to go drop a link to your review in an appropriate mailling list -current being choice of last resort. If you do that I am pretty sure you'll get plenty of feedback. > > > > > We intend to update our license policy to require core sign off for > > new GPL code to ensure we're not adding new, tightly integrated > > dependencies, to document that we're doing so knowingly, and > > to make sure steps aren't missed. The current document is at: > > https://www.freebsd.org/internal/software-license.html Given the high push in the last few years to be GPL free, and that being well publically aired at conferences and in commit mail as we try to achive that goal I can not see why here do we need to add policy for what really should be common knowledge, yet in areas that we clearly do not follow or have policy there seems to be no reason what so ever to fix what we dont follow or add what we do want. IMHO, this commit should be a huge red flag, we seem to have a problem Houston, in communications! > -M -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201902260218.x1Q2Ig4r042692>