On Wed, Jan 27, 2021 at 12:43:25PM +0100, Greg Kroah-Hartman wrote:

On Tue, Jan 26, 2021 at 08:08:01PM +0100, Bartosz Golaszewski wrote:

quoted

On Tue, Jan 26, 2021 at 6:11 PM Greg Kroah-Hartman
[off-list ref] wrote:

quoted

On Tue, Jan 26, 2021 at 04:07:47PM +0100, Bartosz Golaszewski wrote:

quoted

On Mon, Jan 25, 2021 at 6:55 AM Kent Gibson [off-list ref] wrote:

quoted

[snip!]

quoted

quoted

I don't like the ifdef hell so I prefer to bundle the header. I'm open
to other suggestions, although I can't come up with anything else.

Going off on a bit of a tangent, but I'm trying to add support for
decoding the GPIO ioctls into strace and am running up against a similar
issue.

The way strace does it is to check the uAPI header on the host and use
it if possible.  To handle where it may be stale, local types are
defined that mirror any types that may have been added since the header
was originally released.  If the corresponding type is available in the
linux header then it is used, else the local type.

This obviously creates a lot of pointless boilerplate code and
preprocessor chicanery so I floated the idea of just including the latest
header in the strace tree, as you are doing here for libgpiod.
But that raised the issue of licencing, specifically if you copy the
linux/gpio.h into a source tree does that mean that the whole project
becomes GPL 2.0?  That is an issue for strace as it is LGPL 2.1 - as is
libgpiod.

The Linux uAPI headers are under the GPL-2.0 WITH Linux-syscall-note,
which is also not totally clear on this point[1].

My gut feeling was that using and even copying API headers doesn't
constitute a derived work, as per the FSF view quoted in [1], and
ethically might even be less of a violation than copying and re-defining
individual types, but I'd rather not rely on a gut feeling.

Is there some clear opinion or precedent on this point?
i.e. are libgpiod and strace in legal licence jeopardy if they include
gpio.h in their source tree?

Cheers,
Kent.

[1] https://lkml.org/lkml/2020/2/21/2193

Thanks for pointing that out. I lack the legal knowledge to have an
opinion of my own on this.

Cc'ing Greg KH for help.

Greg: do you know if it's fine to bundle a 'GPL-2.0 WITH
Linux-syscall-note' uAPI header together with an LGPL-v2.1-or-later
user-space shared library?

How would you "bundle" such a thing as that is not what is in the kernel
source tree?  If you are going to copy files out of the kernel and do
other things with them, well, I recommend asking a lawyer as I am not
one :)

good luck!

greg k-h

By "bundling" I mean - copying the kernel uAPI header verbatim from
the kernel tree into the project repository. The reason for that is
the fact that always relying on the toolchain kernel headers leads to
build issues if we want to support more recent kernel features in the
library while the supplied headers don't define all required symbols.

We can either make the latest supported version of linux headers a
hard requirement for building (I did that and buildroot folks yelled
at me because two stable versions of the library had different kernel
headers requirements) or redefine certain symbols (new symbols since
the oldest supported kernel version) or - and this is preferred unless
it's against the linux license - include the kernel headers in the
source tarball of the library.

I hope this is not a stupid question but obviously I don't know any
lawyer well versed in software copyright: can we direct this question
to anyone at the Linux Foundation maybe?

Ok, first off, I am not a lawyer so don't take legal advice from me.

But, if you copy the .h file directly, and keep the same license on the
file, that should be fine as you would be using it under the "GPLv2 with
syscall note" license for your userspace program, right?

So there shouldn't be an issue there that I can determine, as we want
userspace programs to be free to use those headers to interact with the
kernel.

It's come up in the past that we might want to somehow make this much
more obvious, and we have talked about this with the legal community,
but that's only in the context of making it more obvious that we want
people to write programs of any license to talk to the kernel, not that
we would want to keep anyone from doing that :)

thanks,

greg k-h

Including Dmitry as he orignally raised the issue and has an interest in
its resolution.

Greg: thanks for providing your view.  You may not be a lawyer (which is
a very good thing, btw), but your opinion carries a lot of weight, and
combined with what we already knew I think we're on very solid ground
distributing the kernel headers in the libgpiod and strace repositories.

Bart and Dmitry: I submit that we are good to copy the headers into the
repositories, but we should take a few steps just to make clear that we
are in full compliance with the GPL v2.

Firstly, we are distributing the headers under Section 1 (distribution)
of the GPL, so we should keep the headers in a separate directory that
contains its own COPYING file as well as the GPL v2 and Linux syscall note
- unless they are already available elsewhere in the repo.

The headers must be copied verbatim so as to not trigger Section 2
(modification).  And it is probably good to include in the commit
comment what kernel version or commit they were drawn from so that can
be easily confirmed.

Section 3 still doesn't apply, as any resulting object code or
executables are no more a derived work due to the availability of the
header than they were previously.  And I don't think anyone is claiming
that the repo itself is a derived work - in this context it is just a
distribution medium.

The COPYING file, or equivalent, for the project should explicitly
exclude any claim on the kernel header directory to make clear we are
not trying to sublicense the headers as LGPL - which could breach
Section 4.

Other than those points, I don't see anywhere we may be in breach.

As with Greg, IANAL so this is not legal advice.  Feel free to
disregard any or all of the above if you still consider the legal
standing uncertain or too risky.

Cheers,
Kent.