From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 09B7F1D90 for ; Wed, 13 Dec 2017 11:46:27 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7DEBE20708; Wed, 13 Dec 2017 05:46:25 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 13 Dec 2017 05:46:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=GvD/Jr0UMBSC3yn4g6hLTf7L38 nAChlNFl0UfSFfB6o=; b=QjY/w5XkS6qK9W7izi9G3RiqsS53xH2xXrppwGkDn4 q9Mygp0/zCkNu+3G5YlkAlLfAjy0VyLcfjtk0A/CbzUs7SmzLK22w2aEaE3aaRuX w9V/V2J2U+4axpElVuYKl0HRTGfOXy+kDOoO21Qanqd07DkD6ae1/kK6ZPdxeJZM M= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=GvD/Jr 0UMBSC3yn4g6hLTf7L38nAChlNFl0UfSFfB6o=; b=NU/3SaKUBquQFN5xrufsGR VxSNOKCZiW9qr3jUazA8XDcWRlfEGpVt/W7G8xI6y1jF2FDtrXsxObEg/PYM8yEP u9VBW23AC6b2WV+GHJxEwVhTtkY7QaL2HErW1vKzB2xNAfzwQhmVC3k/xr3SIqu6 P5RIuvlfqqLt7cliljOFTSyf7t8MyjJuVCWAj3X8eZ9zRIuaskRdBmL4KhEdr/co 2lGGeyYRqdWJIFKZyvvsa7GABp/oc+BagXVkuz0gkr9HeTyioGQ7edEkeiAPVOCs r0PuBstWfN0ujd6UcinNVuJv0s/aryVbrztLZvGlAhbYgO7pV/MWMyV97Gk2NyWw == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 26C487E34F; Wed, 13 Dec 2017 05:46:25 -0500 (EST) From: Thomas Monjalon To: Hemant Agrawal Cc: dev@dpdk.org, stephen@networkplumber.org, bruce.richardson@intel.com, john.mcnamara@intel.com Date: Wed, 13 Dec 2017 11:46:23 +0100 Message-ID: <4544178.LpVkm1JlzH@xps> In-Reply-To: <1512718913-11462-1-git-send-email-hemant.agrawal@nxp.com> References: <1512117499-23412-1-git-send-email-hemant.agrawal@nxp.com> <1512718913-11462-1-git-send-email-hemant.agrawal@nxp.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 1/4] Introducing SPDX License Identifiers X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 10:46:27 -0000 Hi Hemant, Some comments below 08/12/2017 08:41, Hemant Agrawal: > --- /dev/null > +++ b/Licenses/Exceptions.txt Please use lowercase for file and directory. By the way, the text is referring to exceptions.txt. > @@ -0,0 +1,12 @@ > +This file will record any exceptions in DPDK Project with respect to DPDK > +IP License policy as defined in DPDK Charter available at: > + > +http://dpdk.org/about/charter#ip This link might be indented. I think we should make clear that - BSD-3-Clause - GPL-2.0 - dual BSD-3-Clause/GPL-2.0 - dual BSD-3-Clause/LGPL-2.1 are not exceptions. > +---------------------------------------------------------------------------------------------- > +License Name SPDX Identifier TB Approval Date GB Approval Date File name > +---------------------------------------------------------------------------------------------- The table is large, and file names will be long. Can we remove "License Name" as it is redundant with SPDX id? > --- /dev/null > +++ b/Licenses/README Good idea to add a README here. > @@ -0,0 +1,82 @@ > +The DPDK uses the Open Source BSD-3-Clause license for the core libraries and > +drivers. The kernel components are naturally GPLv2 licensed. You should use SPDX GPL-2.0 > +Including big blocks of License headers in all files blows up the > +source code with mostly redundant information. An additional problem > +is that even the same licenses are referred to by a number of > +slightly varying text blocks (full, abbreviated, different > +indentation, line wrapping and/or white space, with obsolete address > +information, ...) which makes validation and automatic processing a nightmare. > + > +To make this easier, DPDK is adpoting the use of a single line reference to Please do not use this tense in the README. We could say "DPDK uses" instead of "DPDK is adpoting the use". > +Unique License Identifiers in source files as defined by the Linux Foundation's > +SPDX project [1]. My preference is to insert URLs inline to make reading flow easier. > +Adding license information in this fashion, rather than adding full license > +text, can be more efficient for developers; decreases errors; and improves > +automated detection of licenses. The current set of valid, predefined SPDX > +identifiers is set forth on the SPDX License List[2] > +at https://spdx.org/licenses/. Here you are mixing inline and reference :) > +For example, to label a file as subject to the BSD-3-Clause license, > +the following text would be used: > + > +Copyright (C) [YEAR] NAME-OF-COPYRIGHT-HOLDER I think (C) is useless. About the YEAR, we should explicit what it is. I think it is only the first year, and we do not need to update the last year of update. We should also explicit why it is there and why it is not required to add more copyrights. The copyright is required to express who is allowed to declare the license of the code. It is a common practice to add a Copyright line when doing a big update. I think it is fair, but for small changes, it is really not required as we implicitly comply with the current copyright holder and license. > +SPDX-License-Identifier: BSD-3-Clause Why adding these spaces in the middle of the line? [...] > +Note: DPDK currently adhere to it's IP policies[3]. Any exception to this shall This sentence is strange. To me, it is obvious that DPDK adheres to its policies. Suggested rewording: Any exception to the DPDK IP policies shall... > +be approved by DPDK tech board and DPDK Governing Board. Steps for any exception > +approval: [...] > +Projects like U-boot have been been using SPDX License Idenfiers successfully > +[2]. They have been referered in implementing SPDX based guidelines in DPDK. I think you can remove this paragraph from the README. [...] > +DPDK project supported licenses are: > + > +Full name SPDX Identifier OSI Approved File name URI > +======================================================================================================================================= This table is large. I suggest to format it as a list: SPDX identifier full name file name URL > +GNU General Public License v2.0 only GPL-2.0 Y gpl-2.0.txt http://spdx.org/licenses/GPL-2.0.html#licenseText > +GNU Lesser General Public License v2.1 or later LGPL-2.1+ Y lgpl-2.1.txt http://spdx.org/licenses/LGPL-2.1.html#licenseText Later than LGPL-2.1 is not specified in the charter. Better to remove the "+". > +BSD 3-clause "New" or "Revised" License BSD-3-Clause Y bsd-3-clause.txt http://spdx.org/licenses/BSD-3-Clause#licenseText [...] > --- a/README > +++ b/README > @@ -1,8 +1,9 @@ > DPDK is a set of libraries and drivers for fast packet processing. > It supports many processor architectures and both FreeBSD and Linux. > > -The DPDK uses the Open Source BSD license for the core libraries and > -drivers. The kernel components are GPLv2 licensed. > +The DPDK uses the Open Source BSD-3-Clause license for the core libraries > +and drivers. The kernel components are GPLv2 licensed. DPDK usages s/GPLv2/GPL-2.0/ s/usages/uses/ > +SPDX Licenese identifiers instead of full license text in source files. s/Licenese/license/ I think it is not needed to mention SPDX in this README. [...] > --- a/doc/guides/contributing/patches.rst > +++ b/doc/guides/contributing/patches.rst > @@ -32,6 +32,42 @@ It is also worth registering for the DPDK `Patchwork The development process requires some familiarity with the ``git`` version control system. > Refer to the `Pro Git Book `_ for further information. > > +Source License > +-------------- > + > +The DPDK uses the Open Source BSD-3-Clause license for the core libraries and > +drivers. The kernel components are GPLv2 licensed. DPDK usaes single line s/GPLv2/GPL-2.0/ s/usaes/uses/ > +reference to Unique License Identifiers in source files as defined by the Linux > +Foundation's `SPDX project `_. > + > +For example, to label a file as subject to the BSD-3-Clause license, > +the following text would be used: > + > +Copyright (C) [YEAR] NAME-OF-COPYRIGHT-HOLDER > +``SPDX-License-Identifier: BSD-3-Clause`` > + > +To label a file as dual-licensed with BSD-3-Clause and GPL-2.0 (e.g., for code > +that is shared between the kernel and userspace), the following text would be > +used: > + > +Copyright (C) [YEAR] NAME-OF-COPYRIGHT-HOLDER > +``SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0`` > + > +To label a file as dual-licensed with BSD-3-Clause and LGPL-2.1 (e.g., for code > +that is shared between the kernel and userspace), the following text would be > +used: > + > +Copyright (C) [YEAR] NAME-OF-COPYRIGHT-HOLDER > +``SPDX-License-Identifier: BSD-3-Clause OR LGPL-2.1`` > + > +To label a file as GPL-2.0 (e.g., for code that runs in the kernel), the > +following text would be used: > + > +Copyright (C) [YEAR] NAME-OF-COPYRIGHT-HOLDER > +``SPDX-License-Identifier: GPL-2.0`` > + > +Any new file contributions in DPDK shall adhere to the above scheme. > +It is also being recommended to replace the existing license. No need to repeat everything in the guide. You can refer to licenses/README. +Cc John for doc review