From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E30AC2D0EE for ; Tue, 31 Mar 2020 15:49:25 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E7E9920848 for ; Tue, 31 Mar 2020 15:49:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="r0UuuVcZ"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="izv08sg0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E7E9920848 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=B6f167xCubs2FKTfgGNfoggzEf0hJOs59PLKYK9dpck=; b=r0UuuVcZlL2ZUx q3T6qY84Z4yN+3cAGHS/SWyAjp7t5ZXVXWF1N6vZvqeXhwz3YCblM2z5r4wb9zFNq/l9LkAJN5qQq 5zuZu7l/lFVtdjP0F/xyw3AS6cfWitxMM2BXunJfkqB7e8mmnUeo8wkWkPEWuxOrPJQnlMXQClFp2 8TPMrUxWwx5Jcz90XVGi38rIqCcDfiTt8TVB1xY0bml5xQ0S0hQVtwulAlhCdo77LnOE/PXE09cqg ERqJRY+Ib1D7QCK67UdMwjTXVKPq/f4sO/yqSVBvJyxgNkO8vJKQtqYTzx7NATFSpoD+jbrgVh03V XTtTw+CUW6A/Gk72bHbw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jJJ8m-0007FU-Fg; Tue, 31 Mar 2020 15:49:24 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jJJ8j-0007ED-Hh; Tue, 31 Mar 2020 15:49:23 +0000 Received: from coco.lan (ip5f5ad4d8.dynamic.kabel-deutschland.de [95.90.212.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1BAA820714; Tue, 31 Mar 2020 15:49:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585669761; bh=cKeBnZ340s/3Wc8cYt7l64sbcQ/n5gd0b1gXKRjgmNE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=izv08sg0h7mu5Q67SxYzpInzivHyMXQgCJmjriTyA5M+yN9kIKLtMMz5m0pwqjMyP Co3XN1kwF5Hm+QRdHZMabF2mQOOXk+jKicqGsxvZMYUwP78rv5FOvL04PqWbuV9FpS J7bcmM/s3z5tL9db5p6M0e2eJ7yANt3L7add1dGg= Date: Tue, 31 Mar 2020 17:49:14 +0200 From: Mauro Carvalho Chehab To: Laurent Pinchart Subject: SPDX headers - Was: Re: [PATCH v4 17/33] media: add SPDX headers on Kconfig and Makefile files Message-ID: <20200331174914.2789865e@coco.lan> In-Reply-To: <20200331120608.GB4767@pendragon.ideasonboard.com> References: <981eea64742859c63d8ab88c24b1b3380ee32dd2.1585651678.git.mchehab+huawei@kernel.org> <20200331120608.GB4767@pendragon.ideasonboard.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200331_084921_624923_95CE5392 X-CRM114-Status: GOOD ( 14.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devel@driverdev.osuosl.org, Sakari Ailus , Greg Kroah-Hartman , Helen Koike , Maxime Ripard , linux-rockchip@lists.infradead.org, Chen-Yu Tsai , Philipp Zabel , Ezequiel Garcia , linux-arm-kernel@lists.infradead.org, Linux Media Mailing List Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Em Tue, 31 Mar 2020 15:06:08 +0300 Laurent Pinchart escreveu: > I've however been thinking about licenses for > build system files recently, and I'll hijack this thread a bit to ask a > question :-) Ok, I'll change the subject, as the answers won't be related to the Kernel :-) > For a project like the Linux kernel, and especially for subsystems that > are covered by a single license, the choice is easy, we can apply the > same license to the build files. However, for a project that contains > components covered by different licenses (such as, for instance, an LGPL > library, a GPL application and a BSD plugin), how should the license > covering the build system files be selected ? I searched a bit for > guidance on this topic, and couldn't find much. Then everything becomes a way more complex :-) I guess nobody has a clear answer for that. Also, IANAL. What I can tell is what it would makes sense for me. The big impact of a complex licenses model would be for the ones packaging it on some distro, and for the users of such distros. The distros need to know if they have the rights to redistribute, and need to notify their usages about each package's license. Let's assume a project "foo-utils" that has such complexity. Assuming a project that started on a green field (like libcamera), and such project doesn't use stuff from external libraries, what one could do would be to design it in a way that different licenses would be packaged differently. For instance: foo-libs # everything here is under LGPL foo-bsd-plugin # everything here is under BSD foo-utils # everything here is under GPLv3 Then, on each of them, a COPYING.foo file (or whatever other way distros would use to identify the per-package license) would contain the license with applied to it. Btw, if you want to take a look on a real-case scenario, see, for example: https://build.opensuse.org/package/view_file/devel:libraries:c_c++/v4l-utils/v4l-utils.spec?rev=a250bff0f849e8c2fa7e476a1f2849a8 %package -n libv4l-devel License: LGPLv2+ ... %package -n qv4l2 License: GPLv2+ Btw, GStreamer actually follows a similar approach, but they even split those into different git trees (core, good, bad and ugly plugins). Thanks, Mauro _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel