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

Matthew Macy mmacy at freebsd.org
Tue Feb 26 17:22:19 UTC 2019


On Tue, Feb 26, 2019 at 09:20 Rodney W. Grimes <
freebsd at pdx.rh.cn85.dnsmgr.net> wrote:

> > This has zero impact on the licensing disposition of the kernel as
> > distributed as it is only used for test kernels. Tests compiled with
> > coverage instrumentation run much slower than even debug, one would never
> > ship this.
>
> Shit happens, mistakes get made, and sadly the consequences for someone
> could be pretty sad.
>
> > You are very much in the minority being more concerned with ideological
> > purity than minimizing the decline in relevance of FreeBSD, much less
> > striving to increase its relevance.
>
> I am not in the minority when it comes to GPL code anyplace
> in our base system, did you not read what core said, did you
> not read the suggested revised license guideline text?
>
> This gcov code has to eventually go, sooner or later.


Unless there is a fully equivalent replacement, that will be another small
step towards Linux's complete hegemony.


>
> > On Tue, Feb 26, 2019 at 08:27 Rodney W. Grimes <
> > freebsd at pdx.rh.cn85.dnsmgr.net> 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?"
> > > >
> > > > 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. ;)
> > >
> > > Didnt we just remove an inbase, compiling BSD licensed chunk of
> > > code called DRM and move it to ports.  So if that was possible
> > > this should be very rapidly applied here and this issue goes away.
> > >
> > > I am still shaking my head over this one.  Yes, there is some
> > > expediance to this.  Also could it not live on a project
> > > branch?  Like.. um.. the ZoL project branch?
> > >
> > > > Thanks,
> > > > Shawn Webb
> > > --
> > > Rod Grimes
> > > rgrimes at freebsd.org
> > >
>
> --
> Rod Grimes
> rgrimes at freebsd.org
>


More information about the svn-src-head mailing list