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.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, 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 BB820C43331 for ; Tue, 31 Mar 2020 15:49:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 89CCB20848 for ; Tue, 31 Mar 2020 15:49:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1585669762; bh=cKeBnZ340s/3Wc8cYt7l64sbcQ/n5gd0b1gXKRjgmNE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=SmrYtqumHPSgcyXE+60LSVxNZ8GUP8ePAm54bD3ZPBBEJXX5QE0hnaI6qsW/YlaRZ WaMAWCeHDER86CVjQZJ2WCyTocGWYlKcFK4TMM2zUNnIsAU6PBAdIYx/pCTj5fdrtc 1PrP3HLLV8fkBzI7pVgTetpkwz7Gp0c5zFGxql68= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730562AbgCaPtW (ORCPT ); Tue, 31 Mar 2020 11:49:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:50158 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730105AbgCaPtV (ORCPT ); Tue, 31 Mar 2020 11:49:21 -0400 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 Cc: Linux Media Mailing List , Sakari Ailus , Maxime Ripard , Chen-Yu Tsai , Ezequiel Garcia , Philipp Zabel , Greg Kroah-Hartman , Helen Koike , linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, devel@driverdev.osuosl.org 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.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 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.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,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 539EBC43331 for ; Tue, 31 Mar 2020 15:49:27 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (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 28FE520781 for ; Tue, 31 Mar 2020 15:49:27 +0000 (UTC) Authentication-Results: mail.kernel.org; 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 28FE520781 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 0252E86B9E; Tue, 31 Mar 2020 15:49:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbOz_9JWUNvR; Tue, 31 Mar 2020 15:49:25 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by fraxinus.osuosl.org (Postfix) with ESMTP id 13F1986A85; Tue, 31 Mar 2020 15:49:25 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by ash.osuosl.org (Postfix) with ESMTP id 68CC11BF831 for ; Tue, 31 Mar 2020 15:49:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 643D9227FF for ; Tue, 31 Mar 2020 15:49:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNVUUeYy62YJ for ; Tue, 31 Mar 2020 15:49:21 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by silver.osuosl.org (Postfix) with ESMTPS id 4F57821551 for ; Tue, 31 Mar 2020 15:49:21 +0000 (UTC) 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-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List 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 Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" 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 _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mauro Carvalho Chehab Subject: SPDX headers - Was: Re: [PATCH v4 17/33] media: add SPDX headers on Kconfig and Makefile files Date: Tue, 31 Mar 2020 17:49:14 +0200 Message-ID: <20200331174914.2789865e@coco.lan> References: <981eea64742859c63d8ab88c24b1b3380ee32dd2.1585651678.git.mchehab+huawei@kernel.org> <20200331120608.GB4767@pendragon.ideasonboard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20200331120608.GB4767@pendragon.ideasonboard.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane-mx.org@lists.infradead.org To: Laurent Pinchart 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 List-Id: linux-rockchip.vger.kernel.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 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