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 <
free...@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.

_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to