License compatitlbe with btrfs-progs?

[jackhill]

Hi,

Thank you for licensing BEES as GPLv3 or later. However, I wonder if that's possble while linking against btrfs-progs which, at least looking at its ioctl.h appears to be GLPv2 only.

Best, Jack

[kakra]

I don't think it links against btrfs-progs:

# lddtree /usr/libexec/bees
bees => /usr/libexec/bees (interpreter => /lib64/ld-linux-x86-64.so.2)
    libuuid.so.1 => /usr/lib64/libuuid.so.1
        ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
    libpthread.so.0 => /usr/lib64/libpthread.so.0
    libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libstdc++.so.6
    libm.so.6 => /usr/lib64/libm.so.6
    libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libgcc_s.so.1
    libc.so.6 => /usr/lib64/libc.so.6

And even when it would probably be a non-issue as a lot of programs under a vast amount of different libraries link to different libraries in Linux at runtime. Only the service wrapper script calls into btrfs-progs - but that's technically not linking.

But bees needs headers from btrfs-progs to call the kernel API properly. But is that technically linking? Aren't header files there to provide an API for other software without statically linking their libraries or without integrating their source code as a sub project?

Here's a question on Stack Exchange: https://opensource.stackexchange.com/questions/6451/using-a-gpl-header-in-a-closed-source-program

The accepted answer quotes:

NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work".

Bees doesn't link to btrfs-progs, it just uses headers from it to call the kernel APIs. Thus it would not be considered derived work of btrfs-progs, or does it? After all, headers/includes can contain code (e.g., inline functions) or defines with code snippets that would be linked into the final product.

This answer additionally states:

Under normal circumstances, using a header file from a GPL-licensed project in your own project means that your code is considered to be a "derived work" of the GPL-licensed code and that you must use a GPL-compatible license when distributing your project

I think GPLv3 and GPLv2 would be compatible in that sense ("must use a GPL-compatible license"), right? So even if bees would be considered derived work, it still uses a GPL-compatible license.

[jackhill]

Yes, you're right, I was confused. Sorry about that. Thanks for taking the time to explain and help me out of my confusion. I agree that the situtation is not problematic.

[Zygo]

I tried switch bees to use the Linux kernel headers (which are GPLv2 with syscall note, and can be combined with any other license) instead of the libbtrfs-dev headers (which are GPLv2 with no exception I can find, and are not compatible with GPLv3).

It turns out the Linux kernel headers are better, so I'm keeping them. Linux kernel headers are C++ compatible (no #undef crc32c needed). The btrfs_stack_* macros broke the buffer size/length checks in get_struct_ptr back in 2016, and I didn't get around to fixing it until now.

[Zygo]

The code in question has been removed, making the license compatibility issue (if there ever was one) moot.