svn commit: r331510 - in head: share/man/man4 sys/conf sys/dev/vmware/vmci sys/modules/vmware sys/modules/vmware/vmci

[Pedro Giffuni]

On 25/03/2018 11:03, Rodney W. Grimes wrote:
>>
>> On 25/03/2018 06:49, Rodney W. Grimes wrote:
>>>> On Sat, Mar 24, 2018 at 6:27 PM, Rodney W. Grimes <
>>>> freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
>>>>
>>>>>> Author: mp
>>>>>> Date: Sun Mar 25 00:57:00 2018
>>>>>> New Revision: 331510
>>>>>> URL: https://svnweb.freebsd.org/changeset/base/331510
>>>>> These files do not each contain a usable copyright, though
>>>>> they seem to contain SPDX tags that indiate they should contain
>>>>> a BSD 2 clause copyright.
>>>> IANAL but I believe you meant "...they should contain a BSD 2 clause
>>>> *license*". The files should contain a valid copyright.
>>> A valid, but unusable.  As the copyright is it is a full copyright
>>> held by vmware without any rights to be published or redistributed
>>> any any manner by anyone but vmware.
>>>
>>> 	"Copyright (c) 2018 VMware, Inc. All Rights Reserved."
>>>
>>> That is a restrictive copyright, allowing no one to publish, or
>>> in our case, redistribute, without a further license of some form.
>>>
>>>> The intent of my commit and the author were to use the implied SPDX version
>>>> of the licenses without burdening the source code with the more heavyweight
>>>> license text. Having seen SPDX in the src tree, I believed
>>>> the SPDX-License-Identifier was sufficient. But, to your point, I'm not
>>>> sure I have seen a discussion or a decision on it.
>>> SPDX tags are purely to be treated as "advisory" and in no one imply
>>> or create any license agreement.
>> As happens in economics, different lawyers can have different
>> interpretations. Our practices were consulted with the SPDX guys but
>> other projects have different practices.
>>
>> While the sound practice, especially when you don't own the code, is to
>> add the SPDX tag in addition to the license text, the linux developers
>> are encouraging replacing it altogether with the SPDX tag. In their case
>> they keep a reference to the complete license text elsewhere and they
>> have some repository log where the copyright owner did the change.
> They have grown use to this from the way the GPL is handled, since
> the length of the body of that license would be impractical to
> include.
>
>> For contrib code we just follow upstream. In no case can anyone other
>> than the copyright owner clarify, or otherwise change, a license.
> That does bring a question of why this code is not either on
> a vendor import branch, or in contrib?
>
> Can you point to any files in /usr/src that lack a full and complete
> standalone license?  Sans perhaps some GPL code that has a pointer
> to COPYING and files that can not such as Makefile and .mk's.
There are some. Here is an outstanding example:
usr.sbin/bhyve/bhyvegc.c

FWIW, the one time I did a change I added a copyright disclaimer to the 
commit log  to avoid future issues:
https://svnweb.freebsd.org/base?view=revision&revision=318788

Cheers,

Pedro.