Subject: SPDX headers - Was: Re: [PATCH v4 17/33] media: add SPDX headers on Kconfig and Makefile files

From: Mauro Carvalho Chehab <[email-masked]>
Date: Tue, 31 Mar 2020 17:49:14 +0200

Em Tue, 31 Mar 2020 15:06:08 +0300
Laurent Pinchart <[email-masked]> 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
[email-masked]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel