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

[Pedro Giffuni]

On 26/02/2019 13:15, Rodney W. Grimes wrote:
>> On Mon, Feb 25, 2019 at 05:11:26PM -0800, K. Macy wrote:
>>>> We had a brief discussion of this commit within a subset of core.  This
>>>> addition of GPLv2 code is fine as the code is easily removal to a module
>>>> (per kmoore@) should the day come that we're read to evict all GPL code.
>>> I don't execute the ctors until coverage is enabled because I have to
>>> manually find the symbols. The linker doesn't actually generate a ctor
>>> section for functions in text.startup in spite of what Juniper's
>>> linker commit would lead one to believe - presumably they have a
>>> private linker script in addition to a private gcov port.  Thus, it
>>> really could just work fine as a module. Nonetheless, everything to be
>>> profiled needs to be compiled with instrumentation, so separating it
>>> out makes very little sense to me. Although, I suppose ctfconvert +
>>> dtrace module is somewhat analogous.
>>>
>>>> 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?
>> We're not asking for the full text, just the standard block:
>>
>> // This program is free software; you can redistribute it and/or
>> // modify it under the terms of the GNU General Public License
>> // as published by the Free Software Foundation; either version 2
>> // of the License, or (at your option) any later version.
>> //
>> // This program is distributed in the hope that it will be useful,
>> // but WITHOUT ANY WARRANTY; without even the implied warranty of
>> // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> // GNU General Public License for more details.
>> //
>> // You should have received a copy of the GNU General Public License
>> // along with this program; if not, write to the Free Software
>> // Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>> // 02110-1301, USA.
>>
>> This is from: https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html#SEC4
>>
>> We're not currently using SPDX to include licenses, largely because OSI
>> completely and utterly botched BSD licenses.  Fixing this is WAY down
>> the list of things on core's plate.  Unless someone takes ownership
>> here, I don't see this changing any time soon.
> What is it that got botched, and what is it that needs to be done,
> some may think I do not support SPDX, I do, in that originally
> it was about tagging the files to mark what license applies, and
> I agree we should tag the files.  I howerver can not support the
> concept that you can replace a copyright and/or license text in a
> file with just a SPDX tag.

I think I have mentioned this before although not in public. I was asked 
to give a talk about my experience tagging SPDX files in the FreeBSD, 
ande did discuss about tags-replacing-licenses informally with some 
lawyers working on the linux kernel. They don't all agree on replacing 
the license with the SPDX tag, however when it is done, they are doing 
it in some context:

1) They keep a complete copy of the license text in the tree.

2) The copyright owners were suggested adopt such simplifications, but 
they were asked to do it themselves.

IANAL, but I agree that bringing such files into FreeBSD must involve 
bringing the license text. This could probably be done once for the gnu/ 
branch.

> Some sight Linux as a big project using SPDX, but if you dig into
> it you find out they did this to recover from there sloppyness of
> actually not having anything in some 6000 files in the kernel,
> they simply tagged them all GPL 2 and boom they claim problem
> solved.

I don't really follow the linux development to know if they followed any 
procedure for licensing all the files or if they assumed some context in 
the process. They did have a huge mess due to finding variants of the 
GPL with different wording and subtle differences, so I understand their 
interest in homogenizing the licensing somehow.

At least in our case we do have a bunch of build artifacts (Makefiles) 
and some headers without a license. In the case of Makefiles and 
manpages we have made no effort to tag those with SPDX, and it probably 
doesn't matter much.

Pedro.