From owner-svn-src-head@freebsd.org Sun Mar 25 16:03:33 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CA93F533EE; Sun, 25 Mar 2018 16:03:33 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7F8916B271; Sun, 25 Mar 2018 16:03:31 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2PG3MDv041798; Sun, 25 Mar 2018 09:03:22 -0700 (PDT) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2PG3KLQ041797; Sun, 25 Mar 2018 09:03:20 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201803251603.w2PG3KLQ041797@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r331510 - in head: share/man/man4 sys/conf sys/dev/vmware/vmci sys/modules/vmware sys/modules/vmware/vmci In-Reply-To: <8dffed54-3319-d826-5ec1-fd80155a3921@FreeBSD.org> To: Pedro Giffuni Date: Sun, 25 Mar 2018 09:03:20 -0700 (PDT) CC: rgrimes@freebsd.org, Mark Peek , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2018 16:03:33 -0000 > > > On 25/03/2018 06:49, Rodney W. Grimes wrote: > >> On Sat, Mar 24, 2018 at 6:27 PM, Rodney W. Grimes < > >> freebsd@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. -- Rod Grimes rgrimes@freebsd.org