Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 14:10 UTC (Mon) by viro (subscriber, #7872)
Parent article: Has Bionic stepped over the GPL line?

FWIW, after looking through their headers for a while I would say that

1) they are close to staying within the things provided by make headers_install; if anything, they tend to strip more definitions.

2) the chief difference is that they pick some garbage from files that lost #ifdef __KERNEL__ when they had been excluded wholesale by */Kbuild mechanism. What they pick is blatantly useless for anything that might use libc and ought to be removed on technical grounds - it's a pure namespace pollution for everything that includes these headers (see below)

3) potential for userland disruption from such removal is very low - AFAICS, their headers do not include those and neither do the kernel headers they do need. In other words, the program would have to explicitly ask for including one of those files. While that is not impossible, resulting breakage will be very visible and the fix will be "so remove that #include, dummy".

4) for a long time _all_ libc implementations had been encouraged to take copies of kernel headers and strip out the kernel-only parts. make headers_install is a technically superior solution that appeared circa 2006. When did development of Bionic libc begin, again? Mid-2000s? If so, they simply followed the common practice for that time.

5) It was *NEVER* intended to force e.g. glibc into GPLv2. Even before 2006. Really. If somebody wants to try and claim in court that their contribution to the kernel had been made with intention to put every distribution out there into copyright violation, I would expect the court taking very dim view of their actions. As for the reaction of kernel *and* userland developers... <shudder>

6) Claim by Bionic libc developers they just followed the common practice, directly sanctioned by Linus and followed by every distribution out there would probably be very hard to reject.

7) (1)--(3) is based the impression from looking through their headers. I have not done an exhaustive analysis of all that pile - I have better uses for my time and what I have seen makes it very unlikely that anything in there would be non-trivial to fix or that switch to make headers_install output as fodder for their script would cause breakage for code using their libc. I agree with bkuhn - the odds are very low.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 16:04 UTC (Mon) by jwildeboer (guest, #55642) [Link]

Thanks for bringing some factual coolness to this :-)

4) for a long time _all_ libc implementations had been encouraged to take copies of kernel headers and strip out the kernel-only parts.

Encouraged as in "discussed on LKML" or "obvious to all in the kernel community"? Just to make sure that TheFlorian doesn't start another campaign on this ;-)

Jan Wildeboer (Red Hat. Evangelist. Nuff said)

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 16:23 UTC (Mon) by swetland (guest, #63414) [Link] (1 responses)

Bionic development started in late 2005 / early 2006, iirc. We explored a number of alternatives before settling on "BSD-libc-based with homegrown syscall and thread glue" which has worked pretty well.

The scripted processing of headers is a result of hand-curation of headers not scaling well. The goal is (obviously, I thought!) to extract the necessary userspace interface to the kernel without picking up internal-only or incompatible-with-userspace headers or subsections. At the time we got started it appeared that other libc projects were mostly doing this by hand.

We'll want to take a look at exclusion methods used by "make headers_install" -- if they provide a way to further reduce the scope of exported headers that's definitely interesting.

We strongly discourage the use of #include <linux/...> in Android userspace code, unless it's code that's directly talking to a kernel interface defined in that space -- primarily to keep things clean and reasonably portable.

Has Bionic stepped over the GPL line?

Posted Mar 21, 2011 17:01 UTC (Mon) by viro (subscriber, #7872) [Link]

See include/Kbuild, include/linux/Kbuild, etc. Or just git grep header-y.
That's what gives the list of headers being exported. As for the rest - trimming is done by scripts/headers_install.pl, all of a screenful of it...

Has Bionic stepped over the GPL line?

Posted Mar 25, 2011 22:53 UTC (Fri) by ccurtis (guest, #49713) [Link]

Ignoring for a moment that this is expressly permitted, it seems like the concern is this:

The kernel provides two de-facto outputs: (1) a GPL-covered kernel, and (2) "Headers for libc implementations".

From a commercial standpoint this is akin to a free version and paid release (or a dual-licensed release). That one is generated by "just a script" is immaterial. What's relevant is that two independent artifacts are created.

Now, Google, instead of using the official "Headers for libc" wrote their own script. This script could have been 'cat' or anything else - what is material is that the copyright notices are stripped. Normally, I think everyone agrees that it is wrong to strip the copyright from a file whether it's a C file, an H file, or GPL-licensed documentation.

So: wouldn't it be easier to update the "official" script, bundled with the kernel sources, to replace the copyright notice in the generated headers with an express lack of copyright notice? If these headers are not GPL covered, clearly they shouldn't say that they are. Right?