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

[Mark Peek]

On Sun, Mar 25, 2018 at 9:03 AM, Rodney W. Grimes <
freebsd at pdx.rh.cn85.dnsmgr.net> 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.
>
> Kirk would have to back me up on this, but my understanding of the
> decisions that the UCB Regents legal staff came to was that each
> file should have a complete copyright and license clause and any
> thing less causes problems because of "seprability", and "alterability"
> because of seperate files.
>
> The exception to this is files that can not be copyrighted such as
> Makefiles, and I have seen those now with copyrights in them,
> which is not enforceable as a Makefile is usually considered
> a receipt.
>
>
Was the discussion with Kirk and the USB regents done recently? In the
context of SPDX?

The main point is ensuring we know the copyright and license for any source
file in our repository. The use of a SPDX identifier (along with a
copyright statement is
intended to give an immutable copy of the specific license without copying
the entire
license text into the source files.

The issue isn't whether I will commit the entire dual license text as I can
easily and will do
that per your concerns. I'd prefer to see us allow SPDX only since it
implies the same thing.

Mark